(七)深入理解蓝牙Mesh的低功耗实现

9 篇文章 20 订阅 ¥49.90 ¥99.00

目录

一.前言:

二.协议细节:

2.1 建立Friend关系: 

2.1.1 Friend request消息:

2.1.2 Friend offer消息:

2.1.3 选择最优Friend的逻辑:

2.1.4 Friend设计的三个时序参数:

2.2 Friend设备通信:

2.2.1 Friend设备接收和缓存消息:

2.2.2 Friend设备发送消息:

2.2.3 LPN设备接收消息:

2.2.4 LPN设备发送消息:

2.2.5 相关消息格式:

2.3 管理Friend设备:

2.4 安全性:

三.工程限制


一.前言:

蓝牙Mesh协议是在BLE广播的基础上设计实现的,因此接入Mesh网络的设备,就需要有足够的时间片来进行扫描操作,以接收其他设备随时可能发送的mesh消息。开启扫描对于BLE芯片来说是一个比较费电的操作,一般的蓝牙芯片扫描功率一般为 6mA左右(以Telink 8253为例,它的扫描功耗Whole Chip RX mode: 5.3mA,发射功耗Whole Chip TX mode: 4.8mA ),这对使用纽扣电池的低功耗设备很不友好,例如CR2450纽扣电池只有550mAh的容量。5号电池一般在2500mAh左右。

因此Mesh协议为了满足低功耗设备的需求,设计了LPN(Low Power Node)和Friend的特性,核心思想是LPN低功耗的Mesh设备,不需要一直打开扫描去被动的接收其他设备的消息,而是主动的周期性的去Friend设备那里去询问,是否有发给我的消息。化“被动扫描”为“主动查询”,而主动查询的周期可以配置为相对较长时间,进而实现了降低功耗的需求。Friend设备来帮助LPN设备缓存一定数量的消息,供LPN设备来查询,Friend设备一般是常带电的。

低功耗设备有一个前提,就是它不需要频繁的发送消息和接收消息。不可能既让它频繁的工作,又让它保持一个较低的功耗,这个是不合理的。典型的低功耗设备就是传感器。

二.协议细节:

Mesh设备是否为LPN设备,是在它的Composition Data的Features字段里面定义的,无法动态改变。一个Mesh设备的Friend特性,也是在Composition Data的Features字段中定义的,如果支持Friend特性,是可以通过config model的消息来打开/关闭该特性的。Friend特性涉及的消息大部分为“控制消息”,不上报到access layer层。

既然LPN节点依赖Friend节点来帮助其缓存消息,那么LPN的第一步操作,就是去找到一个合适的Friend节点,和这个Friend设备建立起“Friendship的关系”

2.1 建立Friend关系: 

LPN设备上电之后,开始去“找朋友”,它向Friend Node的组地址(0xFFFD),发送Friend Request消息,支持Friend特性并且打开了Friend特性的节点,会回复Friend Offer消息,如果周边的Friend节点很多,最终LPN会选择其中一个Friend节点与之建立FriendShip关系,后面就是进行Friend Poll和Friend Update的正常通信了,完整过程如图1。

图1

2.1.1 Friend request消息:

消息格式如图2:

图2

该消息中,定义了Friend设备通信中使用的PollTimeout,ReceiveDelay这两个时序参数,这两个参数的作用,本文后面有介绍。另外比较重要的是Criteria字段,它的详细定义如图3,其中最重要的是RSSIFactor和ReceiveWindowFactor这两个因子。Criterai的作用是为了让LPN从众多Friend节点中选出一个最优的设备建立Friendship关系,其他的非最优的设备则被忽略,LPN同一时间只能与一个Friend设备建立FriendShip关系。 

图3

2.1.2 Friend offer消息:

详细格式如图4:

 图4

此消息中的ReceiveWindow表示这个Friend需要LPN节点支持的扫描窗口,详细后面有介绍。QueueSize表示的是Friend可以为LPN缓存的消息队列的大小。RSSI信号强度,可以变相理解为Friend和LPN之间的距离(RSSI越大,表示两个设备越近,RSSI越小,表示两个设备越远)。

2.1.3 选择最优Friend的逻辑:

介绍完Friend Request消息和Friend Offer消息的格式之后,再讲解一下LPN选择最优Friend的逻辑,根据协议定义,Friend设备收到Friend Request之后等待Friend Offer Delay时间之后,再回复Friend offer消息。这个Delay的时间计算如下:

图5

这里面涉及到了RecevieWindow和RSSI两个核心参数以及前面提到两个因子。ReceiveWindow和RSSI是Friend offer消息中的字段,两个因子是Friend request消息的字段。我们从LPN的角度来看,它肯定最想要RSSI最强的,要求自己的扫描窗口最小(可以降低功耗)的设备来与它建立FriendShip,从上面的公式可以算出,越是符合LPN理想型的Friend设备,Local Delay的值越小,回复的越快。因此LPN节点会选择回复Offer最快的那个Friend设备来建立FriendShip关系。但是一个Friend设备有可能不同时拥有最优的RecevieWindow和RSSI。这时候就需要LPN来做取舍了,LPN的Friend request消息中这两个因子开始起作用了:更需要“小receiveWindow”的话,就把ReceiveWindowFactor调大,增加“大ReceiveWindow”Friend设备回复的delay时间,减少它被选择可能性;更在乎RSSI的话,就把RSSIFactor调大,减少“信号强度高”的Friend设备回复的时间,增加它被选择的可能性。

2.1.4 Friend设计的三个时序参数:

另外,在Friend建立过程中,确定了三个时序参数:ReceiveDelay,ReceiveWindow,和PollTimeout。

ReceiveDelay:LPN节点发送request之后,等待ReceiveDelay这么长时间后,再打开扫描以接收Friend Node的response。RecevieDelay主要是为了给Friend节点一定的时间来准备response。

ReceiveWindow:ReceiveWindow与BLE的scan Window类似,即打开扫描的窗口,以接收Friend的response消息。此参数设置的过大,会增大LPN设备的功耗(这个参数是Friend节点来确定的,如果这个Friend节点的发送性能差,它就会要求LPN开启更大的扫描窗口来接收它的消息)。

PollTimeout:Friend节点连续收到两个LPN的poll消息的最大时间间隔。在Friend节点收到LPN节点的poll消息后,又过了PollTimeout这么长时间,如果没有收到任何LPN节点的poll消息,则仍认为是LPN节点已经离线了,这时候Friend节点可以单方面终止FriendShip关系。

根据深入理解蓝牙Mesh的消息格式之“格式与长度”的文章可知,Friend request,Friend offer和Friend Poll等消息属于transport layer control消息,格式中有一个7bit的opcode的定义,图2和图3中的数据是实际上是transport layer control消息中的部分内容,Friend request的opcode是0x03,Friend offer的opcode是0x04。

2.2 Friend设备通信:

建立起FriendShip关系之后,LPN节点和Friend节点就开始正常通讯了。

 图6

2.2.1 Friend设备接收和缓存消息:

Friend节点扫描到有发给“与自己建立了FriendShip的LPN节点”的消息时,会帮LPN设备缓存,缓存在自己的队列中,等待LPN设备来查询。Friend节点接收到LPN设备的Friend Poll消息,则回复它缓存的消息,当有IV更新或者缓存队列为空时,则发送Friend Update给LPN设备。另外Friend设备还可以接收LPN设备的Mesh消息,并替它relay出去。

2.2.2 Friend设备发送消息:

当LPN设备通过Friend Poll消息来查询时,Friend发送它缓存的Mesh消息,如果缓存队列为empty,则发送Friend Update消息(MD=0)通知LPN设备。只有当缓存队列为空,或者IV Index更新时,才会发送Friend Update消息。

2.2.3 LPN设备接收消息:

LPN节点周期发送Friend poll消息去Friend节点处查询,是否有发给自己的access layer消息,Friend节点则回复相应的access layer消息给LPN节点,如果IV发生了变化,则通过Friend update消息告知。这里的access layer消息指的是开关/设置亮度等。当然也可以是SNB消息。

2.2.4 LPN设备发送消息:

当LPN节点需要向外发送消息时(这里指的是access消息,并非是Friend相关的control消息),可以选择通过Friend Node来relay转发,也可以直接跳出FriendShip的关系,直接发到Mesh网络中。向外发送的消息指的是开关状态,亮度状态等。

2.2.5 相关消息格式:

Friend Poll消息格式如下图:

图7

FSN:是FRIEND SEQ NUMBER的缩写,仅有一个bit,会从0,1,0,1之间跳变。当LPN设备发送的Friend Poll消息收到了的回复(Friend Update或者缓存的Mesh接入消息),下一包的Friend Poll消息中的FSN会变化。Friend节点也会根据LPN的Friend Poll消息中的FSN变化,判断上一条消息回复,LPN是否收到(如果LPN节点的Friend Poll消息中的FSN没有变化,Friend则重发上一条消息)。 

Friend Update消息如下图:

图8

Flags,IV Index这两个参数,与SNB消息中的含义相同,MD表示队列是否为空。LPN节点可以一直频繁的Friend Poll,直到收到MD为0的Friend Update消息(MD为1,表示还有数据,MD为0,表示数据队列已为空)。

2.3 管理Friend设备:

图9

管理Friendship相对来说,没有那么多可说的内容,图9基本上可以解释清楚了。当一个Friend节点掉电后,LPN会一直Friend Poll不到消息,进而主动终止FriendShip关系,寻找新的Friend节点。找到新的Friend节点并建立FriendShip关系之后,会由新Friend节点负责发送Friend Clear消息通知旧Friend节点:“你和LPN节点的友谊关系已经结束了,现在LPN已经跟了我了”,旧Friend节点收到后,回复Friend Clear Confirm,也终止了FriendShip关系,不再为LPN设备缓存消息。

新Friend节点是如何知道旧Friend节点的地址的呢?其实是LPN设备通过Friend request消息中的PreviousAddress字段告诉他的。看到这里明白了,LPN设备挺阴险呀,自己不愿意告诉旧Friend节点:“我们已经结束了”,而是告诉新Friend节点关于旧Friend的信息,让新Friend去当这个坏人。

2.4 安全性:

图10

Friendship是Friend节点和LPN节点之间的私事,不想让其他节点知道,因此通信过程中使用了私有的密钥进行加解密,私有的EncryptionKey,PrivacyKey和NID,这三个元素的生成规则如图10,叫做friendship security material,阅读过我的前几篇文章的朋友,会知道这三个都是用来加密和混淆network层的数据包的。

Friend Poll,Friend Update,Friend Subscription List Add/Remove/Confirm message和Friend节点缓存的消息,这几个是使用friendship security material进行加解密和混淆的。

Friend Request,Friend Offer,Friend Clear和Friend Clear Confirm消息仍然使用网络主密钥进行加解密。

Friendship中的涉及的seq number,LPN的seq number也会引起主网络的IV Update。虽然没用使用主密钥,但是Mesh网路中每个设备的seq number只有一个,无论它有几个网络。

LPN节点在publish的时候,可以选择Friendship的密钥,也可以选择主密钥。选择前者需要Friend节点帮助它把消息relay出去,使用后者则相当于直接发送状态到网络中。根据Publish 消息的Friendship Credentials Flag的值,用来表示选择这两种方式中的哪一种。

图11

上图中,虚线表示使用friendship的密钥进行加密,实线表示使用网络主netkey的派生密钥进行加密。OutMsg1是通过Friend节点relay出去的,OutMsg2是直接发送去的。

这里要提到一点,如果使用ellisys抓包分析Friend和LPN节点的通信过程的话,需要把FriendShip建连时的Friend Request和Friend Offer也抓到,不然ellisys无法计算出friendship的密钥,无法解密出Friend Poll和Friend Update消息。

三.工程限制:

协议的设计可以很理想化,工程落地则应该接地气。应了那句话,理想很丰满,现实却是很骨感。很多IOT产品在硬件设计时,出于对成本的考虑,往往选择比较便宜BLE芯片,这在某种程度上增加了Mesh开发的难度,工程师们不仅仅要理解Mesh协议的细节,还要根据现有的硬件能力做优化,做妥协和增加额外的设计,可能这就是做设计和做工程的区别。

从事蓝牙Mesh的开发,经常会遇到各种硬件条件的限制:

1.没有使用独立的BLE芯片来支持Mesh,而是使用了WiFi/BT的combo芯片,很多时候Combo芯片只有一根天线,WiFi和BT分时复用,因此Mesh无法开启100%的扫描窗口,WiFi和BT对天线的使用进行切换时,也会有切换时间的损耗。

2.处理器能力偏弱,很多controller不支持多级中断,在各种状态切换时,会引入多余的时延。

3.LPN节点无法单独使用,需要在其周边配置Friend功能的Mesh节点,已给他缓存消息。

4.Friend节点搭配LPN节点一起使用时,需要二者的时序完美的配合才能正常工作,如果每次LPN来Friend节点Poll消息时,Friend节点都处于非BLE扫描的状态,就会导致LPN节点无法获取Mesh消息,或者Poll消息成功率低。

  • 2
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

GuoFeng.Wan

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值