RW_BLE_CORE记录

传输信道

BLE的传输信道在2.4G频段有40个channel。包括2种物理信道：广播信道和数据信道。数据帧中设置Access Address用于标识该信道，防止信道碰撞。Channel MAP如下：

数据帧通信

蓝牙帧结构如下：

Preamble：根据Access Address而定，假如AA的LSB（最右bit）bit为1，则前导便是10101010b，反之则为01010101b。

Access Address：广播帧的AA为：0x8E89BED6。其他情况可以是一个32bit的随机数。AA需满足以下条件

·不超过连续6个1或者0。

·与广播帧的AA不同bit超过1个。 ·不能4byte相同。

·0 1跳变不能超过24次

·MSB 6bit 0 1跳变超过2次。 以下逐个介绍PDU。

一、Advertising Channel PDU

蓝牙广播帧帧结构

其中Header的帧格式如下：

其中，

a、广播帧类型（PDU Type）分为以下几类：

? ADV_IND: connectable undirected advertising event

? ADV_DIRECT_IND: connectable directed advertising event ? ADV_NONCONN_IND: non-connectable undirected advertising event

? ADV_SCAN_IND: scannable undirected advertising event

b、Length：3~37bytes 广播帧分为很多种，其区别就是payload所代表的意义不同，以下分别对几种广播帧作分别阐释： 1、ADV_IND

ADV_IND的payload格式如下：

在广播帧帧头中的TxAdd位是广播地址的标示位： TxAdd==0：AdvA地址为公用地址； TxAdd==1：AdvA地址为随机地址。 AdvData则是广播HOST的广播数据。

2、ADV_DIRECT_IND

这种帧用于直接接入的广播事件。

ADV_DIRECT_IND的payload帧格式如下：

其中AdvA的意义与ADV_IND相同。 InitA为广播发起者地址：

RxAdd==0：发起者地址是公用地址； RxAdd==1：发起者地址是随机地址。 注意：该帧不包含任何HOST数据。

3、ADV_NONCONN_IND

用于不可接入不直达（non-connectable undirected）的网络。其payload意义与ADV_IND类似。

4、ADV_SCAN_IND

用于可扫描不直达网络。Payload意义与ADV_IND类似。

二、Scaning PDUs

1） SCAN_REQ：

这是扫描请求帧，处于广播状态的接收设备接收这种帧。

此处，

ScanA为扫描者的地址，其地址由TxAdd控制是公共地址还是随机地址。 AdvA为该扫描帧的目的地址。由RxAdd控制意义。 2） SCAN_RSP

扫描确认。处于广播状态的设备在收到扫描请求后，需要回复扫描确认帧。AdvA地址意义由TxAdd确定。ScanRspData为广播端的附带数据。

三、Initiating PDU

该部分为连接发起协议。发起的帧格式仅一种：CONNECT_REQ。由发起方发送该帧，广播方接收该帧。

1） CONNECT_REQ

CONNECT_REQ帧格式如下：

TxAdd确认InitA地址为公共地址还是随机地址； RxAdd确认AdvA地址为公共地址还是随机地址。 LLData的数据格式如下：

AA：AccessAddress

CRCInit：CRC校验的初始值，它应该是LinkLayer产生的一个随机值。

WinSize：发送窗长度参数。transmitWindowSize=WinSize*1.25ms。

WinOffset：发送窗起始偏移量。TransmitWindowOffset=WinOffset*1.25ms。 上述两个window意义如下：

Interval：确定connect interval的时间长度。connInterval = Interval * 1.25 ms。 Latency：connSlaveLatency =Latency。

TimeOut：connSupervisionTimeout= Timeout * 10 ms（100ms~32s之间），当两帧数据之间的时间间隔超过6*connInterval或者connSupervisionTimeout时，则认为连接丢失。

ChM：即ChannelMAP，一共0~36个信道。LSB代表channel0，哪一个是1，则哪一个信道有效。Channel 37~39保留。

Hop：5~16之间的随机值，用于设置HopIncrement。用于计算不使用的信道编号。

unmappedChannel= (lastUnmappedChannel+ hopIncrement) mod 37

如果计算结果是属于保留信道，则通过下式计算：

remappingIndex= unmappedChannelmod numUsedChannels

SCA：设置Master睡眠时钟精确度的最大值。对应表如下：

四、Data Channel PDU

数据信道的帧格式如下：

其中包括16bit Header，长度可变的Payload，和一个信号完整性确认字段（MIC）。 1、关于Header和MIC

Header的数据格式如下：

每个字段的意义如下：

MIC字段使用的时候，有两个条件：1、不能使用于非加密的数据帧；2、数据帧payload长度不能为0。字长为4byte。 2、关于Payload

Payload分为两类，LL Data PDU和LL Control PDU（LLID==11b）。LL Data PDU里面又分为两类，一类是完整数据帧或帧碎片起始帧（LLID==10b），另一类是帧碎片（LLID==01b）。其中，帧碎片帧的帧长度可以为0，而完整（起始）帧的长度不可以为0。

下面具体介绍LL Control PDU： LL Control PDU的帧格式如下：

其帧长度不能为0，其中包含两个字段：Opcode和CtrData。

Opcode用于确定控制帧类型：

假如收到的LLC PDU格式不支持或者是无用帧，则回复LL_UNKNOWN_RSP PDU，此时的Type字段需设置成收到的无用的opcode。 LL_CONNECTION_UPDATA_REQ： 该帧的帧格式如下：

这些信息的意义在下一章的四中有详述。 LL_CHANNEL_MAP_REQ：

LL_TERMINATE_IND:

这个ErrorCode在蓝牙协议中有具体制定意义。[Vol2 Part D] LL_ENC_REQ:

和加密相关的请求帧

LL_ENC_RSP:

和加密相关的回复帧 LL_START_ENC_REQ: 没有CtrData字段 LL_START_ENC_RSP: 没有CtrData字段 LL_UNKNOWN_RSP:

LL_FEATURE_REQ:

LL_FEATURE_RSP:

LL_PAUSE_ENC_REQ: 没有CtrData字段 LL_PAUSE_ENC_RSP: 没有CtrData字段 LL_VERSION_IND:

LL_REJECT_IND:

关于蓝牙通信协议的理解

一、时钟要求

Active状态下小于±50ppm。 Sleep Mode下小于±500ppm。

二、设备过滤

除了仅支持不可连接的广播系统（non-connectable advertising），其他模式均需支持设备过滤。广播、扫描、连接发起均具有各自独立的过滤机制。如果芯片不支持这几种模式的话，那就可以不支持设备过滤。设备过滤是为了尽量减少不必要的数据通信。 设备过滤时需要具备一个白名单，白名单内容包括不过滤设备的地址和地址类型（公共或随机）。白名单内容由HOST设置。以下对各种过滤模式作一个介绍： 1、广播过滤

支持过滤方式如下，一次仅支持一种方式：

·广播设备仅处理来自白名单的设备的扫描、连接请求。 ·广播设备处理一切设备的扫描、连接请求。（复位值）

·广播设备处理所有设备的扫描请求，仅处理白名单的连接请求。 ·广播设备处理所有设备的连接请求，仅处理白名单的扫描请求。

2、扫描过滤

支持过滤方式如下：

·扫描设备仅处理来自白名单设备的广播帧。 ·扫描设备处理一切设备的广播帧。 假如广播方已经过滤该扫描设备的话，通信不能成功。

3、发起过滤

支持过滤方式如下：

·被发起设备处理来自白名单内所有设备的连接发起请求。

·被发起设备忽略白名单，仅处理host给出设备的连接发起请求。

三、非连接状态简述

1、standby

Standby是复位后的芯片初始状态，由它可以进入广播、扫描和连接状态。 2、advertising

进入广播状态后，便开始发送广播帧。在发送完一帧广播帧以后，advertising event将被关闭，来适应其他功能。广播事件有以下几种类型：

第一帧广播帧应该在channel index中的最低的广播信道发送。

广播事件是否有回复帧由广播帧类型决定，具体如下表：

当收到错误的返回帧时，广播端会在下一个广播信道发送广播帧，或直接停止广播事件。 广播事件间隔必须是625us的倍数，范围在20ms~10.24s，其设置方式如下：

T_advEvent = advInterval+ advDelay

scannable undirected和non-connectable undirected事件，advInterval长度必须大于100ms；connectable undirected事件，advInterval长度必须大于等于20ms 。advDelay

是0~10ms的伪随机数。连续广播帧发送示意图如下：

a）Connectable Undirected Event Type

如图4.5接收到CONNECT_REQ之后，广播方便退出广播状态，进入Slave状态。

b）Connectable Directed Event Type

c）Scannable Undirected Event Type

d）Non-connectable Undirected Event Type

1、 scanning

检测状态是用来监听广播帧的，其状态由HOST控制，分为主动扫描和被动扫描。 扫描状态下有两个参数scanWindow、scanInterval用于设置一次扫描的时间。扫描时间不能长与10.24s，scanWindow

被动扫描（Passive Scanning）：只接收帧，不发送帧。 主动扫描（Active Scanning）：监听广播帧，根据广播帧格式，回复相应帧。

ADV_IND/ADV_SCAN_IND ->SCAN_REQ

ADV_DIRECT_IND PDU/ADV_NONCONN_IND不回复SCAN_REQ 扫描需进行退避操作。具体看文档吧，就不贴进来了。

2、 initiating

initiating没有channel index的限制。

当收到一个在过滤白名单内的ADV_IND或ADV_DIRECT_IND，发起者将会发送一个CONNECT_REQ给广播方。发送完CONNECT_REQ后退出发起状态，进入连接状态。

四、连接状态简述：

当发起者发送CONNECT_PDU或者广播方收到CONNECT_REQ，则认为连接被创建，但此时并非认为已经建立连接。只有当正式开始数据通信后，才认为连接已经被建立。

连接建立后，连接中有两个角色：Master和Slave。Master主控connection event的时序。每次connection event便是Master和Slave的一次同步结点。 1、连接事件（Connection Events）

一次连接时间，使用同一个channel index。每次连接至少进行一次数据传输。Slave端

在接收到来自Master的数据帧后，无论CRC是否正确，均需要回复数据，除非多次连续CRC不正确。Master也是不管Slave发过来的帧是否正确，均需回复数据，没有除非。无论CRC是否正确，我们都认为Header是对的。Master收不到来自Slave的数据，则关闭connection event。Master和Slave都能关闭此次connection。

连接事件持续时间长度由connInterval和connSlaveLatency决定。

每次连接事件的起始点称作anchor point。在anchor point，Master开始发送数据，Slave开始接收数据。connInterval便是本次连接的持续时间。Master必须确保本次连接时间在下次anchor point之前间隔T_IFS的时间关闭。connInterval长度必须是1.25ms的倍数，长度在7.5ms~4.0s不等。connInterval由发起者通过CONNNECT_REQ传送给广播方。

connSlaveLatency是Slave端允许的监听延时时间，其长度范围如下：

0~((connSupervisionTimeout/ connInterval) - 1)且必须小于500。

也就是说，假如connSlaveLatency=0，则Slave需要在每个anchor point时刻监听。没收到设置connSlaveLatency的帧时，亦如是。 Master和Slave均有一个16bit的计数器connEventCounter每有一次connection event，计数器就加一，假如溢出则循环。它是用于LinkLayer作同步时用。Slave在等待connSlaveLatency时，该计数器亦计数。

2、连接超时（Supervision Timeout）

蓝牙系统为了检测连接丢失，便设置了一个SupervisionTimeout计数器TLLconnSupervision。每次接收到数据帧，则计数器清零。Supervision Time超过以下几个范围则认为超时：

·大于6 * connInterval

·大于connSupervisionTimeout

connSupervisionTimeout为10ms的倍数，范围是100ms~32s，并且小于(1 + connSlaveLatency) * connInterval。

Timeout以后，设备停止发送，进入Standby状态，并且上报中断。

3、 发送窗（Transmit Window）

Transmit Window的信息包含在CONNECT_REQ中，传送给发起者。

发送窗起始是在收到CONNECT_REQ之后transmitWindowOffset+ 1.25ms， transmitWindowSize定义发送窗的宽度。

transmitWindowOffset范围1.25ms的倍数，0 ms~connInterval。

transmitWindowSize范围1.25ms的倍数，1.25ms~10ms|connInterval - 1.25 ms。

4、主设备（Master Role）

建立连接后，发起的一方成为Master。 连接状态建立以后，Master重新设置TLLconnSupervision，LinkLayer确认连接已经建立。随后Master在transmit window时间内开始发送第一个数据帧，Master的第一帧长度可以超过

transmit window。Master决定第一个anchor point，

下一个anchor point=connInterval+first anchor point。 以下是一个例子：

5、从设备（Slave Role）

建立连接后，广播的一方成为Slave。

Slave一方也相同，重新设置TLLconnSupervision，LinkLayer确认连接已经建立。连接建立后的第一帧，无论CRC是否收对，都把它作为第一次连接事件的anchor event。 假如第一个transmit window没有收到数据帧，则准备在下一个transmit window下接收数据，而此时事件同步计数器connEventCount亦加一。

6、关闭连接事件（Closing Connection Events）

Header中的MD位标识是否该次事件之后还有数据发送。假如MD置位，则Master接着发，Slave接着收。任何一方收不到对方的帧了，均关闭连接事件。

连续两次收到数据CRC不对，也关闭连接事件。总结如下：

7、发送窗拓宽（Window Widening）

由于发送端接收端都存在晶振频偏，所以可能会导致Slave端anchor point不同步，因此Slave每次接收完一个数据帧，均需同步一次anchor point。 接收端需要根据发送端的频偏MasterSCA和接收端频偏SlaveSCA来计算接收端的接收窗拓宽参数，以保证数据成功接收。计算方式如下：

其值应小于((connInterval/2) - T_IFS us)。假如到达这个值，则认为连接丢失。

8、信道列表选择（Data Channel Index Selection）

Master端需要给此次连接的信道分类：使用信道和不使用信道。使用信道最少为两个。信道分类由HOST产生。而Slave的Channel Map通过CONNECT_REQ帧接收到本地。 连续的connection event每次需要获取两个参数unmappedChannel和lastUnmappedChannel。前者是此次连接没有使用过的信道列表，后者是前一次连接未用过的信道编号。 未用信道编号计算方法如下：

unmappedChannel= (lastUnmappedChannel+ hopIncrement) mod 37

假如unmappedChannel为used Channel的话，则此次的Channel Index则根据这个unmappedChannel得到该次connection所使用的Channel。

假如unmappedChannel为unused Channel，则根据下面公式计算得到一个remappingIndex。

remappingIndex= unmappedChannelmod numUsedChannels

总结如下图：

9、确认机制和数据流控制（Acknowledgement and Flow Control）

数据的确认依靠transmitSeqNum（SN）和nextExpectedSeqNum（NESN）来控制。NESN用于确认前一帧是否接收正确，是否需要重发。刚刚进入连接状态，SN和NESN均需设置成0。控制方式如下图：

NESN在一种情况下不会被更新，就是接收BUFFER不够的情况。这会使发送端重传该帧，如此实现数据流控制。

五、LinkLayer控制描述

LLCP（LinkLayer Control Protocol）是用来控制两个LinkLayer之间的控制和协商的。其中包括连接控制，加密控制等等。

1、 LinkLayer连接更新和ChannelMap更新

每次进入连接状态后，设备均需更新connInterval, connSlaveLatency和connSupervisionTimeout。Master通过发送LL_CONNECTION_UPDATE_REQ帧来实现参数更新，Slave不能发送这种格式的帧，它通过使用L2CAP信道回复更新确认来确认参数更新。参数更新之前使用老的参数，更新之后使用新参数。

Slave端收到LL_CONNECTION_UPDATE_REQ之后，假如

connEventCount mod 65535小于32767，并且不等于本地的connEventCount，此时它需监听所有的Connection Event，直到确认Master收到自己的REQ ACK。Slave在确认两边

connEventCount相等之前的Connection Event均需要监听。 假如connEventCount mod 65535大于32767，则Slave认为与Master丢失连接，回到

Standby状态，并上报主机。 Master这边，需要在第一个Transmit Window内发送数据，它发送的这帧数据作为此次Connection的anchor point。Master在这个anchor point以后更新它的connInterval，并清零TLLconnSupervision计数。 假如使用自动发送LL_CONNECTION_UPDATE_REQ，则Timeout参数不跟新，与前次LL_CONNECTION_UPDATE_REQ或者CONNECT_REQ设置时相同。其他参数亦如是。 自动更新机制用于Master由于其他需求，需要更改anchor point时间。

ChannelMap的更新由LL_CHANNEL_MAP_REQ完成，

2、加密

加密参数设置通过LL_ENC_REQ和LL_ENC_RSP 开始加密：

LL_START_ENC_REQ 和 LL_START_ENC_RSP

结束加密：

LL_PAUSE_ENC_REQ or LL_TERMINATE_IND PDUs

Empty PDUs or LL_PAUSE_ENC_RSP orLL_TERMINATE_IND

3、Feature Set Exchange

进入连接状态以后，蓝牙设备之间需要交换各自所支持的功能参数。该过程通过LL_FEATURE_REQ PDU和LL_FEATURE_RSP PDU交换信息。数据帧交换时间关系如下：

具体的Feature对应位如下图所示：

4、Version Exchange

主从之间交换设备所支持的蓝牙协议版本信息，通过LL_VERSION_IND来交换信息。其信息包括：

VersNr：所支持的蓝牙协议 CompId：认证信息

SubVersNr：Controller的实现版本号。 5、Termination Procedure

终止通信，通过LL_TERMINATE_IND来交换信息。

IP架构

以下是几个理解上的难点：

一、关于ExchangeTable和ControlStructure

ExchangeMemory是一个动态的存储器件，其中包括了ExchangeTabel、ControlStructure、T/RxDescriptor、T/RxBuffer，它们之间的连接都是由指针完成。关系大概如下：

首先需要将ControlStructure和TRXDescriptor在EM中配置完成后，再配置ExchangeTabel。其可配置的空间如下图所示：

也就是说首先需要在0x0050~0xFFFF地址内配置ControlStructure、Descriptor和DataBuffer，然后在0x0000~0x001F内配置ControlStructurePtr0的指针，指向ControlStructure的首地址。这样在下次PreFetch的时候，BLE_CORE就能够读取相应ControlStructure等等的值了。

BLE_CORE会根据下图，对ExchangeTabel进行扫描，其中菱形为PreFetch时间点，黑色坐标为event发生时间：

1、 一次扫描3个ET：ET_n,ET_n+1,ET_n+2。根据这3个状态是否是有效可读来判断接下来

要做什么，方式如下图所示。

2、 当扫描到ET_n+2为ET有效入口，则立即终止当前的event，终止时间最短不能小于

max packet length *2 + T_IFS * 2 （+ ~25（假如有AES-CCM加密的话））。