The Bluetooth® Mesh Networking Primer

1. Revision History

Version	Date	Author	Changes
1.0.0	19 January 2019	Martin Woolley, Bluetooth SIG	Initial version
1.1.0	16 May 2024	Martin Woolley, Bluetooth SIG	Updated to include key features of Bluetooth Mesh 1.1 and Bluetooth Networked Lighting Control (NLC)

2. About this paper

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

It is not the aim of this paper to reproduce or cover 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 Mesh Networking concepts, pointing the way to other resources and specifications and hopefully, making the learning curve a little bit less steep.

3. Introduction

3.1 The Evolution of Bluetooth technology

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. This first version of Bluetooth technology, used in those very first ever Bluetooth products is known formally as Bluetooth BR (Basic Rate) and operates at one million bits[1] per second (Mb/s) at the physical layer. It was followed by a faster version of the same technology which doubled the bit rate to 2 Mb/s called Bluetooth BR/EDR where EDR stands for Enhanced Data Rate.

Bluetooth LE first appeared in Bluetooth Core 4.0[2]. 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 broadcast mode which allows one device to transmit data to an unlimited number of receivers simultaneously.

Bluetooth LE 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.

3.2 Bluetooth Mesh Networking

Bluetooth Mesh Networking was created to provide a secure, scalable and standardized wireless communication technology that can be applied to the problems and opportunities of commercial buildings.

Networked Lighting Control (NLC) is a key application for Bluetooth Mesh Networking and both manual and automated lighting control across physically large spaces is made possible.  An individual light or a group of lights can be acted upon in a single network operation.

Here are a few of the key things that are possible with networked lighting control based on a Bluetooth Mesh network.

• They can be switched on and off.
• Their brightness (more accurately termed lightness) can be controlled along a perceptually uniform scale that compensates for the varying sensitivity to light of the human eye.
• Color temperature, hue and saturation can be modified.
• Sensors can deliver information about more or less any measurable property of a room to relevant lights so that their state can be automatically adjusted in response to the environmental conditions. Note that Bluetooth Mesh Networking does not require a centralized router to exchange messages between the sensors and lights.
• Arbitrary collections of certain state values known as scenes can be defined and lights can switch from one scene to another at a single request.
• Scene changes affecting groups of lights can be scheduled to take place automatically at specific points in time.
• Allows the automatic triggering of scenes based on room occupancy and the automatic transition to a standby state when there are no occupants. This helps in saving energy.
• Supports the ability to set predefined schedules for changing the states of lights.
• Supports the concept of vendor models which allow manufacturers to add additional features to their devices when needed.

Control over lights in a network is not limited by the range of direct wireless communication. A device like a switch or a sensor can exercise control over lights that are located in the far distant reaches of a building, perhaps tens of floors above.

Security was designed into Bluetooth Mesh Networking technology from the start, and it addresses potential issues and threats including:

• safeguarding the confidentiality of information
• preventing devices from being tracked through device and network privacy mechanisms
• preventing the manipulation of network control messages
• constraining actions of devices to specific parts of the network only
• preventing replay attacks
• ensuring the addition of devices to the network is subject to a secure process
• ensuring devices can be securely removed from the network without any risk that discarded devices can be used to gain unauthorized access at a later time
• offering the ability to provide and revoke guest access to relevant functionalities in the network without compromising security of larger network.

Buildings that are equipped with a Bluetooth Mesh network and wireless Networked Lighting Control enjoy a range of benefits.

• They become more energy efficient, with sensors delivering data about ambient light levels and room occupancy which can be automatically used to adjust lighting levels.
• Lighting can be reconfigured at the touch of a switch or smartphone application user interface (UI) to be optimized for a room’s current use, be it presentation or large company round-table meeting.
• Proactive maintenance is facilitated by the usage and device health data that  devices that support Bluetooth Mesh Networking can make available.
• Changes to physical layout and lighting requirements in a building are more easily brought about. It’s wireless!
• Bluetooth Mesh Networking technology is defined by a series of standard specifications that span the full protocol stack and the behaviors, capabilities and interfaces to devices. This means that compliant products from any mix of manufacturers will be interoperable. Adopters of Bluetooth Mesh Networking technology are not locked into a single manufacturer or small, closed group.

4. Key Features and Concepts

Understanding Bluetooth Mesh Networking topology requires the reader to learn about a series of fundamental features, technical terms and concepts that are not found anywhere else in the world of Bluetooth LE. In this section, we’ll explore the most fundamental of these features, terms and concepts.

4.1 Bluetooth Operational Modes

Bluetooth LE defines a number of different ways which devices can communicate with each other. They are formally defined in the Bluetooth Core Specification and informally referred to as “operational modes” in this paper.

The various operational modes differ in a number of ways including the topology formed by the devices, the direction of communication which is possible and the underlying technicalities of the mode such as whether it is a connection-oriented or connectionless mode.

In connection-oriented communication the devices first exchange information which allows them to agree important aspects of the subsequent communication such as transmit and receive timing parameters. In connectionless communication, this does not happen and transmit and receive timings are not pre-agreed in the same way. In Bluetooth LE, connection-oriented communication always takes place between exactly two devices whereas connectionless communication can be used by one transmitting device to communicate with multiple receiver devices, with or without some degree of pre-agreed information about the parameters.

Topology is concerned with the cardinality of the relationships which may be formed between communicating devices. Three distinct topologies are recognized:

• one-to-one (1:1)
• one-to-many (1:m)
• many-to-many (m:n)

Some operational modes allow communication of application data in one direction only whereas others allow bidirectional communication.

Some modes use a precisely regular schedule for the transmission of packets and in other cases, it is irregular.

Seven operational modes are currently defined. They are as follows:

• LE Asynchronous Connection-oriented Logical transport (LE ACL)
• LE Advertising Broadcast (ADVB)
• Periodic Advertising (PADVB)
• Periodic Advertising with Responses (PAwR)
• Connected Isochronous Stream (CIS)
• Broadcast Isochronous Stream (BIS)
• Channel Sounding (CS)

The Bluetooth Core Specification defines each mode in detail.

Table 1 summarizes the key attributes of the seven operational modes for the purpose of comparison. Note that Channel Sounding (CS) is a special mode which is designed to support the secure calculation of the distance between two devices only and is not used for the transfer of application data.

Operational Mode	Connection-Oriented or Connectionless	Topology	Transmit Schedule	Direction of Application Data
LE ACL	connection-oriented	point-to-point	regular	bidirectional
ADVB	connectionless	one-to-many	irregular	unidirectional
PADVB	connectionless	one-to-many	regular	unidirectional
PAwR	connectionless	one-to-many	regular	bidirectional
CIS	connection-oriented	point-to-point	regular	bidirectional
BIS	connectionless	one-to-many	regular	unidirectional
CS	N/A	one-to-one	regular	N/A

Table 1 – Attributes of Bluetooth Operational Modes

Bluetooth Mesh Networking technology is not an operational mode. It’s a protocol with a series of defined procedures, standard application-layer behaviors, and other features which make it possible to use Bluetooth LE as a wireless networking technology. It builds upon core capabilities of Bluetooth LE including several of the operational modes so that at times it is acting in a connectionless way and at other times using connection-oriented communication. In principle, the topology formed by a Bluetooth Mesh network is many-to-many since any device may potentially communicate with any other device and communication of application data can occur in either direction.

Communication is achieved using messages which are transported by Bluetooth LE in a suitable way using a mechanism called a bearer which is based upon one of the operational modes. Devices are able to relay messages to other devices right across the network so that the end-to-end communication range is extended far beyond the radio range of each individual mesh device.

4.2 Devices and Nodes

Devices which are part of a mesh network are called nodes and those which are not are called unprovisioned devices.

The process which transforms an unprovisioned device into a node is called provisioning.

Provisioning is a procedure which results in an unprovisioned device possessing a series of security keys, having a unicast address assigned to it and being listed in a database on a device known as the Provisioner. The Provisioner is typically a tablet or smartphone.

4.3 Elements

Some nodes have multiple constituent parts, each of which can be independently controlled. In Bluetooth Mesh Networking terminology, these parts are called elements. Figure 1 shows an LED lighting product which if added to a Bluetooth Mesh network, would form a single node with three elements, one for each of the individual LED lights.

Figure 1 – Lighting node consisting of three elements

4.4 Messages

When a node needs to query the status of other nodes or needs to control other nodes in some way, it sends a message of a suitable type. If a node needs to report its status to other nodes, it sends a message. All communication in the mesh network is message-oriented and many message types are defined, each with its own unique opcode.

Messages fall within one of two broad categories:

• Acknowledged messages require a response from nodes that receive them. The response serves two purposes: it confirms that the message it relates to was received, and it returns data relating to the message recipient to the original message sender. The sender of an acknowledged message may resend the message if it does not receive the expected response(s) and therefore, acknowledged messages must be idempotent. This means that the effect of a given acknowledged message, arriving at a node multiple times, will be the same as if it had only been received once.
• Unacknowledged messages do not require a response.

Most Bluetooth Mesh Networking scenarios involve the use of unacknowledged messages since this model of messaging scales very well. It is made reliable by configuring nodes to retransmit copies of messages multiple times in quick succession.

Messages that require acknowledgements to be returned work well when the target is a single device but do not scale well when targeting a group of multiple devices. Most messages that are involved in configuring a node or its elements use acknowledged messages.

A system known as relaying allows messages to be delivered beyond the immediate radio range. Relaying is explained in 4.19 Message Relaying.

4.5 Addresses

Messages must be sent from and to an address. Bluetooth Mesh Networking defines three types of address.

A unicast address uniquely identifies a single element. A unicast addresses is assigned to a device during the provisioning process.

A group address is a multicast address. This address type allows more than one device to receive the same transmitted message through a process called publish and subscribe. Group addresses are either defined by the Bluetooth SIG and are known as Fixed Group Addresses or are assigned dynamically. Seven SIG Fixed Group Addresses have been defined. These are named all-nodes, all-relays, all-friends, all-proxies, all-directed-forwarding-proxies, all-ipt-nodes and all-ipt-border-routers. The terms Proxy, Friend and Relay will be explained later in this paper.

It is expected that dynamic group addresses will be established by the user via a configuration application and that they will reflect the physical configuration of a building, for example defining group addresses which correspond to each room in the building.

A virtual address is similar to a group address in that it allows a single transmitted message to be received by multiple devices through publish and subscribe. It takes the form of a 128-bit UUID value with which any element can be associated and is much like a label. For example, virtual addresses can be preconfigured at the point of manufacture and used for scenarios such as allowing the easy addressing of all meeting room projectors made by the manufacturer that are deployed in a mesh network.

4.6 Publish / Subscribe

The act of sending a message is known as publishing. Nodes are configured to receive only those messages that were sent to specific addresses for processing, and this is known as subscribing.

Typically, messages are addressed to group or virtual addresses. Group and virtual address names will have readily understood meaning to the end user, making them easy and intuitive to use when configuring devices.

In Figure 2, we can see that the node named Switch 1 is publishing to the group address Reception. Nodes Light 1, Light 2 and Light 3 each subscribe to the Reception address and therefore process messages published to this address. In other words, Light 1, Light 2 and Light 3 can be switched on or off using Switch 1.

Switch 2 publishes to the group address Accounts.  Light 3 alone subscribed to this address and so is the only light controlled by Switch 2. Note that this example also illustrates the fact that nodes may subscribe to messages addressed to more than one distinct address. This is both powerful and flexible.

Similarly, notice how both Switch 5 and Switch 6 publish to the same Underwriting address.

The use of group and virtual addresses with the publish/subscribe communication model has an additional benefit in that removing, replacing or adding new nodes to the network does not require reconfiguration of other nodes. Consider what would be involved in installing an additional light in the accounts department. The new device would be added to the network using the provisioning process and configured to subscribe to the Accounts address. No other nodes would be affected by this change to the network. Switch 2 would continue to publish messages to Accounts as before but now both Light 3 and the new light would respond.

Figure 2 – Publish and Subscribe

4.7 States and Properties

Elements can be in various conditions, and this is represented in Bluetooth Mesh Networking by the concept of state values.

A state is a value of a certain type, contained within an element and one of its models – see below). States also have associated behaviors and may not be reused in other contexts.

As an example, consider a simple light which may either be on or off. Bluetooth Mesh Networking defines a state called Generic OnOff. The light would possess this state and a value of On would correspond to and cause the light to be illuminated, whereas a Generic OnOff state value of Off would cause the light to be switched off.

The significance of the term Generic will be discussed later.

Properties are similar to states in that they contain values relating to an element.  But they are different to states in other ways.

Readers who are familiar with Bluetooth LE[3] will be aware of characteristics and recall that they are data types with no defined behaviors associated with them, making them reusable across different contexts such as within different GATT services. A mesh property provides the context for interpreting a characteristic in a  device that supports Bluetooth Mesh Networking.

To appreciate the significance and use of contexts as they relate to properties, consider for example, the characteristic Temperature 8, an 8-bit temperature state type which has a number of associated properties, including Present Indoor Ambient Temperature and Present Outdoor Ambient Temperature. These two properties allow a sensor to publish sensor readings in a way that allows a receiving client to determine the context the temperature value has, making better sense of its true meaning.

4.8 States and Fundamental Operations

Messages are the mechanism by which operations that act upon mesh devices are invoked. A given message type defines an operation on a state or a collection of state values. All messages are of three broad types, reflecting the types of operation which Bluetooth Mesh supports. The shorthand names for the three types are GET, SET and STATUS.

GET messages request the value of a given state from one or more elements. A STATUS message is sent in response to a GET and contains the relevant state value.

SET messages change the value of a given state. An acknowledged SET message will result in a STATUS message being returned in response to the SET message whereas an unacknowledged SET message requires no response.

STATUS messages are sent in response to GET messages, acknowledged SET messages or independently of other messages, perhaps driven by a timer running on the element sending the message, for example.

Specific states referenced by messages are inferred from the message opcode. Properties on the other hand, are referenced explicitly in generic property related messages using a 16-bit property ID.

4.9 State Transitions

Changes from one state to another are called state transitions. Transitions may be instantaneous or execute over a period of time called the transition time. A state transition is likely to have an effect on the application layer behavior or appearance of a node.

4.10 Bound States

Relationships may exist between states whereby a change in one triggers a change in the other. Such a relationship is called a state binding. One state may be bound to several other states.

For example, consider a light controlled by a dimmer switch. The light could possess the two states, Generic OnOff and Generic Level with each bound to the other. Reducing the brightness of the light until Generic Level has a value of zero (fully dimmed) results in Generic OnOff transitioning from the On state to the Off state.

4.11 Models

Models pull the preceding concepts together and define combinations of state data and associated message types and functionality in much the way that a class or object does in object-oriented software development.

A model is typically either a server model or a client model.

• A server model defines a collection of states, state transitions, state bindings, and messages which the element containing the model may send or receive. It also defines behaviors relating to the supported messages, states and state transitions.
• A client model does not define any states. Instead, it defines the messages which it may send or receive in order to GET, SET or acquire the STATUS of states defined in the corresponding server model.

Models may be created by extending other models. A model which is not extended is called a root model.

Models are immutable, meaning that they may not be changed by adding or removing behaviors. The correct and only permissible approach to implementing new model requirements is to extend the existing model.

Foundation Models are those models that are required to configure and manage a mesh network. Other models are concerned with the specific types of functionality as might be required by certain classes of product.

4.12 Generics

It is recognized that many different types of device, often have semantically equivalent states, as exemplified by the simple idea of ON vs OFF. Consider lights, fans and power sockets, all of which can be switched on or turned off.

Consequently, the Bluetooth Mesh Model specification defines a series of reusable, generic states such as Generic OnOff and Generic Level.

Similarly, a series of generic messages that operate on the generic states are defined. Examples include Generic OnOff Get and Generic Level Set.

Generic states and generic messages are used in generalized models, both generic server models such as the Generic OnOff Server and generic client models such as the Generic Level Client.

Generics allow a wide range of device type to support Bluetooth Mesh Networking without the need to create new models. Remember that models may be created by extending other models too. As such, generic models may form the basis for quickly creating models for new types of devices.

Figure 3 – Generic Models

4.13 Scenes

A scene is a stored collection of states which may be recalled and made current in response to receiving a special type of message or at a specified scheduled time. Scenes are identified by a 16-bit Scene Number, which is unique within the mesh network.

Scenes allow a series of nodes to be set to a given collection of previously stored, complimentary states in one coordinated action.

Imagine that in the morning you like the temperature in your reception area to be 20 degrees Celsius, the LED lights to be at a certain brightness level and the lamp on the receptionist’s desk set to a nice warm yellow hue. Having manually set the various nodes in this example scenario to these states, you can store them as a scene using a configuration application and recall the scene later on, either on demand by sending an appropriate, scene-related mesh message or automatically at a scheduled time.

4.14 Networks and Subnets

A Bluetooth Mesh network is defined by a set of four common resources – address space, network keys and application keys, and IV index. A Bluetooth Mesh network can be subdivided into a series of subnets. Unlike networks based on protocols such as TCP/IP, belonging to a particular network does not relate in any way to the address of the device. Instead, Bluetooth Mesh network and subnet membership is achieved largely through issuing a node with a network key (see 4.15 Keys). An element can be issued with multiple network keys and therefore be a member of more than one subnet. Subnets can be completely separate from each other, or they may overlap or be fully contained within another subnet.

Subnets have a number of uses including:

• Adding security to the network by isolating one group of devices from other, unrelated devices.
• Radio spectrum use can be made more efficient by preventing the flow of messages beyond the boundary of the subnet.
• Making network management easier. For example, a “guest device” can be given temporary access to a small part of the network using a subnet and its network key.

Figure 4 depicts subnets used for each guest room in a hotel.

One subnet is designated the primary subnet. Devices that are expected to be permanent members of the network are made members of the primary subnet.

Figure 4 – an example of subnets being used to isolate devices in each room in a hotel

4.15 Keys

The Bluetooth Mesh Protocol specification defines several types of security key.

• Each node has a unique device key (DevKey). Only the device to which it is issued and the Provisioner know this key value. This key is used to make the configuration process secure.
• A device is issued with at least one shared network key (NetKey). This type of key secures communication at the network layer. Possession of a particular NetKey makes a node part of the associated network or subnet. A special key called the primary NetKey relates to the primary mesh network.
• A mesh network has at least one application key (AppKey). Examples of applications that the network supports might include lighting, air conditioning, or heating. An AppKey is used to secure communication at the Upper Transport Layer and has the effect of partitioning messaging between different applications from a security perspective.

A device key and the primary network key are provided to each node during the provisioning process (see 4.16 Provisioning). Application keys and if required, further network keys corresponding to subnets are issued to a device during configuration (see 4.17 Configuration).

4.16 Provisioning

Provisioning is the process by which a device joins the mesh network and becomes a node. It involves several stages, results in various security keys being generated and is itself a secure process.

Provisioning is usually accomplished using an application on a device such as a smartphone or tablet. Other architectures (e.g. cloud-based provisioning) are possible. In this capacity, the device used to drive the provisioning process is referred to as the Provisioner and the device being provisioned, the Provisionee.

A Provisioner can provision a device that is in direct radio range. An optional feature known as Remote Provisioning makes it possible to provision a device that is located anywhere within the network, at any distance from the Provisioner.

4.16.1 Direct Provisioning

The direct provisioning process progresses through five steps, and these are described next.

Step 1. Beaconing

An unprovisioned device indicates its availability to be provisioned by broadcasting an Unprovisioned Device beacon. This is indicated by the inclusion of a Mesh Beacon advertising data (AD) type in the advertising packet payload field.

The user might need to start a new device advertising in this way by pressing a button, for example.

Step 2. Invitation

In this step, the Provisioner sends an invitation to the Provisionee, in the form of a Provisioning Invite PDU. The beaconing Provisionee device responds with information about itself in a Provisioning Capabilities PDU.

Step 3. Exchanging Public Keys

The Provisioner and the Provisionee, exchange their public keys, which may be static or ephemeral, either directly or using an out-of-band (OOB) method.

If supported, X.509 certificates can be used for authentication of public keys. See 4.16.3 Certificate-Based Provisioning.

Step 4. Authentication

During this step, the Provisioner and Provisionee perform certain actions to authenticate. For example, the Provisionee could output a random, single or multi-digit number to the user in some form, using an action appropriate to its capabilities. For example, it might display a multiple digit numeric value. The user then enters the digits output by the new device into the Provisioner and a cryptographic exchange takes place between the two devices, involving the random number, to complete the authentication of each of the two devices to the other. Equally, the Provisioner could output a value which must be input to the Provisionee. A variety of authentication methods are possible, depending in part on the input/output capabilities of the devices.

Step 5. Distribution of the Provisioning Data

After authentication has successfully completed, a session key is derived by each of the two devices from their private keys and the exchanged, peer public keys. The session key is then used to secure the subsequent distribution of the data required to complete the provisioning process, including a security key known as the network key (NetKey) and a device-specific key called the device key (DevKey). Critically, the device key is calculated independently by Provisioner and Provisionee and so never transmitted over the air.

After provisioning has completed, the provisioned device possesses a DevKey, the network’s NetKey, a mesh security parameter known as the IV Index and a Unicast Address, allocated by the Provisioner. It is now known as a node.

4.16.2 Remote Provisioning

Using remote provisioning (RPR), the Provisioner and unprovisioned device may be in any location, provided a communication path across the network between the two devices can be formed. This offers a more practical approach to provisioning for many real-world situations.

Figure 5 – Remote Provisioning

4.16.3 Certificate-Based Provisioning

The provisioning process includes an authentication step. Authentication can be achieved in a number of ways, including for example, displaying a multiple-digit number. Generally, authentication requires the device being provisioned to be in sight of the person performing provisioning so that (e.g.) the number of flashes of an LED can be counted. This is not always practical, however. In particular, if remote provisioning is in use, the device to be provisioned may be completely out of sight, perhaps on the far side of the building.

X.509 certificates are a digital, public key certificates that have a standard format. Bluetooth Mesh supports the use of X.509 certificates during provisioning. Devices provisioned using X.509 certificates do not need to be in sight and therefore compliment remote provisioning very well.

4.17 Configuration

Each node supports a standard set of configuration states which are implemented within the standard Configuration Server Model and accessed using the Configuration Client Model. Configuration state data is concerned with the node’s composition and those capabilities that are independent of any specific application or device type behaviors (these are governed by other models implemented on the device).

The Composition Data state is divided into pages and contains information about the node, including its elements and the models that it supports. The Large Composition Data Server model compliments this state and provides support for devices that have a complex composition and large number of components. DALI (Digital Addressable Lighting Interface) devices are a prime example of such devices.

DALI devices are built around a communication bus, into which up to 128 components (known as bus units in DALI terminology) may be plugged or unplugged easily. When part of a mesh network, a DALI component becomes an element in a complex mesh node which represents the DALI device as a whole. If device firmware detects changes to the components plugged into the bus, its composition data can be automatically updated, providing a plug-and-play capability.

The features supported by a node (see 4.18 Features) are indicated by Configuration Server states. The addresses to which a node has subscribed are stored in the Subscription List state. The network and subnet keys indicating the networks the node is a member of are stored in the NetKey List state and application keys are stored in the AppKey List state.

A series of configuration messages allow the Configuration Client Model and Configuration Server Model to support GET, SET and STATUS operations on the Configuration Server Model states.

4.18 Features

All nodes can transmit and receive mesh messages but there are a number of optional features which a node may possess, giving it additional, special capabilities. There are four such optional features: the Relay, Proxy, Friend and Low Power features. A supported feature may be enabled or disabled at a given time.

4.18.1 Relay Nodes

Nodes which support the Relay feature are known as Relay nodes and are able to retransmit received messages. Relaying is the mechanism by which a message can traverse the entire mesh network, making multiple hops between devices by being relayed.

Mesh network PDUs include a field called TTL (Time to Live). It takes an integer value and is used to limit the number of hops a message will make across the network. Setting TTL to 3, for example, will result in the message being relayed a maximum of two times. Setting it to 0 will result in it not being relayed at all, only travelling a single hop from the originating device directly to the destination device. A TTL value of 1 means that the message has already been relayed some number of times and should not be relayed again. Messages sent with TTL = 1, do not leave the device and therefore can only be used for local communication on the node via loopback.

For the most efficient use of the network and radio spectrum, an optional feature called Directed Forwarding can be used. Directed Forwarding uses relaying in an informed and more efficient way.

See 4.19 Message Relaying for more information on how relaying works.

4.18.2 Low Power Nodes and Friend Nodes

Some types of nodes have a limited power source and need to conserve energy as much as possible. Devices of this type may be predominantly concerned with sending messages but still have a need to occasionally receive messages.

Consider a temperature sensor which is powered by a small coin cell battery. It sends a temperature reading once per minute whenever the temperate is above or below configured upper and lower thresholds. If the temperature stays within those thresholds, it sends no messages. These behaviors are easily implemented with no particular issues relating to power consumption arising.

However, the user is also able to send messages to the sensor, which change the temperature threshold state values. This is a relatively rare event, but the sensor must support it. The need to receive messages has implications for duty cycle and as such power consumption. A 100% receive (RX) duty cycle would ensure that the sensor did not miss any temperature threshold configuration messages but use a prohibitive amount of power. A low duty cycle would conserve energy but risk the sensor missing configuration messages.

The answer to this apparent conundrum is the Friend node and the concept of friendship.

Nodes like the temperature sensor in the example may be designated Low Power nodes (LPNs) and a feature flag in the sensor’s configuration data set to indicate this.

LPNs work in tandem with another node, one which is not power-constrained (e.g. it has a permanent AC power source). This device is termed a Friend node. The Friend stores messages addressed to the LPN and delivers them whenever the LPN polls the Friend node for waiting messages. The LPN may poll the Friend relatively infrequently so that it can balance its need to conserve power with the timeliness with which it needs to receive and process messages. When it does poll, all messages stored by the Friend are forwarded to the LPN, one after another, with a flag known as MD (More Data) indicating to the LPN whether there are further messages to be sent from the Friend node.

The relationship between the LPN and the Friend node is known as friendship. Friendship is key to allowing very power constrained nodes which need to receive messages, to function efficiently in a Bluetooth Mesh network.

4.18.3 Proxy Nodes

4.18.3.1 About Proxy Nodes

There are an enormous number of devices in the world that support Bluetooth LE including most smartphones and tablets. Typically, such devices do include the Bluetooth Mesh Networking stack, but they do have the ability to connect to other devices and interact with them using procedures defined by GATT, the Generic Attribute Profile.

Proxy nodes implement a GATT service and several characteristics which other Bluetooth LE devices may use to send messages into and receive messages from a Bluetooth Mesh network. The Proxy node acts as the GATT server and the other device is the GATT client.

A protocol called the Proxy protocol is defined. GATT devices read and write Proxy protocol PDUs from within GATT characteristics implemented by the Proxy node. The Proxy node transforms these PDUs to or from mesh network PDUs. With respect to the use of the Proxy protocol, the Proxy node is deemed the Proxy server and the other device the Proxy client.

Proxy client devices must first be provisioned, just like any other device that is a member of the network.

Proxy nodes allow Bluetooth LE devices that do not possess a full Bluetooth Mesh Networking stack to interact with nodes in a mesh network. In practice this means that powerful devices that have a full operating system and high-resolution display can be equipped with applications that provide the user with a graphical user interface (GUI) via which to interact with devices such as lights in the network.

Figure 6 – Smartphone communicating via a mesh proxy node

4.18.3.2 Proxy Discovery

Proxy nodes operate in one of two modes, enabling them to be discovered and engaged with by a Proxy client such as a smartphone application in one of two ways.

4.18.3.2.1 Continuous Advertising Mode

In this mode, the Proxy node broadcasts advertising packets at intervals irrespective of whether a Proxy client device is present. The broadcast packets contain an advertising data item called Service Data which includes the UUID identifier of the GATT Mesh Proxy Service and other service data. The presence of the Mesh Proxy Service UUID identifies the advertising device as a Proxy node. A Proxy client can discover the Proxy node by scanning for advertising packets that contain the Mesh Proxy Service UUID, connect to the Proxy node and then exchange Proxy PDUs over the connection. The Proxy node relays PDUs to and from the mesh network using the advertising bearer.

The indiscriminate, more or less permanent advertising used in this approach is sub-optimal and makes wasteful use of the Bluetooth advertising channels. The advertising bearer, used by the greater majority of nodes in the mesh network is dependent on these channels being available.

4.18.3.2.2 On-Demand Private Proxy Mode

A second, more efficient approach that involves a technique called solicitation is defined. It is called the On-Demand Private GATT Proxy, support for which is optional.

In this approach, advertising does not start until the Proxy server has become aware that a Proxy client is present and in need of its services.

A Proxy client that supports the On-Demand Proxy feature indicates that it needs the services of a Proxy node by advertising. The advertising packets that it transmits contain a PDU called a Solicitation PDU. This contains the UUID of the Mesh Proxy Solicitation Service and other information.

The Proxy server node carries out a form of scanning called passive scanning. Passive scanning does not involve the transmission of any packets and therefore has no impact on radio channels. On receiving and authenticating a Solicitation PDU from a Proxy client, the Proxy node starts advertising so that the Proxy client can connect to it and start the exchange of Proxy PDUs over the established connection in the standard way.

The On-Demand Private GATT Proxy makes efficient use of advertising channels by only advertising when a Proxy client has indicated that it should do so. It also offers improved privacy due to its use of Mesh private beacons. See 7.7 Privacy.

4.19 Message Relaying

4.19.1 Multi-hop Message Delivery

A Bluetooth Mesh network may span a large area and nodes in one part of a building will often be out of direct radio range of other nodes. To enable message-based communication between all nodes, regardless of how far apart an originating node is from the destination node(s) to which its messages are sent, Bluetooth Mesh Networking uses a system which involves messages being retransmitted by certain nodes so that they hop from node to node across the network until they arrive at their destination.

In general terms, the process of retransmitting messages is called relaying, and this is the function of the Relay node.

Relaying can function in one of two different ways. The first approach is called managed flooding and the second, directed forwarding.

4.19.2 Managed Flooding

A Relay node uses the simpler managed flooding approach by default. Managed flooding involves messages received by the Relay being retransmitted.

Certain conditions will cause a Relay to not retransmit however, and this helps improve radio spectrum efficiency. Examples include:

• PDUs contain a field called Time to Live (TTL). The sender sets this field to an integer value which limits the number of times a message will be relayed. This stops messages from being relayed right across the network for no good reason.
• Details of messages received are cached by relays. The cache is checked before relaying. If the message is found in the cache it is assumed that the message has been received before and retransmitted in which case the new copy of the message is discarded.

4.19.3 Directed Forwarding

The directed forwarding approach is more sophisticated than managed flooding and makes more efficient use of radio spectrum. When using directed forwarding:

• The Relay node only retransmits a message if it knows it is a member of a sequence of nodes via which the message can travel to reach its destination. If the destination cannot be reached via this node, the message is discarded. Radio transmissions are thus reduced, and spectrum use is more efficient, leaving more capacity for messaging in the network and reducing the probability of collisions occurring.
• The sequences of nodes along which delivery to a destination is possible is either created manually during configuration or is automatically created and maintained by various system procedures.

Section 6.4 Relaying explores directed forwarding further.

For a deeper explanation of directed forwarding, see Bluetooth Mesh Directed Forwarding.

4.20 Device Firmware Updates

4.20.1 About Firmware

The low-level software which implements a device’s functionality and controls the hardware is usually called firmware. Devices that support Bluetooth Mesh Networking run firmware which implements the Bluetooth Mesh protocol and the models that the device supports.

Typically, firmware needs to be updated during its lifetime. Reasons for updating a  device that supports Bluetooth Mesh Networking firmware include:

• to upgrade the version of the Bluetooth Mesh Protocol that the device supports
• to add new functionality through support for further Mesh Models
• to fix bugs

4.20.2 Practical Issues

Devices in a Bluetooth Mesh network are often installed in locations that are physically difficult to reach (e.g. mounted on ceilings). From a practical point of view, any firmware update procedure that relies on physical, wired connectivity is likely to be problematic. Even a wireless update mechanism that relies on direct communication with the device to be updated is sub-optimal, especially in a large building.

Bluetooth Mesh Networking defines a set of procedures which allow the firmware on devices to be updated from across the network, allowing updates to any node to be initiated from any physical location.

This Device Firmware Update (DFU) feature is described next.

4.20.3 The DFU Capability

The Bluetooth Mesh Networking DFU feature allows firmware update files (often known as binary images) to be wirelessly distributed across the network to sets of one or more target devices in a single operation. It is a convenient tool for keeping firmware up to date and works in a way which makes efficient use of human, network and radio resources.

4.20.3.1 DFU Models and Roles

The Bluetooth Mesh Networking DFU feature involves three pairs of client and server models.

• The BLOB Transfer models provide a generalised mechanism for transferring Binary Large Objects (BLOBs) between nodes. A firmware update file is an example of a BLOB.
• The Firmware Distribution models support procedures which distribute firmware update files to the nodes that are to be updated. The firmware distribution procedures make use of the BLOB Transfer models.
• The Firmware Update models support procedures for applying updates to device firmware.

A number of DFU roles are defined:

Role	Description	Models
Target	A node which receives firmware updates. A Target is able to report the version of firmware it is running and the location from which updates can be obtained.	Firmware Update Server BLOB Transfer Server
Initiator	Usually runs on a device that both supports Bluetooth Mesh and has internet connectivity. Examples of such devices include smartphones and gateway devices. Periodically or on request, an Initiator checks manufacturers’ websites for new firmware releases. It then downloads update files and sends them to a Distributor node.	Firmware Distribution Client Firmware Update Client BLOB Transfer Client
Distributor	Receives firmware update files from an Initiator and sends them to Target nodes for installation. Acts as an intermediary for the Initiator which means the Initiator does not need to be in range of the mesh network for the full duration of the distribution and update procedures.	Firmware Distribution Server Firmware Update Client BLOB Transfer Client BLOB Transfer Server
Standalone Updater	A Stand-alone Updater fulfils the role of a combined Initiator and Distributor, acquiring firmware updates and sending them directly to Updating Nodes without the need for an intermediate Distributor.	Firmware Update Client BLOB Transfer Client

4.20.3.2 The Firmware Update Process[4]

4.20.3.2.1 Obtaining Firmware Updates

The Mesh DFU model specification defines the Firmware Check Over HTTPS procedure. This procedure is invoked by an Initiator (or Standalone Updater) and typically involves:

1. Receiving a list of Target nodes from the application layer
2. For each Target node on the list
   1. Retrieving information about the firmware currently installed such as the version number and the Uniform Resource Identifier (URI) of the location from which updates may be obtained.
   2. Sending a HTTP GET request to the URI and if a firmware update is available, downloading a firmware description file in the response.

A firmware description file is a JSON format file which provides information such as the number of files that a firmware update is partitioned into and the total size of the update in bytes.

The Firmware Retrieval over HTTPS procedure is then used to obtain the firmware update file(s) using the HTTPS protocol. Either the Initiator can do this, or it can instruct a Distributor to obtain the firmware updates.

Note that the specification also allows firmware updates to be checked for and retrieved using vendor-specific approaches.

4.20.3.2.2 Distributing Firmware Updates

The Initiator uses the Firmware Distribution Client model which is backed by the BLOB Transfer Client model to send firmware updates and target node details to a Distributor. The Distributor then uses the Firmware Update Client model and BLOB Transfer Client model to send updates to each of the Target nodes.

4.20.3.2.3 Firmware Installation

Targets use vendor-specific procedures to verify and install updates. Progress information is available to the Distributor.

4.20.3.2.4 DFU Security

There are security risks associated with acquiring firmware from remote sources and then installing it on nodes in the Bluetooth Mesh network. There needs to be a way of verifying that the remote source is trustworthy and that firmware update files have not been tampered with.

The DFU specification mandates the use of the secure HTTPS protocol for downloads from remote servers within the standard Firmware Check and Firmware Retrieval procedures. This ensure that downloads are encrypted and cannot be tampered with in-flight without detection. HTTPS also requires the remote server to have a digital certificate by which its identity can be authenticated.

The Firmware Check Over HTTPS and Firmware Retrieval Over HTTPS procedures address the primary security issues. The vendor-specific installation procedure used by a device offers other opportunities for further security checks.

5. System Architecture

5.1 Introduction

In this section we’ll take a closer look at the Bluetooth Mesh architecture, the layers of the mesh networking stack and the technical specifications which define the technology.

5.2 The Bluetooth Mesh Specifications

Bluetooth Mesh Networking is defined by a collection of specifications.

• The Mesh Protocol specification defines the architecture, protocols, procedures, foundation models and other core concepts of Bluetooth Mesh technology.
• The Mesh Models specification defines additional models that provide functionality beyond that which is defined by the foundation models.
• The device firmware update and BLOB transfer capabilities each have dedicated specifications in which their respective models are defined.
• A collection of profile specifications define additional requirements and implementation details that further standardize particular classes of products, improving interoperability as a result.

5.3 The Bluetooth Mesh Networking Stacks

Figure 7 shows the architecture of Bluetooth Mesh Networking in terms of its layers and dependencies on parts of the Bluetooth Core Specification. There are two stacks. The mesh Networking stack enables communication between nodes in a Bluetooth Mesh network. The mesh provisioning stack enables the provisioning of devices.

Figure 7 – The Bluetooth Mesh architecture

At Figure 7, there is a component labeled Bluetooth Core Specification (LE Physical Transport). This represents the set of core Bluetooth LE features that are leveraged by Bluetooth Mesh Networking.

A Bluetooth LE system consists of a controller and a host. These are often physically separate components that are connected in some way (e.g. UART) and which communicate using a set of standard commands and events known as the Host Controller Interface (HCI). The layers of the Mesh Networking stack are all resident in the host component. The Mesh Networking stack is dependent on parts of the Bluetooth LE stack that run in the controller such as the link layer and the physical layer. See The Bluetooth LE Primer for more information on these layers and the basic architecture of Bluetooth LE.

We’ll now review each layer of the Mesh Networking architecture, working our way up from the bottom layer.

5.4 Bearer Layer

Mesh Networking messages require an underlying communications system for their transmission. The bearer layer defines how mesh PDUs will be handled by a given communications system. Two main bearers that are used for general messaging purposes are defined and these are called the advertising bearer and the GATT bearer.

The advertising bearer leverages Bluetooth LE advertising and scanning features to transmit and receive mesh PDUs.

The GATT bearer allows a device which does not support the advertising bearer to communicate indirectly with nodes of a mesh network using a protocol known as the Proxy protocol. The Proxy protocol is encapsulated within GATT operations involving a GATT service called the Mesh Proxy Service which includes two GATT characteristics named Mesh Proxy Data In and Mesh Proxy Data Out.

A Proxy node implements the Mesh Proxy Service and its characteristics. It supports both the GATT bearer and the advertising bearer, and this allows it to convert and relay messages over the two types of bearer.

The GATT bearer may also be supported by nodes that do not support the Proxy feature.

5.5 Network Layer

The network layer defines the various message address types and a network message format that allows transport layer PDUs to be handled by the bearer layer.

It can support multiple bearers, each of which may have multiple network interfaces, including the local interface which is used for communication between elements that are part of the same node.

The network layer determines which network interface(s) to output messages over. An input filter is applied to messages arriving from the bearer layer, to determine whether they should be delivered to the network layer for further processing. Output messages are subject to an output filter to control whether they are dropped or delivered to the bearer layer.

リレー機能とプロキシ機能は、ネットワークレイヤー実装してもよい。

5.6ローワー トランスポート レイヤー

ローワー トランスポート レイヤー アッパートランスポートレイヤー 、ピアデバイス上のローワー トランスポート レイヤー PDUを受け取り、それをローワー トランスポート レイヤー 送信する。必要に応じて、PDUのセグメンテーションと再アセンブリを実行する。単一のトランスポートPDUに収まらない長いパケットの場合、ローワー トランスポート レイヤー セグメンテーションを実行し、PDUを複数のトランスポートPDUに 分割する。もう一方のデバイスの受信ローワー トランスポート レイヤー 、セグメントを1つのアッパートランスポートレイヤー PDUに組み立て直し、これをスタックに渡す。

5.7アッパートランスポートレイヤー

アッパートランスポートレイヤー 、アクセス レイヤー間でやり取りされるアプリケーション 暗号化、復号化、および認証 責任を負う。また、内部的に生成され、異なるピアノードの上位トランスポート レイヤ間で送信されるトランスポート制御メッセージの責任も負う。これには、フレンドシップ、有向転送、ハートビートに関連するメッセージが含まれる。

5.8アクセス レイヤー

アクセス レイヤー 、モデルがどのようにアッパートランスポートレイヤー使用するかを定義する責任を負う。これには以下が含まれる：

• メッセージデータのフォーマットを定義する。
• アッパートランスポートレイヤー実行される暗号化および復号化プロセスを定義し、制御する。
• データをスタックに転送する前に、アッパートランスポートレイヤー 受信したデータが正しいネットワークとモデルであることを確認する。

5.9基本モデル階層

基本モデル階層 、メッシュネットワークの構成と管理に関係するモデルの実装を担当する。

5.10 モデル層

モデルレイヤーはモデルの実装に関係し、1つ以上のモデル仕様で定義されたビヘイビア、メッセージ、ステート、状態 バインディングの実装を行う。

6.メッセージング

このセクションでは、Bluetooth Meshネットワークにおけるメッセージングがどのように機能するかについて説明し、セクション4で説明した重要な概念のいくつかをまとめます。主な機能とコンセプト

6.1 メッセージの公表と配信

Wi-Fiを使用するネットワークは、アクセスポイントと呼ばれる中央のネットワークノードを中心に構成され、すべてのネットワークトラフィックはアクセスポイントを経由する。ルーターが利用できなくなると、ネットワーク全体が利用できなくなる。

一方、Bluetooth Mesh Networkingでは、電波の届く範囲にいるノードに直接メッセージを送ったり、距離が離れている場合は中継ノードを経由してメッセージを送ったりする。ノードがパブリッシュした場合、メッセージは特定のノードに直接ルーティングされるのではなく、ブロードキャストされます。すべてのノードは、直接無線範囲内にあるノードからのすべてのメッセージを受信します。そのように設定されている場合、ノードはフラッディング または有向転送のいずれかを使用し、受信したメッセージをリレーします。

6.2 マルチパス配信

ブロードキャスト通信と中継を使用することの重要な帰結は、メッセージがネットワークを介して複数の経路を経由して宛先 到着することができることである。これはBluetooth Mesh Networkingが信頼性の高いネットワーク技術であることに貢献している。

6.3 スタックのトラバース

メッセージの受信は、Bluetooth LE コントローラのリンクレイヤー パケットを受信することから始まる[5]。そして、そのペイロードはHost Bluetooth Mesh Networkingベアラ層に渡され、そこからネットワークレイヤー渡されます。

ネットワークレイヤー 様々なチェックを行い、メッセージをスタックの上位に渡すか、破棄するかを決定する。

加えて、PDUにはネットワークID フィールドがあり、メッセージがどのNetKey 暗号化されたかを高速に判断する方法を提供する。受信側ノードのネットワークレイヤー このネットワークID 認識できない場合は、対応するネットワークレイヤー おらず、 サブネットでないことを示す、これは対応するNetKey おらず、そのサブネット メンバー でないことを示すので、PDUは破棄される。ネットワークメッセージ整合性チェック（MIC）フィールドもある。MICチェックに失敗した場合、メッセージは破棄される。

メッセージは発信者の範囲内にあるすべてのノードによって受信されるが、その多くが、そのノードが属するネットワークやサブネット関係で、そのノードに関係ないことが明らかになると、すぐに破棄される。

同じ原理がスタックの上位のアッパートランスポートレイヤー適用される。しかし、ここでは、メッセージに関連付けられ、PDUの識別子(AID)フィー ルドでアプリケーション されるアプリキー チェックが行われる。このノードがAIDを認識できない場合、PDUはアッパートランスポートレイヤー破棄される。トランスポートメッセージの完全性チェック(TransMIC)が失敗した場合、メッセージは破棄される。

アッパートランスポートレイヤー メッセージをアクセス レイヤー渡す。そこからモデルレイヤーは、受け取ったメッセージのタイプに基づいて適切なモデル関数を呼び出すために使用される。

6.4 中継

中継の基本的な考え方はセクション4.19メッセージ中継で紹介した。有向転送(directed forwarding)メソッドは、管理されたフラッディング managedフラッディング メソッドよりも複雑なので、このセクションでさらに説明する。

6.4.1 直接転送

6.4.1.1フラッディング比較

フラッディング 使用される場合、TTL フィールドで示される最大ホップ数がすでに経過している場合などの限られた状況を除いて、リレー・ノードは受信したすべてのメッセージを再送する。これはシンプルで効果的なメカニズムであるが、無線スペクトラムの使用に関しては最も効率的とは言えない。メッセージは、宛先 ノードがリレーノードある方向に位置しているかどうかに関係なく、ネットワークを全方向に伝搬する。

図8と図9は、ブルートゥース・メッシュ・ネットワークが設置され、ステージ上の照明を制御するスイッチもある大きな会議場を示している。すべてのホップに到達するためには、メッセージを1ホップで中継する必要があります。

スイッチの範囲内に2つのリレーノードがある。ステージ照明スイッチが使用されると、メッセージが送信され、両方のリレーで受信され、再送信されます。このため、メッセージはターゲット照明に向かっても、ターゲット照明から遠ざかっても、ネットワーク内を移動します。 

図8 - 点灯/消灯メッセージを放送する照明スイッチ

図9-2つのリレーがメッセージを受信し、両方が再送信する

これは最適とは言えません。ステージから最も遠いリレーノード 、スイッチからステージ照明へのオン／オフ制御メッセージの配信に貢献できない。

有向転送が管理型フラッディング 異なる点は、リレーノード 状態 データが、メッセージでアドレス指定された1つ以上のノ ードへのパス上にあることを示す場合にのみ、中継が行われる点であ る。有向転送を使用できるリレーノード 、有向リレーノード呼ばれる。

図10は、会議ホールの照明スイッチとリレー・ノードが使用した場合の有向転送の効果を示しています。照明スイッチからのオン/オフ・メッセージの伝搬は、ステージ上の照明に向かってのみ行われ、ネットワークの他の部分には伝搬されません。

図10 - 有向転送の効果

パスの概念は、有向転送において正式に定義されたものである。

6.4.1.2 進路と車線

有向転送は、与えられた送信アドレス 特定の宛先 アドレスメッセージを配送することができる有向中継ノードのシーケンスを定義または発見することを含む。このようなノードシーケンスはパスと呼ばれる。

パスの定義では、送信アドレス 常にアドレスであるが、宛先 アドレス グループアドレス、どのようなタイプでもよい。宛先 アドレス 複数のノードに対応する場合、有向転送パスを有向中継ノードのシーケンスの集合として記述する方がより正確である。

Directedリレーノード Forwarding Tableと呼ばれる状態 データ項目は、リレーがサービ スできるパスを示す。これは、ソースアドレスと宛先 アドレスのペアのリストで構成される。メッセージを受信すると、Directed RelayはForwarding Tableを参照し、その中にメッセージの送信元アドレスと宛先 アドレス エントリがあれば、そのメッセージは中継される。そうでない場合、メッセージは破棄される。

特定のターゲットノードに到達するために、メッセージが中継される有向中継ノードのシーケンスが複数存在する可能性がある。これはマルチレーンパスを作成することで利用できる。レーンはDirected Relayノードのシーケンスであり、その点ではパスと同じです。1つの送信元ノードから1つの宛先 ノードへのメッセージ配送に複数の代替ノードシーケンスが利用可能な場合、レーンという用語はシーケンスに使用され、パスという用語はすべてのレーンの集合に使用されます。マルチレーン・パスは冗長性が高いため、Directed Relayノードのシーケンスの1つが何らかの理由で使用できない場合でも、メッセージが配送される可能性が高くなるという利点があります。 

6.4.1.3 パスの作成とメンテナンス

パスは、Configuration Managerツールを使って手動で作成されるか、一連の自動化された手順の実行によって動的に発見され、確立される。

自動パス作成が使用されている場合、プロセスはいくつかのステージにわたって実行される。パスが必要とされる送信元と宛先 アドレス ペアについては、送信元から宛先メッセー ジを送信できるリレーノード 配列の発見を目標に、ネットワークを探索するために特別なメッセー ジが使用される。この過程で、パスメトリックと呼ばれる測定値が確立され、代替シーケンス間の比較が行われ、最適なものが使用されるように選択される。パスメトリックとは、送信元ノードから所定のリレーシーケンスを経由して宛先 到達するのに要するホップ数を単純にカウントしたものである。より少ないホップで構成されるパスの方が、より多くのホップを必要とするパスよりも優れている。

送信元/宛先アドレス ペアのパスとして機能するノードの最短シーケンスが発見されると、そのシーケンス内のノードは、そのパスの一部であることを示すように、制御メッセージを使用して更新される。

7.セキュリティ

7.1 ブルートゥース・メッシュ・ネットワーキングにおけるセキュリティは必須である

Bluetooth LE 、プロファイル設計者が様々なセキュリティの仕組みを利用することを可能にする。 これには、2 つのデバイスのペアリングが機能する様々な方法、広告パケットにおけるプライベートデバイ スアドレスの使用、GATT 特性に付随するセキュリティルールが含まれる。しかし、セキュリティは完全にオプションであり、セキュリティ保護や制約のない完全にオープンなデバイスを持つことも許されます。ブルートゥースSIG 仕様が適用されない場合（例えば、カスタムプロファイルやサービスを扱う場合）、機器の設計者又は製造者は、脅威を分析し、セキュリティ要件を決定し、それらの要件を満たすためにBluetooth LE のセキュリティ機能をどのように使用するかを決定する責任がある。

一方、Bluetoothメッシュ・ネットワーキングでは、セキュリティは必須である。ネットワーク、デバイス、個々のアプリケーションはすべてセキュアであり、セキュリティをオフにしたり低減したりすることはできない。

7.2 セキュリティの基礎

以下の基本的なセキュリティに関する記述は、すべてのBluetooth Meshネットワークに適用されます：

1. メッシュ・メッセージはすべて暗号化され、認証される。
2. ネットワーク・セキュリティー、アプリケーション セキュリティー、デバイス・セキュリティーは、それぞれ独立に扱われる。後述の「7.3 懸念事項の分離とセキュリティ・キー」を参照のこと。
3. セキュリティ・キーは、メッシュ・ネットワークの使用中に、キー更新 手順と ノード・プロビジョニング・プロトコル・インターフェイス手順を使用して変更することができます。
4. メッセージの難読化は、ノードの追跡を困難にするプライバシー・メカニズムを提供する。
5. メッシュ・プライベート・ビーコンは、デバイス追跡に使用される可能性のある静的情報がノードからブロードキャストされないことを保証する。
6. メッシュ・セキュリティは、リプレイ攻撃からネットワークを保護する。
7. デバイスをメッシュ・ネットワークに追加してノードにするプロビジョニング・プロセスは、安全なプロセスであり、X.509デジタル証明書のサポートも含まれている。
8. ゴミ箱攻撃を防ぐ方法で、ノードをネットワークから安全に削除することができる[6]。

7.3 懸念事項の分離とセキュリティ・キー

ブルートゥース・メッシュ・ネットワーキングのセキュリティの中心は、3種類のセキュリティキーです。これらのキーは、ネットワークのさまざまな側面にセキュリティを提供します。Bluetoothメッシュ・セキュリティのdesign 、異なるタイプのセキュリティキー キーを使用することは、懸念事項の分離として知られる重要な原則の一例です。

このことを理解し、その意義を理解するために、リレーノード機能するメッシュライトを考えてみよう。リレーノード機能するメッシュ・ライトは、建物のブルートゥース・メッシュ・ネットワーキングのドアや窓のセキュリティ・システムに関するメッセージを処理する。ライトは、そのようなメッセージのデータにアクセスして処理できる正当な理由はないが、他のノードにリレーする必要がある。

この潜在的な利益相反に対処するため、ブルートゥース・メッシュ・ネットワーキングは、照明、物理的セキュリティ、暖房などの特定のアプリケーションに関連するデータを保護するために使用されるセキュリティ・キーとは異なる、ネットワークレイヤー セキュリティを提供するためのセキュリティ・キーを使用する。

Bluetooth Meshネットワークのすべてのノードは、少なくとも1つのネットワークキー NetKey）を所有しています。この共有キーを所有することで、ノードはネットワークのメンバー であることができます。ネットワーク暗号化キーとプライバシー・キーはNetKey直接導き出されます。

NetKey 所有することで、ノードはネットワークレイヤー 復号と認証を行うことができ、中継などのネットワーク機能を実行することができる。ただし、アプリケーション データを復号化することはできない。

特定のアプリケーション データは、正しいアプリケーション キーアプリキー）を所有するノードによってのみ復号化できる。メッシュネットワーク内のノード全体では、多くの異なるアプリキーが存在する可能性がありますが、通常、アプリキー ノードのごくサブセット 、つまり特定のアプリケーション参加できるタイプのノードによってのみ所有されます。例えば、照明と照明スイッチは照明アプリキー アプリキー 持つが、暖房システムのアプリキー 持たない。

AppKeyは、アッパートランスポートレイヤー メッセージを復号化し、認証するために使用するアクセス レイヤー

AppKey は 1 つのNetKey にのみ関連付けられる。この関連付けはキーバインディングと呼ばれ、特定のアプリキー所有によって定義される特定のアプリケーションは特定のネットワーク上でのみ動作可能である。

最後のキータイプはデバイスキーである。これは特殊なタイプのアプリケーション キーである。各ノードは、プロビジョナー いる固有のデバイスキー 持つ。デバイスキー 、コンフィギュレーション・プロセス中の通信を保護するために使用される。

図11 - Bluetooth Meshのセキュリティ・キー

7.4 サブネットとサブネット ブリッジング

ネットワークはサブネットに細分化できる。サブネット 独自のNetKey持ち、そのNetKeyキーはそのサブネットメンバーであるノードだけが持つ。これは例えば、ホテルの各客室など、物理的に異なるエリアを分離してセキュアにするために使用される。この場合、特定の客室の照明などのデバイスは、同じ客室で同じサブネット上にある他のデバイスによってのみ制御できるようになります。

異なるサブネットにあるデバイス間の通信が必要な場合があります。ホテルの管理スタッフが全客室の全デバイスを一元的にコントロールする必要がある場合もありますが、同時に、ある客室のデバイスを使って別の客室のデバイスをコントロールしたり、ある客室のデバイスからの通信を別の客室のデバイスが傍受して解読したりすることができないようにする必要があります。ブルートゥース・メッシュ・ネットワーキングには、これを可能にするサブネット ブリッジと呼ばれる機能 ある。

サブネット ブリッジ機能 、ネットワークプランナーはエリア分離のためにサブネットを使用するだけでなく、セキュリティを損なうことなく、隣接する異なるサブネット内の特定のデバイス間の通信を選択的に許可することができます。これには、サブネット 機能する1つ以上のノードをセットアップする必要があります。これらのノードは、ブリッジ設定サーバモデルと呼ばれるモデルとその様々な状態だけでなく、ブリッジされる各サブネットのNetKey 所有しています。

サブネット 、サブネット 呼ばれる状態 有効になる。ブリッジングテーブルと呼ばれる更なる状態 、特定のソースアドレス 特定の宛先 アドレス間の通信を可能にするエントリを含む。さらに、ブリッジングテーブルのエントリは、最初のサブネット NetKey 2番目のサブネット NetKey キーを示す。

これは、あるサブネットメッセージを、最初のNetKey暗号化し、サブネット・ブリッジとして動作するノードが復号化し、2番目のサブネットのNetKey再暗号化することを可能にするブリッジ・テーブルの状態 情報である、で暗号化された1つのサブネットからのメッセージを、サブネット ブリッジと して動作するノードが復号し、2番目のサブネット NetKey 再暗号化し、この動作を指定され た送信元と宛先 アドレスメッセージに制限することを可能にするブリッジングテーブル の情報である。

7.5 ノードの削除、キー更新 ゴミ箱攻撃

ノードには様々なメッシュ・セキュリティ・キーが含まれている。ノードが故障して廃棄する必要が生じた場合、あるいは所有者がノードを別の所有者に売却することを決めた場合、そのデバイスとその中に含まれる鍵が、ノードの持ち出されたネットワークへの攻撃に使用されないようにすることが重要である。

ネットワークからノードを削除する手順を定義する。アプリケーション 使用してノードを拒否リストに追加し、キー更新 手順と呼ばれるプロセスを開始する。

キー更新 手順により、拒否リストのメンバーを除く、ネットワーク上のすべてのノードに、 新しいネットワーク・キー、アプリケーション キー、および関連する派生データが発行される。言い換えれば、ネットワークとアプリケーション セキュリティの基礎となるセキュリティ鍵のセット全体が置き換え られる。

その結果、ネットワークから削除され、古いNetKey 古いAppKeyのセットを含むノードは、もはやネットワークのメンバー 、脅威とならない。

7.6 リプレイ攻撃

リプレイ攻撃とは、盗聴者が1つまたは複数のメッセージを傍受してキャプチャし、後で再送信する技術で、受信者を騙して攻撃デバイスが許可されていないことを実行させることを目的とする。

7.6.1IVインデックス シーケンス番号

ブルートゥース・メッシュ・ネットワーキングには、リプレイ攻撃に対する保護機能がある。この保護の基礎となるのは、シーケンスナンバー （SEQ）とIVインデックス呼ばれる2つのデータ項目の使用です。エレメントはメッセージをパブリッシュ たびにSEQ値をインクリメントする。最後に有効だったメッセージに含まれていた値以下の SEQ 値を含むエレメント メッセージを受信したノードは、それがリプレイ攻撃に関連する可能性が高いため、そのメッセージを破棄する。

IVインデックスはネットワーク共有リソースで、メッセージ受信時にSEQとソース・アドレス 値と一緒にチェックされる。SEQ、IVインデックス 、およびSRC（送信アドレス）フィールドの組み合わせ値は、エレメント 送信するすべてのメッシュ・メッセージで常に一意である。

ネットワークは一度に1つのIVインデックス 値を使用する。ただし、IVアップデート 手順が進行している間は、手順が完了しネットワーク全体に新しい値が割り当てられるまで、2つの異なる値が使用される。

7.6.2IVアップデート 手順

シーケンス番号は24ビット長である。SEQフィールドのインクリメントを繰り返すうちに、ノードはシーケンスナンバー 供給量を使い果たしてしまうかもしれない。このような事態を避けるために、IVアップデート 呼ばれるネットワーク手順が、このような状況に陥ったノードによって開始される。これにより、古い値をインクリメントして新しいIVインデックス 値が計算され、ネットワーク全体に割り当てられ、影響を受けるノードのエレメントはシーケンスナンバー ゼロにリセットする。

セキュリティ上の理由から、サブネット メンバであるノードだけがIVアップデート 手順を開始することが許可されている。非プライマリサブネットのメンバーであるゲストデバイスだけがIVアップデート開始することはできません。これにより、この重要な共有ネットワークリソースが保護されます。

7.7 プライバシー

NetKey から派生したプライバシーキーは、送信アドレスネットワーク PDU ヘッダー値を難読化するために使用されます。難読化によって、何気ない受動的な盗聴が、デバイスとそれを使用する人々を追跡するために使用できないことが保証されます。また、トラフィック解析に基づく攻撃を困難にします。

キー更新 手順やIVアップデート 手順を含む、Bluetoothメッシュネットワーキング手順の多くは、以下を使用しています。 ビーコン送信を使用して、ネットワーク内の他のデバイスにデータをブロードキャストし、その存在と状態示します。ビーコン送信はBluetoothの広告を活用する技術です。

静的で変化しない情報の送信は、ネットワーク上を移動するデバイスを追跡し、デバイス、デバイスのユーザー、そしておそらくネットワーク全体に関する情報を推測することが可能になるため、セキュリティ・リスクとなる可能性があります。このリスクにアドレス するため、Bluetoothメッシュ・ネットワーキングにはメッシュ・プライベート・ビーコンと呼ばれる機能が搭載されています。

メッシュ・プライベート・ビーコン送信には静的な情報は含まれません。ビーコン・メッセージに含まれるデータを使ってデバイスが追跡される可能性を排除することで、ネットワーク・プライバシーを向上させます。

8.スケーラビリティ

ブルートゥース・メッシュ・ネットワーキングは拡張性が証明されている。現実の世界では、6,000ものノードが商用展開されている。

ブルートゥース・メッシュ・ネットワークの理論上の最大アドレス可能エレメント数は32,767個です。これは、エレメント 識別するためのユニキャスト・アドレス 長さが15ビットであることに起因します。つまり、ネットワークが収容できるノード数でスケーラビリティを考えることは、このトピックを見る上で特に有益な方法ではありません。それよりも、ネットワークがサポートできる作業量、別の言い方をすれば、ネットワーク運用の量と速度という観点から考える方が適切だ。

スケーラビリティとその他のパフォーマンス指標は、ネットワーク・プランナー（10.1 プランナー参照）がネットワークを設計する際に考慮する問題です。ノードの配置と構成は、ネットワークの性能と、将来必要とされる最大のノード数への拡張のしやすさに大きな影響を与えます。

ワイヤレス・ネットワークのスケーラビリティは、共有する無線スペクトラムをいかに効率的に使用するかなど、多くの要因によって制限される傾向がある。衝突は、2つのデバイスが同じ無線チャネルで同時に送信するときに発生し、ネットワークのスケーラビリティを制限する要因になり得る。そのため、衝突によるメッセージ損失の確率を回避または低減することは、Bluetooth Meshのdesign およびネットワークプランナーによるdesign 作業における重要な戦略です。

すべてのネットワークが同じとは限らない。ノードの数が比較的少ない小規模なネットワークは、小規模なネットワークのノードが物理的に近くに配置され、ノードが頻繁にメッセージを送信する場合、大規模なネットワークよりもスケーリングが難しくなる可能性があります。つまり、ネットワーク密度やノードの冗長性といった概念が重要なのだ。ネットワークに含まれるノードの絶対数だけではありません。

ブルートゥース・メッシュ・ネットワーキングは、当初からスケーラビリティを念頭に置いて設計されました。PDUは小さく（長さは最大29オクテット）、これによって送信に使用される通信時間が短縮されるため、衝突が発生する確率が低くなります。

通常、メッセージのコピーは3つの異なるチャンネルで送信される。これにより、ネットワーク容量が増加し、衝突によるメッセージ損失の確率が減少する。

有向転送機能 精巧さの有無にかかわらず、中継プロセスはメッセージのための複数の経路を確立し、特に混雑したネットワークでは配送の確率を高める。

特に、1つのデバイスが他のデバイスのグループを1回の操作で制御しようとするマルチキャストシナリオ（Bluetooth Meshネットワークでは非常に典型的な状況）では、認識されないメッセージはネットワークトラフィックを削減します。

分散型のdesign 思想は、Bluetooth Mesh Networkingがどのように機能するかの重要な側面の基本となっている。これにより、より高いレベルのスケーラビリティがサポートされ、他の類似技術とも差別化される。例えば、センサーは中間の照明コントローラーを必要とせずに照明と直接通信します。

BluetoothSIG ウェブサイトには、Bluetooth Meshネットワークにおけるスケーラビリティについて、より詳しく説明した記事が掲載されている。

9.ネットワーク照明制御 （NLC）

ブルートゥース・メッシュ・ネットワーキングが設計された主な用途のひとつは、大規模ビルにおけるネットワーク化された照明機器の制御である。

ライト（正式には照明器具と呼ばれることもある）は複雑で、独立して制御可能な複数のランプを備え、明るさや色の制御をサポートし、人間が操作するスイッチによる手動制御と、遠隔のワイヤレスセンサーによる環境測定制御の両方が可能である。

ブルートゥース・メッシュ・モデル仕様は、照明などのデバイスがネットワーク内で特定の機能（スイッチのオン／オフなど）を得るために実装する標準化された機能ブロックを定義しています。モデルのモジュール性は、革新的な多機能製品の作成をサポートします。個々のモデルは洗練されていることが多く、その状態 動作を制御するために多数のパラメータが利用可能です。このことが、NLCの技術としてのブルートゥース・メッシュ・ネットワーキングの柔軟性と汎用性をさらに高めている。

Bluetooth Mesh Networking の様々な重要な側面はオプションです。これには、サポートされるベアラのリスト、デバイスのプロビジョニング方法、サポートされるノード機能（Proxy、Relay、LPN、Friendなど）などが含まれます。Bluetooth Mesh Networking仕様の異なる部分間には、しばしば依存関係があります。

ブルートゥース・メッシュ・ネットワーキング技術の柔軟な性質は、かなりの利点がある。しかし、これは標準化によって異なるメーカーの製品間の相互運用性を実現するという目標とのバランスを取る必要があります。ある技術が構成可能で可変的であればあるほど、相互運用性を確保することが難しくなる場合があります。このため、一連のBluetooth NLCデバイス・プロファイル仕様は、様々なタイプのデバイスに対する標準的なコンフィギュレーションやその他のアプリケーション 層の要件および推奨事項を定義しています。関連するプロファイルに準拠することで、同じプロファイルを実装する他の製品 相互運用が可能になります。

以下の製品 タイプのNLCプロファイル仕様が定義されている。

• 環境光センサー NLCプロファイル
• ベーシック・ライトネス・コントローラー NLCプロファイル
• ベーシックシーンセレクター NLCプロファイル
• 調光制御 NLCプロファイル
• エネルギーモニターNLCプロフィール
• NLCプロファイル

ブルートゥース・メッシュ・ネットワーキングは、物理層からアプリケーション 層までデバイスの全層を定義することで、ワイヤレス照明制御のための初のフルスタック規格となっている。

10.ブルートゥース・メッシュ・ネットワーキングのステークホルダー

主な利害関係者とその役割を理解することは、Bluetooth Meshネットワークの計画、作成、維持、管理方法についての理解を深めるのに役立ちます。このセクションでは、多くの標準的な役割を特定し、説明します。

10.1 プランナー

プランナーには広範な責務があり、そのすべてが作成されるネットワークの定義に関係する。これらの責任を3つのサブカテゴリーに分類して考えることは有益である：

• 物理的計画
• 機能計画
• ネットワーク計画

同じ人がすべてのサブカテゴリーを担当することもあれば、スペシャリストに分散させることもある。

物理的計画とは、建物内の機器の物理的配置を定義することである。建築家、インテリアデザイナー、工業デザイナーは、一般的に物理的なプランニングを担当する。

機能計画は、デバイスの機能特性とネットワーク内の他のデバイスとの機能的関係を定義することに関係する。機能計画は物理計画に影響を与えるかもしれない。

ネットワークプランニングは、必要な機能性と信頼性が達成されるように、デバイスの必要な構成を決定することに関係する。例えば、どのデバイスをフレンドノード、低電力ノード、リレーノード、プロキシノードとして機能させるかを決定するのはこの役割です。ネットワークプランナーは物理的なプランニングに影響を与えます。

10.2 インストーラー

インストーラーは、建物内に機器を物理的に設置する。通常、穴を開けたり、はしごに登ったり、ドライバーを使ったり、電力を供給接続中 する。

10.3 委員

プランナーによって作成されたdesign 、設置業者によってデバイスが物理的に設置された後、この役割はデバイスをプロビジョニングすることによって、新しいBluetooth Meshネットワークの一部にします。プロビジョニング後、コミッショナーは各新規ノードが機能およびネットワークプランニング作業によって指定された機能と構成を持つように設定します。通常、プロビジョニングとコンフィギュレーションは同じツールを使って同時に行われます。

10.4 ビル・メンテナンスの役割

ビルメンテナンスの役割は、プランナー、インストーラー、コミッショナーの役割の側面を含むが、新しいネットワークを構築するのではなく、ビル内の既存のネットワークに責任を持つ、もう1つの幅広い役割である。ビルメンテナンス担当が行うタスクの例としては、デバイスの交換（インストール、プロビジョニング、コンフィギュレーションが必要）、問題の診断と解決、不要になったデバイスの安全な廃棄などがある。

10.5 ビル所有者

ビルのオーナーはビルを所有し、ネットワークが要求通りに機能し、安全で、期待される投資収益率（ROI）を実現することを懸念している。

11.結論

本稿では、Bluetooth Mesh Networkingについて、その主な機能、コンセプト、用語を紹介した。これはBluetoothだが、我々が知っているBluetoothではない。新しいトポロジーを使ってデバイスが通信する新しい方法をサポートするBluetooth技術だ。

そして何よりも、この最も広く普及している低消費電力ワイヤレス技術を、まったく新しいユースケースや産業分野に完璧に適合させるのがブルートゥースなのだ。

12.追加リソース

このセクションでは、様々な観点からBluetooth LE 学習を支援するその他のリソースを掲載する。

リソース	項目	所在地
ブルートゥース・メッシュ・プロトコル仕様	この仕様は、Bluetooth Mesh Networking アーキテクチャとそのプロトコルおよび手順を定義する。	https://www.bluetooth.com/specifications/specs/mesh-protocol/
ブルートゥース・メッシュ・モデル仕様	照明やセンサーなどのアプリケーションのための標準化されたモデル一式を定義する。	https://www.bluetooth.com/specifications/specs/mesh-model-1-1/
ブルートゥースコア仕様	Bluetooth スタックの全レイヤーと関連するプロトコルおよび手順を定義しています。Bluetooth LE とBluetooth BR/EDR両方をカバーしています。	https://www.bluetooth.com/specifications/specs/
プロフィールとサービス仕様	サービス仕様は、1つのGATTサービスを、そのサービスに含まれる特性および記述子とともに定義する。サービスをホストするGATTサーバーデバイスが様々な条件や状態 データ値に応答して示すべき動作は、サービス仕様書に定義される。 プロファイル仕様は、関連デバイスが担う役割を定義し、特に、クライアント 動作と、それが動作すべき接続サーバー上のデータを定義する。	https://www.bluetooth.com/specifications/specs/
Bluetooth LE 入門	Bluetooth LE 入門』はBluetooth LE スタックの各レイヤーについて解説しており、下部の物理レイヤーから始まり、最上部の汎用アクセス・プロファイルで終わります。セキュリティなど、スタックのレイヤーアーキテクチャに関連するトピックもカバーしています。本書は、Bluetooth LE 初めてで、技術的な観点からBluetooth LE 学びたい方にお勧めの一冊です。	https://www.bluetooth.com/bluetooth-resources/the-bluetooth-low-energy-primer/
ブルートゥース・メッシュ・プロトコル仕様 -機能 概要	Bluetooth Mesh Protocol仕様では、いくつかの重要な新機能が導入されました。本稿では、変更点を高いレベルで要約し、各新機能のより詳細な情報を提供する論文へのリンクを示します。	https://www.bluetooth.com/mesh-feature-enhancements-summary/
スタディガイド -Bluetooth LE 開発入門	スマートフォンや周辺機器との接続を重視したソフトウェア開発について学びたい開発者向けの教材。解決策を含む一連のハンズオンプロジェクトが含まれています。	https://www.bluetooth.com/bluetooth-resources/bluetooth-le-developer-starter-kit/
スタディガイド - ブルートゥース・メッシュ・ネットワーキング・ソフトウェア開発入門	Bluetooth Mesh NetworkingとマイクロコントローラへのMesh Modelsの実装について学びたい開発者向けの教育リソースです。ソリューション付きの一連のハンズオンプロジェクトが含まれています。	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-developer-study-guide/
スタディガイド - Bluetoothメッシュ・ネットワーキング・プロキシ機能入門	Bluetooth Mesh ネットワークのノードとのインタラクションを可能にする、スマートフォンなどのデバイス用の GUI アプリケーションの作成方法を学びたい開発者向けの教育リソースです。ソリューションを含む一連のハンズオンプロジェクトが含まれています。	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-proxy-kit/
論文 - ブルートゥース・メッシュ・ネットワーキング - 開発者のための入門書	ブルートゥース・メッシュ・ネットワーキングの主要なコンセプトと機能について学びたい人のための教材。	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-networking-an-introduction-for-developers/
論文 - ブルートゥース・メッシュ・モデル - 技術的概要	ブルートゥース・メッシュ・ネットワーキング製品で使用可能な標準モデルの理解を深めるための教育リソースです。	https://www.bluetooth.com/bluetooth-resources/bluetooth-mesh-models/
スタディガイド -Bluetooth LE セキュリティを理解する	Bluetooth LE Mesh Networkingを除く）におけるセキュリティの全側面を解説した教育用リソース。セキュリティに関する全くの初心者の方にも、経験者の方にも最適です。解決策を含む一連の実践的プロジェクトを含みます。	https://www.bluetooth.com/bluetooth-resources/le-security-study-guide/
論文 - ブルートゥースのセキュリティとプライバシーのベストプラクティス・ガイド	このガイドは、実装者が、特定のアプリケーションにおいて、利用可能な特定のセキュリティとプライバシーの選択肢が他よりも優れている、あるいは劣っている理由や、仕様にどのようなリスクや落とし穴が残されているかをよりよく理解できるようにすることを目的としている。	https://www.bluetooth.com/bluetooth-resources/bluetooth-security-and-privacy-best-practices-guide/
記事 - Bluetoothメッシュ・ネットワークにおけるスケーラビリティ	スケーラビリティの問題を検討し、定義を提示し、より大規模なネットワークにおける問題を支配する要因を探るブログ記事。	https://www.bluetooth.com/blog/mesh-in-large-scale-networks/

[1]無線伝送レートを議論する場合、ビットではなく、1秒あたりのシンボルを使用するのが一般的です。しかし、Bluetoothではデジタルビットとアナログシンボルが1対1で対応しています。

[2]Bluetoothの仕様はセクション5で紹介します。システム・アーキテクチャ

[3] Bluetooth LE 入門書は、一般的なLEの入門書として推奨される。

[4]スタンドアロンアップデータの役割は、このセクションのイニシエータ またはディストリビュータへの言及に置き換えることができる。

[5]6.3 ブルートゥース・メッシュ・ネットワーキング・スタックを参照。

[ゴミ箱攻撃は、廃棄されたデバイスを回収し、そのデバイスに含まれるセキュ リティ・キーを回収し、悪意を持って使用するものである。