蓝牙mesh基本概念讲解

https://blog.csdn.net/JaLLs/article/details/88864829

1.蓝牙MESH基本概念
网状网(mesh)

    Mesh网络，就是一个多对多网络(Many to Many)。 每个设备节点都可以和别的节点自由通讯。在这种拓扑中，因为很多节点可以中继（relay）收到的消息(Message)， 所以端对端的通信可以比原来单点之间的通讯距离要远很多。就好像小组讨论自由发言，如果做的太远听不见的话，别人也可以代为传话。

                  

设备和节点（Devices and Nodes）

如果一个设备成为了蓝牙mesh网络的一部分，我们就把它叫做节点(node)。 反之，我们就把它叫做“未配网的设备”（unprovisioned devices）。把未配网的设备变成节点的过程我们把它叫做 “配网” （provisioning）。

元素(element)

如下图，三个子灯组成一大灯，每个子灯都可以通过寻址访问，子灯就称之为元素(element),大灯称之为节点(node)。

           

消息（Messages）

消息也是蓝牙mesh里的一个重要概念。当一个节点需要查询别的节点的状态(Status)或者控制别的节点的时候，就需要发一个对应类型的消息。当一个节点向别人报告状态改变的时候，他也需要发出一个消息。在蓝牙mesh里面定义了很多种类型的消息，每种消息都有对应的操作码(opcode)。消息可以按照有应答（acknowledged）和没应答（unacknowledged）来分类。 和大多数的通讯系统一样，有应答的消息需要接收节点给个响应。“发给你了” “收到两条了”。这样做有两个目的：一是告诉你我收到了。二是可以返回一些需要的值。如果发现没有收到应答，发送端可以再次发送。当然，如果是不用应答的消息，接收端收到就算了，不会告诉发送端的。

地址（Addresses）

在蓝牙mesh里面定义了三种类型的地址：单播地址（unicast address），组播地址（group address）和虚拟地址（virtual address）。

唯一性的单播地址可以识别出一个元素。这个地址是在配网的时候分配给设备的。一个mesh网络可以有32767个单播地址。

组播地址是一个表示一个及以上元素的广播地址。组播地址可以由蓝牙SIG来定义(SIG Fixed Group Addresses)， 也可以动态分配。目前SIG定义了4个组播地址，分别是“All-proxies”, “All-friends”,“All-relays” and “All-nodes”。 动态分配的组播地址是设计成在用户配置的时候，可以分配代表一些实际的场所，比如可以定义几个组播地址代表几个不同的房间。一共可以有16384个组播地址，其中SIG保留了256个，其他16128个都是动态分配的。

虚拟地址基本可以认为是组播地址的一个扩展，厂家自定义的地址类型。

https://blog.csdn.net/hesuping/article/details/108688419 

蓝牙Mesh中地址分为三种，单播地址、虚拟地址、群组地址。

单播地址： 网络内每个元素都有一个单播地址，所以一个有多个元素的节点也就有多个单播地址，单播地址范围为1- 0x7fff。
群组地址： 群组地址是多个元素共有的地址，地址范围为 0xc000 - 0xffff(中间包括特定群组地址和部分保留区域)，群组地址一般由Provisioner设置，在数据库中进行统一的分配和管理，防止网络中发生群组地址冲突。
虚拟地址： 虚拟地址是由节点的label UUID通过hash处理生成的，设置虚拟地址时，Provisioner会将label UUID发送给对应的设备，对应设备在收到目的地址是虚拟地址的数据后，会尝试用之前设置的label UUID进行验证。故Provisioner不用在数据库中维护虚拟地址的分配管理。虚拟设备也可以不经过Provisioner，由两个设备通过协商来生成。
 

https://blog.csdn.net/JaLLs/article/details/88864924

发布和订阅（Publish/Subscribe）

在蓝牙mesh里面发消息的动作我们叫做发布（Publish）。光从字面意思理解大家基本上就能看懂了。我想告诉别人什么事情发生或者做什么事情就叫做发布。谁对某些消息感兴趣就可以订阅这些内容。节点发布消息到单播地址，组播地址或者虚拟地址。节点有兴趣接收这些数据的可以订阅这些地址。

在上图中，开关1 发布信息给组播地址”厨房“， 节点灯1， 灯2， 灯3 每个都注册到了”厨房“这个地址上， 因此他们能收到处理发给厨房的消息。换句话说， 灯1，灯2 和灯3 都能被开关1控制开关。 开关2 发布消息到”餐厅“，只有灯3订阅了"餐厅"这个地址，所以只有灯3能被开关2控制。在这个例子里同样说明了每个节点可以订阅多个确切的地址。同样的，你一定也注意到了，开关5和开关6同样都可以发布消息到”花园“。

状态和属性(States and Properties)

在蓝牙mesh中，元素的不同情况叫做状态(States),状态是一个特定类型的值，在每个元素内部存在。除了本身的值以外，状态还有一些相关的行为。 拿灯来说，蓝牙mesh定义了一个状态叫”Generic OnOff.“  灯收到了一个ON的状态，理解以后就会执行相应的动作比方说 点亮灯泡的行为。

在蓝牙mesh里面的属性它提供一个来解释Characteristic的上下文。举个例子。如果有一个Characteristic，叫做Temperature 8，一个8位的温度状态类型，它有着一些相关联的属性， 包含现在室内环境温度和现在室外环境温度。这两个属性允许一个传感器来发布传感器消息，收到的客户端（关于客户端和服务器端的内容我们后面会讲）会根据属性得知到底是哪个温度信息。

消息,状态和属性的关系 (Messages, States and Properties)

蓝牙Mesh里面，要进行某种操作，就是调用消息这一基本机制。一个给定的消息类型代表了一个对状态的操作或者对多个状态的采集。所有的消息都可以分成三种简单类型：get 、set 、 status。

GET 顾名思义，就是获取一个节点或者多个节点的给定的状态。当收到GET消息以后，STATUS消息就发出来了。当然，它里面带着的是相对应的状态内容。

SET消息分为有应答和无应答两种。如果是有应答的，就会有STATUS消息跟着出来，如果是无应答的话，那就没有应答包。

STATUS 消息，除上面的两种情况会出现之外，也可以在其他的消息中出现，当然也可以独立出现。比方说某个元素用定时器每隔一段时间发送一次。

在蓝牙mesh里面定义了很多种消息，通过Opcode来区分，还包含了相关联的参数和行为。Opcode可以是单字节，双字节（常见）或者三字节（厂商指定）。

绝大部分的mesh消息都是对状态进行操作的，只有特别的和属性相关的消息，才会对属性进行操作，而且需要制定16位的属性ID。

状态转换（State transitions）

上面说到了状态的设置和获取，那么在进行状态改变的时候，这种改变可以是立刻发生的，也可以是过一段时间发生的。下图把不同的时间给表示出来了。

初始化状态(initial State)是指刚收到SET新的状态值的时间。从收到SET消息到状态改变的时间叫做转换时间。从STATUS消息发出（可以在中间的任何时间点）到目标状态完成这个叫保持时间(Remaining time), 所以当你收到STATUS消息的时候，状态可能还没有变化，在STATUS消息里也可以包含离目标状态的变化还有多少时间。

状态绑定（Bound States）

不同的状态之间可能会有一些关系。比如说一个状态的变化会造成另外状态的触发，这种关系叫做状态绑定。状态的绑定是可以跨Model的，（Model这个重要概念我们马上会提到），也可以在多个元素中。再举个例子，灯光亮度状态和开光状态。当你把亮度状态改到0了，也就触发了开关状态的“关”状态，反之亦然。

https://blog.csdn.net/JaLLs/article/details/88864967

模型（Models）

模型（Model）定义了一个节点的基本功能。一个节点当然可以包含多个Model。一个Model定义了节点所需要的所有的状态。消息会给基于这些状态进行操作，当然也会有相应的行为随之产生。

Mesh的应用定义的是使用“发布-订阅（publish-subscribe）”的典型的“服务器-客户端（client-server）”的架构。在Mesh里面，并没有沿用传统的端到端的“Profile”的概念，而是定义了三种不同的模式， Client, Server 和Control。

Server model: 定义了状态states, 状态转换 state transitions, 状态绑定state bindings 和包含了哪些消息，当然也同样定义了与这些消息，状态，状态转换相关的行为Behaviors。

Control model:具备client model的功能与其他的server model进行交互，同时也可以有server model功能与其他client model进行交互。内置了逻辑控制层（一套规则和行为在各个与之连接的模型中进行协调交互）。

Client model: 没有定义任何的状态States，但是它定义了要收发哪些消息。定义这些消息是为了GET，SET或者获取在Server models里面定义的状态。

下图展示的是Device C(server model)带有状态，支持R S T X Y Z消息，Device A（client model）支持 X Y Z消息，Device B(client model)支持 R S T Z消息。

下图中 Device C(control model)可以作为client model与server model（device A与device B）进行通讯(分别支持X Y Z 和R S T消息)，也可以作为server model与client model（device D）进行通讯（支持 A B C消息）。

 通用（Generics）

为了满足不同的需求，Mesh中定义了多种不同的models,实际上SIG确实有一个Model specification。现在是1.0的版本，只定义了几个Model group：Generics，Sensors，Time and Scenes和Lighting 。你仔细看一下这几个名字就会发现，其实Generic这个model就是把很多不同应用的相似的部分例如ON/OFF，Level一些状态和行为放在了一个叫做 通用 的model里面。如果你的产品没有办法找到对应的model，就可以先用 generic 这个model先用。

配网（Provisioning）

配网的全过程包括大概5个步骤，分别是

Step 1. Beaconing；

Step 2. Invitation；

Step 3. Exchanging Public Keys；

Step 4. Authentication;

Step 5. Distribution of the Provisioning Data

其实也很简单，第一步，告诉你我要配网，这里使用的是新定义的AD广播包类型, Mesh AD。第二部， 配网者Provisioner听到了这个Beacon以后，就发一个邀请，这个邀请就是配网邀请PDU（Protocol Data Unit）。要入网的设备收到邀请以后，会把自己的一些配网的能力(Provisioning capabilities)发回来。接下来，既然郎有情妾有意， 就公开交换信物-公钥呗。接下来就会有一个互动随机数的认证流程，这点和原来蓝牙输入0000  的密码很像， 但是会简单一点点。 最后一步，认证完成，从公钥和两个设备的私钥派生出Session Key。后面的配网的信息交互的过程会用这个Session key来加密。配网成功以后，就会根据最后一步里面包含交换的NetKey来加密后面的数据交换。跟加密相关的一些参数例如IV index， 和单播地址，会存在配网者那里。

节点特性（node features）

mesh里面还给每个节点有一些额外的四种可选的特性(Features)。分别是中继Relay,代理Proxy,朋友Friend和 低功耗Low Power features。节点可以在某个时间点选择不支持或者支持多个Feature。

中继（Relay）支持中继的节点，可以帮忙转发收到的消息。因为有了Relay，Mesh网络就可以实现多跳(Hops)。

低功耗和朋友（Low Power Nodes and Friend Nodes）， 这是搭配来用的。我们先说Low power节点，类似于对功耗有要求的设备，例如温度传感器。这种类型的设备为了节约功耗，很大的时间都是在休眠的。也就是意味着他们收不到网络中发过来的消息。Friend节点能帮LP节点暂存消息。当LP节点需要的时候，可以发消息给Friend节点， 问问有没有“waiting message”。如果有，就会一条条的发给LP节点。简而言之，Friend节点就像是门卫的张大爷，你（Low power node）想起来的时候去门卫拿你要的信就好了。这种方式和zigbee里面的enddevice向父节点拿数据的方式类似。

下面简单的拓扑结构基本上说明了这两种Feature和其他一般Node的关系和消息路径。显而易见，如果有消息要发从T发给L，S会帮忙转发，Ｏ会帮忙Ｌ存起来。Ｌ要消息的时候，Ｏ再把Ｔ的消息发给Ｌ。

图 ：  mesh 网络中的拓扑结构

代理(Proxy)的feature又是什么呢？这就是Mesh想到的兼容现有的非Mesh设备的方法。在Proxy节点， 其实是可以通过BLE的GATT来交流的。（这是现在非Mesh BLE设备最常用的数据交流方式）。

图： 有mesh功能与无mesh功能之间的通讯方式

每个节点当然还有一系列配套的配置集，在Configuration Server Model和Configuration Client Model里的States都有实现。比如，上面说到的不同的Feature，都是在Configuration Server states说明的。在蓝牙Mesh也一样定义了配置消息（configuration messages）集。

https://blog.csdn.net/JaLLs/article/details/88865194

蓝牙mesh协议架构
mesh协议层架构图

图：mesh系统架构

承载层（Bearer Layer）

Bearer Layer 定义了Mesh节点怎么传递网络消息的。定义了两种Bearer，广播advertising bearer 和GATT bearer 。

Advertising Bearer 利用的是BLE GAP广播包的advertising 和scanning
的功能来传递接收mesh的报文。

The GATT Bearer 允许不支持Advertising Bearer的设备间接的与mesh节点进行通讯。怎么通讯呢？使用前面讲的代理(Proxy Protocol)。Proxy Protocol是封装在GATT里面，当然会用特别定义的GATT characteristics。上一讲我们讲到了Proxy Feature，支持Proxy Feature的Proxy Node也就是代理节点，因为可以同时支持两种Bearer Layer，所以可以作为mesh节点和非mesh节点的中间桥梁。

网络层（Network Layer）

网络层定义了几件事情， 一个是定义了多种网络地址类型，我之前有说过关于Mesh地址的内容。二是定义了网络层的格式，打通传输层（Transport layer）和承载层(Bearer layer)；三是定义了一些输入输出Filter，决定哪些消息需要转发，处理还是拒绝。四是定义了网络消息的加密和认证。

底层传输层（Lower Transport Layer）

这层做的事情很简单，就是拆拆拼拼。把太长的传输层的包拆成若干个分给网络层，把短的网络层的包再组成一个长的传输层的PDU(Protocol Data Unit)。

上层传输层（Upper Transport Layer）

上层传输层主要是负责加密，揭秘和应用数据授权。一句话，消息的安全性和机密性就是有这一层负责的。还有就是会定义一些节点间在这一层的一些会话，比如Friend功能，心跳包（Heartbeats）。

访问层（Access Layer）

访问层主要负责：1.定义更高层的应用如何跟upper transport layer通讯。2.定义应用数据的格式。3.定义和控制upper transport layer应用数据的加解密。4.在把应用数据扔到上层之前，会检查校验接收过来的应用数据是否合法。

基础Model层（Foundation Models Layer）

基础model层定义访问层（access layer）的状态，消息，模型配置和mesh网络管理。

Model层（Model Layer）

Model层定义了典型的用户场景标准化操作的相关models（相关的models定义在Bluetooth Mesh Model specification文档中）。更高层次模型规范的例子包括照明和传感器的模型。

 
————————————————
版权声明：本文为CSDN博主「JaLLs」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/JaLLs/article/details/88865194