蓝牙mesh V1.0开发指南：入门必备

5星 · 超过95%的资源需积分: 49 162 浏览量更新于2024-07-19 3 收藏 5.26MB PDF 举报

蓝牙mesh V1.0是蓝牙联盟于2017年7月13日发布的官方标准，其修订号为v1.0，标志着无线蓝牙mesh技术在低功耗蓝牙（Bluetooth Low Energy, BLE）领域的重要进展。该文档定义了蓝牙mesh网络的基础要求，旨在促进蓝牙设备之间的互通性和网络的可扩展性，为开发工程师提供了构建蓝牙mesh网络应用的入门指南。蓝牙mesh Profile/Specification是由Mesh Working Group负责准备的，其目的是为了实现一种基于蓝牙标准的物联网解决方案，通过建立一个分布式、可扩展的网络架构，使得多个智能设备能够相互通信，共同协作完成任务，例如智能家居、工业自动化和智能城市等场景。此版本的规范历史中记录了从v1.0开始的修订过程，包括各个主要贡献者如Qualcomm Technologies International Ltd., Broadcom Corporation, Ericsson AB, NXPSemiconductors, Google Inc., Intel Corporation等公司的代表人物，他们在蓝牙mesh技术的发展和标准化过程中发挥了关键作用。文档内容涵盖了蓝牙mesh网络的核心要素，包括但不限于设备的角色分配（如路由器、网关和终端节点），网络拓扑管理，数据包路由、确认与错误检测机制，以及安全措施等。此外，还提到了如何利用诸如Mesh Profile API来实现设备间的通信，这对于开发者来说是至关重要的实践指导。学习蓝牙mesh V1.0，开发人员需要理解如何构建连接稳定的网络，如何处理网络流量，确保数据可靠传输，并且遵循蓝牙SIG的专有协议，以确保所有兼容设备之间的互操作性。对于想要在物联网领域应用蓝牙技术的工程师来说，这是一份不可多得的参考资料，无论是在设计之初还是在解决实际问题时，都能提供有价值的参考和支持。蓝牙mesh V1.0不仅是蓝牙技术生态系统中的一个重要里程碑，也是开发人员进入蓝牙mesh应用开发领域的必备文档，它帮助构建高效、灵活和安全的无线网络系统。

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 16 of 331

2 Mesh system architecture

This section provides an overview of the mesh network operation and layered system architecture.

2.1 Layered architecture

The Mesh Profile specification is defined as a layered architecture as shown in Figure 2.1.

Figure 2.1: Mesh system architecture

2.1.1 Model layer

The Model layer defines models that are used to standardize the operation of typical user scenarios and

are defined in the Bluetooth Mesh Model specification [11] or other higher layer specifications. Examples

of higher layer model specifications include models for lighting and sensors.

2.1.2 Foundation Model layer

The Foundation Model layer defines the states, messages, and models required to configure and manage

a mesh network.

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 17 of 331

2.1.3 Access layer

The access layer defines how higher layer applications can use the upper transport layer. It defines the

format of the application data; it defines and controls the application data encryption and decryption

performed in the upper transport layer; and it checks whether the incoming application data has been

received in the context of the right network and application keys before forwarding it to the higher layer.

2.1.4 Upper transport layer

The upper transport layer encrypts, decrypts, and authenticates application data and is designed to

provide confidentiality of access messages. It also defines how transport control messages are used to

manage the upper transport layer between nodes, including when used by the Friend feature.

2.1.5 Lower transport layer

The lower transport layer defines how upper transport layer messages are segmented and reassembled

into multiple Lower Transport PDUs to deliver large upper transport layer messages to other nodes. It

also defines a single control message to manage segmentation and reassembly.

2.1.6 Network layer

The network layer defines how transport messages are addressed towards one or more elements. It

defines the network message format that allows Transport PDUs to be transported by the bearer layer.

The network layer decides whether to relay/forward messages, accept them for further processing, or

reject them. It also defines how a network message is encrypted and authenticated.

2.1.7 Bearer layer

The bearer layer defines how network messages are transported between nodes. There are two bearers

defined, the advertising bearer and the GATT bearer. Additional bearers may be defined in the future.

2.2 Overview of mesh operation

The mesh network operation defined by this specification is designed to:

• enable messages to be sent from one element to one or more elements;

• allow messages to be relayed via other nodes to extend the range of communication;

• secure messages against known security attacks, including eavesdropping attacks, man-in-the-

middle attacks, replay attacks, trash-can attacks, brute-force key attacks, and possible additional

security attacks not documented here;

• work on existing devices in the market today;

• deliver messages in a timely manner;

• continue to work when one or more devices are moved or stop operating; and

• have built-in forward compatibility to support future versions of the Mesh Profile specification.

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 18 of 331

This specification defines a managed-flood-based mesh network, which uses broadcast channels to

transmit messages so that other nodes can receive messages and relay these messages; thus extending

the range of the original message. Any device in a managed-flood mesh network can send a message at

any time as long as there is a sufficient density of devices that are listening and relaying messages.

Enhancements to add routing functionality and define a routing-based mesh network may be considered

for a future revision of this specification.

There are a number of methods used by this specification to restrict the unlimited relaying of messages in

a managed-flood mesh network. The two main methods used are the network message cache method

and the time to live method.

The network message cache is designed to prevent devices from relaying previously received messages

by adding all messages to a cached list. When a message is received, it is checked against the list and

ignored if already present. If not already received, then it is added to the cache so that it can be ignored in

the future. To prevent this list from becoming too long, the number of messages that are cached is limited

by implementation.

Each message includes a Time to Live (TTL) value that limits the number of times a message can be

relayed. Each time a message is received and then relayed (up to a maximum of 126 times) by a device,

the TTL value is decremented by 1.

2.2.1 Network and subnets

A mesh network consists of nodes sharing four common resources:

• network addresses used to identify source and destination of messages (see Section 3.4.2);

• network keys used to secure and authenticate messages at the network layer (see Section

3.8.6.3);

• application keys used to secure and authenticate messages at the access layer (see Section

3.8.6.2); and

• an IV Index used to extend the lifetime of the network (see Section 3.8.4).

A network can have one or more subnets that facilitate ”area” isolation (e.g., isolated hotel room subnets

within a hotel network). A subnet is a group of nodes that can communicate with each other at a network

layer because they share a network key. A node may belong to one or more subnets by knowing one or

more network keys. At the time of provisioning, a device is provisioned to one subnet and may be added

to more subnets using the Configuration Model.

There is one special subnet called the primary subnet, which is based on the primary NetKey (see

Section 3.8.6.4). Nodes on the primary subnet participate in the IV Update procedure (see Section

3.10.5), and propagate IV updates to other subnets, while nodes on other subnets only propagate the IV

Index updates to those subnets.

The network resources are managed by a node that implements the Configuration Client model, known

as the Configuration Client, (typically a smart phone or other mobile computing device) and are allocated

to nodes at the time of configuration (see Section 5) using the Configuration Server model (see Section

4.4.1). In particular, a Provisioner manages allocation of addresses to make sure no duplicate unicast

addresses are allocated, whereas a Configuration Client generates and distributes network and

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 19 of 331

application keys and makes sure that devices that need to communicate with each other share proper

keys for both network and access layers. The Configuration Client also knows device keys (see Section

3.8.6.1), which are used to secure communication with each individual node, including distributing

updated network and application keys.

2.2.2 Devices and nodes

A device that is not a member of a mesh network is known as an unprovisioned device. A device that is a

member of a mesh network is known as a node. A Provisioner is used to manage the transitions between

an unprovisioned device and a node.

An unprovisioned device cannot send or receive mesh messages; however, it advertises its presence to

Provisioners. A Provisioner will invite an unprovisioned device into a mesh network after it has been

authenticated, converting the unprovisioned device into a node.

A node can send or receive mesh messages and is managed by a Configuration Client, that may also be

the same device as the Provisioner, over the mesh network to configure how the node communicates

with other nodes. A Configuration Client can remove a node from a mesh network, which reverts it back

to an unprovisioned device.

A device may support multiple instances of a node by offering itself to be provisioned to another mesh

network after already being provisioned to a mesh network. Each instance of a mesh network is

determined by addresses and a device key obtained by the device during provisioning.

2.2.3 Adding devices to a mesh network

Devices are added to a mesh network by a Provisioner, at which point they become nodes. The

provisioning of devices into a mesh network differs from the point-to-point bonding and pairing that is

typically used in Bluetooth wireless technology. Provisioning of devices is enabled using either a simple

advertising bearer or a point-to-point GATT-based bearer. A single provisioning protocol is used over both

bearers. Provisioning over an advertising-based bearer is implemented by all devices. Provisioning over a

GATT-based bearer allows devices such as legacy phones (i.e., devices that do not support provisioning

over an advertising bearer natively) to be Provisioners.

To assist with provisioning of multiple devices, a device has an attention timer that can be set by a

Provisioner. When set to a non-zero value, the device identifies itself using any means it can. For

example, the device may flash a light, make a sound, or vibrate. When the attention timer expires, the

device stops identifying itself. This allows a Provisioner to send a single message to a device to cause it

to identify itself and the device automatically stops identifying itself after a given time.

The protocol to run over these two bearers is a derivative of the Security Manager protocol of v4.2 of the

Bluetooth Core Specification to introduce the ability to authenticate devices that have a very limited user

interface, such as a light or a switch. The Security Manager protocol requires a reliable bearer, something

that cannot be guaranteed by the advertising provisioning bearer; therefore the protocol used in this

specification is designed to enable reliable delivery of messages independent of the bearer. The similarity

to the Security Manager protocol enables significant reuse of existing code on devices that have

implemented such functionality.

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 20 of 331

2.2.4 Communications support

Many current devices are unable to advertise or comprehend mesh messages without being updated. To

enable these devices to communicate with a node in a mesh network without the need for an operating

system update or similar hardware/software update, the specification enables the use of GATT

connectivity for all existing devices.

2.2.5 Low power support

The features within this specification enable many devices in the mesh network to be battery-powered or

to use techniques such as energy harvesting. Such devices may be constrained in how they can function

as a part of a mesh network (e.g., devices that only send data when interacted with). This specification

does not require devices to coordinate transmissions, make connections, or restart security on every

connection; thus facilitating low power operation. Devices needing low power support can associate

themselves with an always-on device that stores and relays messages on their behalf, using the concept

known as Friendship (see Section 3.6.6). However, devices that relay messages will receive messages

as well as forward messages a majority of the time and are likely to use significantly more power than

could be provided by typical small batteries or capacitors.

2.3 Architectural concepts

The mesh networking architecture uses several different concepts: states, messages, bindings, elements,

addressing, models, publish-subscribe, mesh keys, and associations.

2.3.1 States

A state is a value representing a condition of an element.

An element exposing a state is referred to as a server. For example, the simplest server is a Generic

OnOff Server, representing that it is either on or off.

An element accessing a state is referred to as a client. For example, the simplest client is a Generic

OnOff Client (a binary switch) that is able to control a Generic OnOff Server via messages defined by the

Generic OnOff Model.

States that are composed of two of more values are known as composite states. For example, a color-

changing lamp can control color hue separately from color saturation and brightness.

2.3.2 Bound states

When a state is bound to another state, a change in one results in a change in the other. Bound states

may be from different models in one or more elements. For example, a common type of binding is

between a Level state and an OnOff state: changing the Level to 0 changes the bound OnOff state to Off

and changing the Level to a non-zero value changes the bound OnOff state to On.

2.3.3 Messages

All communication within a mesh network is accomplished by sending messages. Messages operate on

states. For each state, there is a defined set of messages that a server supports and a client may use to

request a value of a state or to change a state. A server may also transmit unsolicited messages carrying

information about states and/or changing states.

剩余330页未读，继续阅读

u014622144

粉丝: 0
资源: 1

蓝牙mesh V1.0开发指南：入门必备

蓝牙mesh文档

MshPRFv1.0.1中文版-Bluetooth mesh核心协议规范 中文版

蓝牙Mesh Profile V1.0.1

蓝牙Mesh规范v1.0

Mesh_v1.0.zip_Mesh_mesh 蓝牙_mesh蓝牙_蓝牙MESH_蓝牙mesh协议

蓝牙Mesh model标准V1.0

蓝牙Mesh 1.0标准

SIG BLE MESH spec v1.0

Mesh_v1.0.pdf

蓝牙LE Mesh v1.0规格：设备属性与互操作性指南

最新资源

MshPRFv1.0.1中文版-Bluetooth mesh核心协议规范中文版