（一）深入理解蓝牙Mesh的虚拟地址

目录

一.前言：

二.virtual address定义：

三.virtual address工作过程：

四.个人总结：

config阶段：

非config阶段：

五.提问与回答：

---

一.前言：

非常幸运有机会在国内两家智能音箱头部公司从事蓝牙mesh的开发。在撸代码之前先要阅读官方mesh spec，否则无从下手，但由于实际项目中，没有使用到virtual address，所以对这一部分并没有深入理解，走马观花一样看了一眼介绍而已，如今利用休息时间，打算再次仔细阅读一下mesh spec，遇到的第一个比较难理解的就是virtual address，这个地址干嘛用，为什么不用group address代替，为什么叫做virtual address？它哪里virtual了？带着这些疑问，我又仔细捋了一下协议细节，理解如下。

二.virtual address定义：

个人理解：virtual address代表着一组单播地址（这跟group address一样呀），每一个virtual address逻辑上代表着一个128-bit的Label UUID，一个甚至更多的element可以配置为发布/订阅这个Label UUID的消息（virtual address逻辑上代表着Label UUID，这个Lable UUID还可以做为订阅和发布的地址，这个Label UUID和地址没有区别呀，但是地址只需要16bits，Label UUID需要128bits，莫非virtual address的使用是为了缩短Label UUID），Label UUID不被传输，并且在upper transport layer层中用作消息完整性检查值的附加数据字段。

个人理解：virtual address是由Label UUID进行hash+salt计算而来的，盐值是使用“vtad”这个字符串生成的，“vtad”就是virtual address的缩写，s1和计算哈希的算法是公开的，看到这里可以断定，virtual address就是为了精简Label UUID的，128bits->16bits，这个Label UUID是干嘛的，为什么要这么用。

个人理解：当收到具有匹配hash值的virtual address的access message时，每个消息对应的upper transport layer将标签UUID用作附加数据，作为对身份验证的一部分消息，直到找到匹配项。（node收到的access message（空中包传过来的）中只有virtual address，而Label UUID在之前已被设置到这个node中，并在node中保存，在upper transport layer用来校验这个virtual address和我的Lable UUID是否是匹配的，如果匹配，则这条消息是发给我的，如果不匹配，那这条消息不是发给我的）。说明access message的空中包中只有virtual address，接收消息的node，会在upper transport layer层计算自己的Label UUID的hash+salt，是否与virtual address匹配。

个人理解：control message是不允许使用virtual address的（Friend request，Friend poll消息属于control message，generic on/off属于access message），Label UUID可以按照[8]中的定义随机生成。configuration client model可以分配和跟踪virtual address，但是也可以使用某些OOB的方式创建virtual address。与group address不同的是，virtual address可以由相关设备商定，不会需要在集中式配置数据库中定义注册，因为它们不太可能重复。我们在应用层的数据库中只记录Label UUID，而virtual address是在收发消息时，在mesh的协议栈中计算出来的。virtual address的值我们不需要在应用层创建，而unicast address和group address是需要在应用层记录的。

个人理解：virtual address方式的一个缺点是，由于Label UUID过大（大于11个字节），在configuration阶段，会导致了需要分包消息来传输Label UUID。查看了Config Model Publication Virtual Address Set消息的结构，里面定义了128bits的PublishAddress，如下图，另外消息的分段重组是Lower transport layer实现的。

三.virtual address工作过程：

provisioner首先通过Config Model Subscription Virtual Address Add消息，将128bit的Label UUID发送给对端mesh设备，同时协议栈会计算出virtual address返回给给应用层，后面应用层就可以使用这个virtual address来发送消息了，对端设备在收到128bit Label UUID后也会在协议栈中保存并计算出virtual address。provisioner要给virtual address发送消息时，将这个消息的目的地址设置为16bit的virtual address，并使用netkey，appkey加密后发往空中（与config阶段不同，这时空中包里面只有virtual address，没有Label UUID），接收端接收到了这个消息，并在transport layer处理时发现dst字段是一个virtual address，然后将自己保存订阅的virtual address拿出来，将这个值与收到的virtual address进行比对，如果相同就处理这个消息，如果不是就忽略这个消息。“目标设备”所订阅的Label UUID可以是出厂时就配置好的，也可以是provisioner通过Config Model Publication Virtual Address Set配置的。

四.个人总结：

virtual address是被协议栈用128bit的Label UUID通过hash+salt计算出来的，不是应用层直接定义的16bit地址，它的作用是为了替换128bit的Label UUID，减少空中包的长度。应用层拿到virtual address后，就可以不在使用Label UUID了，可以直接使用virtual address来替代它。

config阶段：

provisioner通过Config Model Publication Virtual Address Set，Config Model Subscription Virtual Address Add/Delete/Overwrite消息，将Label UUID发往对端mesh设备，收到之后两端mesh设备各自计算出相同的virtual address。Label UUID的值，仅仅在config阶段出现过，并被添加到发送的消息里面，之前提到的“The Label UUID is not transmitted”，指的是除了这几个config消息以外的消息。

非config阶段：

经过config阶段之后，应用层无需再使用128bit的Label UUID了，而是使用协议栈返回的vitrual address来收发数据即可，与group address的使用方式一样。

五.提问与回答：

1.它为什么叫做virtual address，哪里virtual了？

因为应用开发最开始使用的是Label UUID，virtual address是协议栈生成的，所以定义为virtual address。

2.Label UUID有什么用，为什么不用group address代替。

个人理解：Label UUID有128bits，主要用于厂商使用，例如厂商想定义一个本产品私有的“组地址”，然后选择了0xc001（group address），那么其他的厂家不接受了，凭什么0xc001给你们产品用，因此不能使用group address。但是Label UUID不一样，他有128bits，厂家自定义的Label UUID，大概率与其他厂家的Label UUID不同，不会因此产生纠纷。即使两个厂家的持有不同的Label UUID却生成了同样的virtual address，不同的Label UUID也可以证明大家不是故意的，相视一笑，缘分呀，后续也好协商。另外一个原因可能是128bits的Label UUID可以赋予某些含义（pid/cid等等）。

3.代码实现：

 截取了zephyr的一段code，从函数的定义可以看到形参virt_addr是uint16_t *指针类型，可以推断出，virtual address是协议栈计算出来的，我们调用Config Model Subscription Virtual Address Add消息接口时，传入label，然后协议栈subscription这个uuid，同时返回了virtural address地址，我们后续操作这个lable时，无需再次使用16 byte label，使用virtual address即可。