参考资料
蓝牙4.0BLE抓包(二) – 广播包解析 https://www.cnblogs.com/aikm/p/5022502.html
蓝牙4.0BLE抓包(三) – 扫描请求和扫描响应 https://www.cnblogs.com/aikm/p/5144209.html
蜗窝科技之蓝牙系列文章
1.BLE广播连接过程图解 -----以手机和设备连接为实例讲解
从广播-->扫描到--》发起连接---》连接建立的过程详细图解
1.1广播advertising
如下图设备不断发送如下广播信号，t为广播间隔。每发送一次广播包，我们称其为一次广播事件（advertising event），因此t也称为广播事件间隔。注意:广播事件是一个持续时间(duration),蓝牙芯片只有在广播事件期间才打开射频模块，此时功效比较高，其余时间蓝牙芯片都处于idle状态，因此平均功耗非常低。由于广播有三个Physical Channel，因此一个广播时间包括三个广播包，即分别在三个广播通道上广播相同的信息。
广播事件的定义:在所有被使用的物理channel上，发送的Advertising PDU的组合，也就是说在各广播通道上一次发送广播数据的这个过程就是Advertising Event。注意:有些广播(如可被扫描、可被连接)发送出去之后，允许Observer接收到后在对应的Channel上回应一些请求，Advertiser接收这些请求后，同样也在同样的Channel上回应，这个过程也包括在Advertising Event中。
广播事件类型：根据应用场景的不同，BLE协议也规定了不同类型的Advertising Event。不同的Advertising Event Type也体现在后续提及的 PDU Type上。
Connectable Undirected Event/Connectable Directed Event/ScanableUndirected Event/Non-connectable Undirected Event
广播周期设定：对于BLE广播通信来说，广播周期这个参数比较重要，关系到系统功耗和通信的效率，因此要结合使用场景，谨慎设定。广播周期 = advInterval(广播间隔) + advDelay(广播延时)。
广播间隔是由HOST设定的参数，有一定的规则。而advDelay是LL层的伪随机数(0~10ms),众多蓝牙设备一起时，一定程度上避免广播通道的拥塞。
1. 2 扫描scanning
处于扫描态的设备可以接收广播信道的报文，通过扫描可以侦听哪些涉笔正在广播。扫描分为主动扫描和被动扫描。主动扫描发送扫描请求给处于广播态的设备，并通过处于广播态的设备返回的扫描响应来获取额外的数据。而被动扫描仅仅接收广播报文，不会发送扫描请求。
扫描中有两个重要的时间参数需要注意：
扫描窗口(Scan Window):一次扫描进行的时间宽度(可理解为RF RX打开的时间)
扫描间隔(Scan Interval):两个连续的扫描窗口的起始时间之间的时间差，包括扫描休息的时间和扫描进行的时间。
这两个参数的值相等时，就是连续扫描了。
如果手机不处于扫描窗口内，手机是收不到设备的广播的。只有手机打开射频接收窗口且手机的射频接收窗口与广播发送的发射窗口匹配成功，手机才能接收到设备的广播信号。注意:匹配成功是一种概率事件，即手机扫到设备也是一个概率事件。手机有时会很快扫到B(如一个广播事件)，也有可能很慢扫到(10多个广播事件)
扫描分为主动扫描(Active Scanning)和被动扫描(Passive Scanning)。被动扫描，BLE设备只听不问，即只接受广播包，不发送SCAN_REQ扫描请求包。主动扫描既听又问，发送SCAN_REQ,接收后续的SCAN_RSP。
扫描的结果，都是吧接收到的数据,反馈到HOST。
1.3 建立连接connection
根据蓝牙specification规定，advertiser 发送完一个广播包会后的150us(F_IFS),advertiser必须开启一段时间的射频Rx窗口，以接收Observer的数据包。即Observer就可以在这段时间里给advertiser发送连接请求。
在第三个ADC_IND的F_IFS时间后Observer发送一个CONN_REQ，手机在收到A1广播包ADV_IND后，以此为初始锚点（这个锚点不是连接的锚点），T_IFS后给Advertiser发送一个connection request命令，即A2数据包，告诉advertiser我将要过来连你，请做好准备。connect_req其实是在告诉advertiser，手机将在Transmit Window期间发送第一个同步包（P1）给你，请在这段时间里把你的射频接收窗口打开。设备收到P1后，T_IFS时间后将给手机回复数据包P2。一旦手机收到数据包P2，连接即可认为建立成功。后续手机将以P1为锚点（原点），Connection Interval为周期，周期性地给设备发送Packet，Packet除了充当数据传送功能，还有两功能：1）同步手机和设备的时钟，重置时序原点，以跟手机同步；2）告诉设备你现在可以传数据给我了。连接成功后，BLE通信将变成主从模式。-------这大部分都是有LL来完成，与HOST已经多大关系。
Initiating状态和Scanning状态类似，只是它的关注点不同，他不关心广播数据，只关心ADV_DIRECT_IND和ADC_IND两类消息，并在符合条件的时候，发出CONNECT_REQ，请求建立连接。啥时符合条件的时候，就是上述的ADC_IND的F_INS之后。
2、从抓包出发分析广播扫描过程
以SIG发布的蓝牙的核心协议和核心协议增补为根本，学习BLE报文结构
核心协议Core_v4.2
核心协议增补CSS v6
2.1LL层的PDU格式
广播通信中，传输的PDU有如下的格式
| Header(16bits) | payload(载荷，长度由Header中的“Length”字段决定)，内容组成有Header中的“PDUType”域决定 |
Header段的格式如下：
| PDU Type(4 bits) | RFU(2 bits) | TxAdd(1 bit) | RxAdd(1 bit) | Length(6 bit) | RFU(2 bits) |
各段意义如下表：
| PDUType | 只是PDU类型，具体有哪些参见后面的介绍 |
| RFU | 留用 |
| TxAdd | true or false 由PDU TYPE决定其作用 发送地址类型 |
| RxAdd | true or false 由PDU TYPE决定其作用 接收地址类型 |
| Length | PDU的长度， 6bit，有效范围为6~37 |
| RFU | 留用 |
接下去讲讲广播中PUD TYPE---决定载荷的组成结构，如下表
| 广播中状态 | PDU TYPE | PDU 格式 | 说明 |
| Advertising | ADV_IND | AdvA(6 octets) AdvData(0~31 octets) |
connectable undirected advetising event,用于最常规的广播，可携带不操作31bytes的广播数据，可被连接，可被扫描的广播。 AdvA，6bytes的广播者地址，并由PDU Header的TxAddr bit决定地址类型(0:public, 1； random)。 AdvData，广播数据 |
| ADV_DIRECT_IND | AdvA(6 octets) InitA(6 octets) |
connectable directed advertising event,专门用于点对点，且已经知道双方的蓝牙地址，不可携带广播数据，可被指定设备连接，不可被扫描 AdvA， 6bytes的广播者地址，并由PDU Header的TXAdd bit决定地址的类型(0:public, 1； random)。 InitA，6bytes的接收者(也是连接的发起者)的地址，由PDU Header的RxAdd bit决定地址类型(0:public, 1； random)。 |
|
| ADV_NONCONN_IND | AdvA(6 octets) AdvData(0~31 octets) |
和ADV_IND类似，但不可被连接，不可以被扫描 | |
| ADC_SCAN_IND | AdvA(6 octets) AdvData(0~31 octets) |
和ADV_IND类似，但不可被连接，可以被扫描 | |
| Scanning | SCAN_REQ | ScanA(6 octets) AdaA(6 octets) |
当接收到ADV_IND或者ADV_SCAN_IND类型的广播数据时，可以通过该PDU，请求广播者广播更多信息。 ScanA，6 bytes的本地地址，并由PDU Header的TxAdd bit决定地址的类型(0:public, 1； random)。 AdvA， 6bytes的广播者地址，并由PDU Header的RXAdd bit决定地址的类型(0:public, 1； random)。 |
| SCAN_RSP | AdaA(6 octets) ScanRspData(0~31octets) |
广播者接收到SCAN_REQ请求后，通过该PDU响应，把更多的信息传送给接收者。 AdvA， 6bytes的广播者地址，并由PDU Header的TXAdd bit决定地址的类型(0:public, 1； random)。 ScanRspData， scan的应答数据 |
|
| Initiating | CONNECT_REQ | InitA(6 octets) AdvA(6 octets) LLData(22 octes) |
当接收的ADV_IND或这ADV_DIRECT_IND类型的广播数据的时候，可以通过该PDU，请求和对方建立连接； InitA，6 bytes的本机地址，并由PDU Header的TxAdd bit决定地址的类型(0:public, 1； random)。 AdvA 6 bytes的广播者的地址，并由PDU Header的RxAdd bit决定地址的类型(0:public, 1； random)。 LLData， BLE连接有关的参数信息 |
注1:蓝牙地址可使用公共地址(Public Address)还是随机地址(Random Address)，两者长度一样，均为6字节48位。BLE设备至少要拥有这两种地址类型的一种，当然可以拥有两种地址类型。
公共地址 = Companny_assigned（24bits）+company_id(24 bits)，此地址独一无二，不能修改。
随机地址=静态地址(Static Device Address)/私有地址(Private Device Address)
静态地址的要求:1)最高2位有效位必须是1；2)最高2位有效位之外的其余部分不能全为0；3)最高2位有效位之外的其余部分不能全为1
私有地址：
注2：广播通信的PDU类型说明:
1--->如果只需要定时传输一些简单的数据(如节点温度)，后续不需要建立连接，则可使用ADV_NONCONN_IND类型；广播者只需要周期性的广播该类型的PDU即可，接受者按照自己的策略扫描、接收，两者不需要任何额外的数据交互。---只接收
2-->如果除了广播数据之外，还有一些额外的数据需要传输，由于种种原因，如广播数据的长度限制、私密要求等，可以使用gADV_SCAN_IND。广播者在周期性广播的同时，会监听SCAN_REQ请求。接收者在接收到广播数据之后，可以通过SCAN_REQ PDU，请求更多的数据。-----接收广播，请求扫描
3-->如果后续需要建立点对点的连接，则可使用ADV_IND。广播者在周期性广播的同时，会监听CONNECT_REQ请求。接收者在接收到广播数据之后，可以通过CONNECT_REQ PDU，请求建立连接。
4-->通过ADV_IND/CONNECT_REQ的组合建立连接，花费的时间比较长。如果双方不关心广播数据，而只是想快速建立连接，恰好如果连接发起者又知道对方（广播者）的蓝牙地址（如通过扫码的方式获取），则可以通过ADV_DIRECT_IND/CONNECT_REQ的方式。 -----快速连接上。
下面形象的将扫描请求和和扫描响应的PDU载荷结构列出来。
报文载荷长度，由Header段中的Length域决定。
广播报文：长度域包含6个bit，有效值的范围是6~37；
数据报文：长度域包含5个bit，有效值的范围是0~31.
为什么广播报文的有效值是从6字节开始，这是因为广播报文必须包含6个字节的广播设备地址。
2.2 PDU载荷中广播数据(AdvaData)和扫描应答数据(SvanRspData)的组成结构
广播数据和扫描应答数据长度是31字节，包括有效数据部分(Signficant part)和无效数据部分(Non-significant part)两部分。
无效数据部分全为0b
有效数据部分是有N个AD Structure组成。每个AD Structure的格式:Length(1 字节)| AD Type(n字节)|AD Data(length-n字节)
这是从ESP-IDF的esp_gap_ble_api.h 中摘出的AD Type：指示AD Data数据的含义
// The type of advertising data(not adv_type)
typedef enum {
ESP_BLE_AD_TYPE_FLAG = 0x01, /* relate to BTM_BLE_AD_TYPE_FLAG in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_16SRV_PART = 0x02, /* relate to BTM_BLE_AD_TYPE_16SRV_PART in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_16SRV_CMPL = 0x03, /* relate to BTM_BLE_AD_TYPE_16SRV_CMPL in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_32SRV_PART = 0x04, /* relate to BTM_BLE_AD_TYPE_32SRV_PART in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_32SRV_CMPL = 0x05, /* relate to BTM_BLE_AD_TYPE_32SRV_CMPL in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_128SRV_PART = 0x06, /* relate to BTM_BLE_AD_TYPE_128SRV_PART in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_128SRV_CMPL = 0x07, /* relate to BTM_BLE_AD_TYPE_128SRV_CMPL in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_NAME_SHORT = 0x08, /* relate to BTM_BLE_AD_TYPE_NAME_SHORT in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_NAME_CMPL = 0x09, /* relate to BTM_BLE_AD_TYPE_NAME_CMPL in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_TX_PWR = 0x0A, /* relate to BTM_BLE_AD_TYPE_TX_PWR in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_DEV_CLASS = 0x0D, /* relate to BTM_BLE_AD_TYPE_DEV_CLASS in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SM_TK = 0x10, /* relate to BTM_BLE_AD_TYPE_SM_TK in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SM_OOB_FLAG = 0x11, /* relate to BTM_BLE_AD_TYPE_SM_OOB_FLAG in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_INT_RANGE = 0x12, /* relate to BTM_BLE_AD_TYPE_INT_RANGE in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SOL_SRV_UUID = 0x14, /* relate to BTM_BLE_AD_TYPE_SOL_SRV_UUID in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_128SOL_SRV_UUID = 0x15, /* relate to BTM_BLE_AD_TYPE_128SOL_SRV_UUID in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SERVICE_DATA = 0x16, /* relate to BTM_BLE_AD_TYPE_SERVICE_DATA in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_PUBLIC_TARGET = 0x17, /* relate to BTM_BLE_AD_TYPE_PUBLIC_TARGET in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_RANDOM_TARGET = 0x18, /* relate to BTM_BLE_AD_TYPE_RANDOM_TARGET in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_APPEARANCE = 0x19, /* relate to BTM_BLE_AD_TYPE_APPEARANCE in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_ADV_INT = 0x1A, /* relate to BTM_BLE_AD_TYPE_ADV_INT in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_LE_DEV_ADDR = 0x1b, /* relate to BTM_BLE_AD_TYPE_LE_DEV_ADDR in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_LE_ROLE = 0x1c, /* relate to BTM_BLE_AD_TYPE_LE_ROLE in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SPAIR_C256 = 0x1d, /* relate to BTM_BLE_AD_TYPE_SPAIR_C256 in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_SPAIR_R256 = 0x1e, /* relate to BTM_BLE_AD_TYPE_SPAIR_R256 in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_32SOL_SRV_UUID = 0x1f, /* relate to BTM_BLE_AD_TYPE_32SOL_SRV_UUID in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_32SERVICE_DATA = 0x20, /* relate to BTM_BLE_AD_TYPE_32SERVICE_DATA in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_128SERVICE_DATA = 0x21, /* relate to BTM_BLE_AD_TYPE_128SERVICE_DATA in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_LE_SECURE_CONFIRM = 0x22, /* relate to BTM_BLE_AD_TYPE_LE_SECURE_CONFIRM in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_LE_SECURE_RANDOM = 0x23, /* relate to BTM_BLE_AD_TYPE_LE_SECURE_RANDOM in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_URI = 0x24, /* relate to BTM_BLE_AD_TYPE_URI in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_INDOOR_POSITION = 0x25, /* relate to BTM_BLE_AD_TYPE_INDOOR_POSITION in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_TRANS_DISC_DATA = 0x26, /* relate to BTM_BLE_AD_TYPE_TRANS_DISC_DATA in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_LE_SUPPORT_FEATURE = 0x27, /* relate to BTM_BLE_AD_TYPE_LE_SUPPORT_FEATURE in stack/btm_ble_api.h */
ESP_BLE_AD_TYPE_CHAN_MAP_UPDATE = 0x28, /* relate to BTM_BLE_AD_TYPE_CHAN_MAP_UPDATE in stack/btm_ble_api.h */
ESP_BLE_AD_MANUFACTURER_SPECIFIC_TYPE = 0xFF, /* relate to BTM_BLE_AD_MANUFACTURER_SPECIFIC_TYPE in stack/btm_ble_api.h */
} esp_ble_adv_data_type;
2.3 抓包分析
3、广播过程设备过滤机制
周围很多BLE设备在广播中，对于Scanner而言，可扫描很多广播数据，如果都上报HOST，则垃圾信息太多。如何只看HOST感兴趣的。
过滤机制就是为了获得直接感兴趣设备的广播包。BLE的过滤机制-----白名单(White List)
3.1 白名单(White List)
每个BLE的Controller，可以保存一个涉笔列表，通过该列表，可以实现设备过滤的功能。这个列表就称为白名单(White List)，保存有一些BLE设备地址。
白名单的大小由Controller自行决定，并在reset的时候为空，后续可以由Host通过HCI接口配置。基于白名单，Link Layer可实现多种设备过滤的策略。 Advertising Filter Policy、Scanner Filter Policy、Initiator Filter Policy
3.2 Advertising Filter Policy 广播过滤策略
定义了Advertiser(处于Advertising状态)的LL层怎么处理SCAN_REQ(扫描请求)和CONNECT_REQ(连接请求)，可采用如下策略(HOST可根据实际情况配置，同一时刻只能配置一种，HOST配置，Controller的LL层执行)。
策略1:Link Layer只接受位于白名单中的设备的扫描和连接请求(最严格)；
策略2:Link Layer可以接收任何设备的扫描和连接请求(最不严格，Controller Reset后的默认状态)；
策略3:Link Layer可以接收任何设备的扫描请求，但只接受位于白名单中的设备的连接请求；
策略4:Link Layer可以接收任何设备的连接请求，但只接受位于白名单中设备的扫描请求。
3.3 Scaanner Filter Policy
定义了Scanner(处于Scanning状态)的Link Layer层怎么处理广播数据，可采用如下策略
策略1:Link Layer只处理位于白名单中的设备的广播数据，并且忽略没有包括自身地址的Connectable Directed Advertising Packet。
策略2:Link Layer处理所有设备的广播数据，并且忽略没有包括自身地址的Connectable Directed Advertising Packet(Controller reset后的默认状态)。
3.4 Initiator Filter Policy
定义了一个Initiator(处于Initiating状态)的Link Layer怎么处理可连接的广播数据，可采用如下策略:
策略1:Link Layer只处理位于白名单中的设备发送的可连接的广播包，并在收到的时候发起连接请求。
策略2:忽略白名单，Link Layer层处理由HOST指定的设备所发送的可连接广播包，并在收到时发送连接请求。
4.BLE广播应用分析
广播通信相关的协议层次 GAP--》HCI--》Link Layer
LL(Link Layer)位于最底层，负责广播通信有关功能的定义和实现，包括物理通道的选择、相关的链路状态的定义、PDU的定义、设备过滤(Device Filtering)机制的实现等
HCI负责将LL提供的所有功能，以Command/Event的形式抽象出来，供Host使用
GAP负责从应用程序的角度，抽象并封装LL提供的功能，以便让应用以比较傻瓜的方式进行广播通信。当然，这不是必须的，也就是说，我们可以在没有GAP参与的情况下，进行广播通信。---
4.1ESP-IDF使用virtual HCI(软件模拟接口) BLE广播
HCI负责将LL提供的所有功能，以Command/Event的形式抽象出来，供上层使用。
HCI Command格式
| OCF(10bit)+OGF(6bit) | Parameter Total Length | Parameter 1 | Parameter 2 | Parameter 3 |
其中OCF和OGF组成16bit的操作码，Parameter Total Length，指示该Command 所有参数长度，Parameter1、Parameter2、等等；16bits 的参数，由具体的Command决定。
HCI Event格式
| Event Code(8 bits) | Parameter Total Length | Parameter 1 | Parameter 2 | Parameter 3 |
广播通信相关HCI命令
HCI _LE_Set_Advertising_Parameters-----------设置广播参数，包括广播间隔、广播类型 本机地址类型 对端地址类型 对端地址 广播通道映射、广播过滤策略等
HCI_LE_Set_Advertising_Data-------------设置广播数据
HCI_LE_Set_Scan_Response_Data------设置Scan请求时的应答数据
HCI_LE_Set_Advertise_Enable-------控制Advertising的使能与否
| 命令 | 命令序列--AD structure | 说明 |
| RESET 0c03 | 01 0C 03 00 | 重置 |
| set_adv_param 0x2006 | 01 20 06 0F 参数 | 设置参数{广播间隔、广播类型 本机地址类型 对端地址类型 对端地址 广播通道映射、广播过滤策略} |
| set_adv_data 0x2008 | 01 20 08 20 02 01 06 ADlen 09 BT_NAME | 设置广播数据 蓝牙名字 最大数据量32 adv_data 见2.2 |
| adv_enable |
BLE广播设置参数
蓝牙广播相关参数：
| Advertising interval | 广播间隔 | |
| Advertising_Type | 广播类型 | 0x00: Connectable Undirected Event Type 可连接的非定向广播 0x01:Connectable Directed Event Type 可连接的定向广播 0x02:Non-connectable Undirected Event Type 不可连接的非定向广播 0x03:Scannable Undirected Event Type 可扫描的非定向广播 0x04~0xFF:保留 |
| Own_Address_Type | 自身地址类型 | |
| Direct_Address_Type | 定向地址类型 | |
| Direct_Address | 定向地址 | |
| Advertising_Channel_Map | 广播信道(一个广播有三个信道) | |
| Advertising_Filter_Policy | 广播过滤策略 | |
| Advertising Data | 广播数据 | |
| ScanResponse Data | 响应数据 |
1、可连接的非定向广播(Connectable Undirected Event Type)
这是一种用途最广的广播类型，包括广播数据和扫描响应数据，它表示当前设备可以接受其他任何设备的连接请求，可称之为通用广播。进行通用广播的设备能够被扫描设备扫描到，或者在接收到连接请求时作为Slave设备进入一个连接。
通用广播在没有连接的情况下发出。
1.2、Scanning状态有关的命令
HCI_LE_Scan_Parameters --------------设置Scan参数，包括Scan Type Scan Interval Scan Window 本机的地址类型 Scanning白名单
HCI_LE_Set_Enable---------------Scan动作开关
1.3、Initiating状态有关的命令
HCI_LE_Create_Connection-----------建立连接，可指定Scan interval Scan Window、Initiator Filter Policy、 Peer Address Type、 Peer Address、 Own Address Type等initiating有关参数，也可指指定连接相关参数
HCI_LE_Create_Connection_Cancel--------取消连接
1.4白名单有关的命令
HCI_LE_Read_White_List_Size，获取BLE Controller的白名单大小；
HCI_LE_Clear_White_List，清空白名单；
HCI_LE_Add_Device_To_White_List，将设备添加到白名单；
HCI_LE_Remove_Device_From_White_List，将设备从白名单移除；
4、2GAP
回到Host端，GAP从用户功能的角度，将Link Layer的各种状态进行了一次映射。
2.1 概述
对于广播通信而言，GAP主要的工作时将Link Layer的“协议语言”，如Advertising、Scanning、Initiating等，转化为更加直观的“人类语言”以及定义扫描数据和广播数据的统一规范。
GAP主要干什么：
1、GAP是吧Link Layer层的状态(standby state、advertising state、initiating state、connection state）进行了抽象,转化成上层的概念。
2、GAP是一个最基础的Profile，其他的Profile都是直接或间接引用该Profile。
3、对广播包数据进行封装，运用统一的格式和类型，已达到设备互联的目的。即扫描蓝牙设备时，就会发现设备的名称，设备的名称运用统一的格式封装在adv的报文中，支持GAP的设备都能读取到设备名称。
BLE协议栈定义的Generic Access(通用访问) Profile，实现如下功能
1、定义GAP层的蓝牙设备角色role
广播模式以及解析过程--------GAP为该模式下色设备定义了两个角色(GAP Role):Broadcaster Role(设备正在发送Advertising events)和 Observer Role（设备正在接受advertising events）
发现模式及其对应的发现过程------GAP为该模式下的设备定义两个角色：Peripheral Role (设备接受Link layer连接，对应Link Layer的Slaver角色)和Center Role（设备发起Link Layer连接，对应Link Layer的master角色）
2、定义GAP层的、用于实现各种通信的操作模式(Operational Mode)和过程(Procedures)
3、设定User Interface有关的蓝牙参数--Address、 Name、 Passkey class
4、security有关的定义
2.2广播数据格式
广播数据/扫描应答数据由一个个AD Structure组成，未满31bytes的数据有0填充；每隔AD Structrue由1byte的长度信息(后代数据长度)和剩余的Data组成。
数据组成AD Type +AD Data,其中AD Type 可以指定Service UUID、设置支持的Profile、Local Name， Flags，设备的GAP发现连接能力等。