"蓝牙mesh标准V1.01：实现互操作性的低功耗蓝牙无线技术网状网络解决方案"

需积分: 9 181 浏览量更新于2024-04-13 收藏 6.23MB PDF 举报

The BLE Mesh Ref V1.01.pdf is a document that outlines the Bluetooth Mesh standard version 1.01, set by the Bluetooth Special Interest Group (SIG). This standard, which was last revised on January 21, 2019, was prepared by the Mesh Working Group and can be accessed for feedback through the email mesh-main@bluetooth.org. The Bluetooth Mesh standard defines the necessary requirements for creating an interoperable mesh networking solution using Bluetooth low energy wireless technology. This standard is crucial for ensuring that different devices can communicate seamlessly within a mesh network, allowing for a wide range of applications and use cases. The document details the various profiles and specifications that must be adhered to in order to be compliant with the Bluetooth Mesh standard. It outlines the revision history of the standard, with the current version being v1.0. Overall, the Bluetooth Mesh standard plays a vital role in the development and implementation of mesh networking solutions using Bluetooth technology. By following the guidelines set forth in the standard, developers can ensure that their devices are compatible with a wide range of other devices, creating a more connected and efficient network.

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 16 of 333

Term Definition

State A value representing a condition of an element that is exposed by an element of

a node.

Subnet

A group of nodes that can communicate with each other.

Table 1.2: Terminology

Mesh Profile / Specification

Bluetooth SIG Proprietary Page 18 of 333

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 19 of 333

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 20 of 333

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.

剩余332页未读，继续阅读

huagui_zhou

粉丝: 2
资源: 4

"蓝牙mesh标准V1.01：实现互操作性的低功耗蓝牙无线技术网状网络解决方案"

BK3432 BLE开发包v12.0203-博芯SDK深度解读

JDY-10M BLE MESH模块组网技术资料介绍

JDY-10M BLE MESH模块资料V2.3版本发布

Skylab_SKB501主从模式AT应用手册_V1.01.pdf

BLE Core_v5.3.pdf

电子-DSBM14580BLE模块简介V1.71.pdf

JDY-10M多功能BLE MESH组网模块资料.rar

JDY-10M多功能BLE MESH组网模块资料.zip

BLE-MIDI-spec.pdf

BLE入门与提高教程.pdf

最新资源