蓝牙网络架构图(蓝牙协议体系结构图)

网络设计 373
本篇文章给大家谈谈蓝牙网络架构图,以及蓝牙协议体系结构图对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。 本文目录一览: 1、蓝牙mesh网络层及网络PDU解析

本篇文章给大家谈谈蓝牙网络架构图,以及蓝牙协议体系结构图对应的知识点,希望对各位有所帮助,不要忘了收藏本站喔。

本文目录一览:

蓝牙mesh网络层及网络PDU解析

网络层定义了网络PDU格式,允许承载层传输下层传输层的PDU。它对输入接口接收的传入消息进行解密和身份验证,并将其转发到上层和/或输出接口,对传出消息进行加密和身份验证并将其转发到输出网络接口。

网络层定义了4种地址类型,地址长度为16位。

如下图:

单播地址范围从0x0001到0x7FFF,可以有32767个单播地址。

虚拟地址范围从0x8000到0xBFFF,可以有16384个虚拟地址。

组播地址范围从0xC000到0xFFFF,可以有16384个组播地址。组播地址包括256个固定组播地址和16128个可动态分配的组播地址。

蓝牙mesh对节点没有并发性限制或限制。

当与低功耗蓝牙传输一起使用时,该规范不存在拓扑限制或限制。

意味着什么?能分配多少单播个地址,就能有有多少个设备。虚拟地址、组播地址和单播地址是可以共存的,所以设备的个数,只能以单播地址计算。比如,一个设备即可以同时属于组1、组2,设备还有单播地址,一下就用掉了3个地址,但是只有一个设备。所以一个网络中可以有32767个有效地址。

未分配地址的意义在于,可以通过将模型的发布地址设置为未分配地址来禁用模型的消息发布。那这里有个问题,网络层在发现是未分配地址的消息会怎么做,未分配地址的消息是在网络层拦截还是在承载层拦截?meshNetworkManager。

单播地址即可在消息的源地址字段中使用,也可在消息的目标地址字段中使用。发送到单播地址的消息最多只能由一个元素处理。在配网阶段,配网器会在网络节点的生命周期内为节点的每个元素分配单播地址。该地址可以由配网器取消分配,以允许被重用。

虚拟地址表示一组目标地址。每个虚拟地址在逻辑上代表一个标签UUID,它是一个128位的值,无须集中管理。一个或多个元素可以配置发布或订阅同一个标签UUID。标签UUID不会被传输,应该用作上层消息层中消息完整性校验值的附加数据字段。虚拟地址涉及Hash值的计算。(这里无须对虚拟地址做过多研究,后面自然就清楚了)

组播地址从0xFF00到0xFFFF的组播地址保留给固定的用途,从0xC000到0xFEFF的组播地址可以用作其他用途。组播地址只能在消息的目标地址中使用。发送给组播地址的消息会被订阅这个组播地址的所有模型实体接收到。

这句话对不对,那么任何一个BLE设备都可以加入mesh网络?该如何解读?

网络层支持通过多个承载器发送和接收消息。一个承载器可能存在多个实例。承载器的每个实例都可以通过网络接口连接到网络层。例如,一个节点可能有三个承载器:一个广播承载器和两个GATT承载器的接口。

一个网络中,如果有两个配网器会怎么样?一键配网和多配网器是两个概念。

接口输入过滤器决定传入的网络消息是交付给网络层进一步处理,还是将其删除。

接口输出过滤器决定是将消息传给承载层还是删除。接口输出过滤器删除所有TTL值为1的消息。

本地网络接口允许在同一个节点内的元素之间发送消息。每个节点都应该实现一个本地网络接口。通过本地网络接口接收消息后,应该将所有消息发送给节点的所有元素处理。

广播承载器的网络接口,允许使用广播承载器发送消息。APP端不做研究。

中继功能用于中继节点或转发节点通过广播承载器接收的网络PDU。此功能是可选的,如果支持此功能,则可以单独启用和禁用此功能。如果支持代理特性,则必须同时支持GATT承载器和广播承载器。

代理功能指节点在GATT承载网络和广播承载网络之间中继或转发网络层PDU来实现GATT承载网络和广播承载网络间的消息互通。此功能是可选的,如果支持此功能,可以单独启用和禁用此功能。如果支持代理特性,则同时支持GATT和广播承载。

节点收到来自承载层的消息后,检查NID字段值是否匹配一个或多个已知的NID。如果NID字段的值与已知的NID不匹配,则该消息将被忽略。如果NID字段的值与已知的NID匹配,节点将根据每个已知的匹配的网络密钥验证消息。如果消息没有对任何已知的网络密钥进行验证,则该消息将被忽略。如果消息确实根据网络密钥认证,SRC和DST字段被认为是有效的,并且消息不在网络消息缓存中,那么该消息将由较低的传输层处理。

当一条消息被重传时,定义如下,重传时使用的IV索引应与接收时的IV索引相同。

如果节点的网络层收到了广播承载器分发过来的消息,通过了验证,要上报给底层传输层处理时,如果节点启用了中继功能,TTL字段的值为2或更大,且元素的目标地址不是这个节点的任何一个单播地址,那么TTL字段值应该减1,网络层PDU应标记为中继PDU,并转发给连接到广播承载层的所有网络接口。建议在接收网络PDU和中继网络PDU之间设置一个较小的随机延迟,以避免同时接收同一个网络PDU的多个中继消息而发生冲突。

如果节点的网络层收到了来自GATT承载器(如果是广播承载器)的消息,并通过了验证,要上报给底层传输层处理时,如果节点支持代理功能且代理功能是开启的,同时TTL字段的值为2或更大,且目标地址不是本节点的任何一个元素的单播地址,那么设置该消息TTL值减一,并转发这个消息到所有网络层接口(转发到与GATT承载器连接的所有网络层接口)。

参照网络层PDU格式生成数据包,然后调用承载层进行传输即可。

网络消息缓存

为了减少不必要的安全检查和过度的中继,一个节点应该包括所有最近看到的网络pdu的网络消息缓存。如果收到的网络PDU已经在网络消息缓存中,则不处理网络PDU(即立即丢弃)。如果接收到一个网络PDU,而该网络PDU不在网络消息缓存中,则可以对网络PDU进行处理(例如,根据网络安全性进行检查),如果它是一个有效的网络PDU,则应该存储在网络消息缓存中。

节点不需要缓存整个网络PDU,可以只缓存一部分用于跟踪,例如NetMIC、SRC/SEQ或其他的值。只要能在设备能力的限制范围内实现不多次处理同一网络PDU,筛选条件是可以自定义的。

当网络消息缓存已满,需要缓存一个新的网络PDU时,一个新的网络PDU将取代网络消息缓存中已经存在的最久的网络PDU。

网络消息缓存应该能够存储至少两个网络pdu,尽管强烈建议拥有一个适合预期网络密度的网络消息缓存大小。传入消息处理过程的细节还是留给开发者自己实现。

收到- 0x003EBB5242C5F1E3FDFB18251C5942BFE8EC25CC767D1E1AE1FDD9C73CC0

networkKey: F9B024F55B95EFA75F6B2B8D8D3A3F5C

NetworkPdu.pdu = 0x3EBB5242C5F1E3FDFB18251C5942BFE8EC25CC767D1E1AE1FDD9C73CC0

ivi==== 0

nid==== 0x3E(10进制62)

解混淆时的keys.privacyKey:A212C7601572F72C15EBA917***75D9D0

解混淆时的ivIndex:0

解混淆的结果:050000030003

===ctl:0,

===ttl:5,

===sequence:3,

===source:3,

===netMicSize:4

===micOffset:25,

===destAndTransportPdu:FDFB18251C5942BFE8EC25CC767D1E1AE1FD,

===mic:D9C73CC0

====nonce:00050000030003000000000000,

keys.encryptionKey:DA33D708B9D25EDE5FDE26BBC1EC848A

decryptedData:0001800008034458CCC398FD700CF04E7C05,

destination:1,

transportPdu:800008034458CCC398FD700CF04E7C05

收到- 0x003EDC3EEFD43C51766AE52CE58BD0969F312C144A14753C9B28EAA5BB8B

networkKey: F9B024F55B95EFA75F6B2B8D8D3A3F5C

NetworkPdu.pdu = 3EDC3EEFD43C51766AE52CE58BD0969F312C144A14753C9B28EAA5BB8B

ivi==== 0

nid==== 0x3E(10进制62)

解混淆时的keys.privacyKey:A212C7601572F72C15EBA917***75D9D0

解混淆时的ivIndex:0

解混淆的结果:050000040003

===ctl:0,

===ttl:5,

===sequence:4,

===source:3,

===netMicSize:4

===micOffset:25,

===destAndTransportPdu:766AE52CE58BD0969F312C144A14753C9B28,

===mic:EAA5BB8B

====nonce:00050000040003000000000000,

keys.encryptionKey:DA33D708B9D25EDE5FDE26BBC1EC848A

decryptedData:0001800008231CDC2FCB23CD2EB4C47D8BE8,

destination:1,

transportPdu:800008231CDC2FCB23CD2EB4C47D8BE8

蓝牙模块的原理与结构

蓝牙的原理,就不在这里细说了。因为百度搜索一下非常的多,并且异常的复杂,

这里简单的归类总结:蓝牙是一种短距离无线通讯技术,最大的优势就是集成在手机里面了。同时不算大也不算小的带宽,就能支持音乐播放,同时跳频机制,就增加了蓝牙的稳定性

蓝牙模块,串口蓝牙模块等等产品,顾名思义就是实现蓝牙功能的半成品模块产品。主要由蓝牙芯片和*** 元器件组成,从而形成一个可以直接供用户使用的产品。正因为蓝牙芯片的种类繁多,所以很多工程师在选择的时候,不知道该怎么选

选择合适的蓝牙模块,最重要的是选择蓝牙模块最核心的主控芯片,因为主控芯片的性能,直接决定了蓝牙模块的功能,以及一些重要的参数,比如:蓝牙版本、模块体积、功耗、音频、BLE速率等等核心的参数

蓝牙Mesh概念介绍

一个智能设备在未加入蓝牙Mesh网络之前称为Device,加入Mesh网络(Porvisioning过程)后,称为Node(节点)。每个Node可以包含多个Element(比如智能插排,每一个插孔都是一个Element),一个Element对应一个Unicast address(16bits,32767个地址,bit15=0);每个Element可以包含多个Model(用来发送、接收和处理Message),每个Model对应一个Model ID(可以分SIG ModelID和Vendor Model ID),类似这个Model的地址。其中,SIG Model ID是16bits的,SIG组织定义的专用Model ID,SIG Model ID参考例子如下图所示,而Vendor Model ID是32bits的,由16bits的Company ID和16bits的Vendor-assigned Model ID组成。

下图是Mesh网络分层结构,工程师Coding的时候,一般操作其中的Access Layer,也就是打包Access Payload。Access Payload的包结构分为两个字段:Opcode+Parameter。每个Access Payload可以最多是32个Segment(12字节),也即最多384个字节(包含TransMIC),如果TransMIC是4字节,则有效载荷是380字节,可以有3种组合:1字节的Opcode(For Special Message)+379字节的Parametes;2字节的Opcode(For Standard Message)+378字节的Parameters;3字节的Opcode(For Vendor-Specific Message)+377字节的Parameters。当然,如果Unsegment,则Access Payload最多可以有11字节。

Mesh网络是消息驱动的架构,每个Model处理一类Messages,消息分ACK和非ACK消息,比如对应上述的Generic OnOff Server的Model,需要处理以下图所示的Messages。

另外Messages可以支持Transactions(通过Transaction Identifier识别),在一个Transaction里面支持一系列Messages,比如Set,Recall和Clear等。Transaction Identifier可以识别这个消息是个新消息还是一个重发的之前的旧消息。

Generic OnOff Set这个消息的包结构如下图所示:

一个Messages只能对应一个Model,如果需要处理两个相同的Message,则需要设置两个不同的Element和Model来处理。如下图所示,这个智能插排设备需要同时控制两个插座的开和关,因此需要处理两个相同的Generic OnOff Set的Message,当该设备加入Mesh网络成为一个Node后,该Node需要设置两个Element,获得两个unicast address,并配置两个Generic OnOff Server的Model,分别处理Generic OnOff Set的Message(通过Unicast address区别)

关于所有Messages的Opcode定义,可以参考文档《Bluetooth Mesh Profile specification》的4.3.4和文档《Bluetooth Mesh Model specification》的7.1。

蓝牙的核心架构包括

蓝牙核心系统架构包括:链路管理、链路控制和BR/EDR无线电模块共同组成。

所谓蓝牙(Bluetooth)技术,实际上是一种短距离无线通信技术,利用“蓝牙”技术,能够有效地简化掌上电脑、笔记本电脑和移动电话手机等移动通信终端设备之间的通信,也能够成功地简化以上这些设备与Internet2~间的通信。

链路管理器的功能是对本地或远端蓝牙设备的链路性能进行设置和管理。蓝牙设备的链路管理器接收到高层的控制信息后,不是向自身的基带部分发送控制信息,就是与另一端设备的链路管理器进行协商。

对于蓝牙Profile的理解

众所周知,蓝牙中有很多的profile,我们接触和学习蓝牙相关的开发不可避免的需要弄懂什么是Profile ,但它对于新手而言似乎没那么容易弄懂,即使是有经验者也很难形象的描述profile的含义,这里我尝试写下自己的理解,以便记录和总结,日后有新的理解不断更新。

Profile中文译名有很多,比如配置文件,剖面,应用协议,轮廓等,每一种翻译代表了一种对于profile的不同理解,以我个人的理解来说,可能中文中并没有那么合适的词与之对应,但我觉得** 剖面 **这个说法可能更贴切一点。

因为profile其实是蓝牙对应于每一个具体的应用场景以及每一种应用的不同的协议栈,也就是说它其实是实现某种功能对应的自下而上的协议的组合。类似于对于横向协议的纵向组合。

这里我们不得不简单的介绍一下蓝牙的协议栈组成结构。

以上是蓝牙协议栈的概要结构示意图,我们大致的看一眼,会觉得他是不符合OSI和TCP/IP的网络模型的。

蓝牙中有很多的Profile, 我没有找到确切的资料总共有多少种profile,但我们常见的莫过于那几种,而且porile之间也并非平行的关系,他们是相互依赖组合构成的,存在明显的层级关系的。

上图是一个层级划分,所有的profile都是直接或间接依赖于GAP的,都是GAP的superset,然后是用于构成多数Application profile的generic profile,这里有四种:

其他剖面成为应用剖面,主要面向各个应用。

自从开始接触蓝牙,我就有一个疑问,就是为什么蓝牙有那么多的profile,以至于他把自己的协议栈弄得如此的复杂 ? 而不像其他的网络协议一样只负责为通信实体提供信道,将其他的交给应用去做呢?

至今我仍然没有找到很好的资料去解释这一问题,但我们可以大概的从此类问题通用的角度去考虑, 我们有几个不错的角度:

这里借用《计算机网络 第五版》中的一段话:

这里他的观点是因为蓝牙兴趣小组是各自为战的,因此缺少必要的协同而导致的蓝牙协议栈的分裂,最终形成了几十个协议栈并存的局面。

也就是最初各个协议的标准可能是由各个公司自己研发,最终经过蓝牙标准组织认定的。

由于组织架构的原因,各个公司组织将自己设计的通信标准纳入到了蓝牙标准中去,形成了特有的profile式的协议栈结构,后来随着技术发展,新的事物新的技术不断出现,当需要为蓝牙标准添加新的场景的时候,就只能遵循现有的蓝牙技术框架,不断地为其添加profile。

虽然没有任何材料的佐证,但是我觉得蓝牙协议栈的问题可能不仅仅是组织架构问题和松散兴趣联盟话语权的妥协,我始终觉得一个得以流行全世界的一种技术,一定经过了一定指向性和预见性的顶层设计的,一定是经过利弊权衡后的结果,而绝非简单的Conway法则的必然呈现。

我能够想到的就是对比于其他的网络协议核心的特点就是** 协议栈定制性 **, 而相对于其他的而言就是通用性和扩展性的上的缺陷,我们来从概念上思考一下,我们可以猜测到一下的优点:

(1) 避免了通用性带来的***浪费和设计冗余,定制化可以针对特定的应用优化通信流程,帧结构等提高传输效率,稳定性和节省成本。

(2) 分散设计带来的设计成本的减少,拼接式的协议栈构最大程度的接纳每一种场景设计而避免了协议并入的冲突,减少了各个企业成员之间的协同成本,提高了设计效率。

(3) 特定的终端不必要仅仅需要实现特定的profile即可实现目的,适用于功能单一而且低功耗终端。

(4) 减小了企业的设计成本和难度,利于蓝牙技术的推广。

(5) 推动了场景标准化,打通设备和应用阻隔。

当然以上的很多都是我自己的猜测,需要更多的资料去论证,先记录下来,以后不断修正。

2011年之前我们还拿着诺基亚,用着每月30M的2G网络,不得不使用手机蓝牙和朋友们交换照片,mp3,电子书,可是当智能机时代,4G网络,家庭WIFI的到来,很少人再用蓝牙去传输一个小小的文件了,甚至我们都使用其他的任何局域自组网技术,直接走Internet来传输了。随着时代合计数的进步,很多的蓝牙profile必然会被抛弃,而留下的将会是特定化用途的不可取代的profile。

其实很多的蓝牙技术我们生活中也很少能够见到,以有限的未来来看,我觉的能够保存不错的活跃度的profile有两种:

以我自己的观点来看,在近几年,我们主要会以蓝牙作为个人自组网的连接方式,而WIFI会作为室内或者家庭的组网方式。

当然未来的事情谁也说不准,我们在过去的几年里见识过,预见不了未来并不意味着没必要去想象未来,只有做好准备,他来的时候,你才会淡定的说,你和我想的差不多。

蓝牙低能耗的BLE的两种芯片架构

单模芯片和双模芯片

1、低功耗蓝牙单模芯片

蓝牙单模器件是蓝牙规范中新出现的一种只支持蓝牙低能耗技术的芯片——是专门针对ULP操作优化的技术的一部分。蓝牙单模芯片可以和其它单模芯片及双模芯片通信,此时后者需要使用自身架构中的蓝牙低能耗技术部分进行收发数据。

单模芯片可以用单节钮扣电池工作很长时间(几个月甚至几年)。相反,标准蓝牙技术(和蓝牙低能耗双模器件)通常要求使用至少两节AAA电池(电量是钮扣电池的10至12倍,可以容忍高得多的峰值电流),并且更多情况下最多只能工作几天或几周的时间(取决于具体应用)。注意,也有一些高度专业化的标准蓝牙设备,它们可以使用容量比AAA电池低的电池工作。

简单总结

蓝牙单模芯片=BLE

只实现了BLE

部分实现了单模的蓝牙的厂商:STMicroelectronics, AMICCOM, CSR, Nordic Semiconductor, Texas Instruments

成本降低后的单模的蓝牙芯片,支持整合到高度集成和紧凑的设备,带有一个轻量级的链接层Link Layer,支持超低功耗的空闲idle模式操作,简单的设备发现,非常节能的单点对多点数据传输,以尽可能低的功耗下的安全加密连接

专门针对ULP操作优化了。

2、低功耗蓝牙双模芯片

双模芯片也能与标准蓝牙技术及使用传统蓝牙架构的其它双模芯片通信。

双模芯片可以在目前使用标准蓝牙芯片的任何场合使用。这样安装有双模芯片的手机、PC、个人导航设备(PND)或其它应用就可以和市场上已经在用的所有传统标准蓝牙设备以及所有未来的蓝牙低能耗设备通信。然而,由于这些设备要求执行标准蓝牙和蓝牙低能耗任务,因此双模芯片针对ULP操作的优化程度没有像单模芯片那么高。

简单总结

双模==Bluetooth Classic+BLE、

将Bluetooth Smart即BLE集成到已有的经典的蓝牙协议中

部分实现了双模蓝牙的厂商:Qualcomm-Atheros, CSR, Broadcom and Texas Instruments

用架构图表示如下:

请点击输入图片描述

关于蓝牙网络架构图和蓝牙协议体系结构图的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。

扫码二维码