有谁知道那样的网站北京电工本更新需要走什么手续?最新版本是TS开头的。谢谢。

转自如有冒犯,请联系删除

因此本文将换个视角,从协议栈设计者的角度思考如下问题:

为什么会有蓝牙协议栈(Why)?
怎样实现蓝牙协议栈(How)
蓝牙协议栈的最終样子是什么(What)?

另外我们知道,当前的蓝牙协议包含BR/EDR、AMP、LE三种技术为了降低复杂度,本文将focus在现在比较热门的BLE(Bluetooth Low Energy)技术上(物联網嘛!)至于BR/EDR和AMP,触类旁通即可

“Why”要回答的其实是需求问题,对BLE(蓝牙低功耗)来说其需求包含两个部分:和传统蓝牙重叠的部汾;BLE特有的低功耗部分。大致总结如下:

通信速率要求不高但对功耗极为敏感; 尽量复用已有的BR/EDR技术; 组网方式自由灵活,既可以使用傳统蓝牙所使用的“基于连接的星形网络(由1个master和多个slave组成)”也可以使用“无连接的网状网络(由多个advertiser和多个scanner组成); 参与通信的设備的数量和种类众多,要从应用的角度考虑易于实现、互联互通等特性; 有强烈的安全(security)需求;

“How”要回答的是设计思路“What”是基于該思路设计出来的最终产品的样子。

按理说需要先介绍“How”,后介绍所产出的“What”但以蜗蜗对蓝牙的理解,显然无法抛开“What”单独回答“How”所以,基于现有的协议框架(What)去理解背后的“How”,才是明智之举

开始之前,我们先总结一下BLE的协议框架后面章节会根据該框架,采用自下向上的方法逐层分析介绍

图片1 BLE协议框架

任何一个通信系统,首先要确定的就是通信介质(物理通道Physical Channel),BLE也不例外茬BLE协议中,“通信介质”的定义是由Physical Layer(其它通信协议也类似)负责

由于BLE属于无线通信,则其通信介质是一定频率范围下的频带资源(Frequency Band);
BLE的市场定位是个体和民用因此使用免费的ISM频段(频率范围是2.400-2.4835 GHz);
为了同时支持多个设备,将整个频带分为40份每份的带宽为2MHz,称作RF Channel

除了物理通道之外,Physical Layer还需要定义RF收发双方的一些其它特性包括(不影响本文后续的讨论,不用深究):


  

经过Physical Layer的定义通信所需的物理通噵已经okay了,即40个RF Channel(后面统一使用Physical Channel指代)此时Link Layer可以粉墨登场了,它主要的功能就是在这些Physical Channel上收发数据,与此同时不可避免的需要控制RF收发相关的参数。但仅做这些还远远不够:

其次,通信是两个实体之间的事情对这两个实体来说,它们希望看到一条为自己独享的传輸通道(就是我们所熟悉的逻辑链路Logical Link)。这也是Link Layer需要解决的; 再则Physical Channel是不可靠的,任何数据传输都可能由于干扰等问题二损毁、丢失這对有些应用来说,是接受不了的因此Link Layer需要提供校验、重传等机制,确保数据传输的可靠性; 等等等等,简直是既当爹又当妈!

BLE系统呮有有限的40个Physical Channel怎么容纳多个通信实体呢?说来也简单Link Layer将BLE的通信场景分为两类:

1) 数据量比较少、发送不频繁、对时延不是很敏感的场景

例如一个传感器节点(如温度传感器),需要定时(如1s)向处理中心发送传感器数据(如温度)

针对这种场景,BLE的Link Layer采取了一种比较懒嘚处理方式----广播通信:

在广播通道上任何参与者,爱发就发爱收就收,随便; 所有参与者共享同一个逻辑传输通道(广播通道),の间的

当然这种方法存在很多问题,例如:

不可靠是否会相互干扰?发送是否成功不知道!接收是否成功?不知道!
效率不高如果同一区域有很多节点在广播数据,某一个接收者是不是要接收所有的数据包不管是不是它关心的?

确实问题多多,不过Link Layer定义了一些筞略尽可能的提高了这种通信方式的便利性,后面我们会介绍至于无法解决的,简单两种方案:

a)忍,广播通信需要占用的资源实茬太少了正对物联网中的那些小节点们的胃口啊。
b)使用基于连接的通信方式(就是给你俩建立一个专线)具体可参考下面5.2.2的介绍。

2)数据量较大、发送频率较高、对时延较敏感的场景

同时为了增加容量,增大抗干扰能力连接不会长期使用一个固定的Physical Channel,而是在多个Channel(如37个)之间随机但有规律的切换这就是BLE的跳频(Hopping)技术。

基于上面5.2小节的思路BLE协议在Link Layer抽象出5种状态:

注1:从横向看,协议的每个层佽(如这里的Link Layer)都可以当做可相互通信的实体这里的状态,就是指这每一层实体的状态因此,在协议的多个层次上都可能有状态定義,甚至名字也一样我们阅读协议栈的时候,一定要留意不要被绕晕了。

并以如下的状态机进行切换(设备在同一时刻只能处于这些狀态的一种):

Standby状态是初始状态即不发送数据,也不接收数据根据上层实体的命令(如位于host软件中GAP),可由其它任何一种状态进入吔可以切换到除Connection状态外的任意一种状态。

Advertising状态是可以通过广播通道发送数据的状态由Standby状态进入。它广播的数据可以由处于Scanning或者Initiating状态的实體接收上层实体可通过命令将Advertising状态切换回Standby状态。另外连接成功后,也可切换为Connection状态

Scanning状态是可以通过广播通道接收数据的状态,由Standby状態进入根据Advertiser所广播的数据的类型,有些Scanner还可以主动向Advertiser请求一些额外数据上层实体可通过命令将Scanning状态切换回Standby状态。

Connection状态是和某个实体建竝了单独通道的状态在通道建立之后,由Initiating或者Advertising自动切换而来通道断开后,会重新回到Standby状态

通道建立后(通常说“已连接”),处于Connection狀态的双方分别有两种角色Master和Slave:

状态和角色定义完成后,剩下的事情就简单了主要包括两类:提供某一状态下,和其它实体对应状态の间的数据交换机制;根据上层实体的指令以及当前的实际情况,负责状态之间的切换BLE协议中,这些事情是由一个叫做空中接口协议(Air Interface Protocol)的家伙负责主要思路如下。

关于packet format我们可以关注如下内容:
2)PDU,BLE在Link Layer的PDU长度最大为257 octets(不知道octets是神马意思当做bytes就行了)。这决定了上層实体如L2CAP、Application等,需要拆分、重组才能支持更大数据量的传输

5.4.2 定义不同类型的PDU及其格式

由5.3小节的描述,Link Layer有5种状态每种状态下所传输数據的功能不尽相同,基于此Air Interface Protocol定义出如下的PDU类型(这里只简单列举一下,不深入讨论):

已连接的双方进行数据通信所用的PDU有效的payload长度為0~251bytes。
用于管理、维护、更新已连接的数据通道的PDU包括:
LL_TERMINATE_IND,告知对方此次连接即将结束以及结束的原因;

主要针对广播通道,因为随着通信设备的增多空中的广播数据将会呈几何级的增长,为了避免资源的浪费(特别是BLE Host)有必要在Link Layer过滤掉一些数据包,例如根据蓝牙地址过滤掉不是给自己的packet。

5.4.4 执行广播通道上实际的packet收发操作

上层软件只需要定义一些参数例如:

Link Layer将会自动发送或者接收数据包。

5.4.5 定义连接建立的方式及过之后的应答、流控等机制

经过Air Interface Protocol的抽象BLE实体已经具备广播通信、点对点连接的建立和释放、点对点通信等基本的能力。除此之外Link Layer又抽象出来一个链路控制协议(Link Layer Control),用于管理、控制两个Link Layer实体之间所建立的这个Connection主要功能包括:

更新该连接所使用的跳频图譜(使用哪些Physical Channels); 执行链路加密(Encryption)有关的过程。

定义Host和Controller(通常是两颗IC)之间的通信协议可基于Uart、USB等物理介质,对理解蓝牙协议来说昰无关紧要的,这里暂不介绍

经过Link Layer的抽象之后,两个BLE设备之间可存在两条逻辑上的数据通道:一条是无连接的广播通道天高任鸟飞;叧一条是基于连接的数据通道,是一个点对点(Master对Slave)的逻辑通道

广播通道暂且不表,这个数据通道(后面简称逻辑通道Logical Channel),要怎么使鼡还需要一番思索,例如:

Logical Channel只有一条而要利用它传输数据的上层应用却不止一个(例如图片1中的ATT和SMP),怎么复用
Logical Channel所能传输的有效payload长喥最大只有251bytes,怎是否意味着上层应用每次只能传输少于这个长度的数据(显然不能!)
Logical Channel仅提供了简单的应答和流控机制,如果传输的数據出错怎么办
Support for Streaming,支持流式传输(如音频、视频等不需要重传或者只需要有限重传);

鉴于篇幅问题,本文重点介绍有利用理解上层协議(ATT、GATT等)的“Protocol/channel multiplexing”功能其它部分会在后续L2CAP的分析文章中重点说明。

所谓的multiplexing(多路复用)还是很好理解的:

可用于传输用户数据的逻辑鏈路只有一条,而L2CAP需要服务的上层Profile和Application的数目肯定远不止这个数量。因此需要使用多路复用的手段,将这些用户数据map到有限的链路资源仩去

至于multiplexing的手段,简单又直接(称的上“协议”的标配):

数据发送时将用户数据分割为一定长度的数据包(L2CAP Packet Data Units,PDUs)加上一个包含特萣“ID”的header后,通过逻辑链路发送出去
数据接收时,从逻辑链路接收数据解析其中的“ID”,并以此判断需要将数据转发给哪个应用

这裏所说的ID,就是多路复用的手段L2CAP提供两种复用手段:

这里的连接,是指基于L2CAP的应用程序在通信之前,先建立一个基于Logical Channel的虚拟通道(称莋L2CAP channel和TCP/IP中的端口类似)。L2CAP会为这个通道分配一个编号称作channel ID(简称CID)。

那CID是怎么确定的呢有一些固定用途的L2CAP Channel,其CID是固定值另外一些则昰动态分配的,具体如下:

另外为了提高数据传输的效率,方便广播通信等应用场景L2CAP在提供基于连接的通信机制之外,也提供了无连接的数据传输方法基于这种方法,CID不存在了取而代之的是一个称作Protocol/Service Multiplexer(PSM)的字段。

这种多路复用的手段则成为Protocol multiplexing(基于协议的多路复用)

Channel,鉯便提供应用程序级别的通道复用到此之后,基本协议栈已经构建完毕应用程序已经可以基于L2CAP欢快的run起来了。

谈起应用程序就不得鈈说BLE的初衷----物联网。物联网中传输的数据和传统的互联网有什么区别呢抛开其它不谈,物联网中最重要、最广泛的一类应用是:信息的采集

这些信息往往都很简单,如温度、湿度、速度、位置信息、电量、水压、等等
采集的过程也很简单,节点设备定时的向中心设备彙报信息数据或者,中心设备在需要的时候主动查询

基于信息采集的需求,BLE抽象出一个协议:Attribute protocol该协议将这些“信息”以“Attribute(属性)”的形式抽象出来,并提供一些方法供远端设备(remote device)读取、修改这些属性的值(Attribute value)。

2)采用client-server的形式提供信息(以后都称作Attribute)的一方称莋ATT server(一般是那些传感器节点),访问信息的一方称作ATT client

Attribute Value代表Attribute的值,可以是任何固定长度或者可变长度的octet array(理解为字节类型的数组即可)

茬蓝牙协议中,profile一直是一个比较抽象的概念我们可以将其理解为“应用场景、功能、使用方式”都被规定好的Application。传统的BR/EDR如此BLE更甚。上媔我们讲过BLE很大一部分的应用场景是信息(Attribute)的共享,因此BLE协议栈基于Attribute Protocol,定义了一个称作GATT(Generic Attribute)的profile framework(它本身也是一个profile)用于提供通用嘚、信息的存储和共享等功能。

蓝牙4.0之后所引入的GATT profile是一个非常有“心计”的profile,其中有三点需要我们重点关注:

1)基于GATT架构,Application的存在形式不再是单一的Profile,很多简单的应用场景可以直接以Service的形式存在(profile的概念隐藏在了GATT中),这大大简化了一些传感器节点的设计复杂度
2)仔细瞅一下图片4中的Service,然后回忆一下蓝牙BR/EDR中的服务发现协议(Service Discover ProtocolSDP)中的“Service”,是否有什么关联你猜对了,非常有关联在存在GATT的实现Φ,SDP就没有存在的必要了Service也是一个普通的Generic Attribute。也正是因为这样的抽象才使得以往蓝牙协议中的“Service”实例化了。
3)所谓的“Service”实例化指嘚是,任何一个profile都是由service和对应的profile功能组成。

Security Manager负责BLE通信中有关安全的内容(毫无疑问在物联网时代,安全变得更重要谁也不想卧室的燈在深夜的时候会无缘无故的亮吧),包括配对(pairing,)、认证(authentication)和加密(encryption)等过程

该部分的内容比较独立,这里先不过多介绍后面会囿单独的分析文章。

上面7到10章的内容都是和基于连接的data channel有关,至于无连接的advertising channel以及连接建立的过程,好像被我们忽略了虽然Link Layer已经做出叻定义(具体可参考第5章的介绍),但它们并没有体现到Application(或者Profile)层面毕竟Link layer太底层了。

因此BLE协议栈定义了一个称作Generic Access(通用访问)的profile,鉯实现如下功能:

1)定义GAP层的蓝牙设备角色(role)

和5.3中的Link Layer的role类似只不过GAP层的role更接近用户(可以等同于从用户的角度看到的蓝牙设备的role),包括:

4)Security有关的定义暂不介绍

暂不介绍了,后续其它文章会结合某些Profile及应用场景的室例作进一步分析。

      最近抽出了点时间弄了下vue ssr项目,至于ssr的优点就不多提了学习路线参照了,有兴趣的同学可以去看下

拿之前的老项目重构的,由于vue-cli 2.0用起来不太好以及当初自己摸索嘚vuex写法比较恶心,就只搭个实例了,有兴趣的觉得写了这么多废话有点用的同学欢迎start。

有兴趣的同学可以一起讨论,无时不在

      最近抽出了点时间弄了下vue ssr项目,至于ssr的优点就不多提了学习路线参照了,有兴趣的同学可以去看下

拿之前的老项目重构的,由于vue-cli 2.0用起来不太好以及当初自己摸索嘚vuex写法比较恶心,就只搭个实例了,有兴趣的觉得写了这么多废话有点用的同学欢迎start。

有兴趣的同学可以一起讨论,无时不在

我要回帖

更多关于 谁知道那样的网站 的文章

 

随机推荐