精华内容
下载资源
问答
  • 蓝牙服务发现协议
    2022-06-07 17:21:13

    蓝牙协议

    蓝牙协议分层

    物理层(PHA),链路层(LL),HCI(可选),GAP层,L2CAP,SMP , ATT ,GATT

    GAP层角色总结

    对于蓝牙的主机和蓝牙的从机,在BLE通信中随着时间的推移,他们的状态在发送变化,两者的关系也在发送着变化。为此蓝牙spec根据不同的时间段或者状态给手机和设备B取不同的名字,即GAP层定义了如下角色:

    • advertiser。 发出广播的设备
    • observer或者scanner。可以扫描广播的设备
    • initiator。能发起连接的设备,扫描蓝牙的是Responder
    • master或者central。连接成功后的主设备,即主动发起packet的设备
    • slave或者peripheral。连接成功后的从设备,即被动回传packet的设备

    蓝牙配对

    蓝牙配对分为

    Just Works (只工作)

    Numeric Comparison (数值比较)

    Passkey Entry: Responder Displays , Initiator Inpots (密码输入,响应器响应,启动器输入)

    Passkey Entrt:Initiator Displays,Responder Inputs (密码输入,启动器显示,响应器输入)

    Passkey Entry:Initator and Responder Input (密码输入,响应器和启动器输入)

    了解芯科BG22蓝牙配对方式https://docs.silabs.com/bluetooth/3.2/general/security/pairing-processes

    OAT线上升级

    所谓DFU(Device Firmware Update),就是设备固件升级的意思,而OTA(Over The Air)是实现DFU的一种方式而已,准确说,OTA的全称应该是OTA DFU,即通过空中无线方式实现设备固件升级。只不过大家为了方便起见,直接用OTA来指代固件空中升级(有时候大家也将OTA称为FOTA,即Firmware OTA,这种称呼意思更明了一些)。只要是通过无线通信方式实现DFU的,都可以叫OTA,比如2G/3G/4G/WiFi/蓝牙/NFC/Zigbee,他们都支持OTA。DFU除了可以通过无线方式(OTA)进行升级,也可以通过有线方式进行升级,比如通过UART,USB或者SPI通信接口来升级设备固件。

    不管采用OTA方式还是有线通信方式,DFU包括后台式(background)和非后台式两种模式。后台式DFU,又称静默式DFU(Silent DFU),在升级的时候,新固件在后台悄悄下载,即新固件下载属于应用程序功能的一部分,在新固件下载过程中,应用可以正常使用,也就是说整个下载过程对用户来说是无感的,下载完成后,系统再跳到BootLoader模式,由BootLoader完成新固件覆盖老固件的操作,至此整个升级过程结束。比如智能手机升级Android或者iOS系统都是采用后台式DFU方式,新系统下载过程中,手机可以正常使用哦。非后台式DFU,在升级的时候,系统需要先从应用模式跳入到BootLoader模式,由BootLoader进行新固件下载工作,下载完成后BootLoader继续完成新固件覆盖老固件的操作,至此升级结束。早先的功能机就是采用非后台式 DFU来升级操作系统的,即用户需要先长按某些按键进入bootloader模式,然后再进行升级,整个升级过程中手机正常功能都无法使用。

    下面再讲双区DFU(dual bank)和单区DFU(single bank),双区或者单区DFU是新固件和老固件覆盖的两种方式。后台式DFU必须采用双区模式进行升级,即老系统(老固件)和新系统(新固件)各占一块bank(存储区),假设老固件放在bank0中,新固件放在bank1中,升级的时候,应用程序先把新固件下载到bank1中,只有当新固件下载完成并校验成功后,系统才会跳入BootLoader模式,然后擦除老固件所在的bank0区,并把新固件拷贝到bank0中。非后台式DFU可以采用双区也可以采用单区模式,与后台式DFU相似,双区模式下新老固件各占一块bank(老固件为bank0,新固件为bank1),升级时,系统先跳入BootLoader模式,然后BootLoader程序把新固件下载到bank1中,只有新固件下载完成并校验成功后,才会去擦除老固件所在的bank0区,并把新固件拷贝到bank0区。单区模式的非后台式DFU只有一个bank0,老固件和新固件分享这一个bank0,升级的时候,进入bootloader模式后立马擦除老固件,然后直接把新固件下载到同一个bank中,下载完成后校验新固件的有效性,新固件有效升级完成,否则要求重来。跟非后台式DFU双区模式相比,单区模式节省了一个bank的Flash空间,在系统资源比较紧张的时候,单区模式是一个不错的选择。不管是双区模式还是单区模式,升级过程出现问题后,都可以进行二次升级,都不会出现“变砖”情况。不过双区模式有一个好处,如果升级过程中出现问题或者新固件有问题,它还可以选择之前的老固件老系统继续执行而不受其影响。而单区模式碰到这种情况就只能一直待在bootloader中,然后等待二次或者多次升级尝试,此时设备的正常功能已无法使用,从用户使用这个角度来说,你的确可以说此时设备已经“变砖”了。所以说,虽然双区模式牺牲了很多存储空间,但是换来了更好的升级体验。
    在这里插入图片描述

    更多相关内容
  • Android 蓝牙hfp 服务发现、rfcomm连接、SLC连接、SCO链路连接等等源码流程图。非常详细的从btif-bta-btm-hci 数据流程走向,以及从controller收到数据到btm层,将Android 源码使用流程图的形式画了出来,使Android ...
  • Android 蓝牙服务发现SDP协议初始化、连接等源码流程图,非常详细的从btif-bta-btm-hci 数据流程走向,以及从controller收到数据到btm层,将Android 源码使用流程图的形式画了出来,使Android 蓝牙开发者更清楚数据...
  • 传统蓝牙SDP协议详细介绍

    千次阅读 2020-08-20 08:38:18
    第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等 第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层...

    零.概述

    主要介绍下蓝牙协议栈服务发现协议(SDP)协议说明以及交互封包流程的介绍

    一. 声明

    本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下:

    第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,以及蓝牙开发板介绍。

    第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等

    第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层(baseband),链路管理层(LMP)等

    第四篇:传统蓝牙host介绍,主要介绍传统蓝牙的协议栈,比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。

    第五篇:低功耗蓝牙controller介绍,主要介绍低功耗蓝牙芯片,包括物理层(PHY),链路层(LL)

    第六篇:低功耗蓝牙host介绍,低功耗蓝牙协议栈的介绍,包括HCI,L2CAP,ATT,GATT,SM等

    第七篇:蓝牙芯片介绍,主要介绍一些蓝牙芯片的初始化流程,基于HCI vendor command的扩展

    第八篇:附录,主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。

    另外,开发板如下所示,对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈,相信我,学完这一套视频你将拥有修改任何协议栈的能力(比如Linux下的bluez,Android下的bluedroid)。

    ------------------------------------------------------------------------------------------------------------------------------------------

    CSDN学院链接(进入选择你想要学习的课程):https://edu.csdn.net/lecturer/5352?spm=1002.2001.3001.4144

    蓝牙交流扣扣群:970324688

    Github代码:https://github.com/sj15712795029/bluetooth_stack

    入手开发板:https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

    蓝牙学习目录https://blog.csdn.net/XiaoXiaoPengBo/article/details/107727900

    ------------------------------------------------------------------------------------------------------------------------------------------

    二. SDP协议说明

    SDP 协议是一个简单的协议,它对下层传输的要求很小。它可以运行在可靠的分组传输协议上(如果是不可靠的,客户端可以在必要时使用超时和重发请求)。

    SDP 使用一个请求/应答模型。在模型中,每一处理事务由请求协议数据单位(PDU)和应答协议数据单位组成。然而,请求和应答实际上都可以不按次序进行传输。

    在服务搜索协议使用蓝牙 L2CAP 传输协议的特定情况下,可以在一个 L2CAP分组中传输多个 SDP PDU,在每一连接上只能发送一个这样的 L2CAP 给指定 SDP服务器。限制 SDP 发送确认分组成为流控制形式的一种。其中SDP是大端数据模式

    1. 协议数据格式

    其中PDU ID就是传输的消息ID,有以下值:

    Transaction ID:传输消息的ID,request放可以在0x0000~0xffff之间取任意值,但是response要跟request一致,根据TID来区分是回应哪个request.

    ParameterLength:后续para的长度

    2. CONTINUATION STATE

    它用于一次response不够把所有的Data传回去的情况。这时候需要将response分多次传输,如果一次response足够了,Continuation State为1个字节=0。

    如果要分多次response,需要重新request,采用新的transaction ID和上一次resposne的Continuation State,用以下流程说明。

    情况一:不需要Continuation State

    A--->B 发送SDP request,transaction ID为C

    B--->A 发送SDP respose,transaction ID为C。假设一次resposne可以返回所有数据,则Continuation State为1个字节=0。

    情况二:需要Continuation State

    A--->B 发送SDP request,transaction ID为C

    B--->A 发送SDP respose,transaction ID为C。假设一次resposne不够返回所有数据,这时response携带Continuation State M

    A--->B 发送SDP request,transaction ID为D(必须与C不同),携带Continuation State M

    B--->A 发送SDP respose,transaction ID为D。假设这次resposne还不够返回所有数据,这时response携带Continuation State N

    A--->B 发送SDP request,transaction ID为E,携带Continuation State N

    B--->A 发送SDP respose,transaction ID为E。假设一次resposne返回的是最后的一部分数据,则Continuation State为1个字节=0。

    整个request-response的流程结束。

    3. ERROR HANDLING

    每一事务都由一个请求和一个应答 PDU 组成。通常,每种请求 PDU 类型都对应于一种应答 PDU类型。但是,如果服务器确认请求格式不正确或由于某种原因,服务器不能采用合适的 PDU类型进行应答时,该服务器将采用。SDP_ErrorResponse 协议数据单元应答。如下图所示:

    其中ErrorCode有以下值:

    4. SERVICESEARCH TRANSACTION

    发送REQ如下:

    SDP客户端生成一个SDP_SERVICE_SEARCH_REQ来定位与作为PDU的第一个参数给出的服务搜索模式匹配的服务记录。在收到此请求后,SDPserver应检查其服务记录数据库,并返回SDP_SERVICE_SEARCH_RSP,其中包含在其SDP数据库中与给定的服务搜索模式匹配的服务记录句柄,或一个适当的错误响应。

    参数:

    ServiceSearchPattern:一般就是需要一个数据元代表UUID

    MaximumServiceRecordCount:

    ContinuationState:

    接受RSP如下:

    接收到有效的SDP_SERVICE_SEARCH_REQ时,SDP服务器生成一个SDP_SERVICE_SEARCH_RSP。响应包含一个服务记录句柄列表,用于匹配请求中给定的服务搜索模式的服务记录句柄。如果生成了部分响应,则只应包含完整的服务记录句柄;一个服务记录句柄值不应该被多个pdu分割。

    参数:

    TotalServiceRecordCount:

    CurrentServiceRecordCount:

    ServiceRecordHandleList:

    ContinuationState:

    我们来看下交互流程,问询A2DP sink的service handle的动作

    具体交互封包格式如下:

    上图是发送SDP_SERVICE_SEARCH_REQ,我们来根据raw data来分析下,巩固下数据元以及上图封包交互,SDP RAW data为:

    0x02 0x00 0x04 0x00 0x08 0x35 0x03 0x19 0x11 0x0B 0x00 0x14 0x00

    其中0x02是PDU ID,也就是SDP_SERVICE_SEARCH_REQ

    0x00 0x04也就是Transaction ID,也就是0x0004

    0x00 0x08也就是ParameterLength,是8个byte

    0x35 二进制表示为00110101b,高5bit为00110b也就是0x6

    低3bit是101b,也就是0x05

    也就是长度在后面1个byte中

    0x03 长度为3个byte

    0x19 二进制为00011001b,高5位是00011b,也就是0x03

    低3位是001b,也就是0x01

    代表后面的2个byte是UUID,也就是0x11,0x0B

    后续的0x00, 0x14,就是这个参数MaximumServiceRecordCount,最大20

    Continue是0

    上图是发送SDP_SERVICE_SEARCH_RSP,我们再来根据raw data来分析下,巩固下数据元以及上图封包交互,这也是最后一次分析SDP raw data,后续的两个过程不再做分析,只截图,SDP RAW data为:

    0x03 0x00 0x04 0x00 0x09 0x00 0x01 0x00 0x01 0x00 0x01 0x00 0x00 0x00

    其中0x03是PDU ID,也就是SDP_SERVICE_SEARCH_RSP

    0x00 0x04也就是Transaction ID,也就是0x0004,跟SDP_SERVICE_SEARCH_REQ必须一致

    0x00 0x09也就是ParameterLength,是9个byte

    0x00 0x01 是参数TotalServiceRecordCount,一共有一个请求UUID的service handle

    0x00 0x01 是参数CurrentServiceRecordCount,也就是当前返回的是1

    0x00 0x01 0x00 0x00是参数ServiceRecordHandleList,也就是0x10000

    0x00 是continue

    好啦,搞定,你应该对SDP的封包交互格式以及数据元有深刻理解了吧?继续开车喽

    5. SERVICEATTRIBUTE TRANSACTION

    发送REQ如下:

    SDP客户端生成SDP_SERVICE_ATTR_REQ来从特定的服务记录中检索指定的属性值。所需服务记录的服务记录句柄和从该服务记录中检索到的所需属性id列表作为参数提供。

    参数:

    ServiceRecordHandle:

    MaximumAttributeByteCount:

    AttributeIDList:

    ContinuationState::

    回应如下:

    参数:

    AttributeListByteCount:

    AttributeList:

    ContinuationState:

    我们来看一个交互流程,巩固下以上的交互流程

    回应如下:

    这个比较麻烦,需要你们好好分析下喽,你分析明白一个,后续再麻烦的也是一通百通了。

    6 .SERVICESEARCHATTRIBUTE TRANSACTION

    发送REQ如下:

    SDP_SERVICE_SEARCH_ATTR_REQ 事务综合 SDP_SERVICE_SEARCH_REQ和

    SDP_SERVICE_ATTR_REQ 二者功能于一个请求中。作为参数,它既包含服务搜索图,又包含一张属性表,该属性表从与服务搜索图匹配的服务记录中检索。 SDP_SERVICE_SEARCH_ATTR_REQ及其应答与 SDP_ServiceSearch 和SDP_ServiceAttribute 两者相比,显得更复杂并且可能需要更多的字节。但是,使用 SDP_ServiceSearchAttributeRequest 可以减少总的 SDP 事务量,特别是当检索多条服务记录时。具体参数如下:

    ServiceSearchPattern:

    MaximumAttributeByteCount:

    AttributeIDList:

    ContinuationState:

    RESPONSE如下格式:

    参数:

    AttributeListsByteCount:

    AttributeLists:

    ContinuationState:

    找一个交互流程让你们体验下:

    发送REQ如下:

    接受RESPONSE如下:

    展开全文
  • 传统蓝牙服务问询协议SDP概念

    千次阅读 2020-08-17 08:22:07
    服务发现协议(SDP)为应用程序提供了一种方法来发现哪些服务可用,并确定这些可用服务的特征。比如主动问询对方支持哪些蓝牙协议,或者单独问询对方蓝牙电话HFP 一. 声明 本专栏文章我们会以连载的方式持续更新,本...

    零.概述

    本文主要介绍传统蓝牙SDP的概念,SDP在整个协议栈中的架构,SDP的UUID,服务类,以及服务类属性介绍。

    服务发现协议(SDP)为应用程序提供了一种方法来发现哪些服务可用,并确定这些可用服务的特征。比如主动问询对方支持哪些蓝牙协议,或者单独问询对方蓝牙电话HFP

    一. 声明

    本专栏文章我们会以连载的方式持续更新,本专栏计划更新内容如下:

    第一篇:蓝牙综合介绍 ,主要介绍蓝牙的一些概念,产生背景,发展轨迹,市面蓝牙介绍,以及蓝牙开发板介绍。

    第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等

    第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层(baseband),链路管理层(LMP)等

    第四篇:传统蓝牙host介绍,主要介绍传统蓝牙的协议栈,比如HCI,L2CAP,SDP,RFCOMM,HFP,SPP,HID,AVDTP,AVCTP,A2DP,AVRCP,OBEX,PBAP,MAP等等一系列的协议吧。

    第五篇:低功耗蓝牙controller介绍,主要介绍低功耗蓝牙芯片,包括物理层(PHY),链路层(LL)

    第六篇:低功耗蓝牙host介绍,低功耗蓝牙协议栈的介绍,包括HCI,L2CAP,ATT,GATT,SM等

    第七篇:蓝牙芯片介绍,主要介绍一些蓝牙芯片的初始化流程,基于HCI vendor command的扩展

    第八篇:附录,主要介绍以上常用名词的介绍以及一些特殊流程的介绍等。

    另外,开发板如下所示,对于想学习蓝牙协议栈的最好人手一套。以便更好的学习蓝牙协议栈,相信我,学完这一套视频你将拥有修改任何协议栈的能力(比如Linux下的bluez,Android下的bluedroid)。

    ------------------------------------------------------------------------------------------------------------------------------------------

    CSDN学院链接(进入选择你想要学习的课程):https://edu.csdn.net/lecturer/5352?spm=1002.2001.3001.4144

    蓝牙交流扣扣群:970324688

    Github代码:https://github.com/sj15712795029/bluetooth_stack

    入手开发板:https://item.taobao.com/item.htm?spm=a1z10.1-c-s.w4004-22329603896.18.5aeb41f973iStr&id=622836061708

    蓝牙学习目录https://blog.csdn.net/XiaoXiaoPengBo/article/details/107727900

    ------------------------------------------------------------------------------------------------------------------------------------------

    二. SDP概念

    服务发现协议(SDP)为应用程序提供了一种方法来发现哪些服务可用,并确定这些可用服务的特征。比如主动问询对方支持哪些蓝牙协议,或者单独问询对方蓝牙电话HFP,在整个蓝牙中的架构如红框内:

    整个SDP是基于C/S架构,主要是client发起request,server回送response,如下图:

    三. SDP常用术语

    1. 服务记录

    服务是任何一个能够提供信息、执行动作、或代表另一实体控制资源的实体 。服务可以以软件、硬件、或硬软件混合的形式来实现。由 SDP 服务器所维护服务的所有信息都包含于一条服务记录中。该服务记录全部由一张服务属性表组成。如下图所示:

    其中服务记录包括服务句柄+服务属性服务句柄是一个32位无符号整形的数字,整个sdp server中必须唯一服务属性如下小节。

    2. 服务属性

    服务属性用于描述某一服务的一个特征。服务属性的实例如下:

    其中服务属性的格式如下:

    其中属性ID是1个16位无符号整形的数字,属性值要看ID,来决定是什么格式,属性在后面介绍

    总结起来,整个服务器应该包含如下结构(0条或者多条记录):

    3.UUID

    UUID 是经授权可在所有时空中保持唯一的通用定位符。UUID 可以分布的方式独立创建,而且不需要指定 UUID 的中心注册机构。UUID 值长度为 128 位。

    为了减少存储压力,并便于 128 位 UUID 值的转换,UUID 值域已经为了常用和注册的目的进行预先分配。在该已分配域的第一个 UUID 作为蓝牙基 UUID,具有来自蓝牙号码分配文件的值 00000000-0000-1000-7007- 00805F9B34FB。在该已分配域的 UUID 值都具有 16 位或 32 位的别名。这些别名常被称为 16 位或 32位 UUID。但每一别名实际上都代表一个 128 位 UUID 。可以通过一个简单的数学运算计算 16 位或 32 位 UUID 的全部 128 位值。

    128 位值 = 16 位值 × 2^96+ 蓝牙基 UUID

    128 位值 = 32 位值 × 2^96+ 蓝牙基 UUID

    通过对 16 位值进行零扩展,将 16 位 UUID 转换成为 32 位 UUID 格式。另外

    一个转换方法是将 16 位值加到所有位都为零的 32 位 UUID 。

    注 :可以直接对两个 16 位 UUID 或 32 位 UUID 或 128 位 UUID 进行比较,如果要对不同大小的 UUID 进行比较,短 UUID 必须在比较前转换成为长 UUID 格式。

    具体协议的UUID如下,参考:https://www.bluetooth.com/specifications/assigned-numbers/service-discovery/

    Base Universally Unique Identifier (UUID)

    The Base UUID is used for calculating 128-bit UUIDs from “short UUIDs” (uuid16 and uuid32) as described in the SDP Specification. See Service Discovery Protocol (SDP) in the Bluetooth Core Specification.

    NOTE: Currently all assigned short UUIDs are uuid16 types.

    UUID NameUUID
    BASE_UUID00000000-0000-1000-8000-00805F9B34FB
    Protocol NameUUIDProtocol Specification
    SDP0x0001Bluetooth Core Specification
    UDP0x0002[NO USE BY PROFILES]
    RFCOMM0x0003RFCOMM with TS 07.10
    TCP0x0004[NO USE BY PROFILES]
    TCS-BIN0x0005Telephony Control Specification / TCS Binary [DEPRECATED]
    TCS-AT0x0006[NO USE BY PROFILES]
    ATT0x0007Attribute Protocol
    OBEX0x0008IrDA Interoperability
    IP0x0009[NO USE BY PROFILES]
    FTP0x000A[NO USE BY PROFILES]
    HTTP0x000C[NO USE BY PROFILES]
    WSP0x000E[NO USE BY PROFILES]
    BNEP0x000FBluetooth Network Encapsulation Protocol (BNEP)
    UPNP0x0010Extended Service Discovery Profile (ESDP) [DEPRECATED]
    HIDP0x0011Human Interface Device Profile (HID)
    HardcopyControlChannel0x0012Hardcopy Cable Replacement Profile (HCRP)
    HardcopyDataChannel0x0014See Hardcopy Cable Replacement Profile (HCRP)
    HardcopyNotification0x0016Hardcopy Cable Replacement Profile (HCRP)
    AVCTP0x0017Audio/Video Control Transport Protocol (AVCTP)
    AVDTP0x0019Audio/Video Distribution Transport Protocol (AVDTP)
    CMTP0x001BCommon ISDN Access Profile (CIP) [DEPRECATED]
    MCAPControlChannel0x001EMulti-Channel Adaptation Protocol (MCAP)
    MCAPDataChannel0x001FMulti-Channel Adaptation Protocol (MCAP)
    L2CAP0x0100Bluetooth Core Specification

    4. 服务类 

    每一服务都是服务类的一个实例。服务类定义提供对所有包含于服务记录中属性的定义,而这些服务记录就代表一个类实例。每一属性定义将给出该属性 ID的数字值、该属性值的用法及其格式。服务记录包含服务类的专用属性,以及用于所有服务的通用属性。

    每一服务类将指定一个唯一标识符 。 该服务类标识符包含于ServiceClassIDList 属性的属性值,并表示为 UUID。由于服务记录中的某些属性的格式和含义依赖于服务记录的服务类,因此 ServiceClassIDList 属性非常重要。在使用任一类指定属性之前,应检查或验证它们的值。由于服务记录的所有属性必须遵循所有的服务类,包含于 ServiceClassIDList 属性中的服务类标识符也与此有关。特别要说明的是,每一服务类都是另外一类的子类,该父类的标识符包含在 ServiceClassIDList 列表中。服务子类定义与其父类不同,子类中包含该其它子类特定的属性定义。ServiceClassIDList 属性中的服务类标识符,按照从底层类到高层类的顺序一一列出。

    在定义本身是另一服务类子类的新服务类时,该新类将保留父类定义的所有属性。同时,也将定义专用于新服务类的其它属性。换句话说, 向已有服务类的某些实例添加新属性的机制将创建一个新的服务类,该服务类是已有服务类的子类。

    有以下服务类,如excel

    Service Class NameUUIDSpecificationAllowed Usage
    ServiceDiscoveryServerServiceClassID0x1000Bluetooth Core SpecificationService Class
    BrowseGroupDescriptorServiceClassID0x1001Bluetooth Core SpecificationService Class
    SerialPort0x1101Serial Port Profile (SPP)
    NOTE: The example SDP record in SPP v1.0 does not include a BluetoothProfileDescriptorList attribute, but some implementations may also use this UUID for the Profile Identifier.
    Service Class/ Profile
    LANAccessUsingPPP0x1102LAN Access Profile
    [DEPRECATED]
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    DialupNetworking0x1103Dial-up Networking Profile (DUN)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    IrMCSync0x1104Synchronization Profile (SYNC)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    OBEXObjectPush0x1105Object Push Profile (OPP)
    NOTE: Used as both Service Class Identifier and Profile.
    Service Class/ Profile
    OBEXFileTransfer0x1106File Transfer Profile (FTP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    IrMCSyncCommand0x1107Synchronization Profile (SYNC) 
    Headset0x1108Headset Profile (HSP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    CordlessTelephony0x1109Cordless Telephony Profile (CTP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    [DEPRECATED]
    Service Class/ Profile
    AudioSource0x110AAdvanced Audio Distribution Profile (A2DP)Service Class
    AudioSink0x110BAdvanced Audio Distribution Profile (A2DP)Service Class
    A/V_RemoteControlTarget0x110CAudio/Video Remote Control Profile (AVRCP)Service Class
    AdvancedAudioDistribution0x110DAdvanced Audio Distribution Profile (A2DP)Profile
    A/V_RemoteControl0x110EAudio/Video Remote Control Profile (AVRCP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class/ Profile
    A/V_RemoteControlController0x110FAudio/Video Remote Control Profile (AVRCP)
    NOTE: The AVRCP specification v1.3 and later require that 0x110E also be included in the ServiceClassIDList before 0x110F for backwards compatibility.
    Service Class
    Intercom0x1110Intercom Profile (ICP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    [DEPRECATED]
    Service Class
    Fax0x1111Fax Profile (FAX)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    [DEPRECATED]
    Service Class
    Headset – Audio Gateway (AG)0x1112Headset Profile (HSP)Service Class
    WAP0x1113Interoperability Requirements for Bluetooth technology as a WAP, Bluetooth SIG [DEPRECATED]Service Class
    WAP_CLIENT0x1114Interoperability Requirements for Bluetooth technology as a WAP, Bluetooth SIG [DEPRECATED]Service Class
    PANU0x1115Personal Area Networking Profile (PAN)
    NOTE: Used as both Service Class Identifier and Profile Identifier for PANU role.
    Service Class / Profile
    NAP0x1116Personal Area Networking Profile (PAN)
    NOTE: Used as both Service Class Identifier and Profile Identifier for NAP role.
    Service Class / Profile
    GN0x1117Personal Area Networking Profile (PAN)
    NOTE: Used as both Service Class Identifier and Profile Identifier for GN role.
    Service Class / Profile
    DirectPrinting0x1118Basic Printing Profile (BPP)Service Class
    ReferencePrinting0x1119See Basic Printing Profile (BPP)Service Class
    Basic Imaging Profile0x111ABasic Imaging Profile (BIP)Profile
    ImagingResponder0x111BBasic Imaging Profile (BIP)Service Class
    ImagingAutomaticArchive0x111CBasic Imaging Profile (BIP)Service Class
    ImagingReferencedObjects0x111DBasic Imaging Profile (BIP)Service Class
    Handsfree0x111EHands-Free Profile (HFP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class / Profile
    HandsfreeAudioGateway0x111FHands-free Profile (HFP)Service Class
    DirectPrintingReferenceObjectsService0x1120Basic Printing Profile (BPP)Service Class
    ReflectedUI0x1121Basic Printing Profile (BPP)Service Class
    BasicPrinting0x1122Basic Printing Profile (BPP)Profile
    PrintingStatus0x1123Basic Printing Profile (BPP)Service Class
    HumanInterfaceDeviceService0x1124Human Interface Device (HID)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class / Profile
    HardcopyCableReplacement0x1125Hardcopy Cable Replacement Profile (HCRP)Profile
    HCR_Print0x1126Hardcopy Cable Replacement Profile (HCRP)Service Class
    HCR_Scan0x1127Hardcopy Cable Replacement Profile (HCRP)Service Class
    Common_ISDN_Access0x1128Common ISDN Access Profile (CIP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    [DEPRECATED]
    Service Class / Profile
    SIM_Access0x112DSIM Access Profile (SAP)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class / Profile
    Phonebook Access – PCE0x112EPhonebook Access Profile (PBAP)Service Class
    Phonebook Access – PSE0x112FPhonebook Access Profile (PBAP)Service Class
    Phonebook Access0x1130Phonebook Access Profile (PBAP)Profile
    Headset – HS0x1131Headset Profile (HSP)
    NOTE: See erratum #3507.
    0x1108 and 0x1203 should also be included in the ServiceClassIDList before 0x1131 for backwards compatibility.
    Service Class
    Message Access Server0x1132Message Access Profile (MAP)Service Class
    Message Notification Server0x1133Message Access Profile (MAP)Service Class
    Message Access Profile0x1134Message Access Profile (MAP)Profile
    GNSS0x1135Global Navigation Satellite System Profile (GNSS)Profile
    GNSS_Server0x1136Global Navigation Satellite System Profile (GNSS)Service Class
    ​3D Display0x1137​​3D Synchronization Profile (3DSP)Service Class​
    ​3D Glasses​0x1138​3D Synchronization Profile (3DSP)​Service Class
    ​3D Synchronization0x1139​​3D Synchronization Profile (3DSP)​Profile
    ​MPS Profile UUID​0x113A​Multi-Profile Specification (MPS)​Profile
    ​MPS SC UUID​0x113B​Multi-Profile Specification (MPS)​Service Class
    ​CTN Access Service​​0x113C​​Calendar, Task, and Notes (CTN) Profile​Service Class
    ​CTN Notification Service​​0x113D​​Calendar Tasks and Notes (CTN) Profile​Service Class
    ​CTN Profile​0x113E​​Calendar Tasks and Notes (CTN) Profile​Profile
    PnPInformation0x1200Device Identification (DID)
    NOTE: Used as both Service Class Identifier and Profile Identifier.
    Service Class / Profile
    GenericNetworking0x1201N/AService Class
    GenericFileTransfer0x1202N/AService Class
    GenericAudio0x1203N/AService Class
    GenericTelephony0x1204N/AService Class
    UPNP_Service0x1205Enhanced Service Discovery Profile (ESDP) [DEPRECATED]Service Class
    UPNP_IP_Service0x1206Enhanced Service Discovery Profile (ESDP) [DEPRECATED]Service Class
    ESDP_UPNP_IP_PAN0x1300Enhanced Service Discovery Profile (ESDP) [DEPRECATED]Service Class
    ESDP_UPNP_IP_LAP0x1301Enhanced Service Discovery Profile (ESDP)[DEPRECATED]Service Class
    ESDP_UPNP_L2CAP0x1302Enhanced Service Discovery Profile (ESDP)[DEPRECATED]Service Class
    VideoSource0x1303Video Distribution Profile (VDP)Service Class
    VideoSink0x1304Video Distribution Profile (VDP)Service Class
    VideoDistribution0x1305Video Distribution Profile (VDP)Profile
    HDP0x1400Health Device ProfileProfile
    HDP Source0x1401Health Device Profile (HDP)Service Class
    HDP Sink0x1402Health Device Profile (HDP)Service Class
     (Max value 0xFFFF) 

     五.特定类属性 

    具体参照,如图:

    我们以截图的方式给出:

    展开全文
  • 蓝牙协议分析

    千次阅读 2021-11-03 14:59:19
    本文是蓝牙协议分析的第二篇文章,在“蓝牙协议分析(1)_基本概念”的基础上,从整体架构的角度,了解蓝牙协议的组成,以便加深对蓝牙的理解。 2. 协议层次 蓝牙协议是通信协议的一种,为了把复杂问题简单化,任何...

    1. 前言

    本文是蓝牙协议分析的第二篇文章,在“蓝牙协议分析(1)_基本概念”的基础上,从整体架构的角度,了解蓝牙协议的组成,以便加深对蓝牙的理解。

    2. 协议层次

    蓝牙协议是通信协议的一种,为了把复杂问题简单化,任何通信协议都具有层次性,特点如下:

    从下到上分层,通过层层封装,每一层只需要关心特定的、独立的功能,易于实现和维护;

    在通信实体内部,下层向上层提供服务,上层是下层的用户;

    在通信实体之间,协议仅针对每一层,实体之间的通信,就像每一层之间的通信一样,这样有利于交流、理解、标准化。

    蓝牙协议也不例外,其协议层次如下:

    bluetooth_stack_layer

    从OSI(Open System Interconnection)模型的角度看,蓝牙是一个比较简单的协议,它仅仅提供了物理层(Physical Layer)和数据链路层(Data Link Layer )两个OSI层次。但由于蓝牙协议的特殊性、历史演化因素等原因,其协议层次又显的不简单,甚至晦涩难懂(如上面图片所示的Physical Link、Logical Transport等)。

    蓝牙协议分为四个层次:物理层(Physical Layer)、逻辑层(Logical Layer)、L2CAP Layer和应用层(APP Layer)。

    物理层,负责提供数据传输的物理通道(通常称为信道)。通常情况下,一个通信系统中存在几种不同类型的信道,如控制信道、数据信道、语音信道等等。

    逻辑层,在物理层的基础上,提供两个或多个设备之间、和物理无关的逻辑传输通道(也称作逻辑链路)。

    L2CAP层,L2CAP是逻辑链路控制和适配协议(Logical Link Control and Adaptation Protocol)的缩写,负责管理逻辑层提供的逻辑链路。基于该协议,不同Application可共享同一个逻辑链路。类似TCP/IP中端口(port)的概念。

    APP层,理解蓝牙协议中的应用层,基于L2CAP提供的channel,实现各种各样的应用功能。Profile是蓝牙协议的特有概念,为了实现不同平台下的不同设备的互联互通,蓝牙协议不止规定了核心规范(称作Bluetooth core),也为各种不同的应用场景,定义了各种Application规范,这些应用层规范称作蓝牙profile。

    在以上四个层次的基础上,蓝牙协议又将物理层和逻辑层划分了子层,分别是Physical Channel/Physical Links和Logical Transports/Logical Links,这一划分,相当使人崩溃,要多花费大量的脑细胞去理解它们,具体请参考下面的分析。

    2.1 物理层

    物理层负责提供数据传输的物理信道,蓝牙的物理层分为Physical Channel和Physical Links两个子层。我们先介绍Physical Channel。

    2.1.1 Physical Channel(物理信道)

    一个通信系统中通常存在多种类型的物理信道,蓝牙也不例外。另外,由“蓝牙协议分析(1)_基本概念”的介绍可知,蓝牙存在BR/EDR、LE和AMP三种技术,这三种技术在物理层的实现就有很大的差异,下面让我们一一介绍。

    首先是相同点,BR/EDR、LE和AMP的RF都使用2.4GHz ISM(Industrial Scientific Medical) 频段,频率范围是2.400-2.4835 GHz。

    注1:不同国家和地区蓝牙的频率和信道分配情况是不同,本文所有的描述都以中国采用的“欧洲和美国”标准为准。

    除了相同点,剩下的都是不同点了。

    BR/EDR是传统的蓝牙技术,它这样定义物理信道:

    1)ISM频率范围内被分成79个channel,每一个channel占用1M的带宽,在0 channel和78 channel之外设立guard band(保护带宽,Lower Guard Band为2MHz,Upper Guard Band为3.5MHz)。

    2)采用跳频技术(hopping),也就是说,某一个物理信道,并不是固定的占用79个channel中的某一个,而是以一定的规律在跳动(该规律在技术上叫做"伪随机码",就是"假"的随机码)。因此蓝牙的物理信道,也可以称作跳频信道(hopping channel)。

    3)BR/EDR技术定义了5种物理信道(跳频信道),BR/EDR Basic Piconet Physical Channel、BR/EDR Adapted Piconet Physical Channel、BR/EDR Page Scan Physical Channel、BR/EDR Inquiry Scan Physical Channel和BR/EDR Synchronization Scan Channel。

    4)BR/EDR Inquiry Scan Physical Channel用于蓝牙设备的发现操作(discovery),即我们常用的搜索其它蓝牙设备(discover)以及被其它蓝牙设备搜索(discoverable)。

    5)BR/EDR Page Scan Physical Channel用于蓝牙设备的连接操作(connect),即我们常用的连接其它蓝牙设备(connect)以及被其它蓝牙设备连接(connectable)。

    6)BR/EDR  Basic Piconet Physical Channel和BR/EDR  Adapted Piconet Physical Channel主要用在处于连接状态的蓝牙设备之间的通信。它们的区别是,BR/EDR  Adapted Piconet Physical Channel使用较少的RF跳频点。BR/EDR Basic Piconet Physical Channel使用全部79个跳频点,而BR/EDR Adapted Piconet Physical Channel是根据当前的信道情况使用79个跳频点中的子集,但是跳频数目也不能少于20个。这个主要是因为蓝牙使用ISM频段,当蓝牙和WIFI共存的时候,部分跳频点被WIFI设备占用而使得蓝牙设备在这些跳频点上的通信总是失败,因此,需要避过那些WIFI设备占用的频点。

    7)BR/EDR Synchronization Scan Channel可用于无连接的广播通信,后续文章会详细介绍。

    8)同一时刻,BT 设备只能在其中一个物理信道上通信,为了支持多个并行的操作,蓝牙系统采用时分方式,即不同的时间点采用不同的信道。

    LE是为蓝牙低功耗而生的技术,为了实现低功耗的目标,其物理信道的定义与BR/EDR有些差异:

    1)ISM频率范围内被分成40个channel,每一个channel占用2M的带宽,在0 channel和39 channel之外设立guard band(保护带宽,Lower Guard Band为2MHz,Upper Guard Band为3.5MHz)。

    2)LE技术定义了2种物理信道,LE Piconet channel和LE Advertisement Broadcast Channel。

    3)LE Piconet Channel用在处于连接状态的蓝牙设备之间的通信,和BR/EDR一样,采用调频技术。和BR/EDR不一样的地方是,只会在40个频率channel中的37个上面跳频。

    4)LE Advertisement Broadcast Channel用于在设备间进行无连接的广播通信,这些广播通信可用于蓝牙的设备的发现、连接(和BR/EDR类似)操作,也可用于无连接的数据传输。

    8)和BR/EDR一样,同一时刻,BT 设备只能在其中一个物理信道上通信,为了支持多个并行的操作,蓝牙系统采用时分方式,即不同的时间点采用不同的信道。

    AMP是为高速数据传输设计的技术,其物理层规范直接采用802.11(WIFI)的PHY规范,主要有如下特点:

    AMP物理信道只有一种,即AMP Physical Channel,主要用于已连接设备之间的数据通信,和BR/EDR技术中的BR/EDR Adapted Piconet Physical Channel位于一个级别,可以互相切换使用。

    2.1.2 Physical Links(物理链路)

    由2.1.1的描述可知,蓝牙协议为BR/EDR、LE和AMP三种技术定义了8种类型的物理信道,包括:

    AMP physical channel

    BR/EDR Basic Piconet Physical Channel
    BR/EDR Adapted Piconet Physical Channel
    BR/EDR Page Scan Physical Channel
    BR/EDR Inquiry Scan Physical Channel
    BR/EDR Synchronization Scan Channel

    LE Piconet Channel
    LE Advertisement Broadcast Channel

    而物理链路,则是对这些物理信道(主要是BR/EDR技术中的Basic Piconet Physical Channel和Adapted Piconet Physical Channel)的进一步封装,其主要特征是(可参考2.5中的图片以辅助理解):

    1)Physical Link是一个虚拟概念,不对应协议中任何的实体,数据包封包/解包的过程中不被体现。

    2)AMP Physical Channel、LE Piconet Channel、LE Advertisement Broadcast Channel均有一个一一对应的Physical Link,分别是AMP Physical Link、LE Active Physical Link、LE Advertising Physical Channel。

    3)BR/EDR Page Scan Physical Channel、BR/EDR Inquiry Scan Physical Channel、BR/EDR Synchronization Scan Channel只在特定时间段使用,且无法控制任何属性,因此不需要再Physical Link中体现。

    4)BR/EDR Basic Piconet Physical Channel和BR/EDR Adapted Piconet Physical Channel是BR/EDR技术中已连接设备之间进行数据通信的通道,且同一时刻只能根据应用场景选择一种channel进行数据传输。因此这两个channel被map到BR/EDR Active Physical Link、BR/EDR Parked Physical Link和BR/EDR Connectionless Slave Broadcast Physical Link三个物理链路上。

    5)BR/EDR Active Physical Link和BR/EDR Parked Physical Link的抽象主要有两个方面的意义:
            5-1)屏蔽底层的Basic/Adapted Piconet Physical Channel之间的差异,统一使用Physical Link取代。在需要的时候,可以通过上层的链路管理协议,指定使用哪一种physical channel(Basic or Adapted)。
            5-2)可以通过Physical Link的抽象,控制Physical Channel的一些属性(如发射功率、收发周期等),以达到节省功耗的目的。而上面的层次(如逻辑层)不需要对这些动作知情。

    6)BR/EDR Active Physical Link定义了连接状态的蓝牙设备在链路处于active状态时的物理链路,该物理链路对应的设备的发射功率是可修改的。

    7)BR/EDR Parked Physical Link定义了连接状态的蓝牙设备在链路处于parked状态时的物理链路。parked状态是一种特殊的连接状态,连接双方没有正在进行的数据传输,所有的链路消耗,都是为保持连接所做的事情。此时可以通过降低在物理信道上的收发频率而降低功耗。该物理链路和BR/EDR Active Physical Link使用相同的物理信道。

    8)BR/EDR Connectionless Slave Broadcast Physical Link使用BR/EDR Adapted Piconet Physical Channel,用于一点到多点的广播通信。

    9)由上面的描述可知,物理链路这一层抽象,实在是可有可无,希望大家不要纠结,知道怎么回事即可。

    2.2 逻辑层

    逻辑层的主要功能,是在已连接(LE Advertisement Broadcast可以看做一类特殊的连接)的蓝牙设备之间,基于物理链路,建立逻辑信道。所谓的逻辑信道,和城市道路上的车道类似:

    一条城市道路可以看做一个物理链路(可能有两个方向,我们只考虑其中一个即可),该物理链路根据行车用途,可以划分为多个逻辑信道,如直行车道、右转车道、左转车道、掉头车道、快速车道、慢速车道等等。

    这里的车道(逻辑信道),从物理角度看,并没有什么分别,只是为了方便交通(数据传输),人为的抽象出来的。和车道类似,蓝牙逻辑信道的划分依据是传输类型,主要包括下面3类(即Logical Link):

    1)用于管理底层物理链路的控制类传输,包括AMP-C、ACL-C、PSB-C、LE-C、ADVB-C。

    2)传输用户数据的用户类传输,包括AMP-U、ACL-U、PSB-U、LE-U、ADVB-U。

    3)其它比较特殊的传输类型,包括流式传输(stream)、PBD(Profile Broadcast Data)。

    以上每种Logic Link都会在下层对应一个Logical Transport,这些Logical Transport具有一些属性值,如流控、应答/重传机制等。如下:

    AMP ACL(Asynchronous Connection-Oriented Link),基于AMP技术的、面前连接的、异步传输链路,为AMP-U提供服务。

    BR/EDR ACL,基于BR/EDR技术的ACL链路,为ACL-C、ACL-U提供服务。

    SCO/eSCO(Synchronous Connection-Oriented/Extended SCO),基于BR/EDR技术的、面向连接的、同步传输链路,为stream类型的Logical Link提供服务。

    ASB(Active Slave Broadcast)、PSB(Parked Slave Broadcast),基于BR/EDR技术的、面向连接的广播传输链路,为ACL-U、PSB-U、PSB-C提供服务。

    CSB(Connectionless Slave Broadcast),基于BR/EDR技术的、无连接的广播链路,为PBD提供服务。

    LE ACL,基于LE技术的、面前连接的、异步传输链路,为LE-U、LE-C提供服务。

    ADVB(Advertising Broadcast),基于LE技术的、广告/广播链路,为ADVB-U、ADVB-C提供服务。

    注2:AMP-C没有对应的Logical Transport,而是直接控制AMP Physical Link完成所需功能。

    注3:蓝牙逻辑层的抽象也是让人醉了!还是那句话,不要逼自己去理解一个疯子的行为,不然自己也会疯的。

    2.3 L2CAP Channels

    L2CAP是Logical Link Control and Adaptation Protocol(逻辑链路控制和适配协议)的缩写,蓝牙协议到这个层次的时候,就清爽多了:

    对下,它在用户类XXX-U Logical Link的基础上,抽象出和具体技术无关的数据传输通道(包括单播和广播两类),至此用户就不再需要关心繁杂的蓝牙技术细节。

    对上,它以L2CAP channel endpoints的概念(类似TCP/IP中的端口),为具体的应用程序(profile)提供独立的数据传输通道(当然,也是一个逻辑通道)。

    2.4 Profiles

    profile是蓝牙Application的代指,也可以翻译为服务,为了实现不同平台下的不同设备的互联互通,蓝牙协议为各种可能的、有通用意义的应用场景,都制定的了规范,如SPP、HSP、HFP、FTP、IPv6/6LoWPAN等等。

    Profiles基于L2CAP提供的L2CAP channel endpoints实现,在它们对应的层次上进行数据通信,以完成所需功能。有关蓝牙profile的介绍,会在后续文章中陆续给出,这里就不再详细说明了。

    2.5 总结

    下面图片包含上面各个层次(除了APP layer)中涉及到的一些实体、概念以及相互关系,供大家参考。

    Overview of transport architecture entities and hierarchy

    摘录自:Core_v4.2.pdf---->Vol1: Architecture & Terminology Overview---->Part A: Architecture---->3 DATA TRANSPORT ARCHITECTURE---->3.2 TRANSPORT ARCHITECTURE ENTITIES

    3. 蓝牙核心框架

    蓝牙规范有两类:一类是蓝牙核心规范,由Bluetooth Core Specification定义,囊括到L2CAP层,以及相关的核心profile;另一类是蓝牙Application规范,包含了各种各样的profile规范(具体可参考“Specifications | Bluetooth® Technology Website”中的列表)。

    蓝牙核心规范所定义的框架如下:

    正在上传…重新上传取消​摘录自:Core_v4.2.pdf ---->Vol1: Architecture & Terminology Overview---->Part A: Architecture---->2 CORE SYSTEM ARCHITECTURE

    经过第2章协议层次的介绍,蓝牙核心框架已经比较容易理解了,这里对层次中各个模块做一个简单的说明,更为详细的分析,请参考后续的文章。

    1)BR/EDR Radio & LE Radio & AMP PHY

    蓝牙RF层(物理层),包括BR/EDR、LE以及AMP三种。负责在物理channel上收发蓝牙packet。

    对BR/EDR和LE RF来说,还会接收来自Baseband的控制命令来控制RF频率的选择和timing。

    AMP PHY使用802.11(WIFI)的规范,本文不再详细介绍,后续有关AMP的内容,也不过多涉及。

    2)Link Controller & Baseband resource management

    Link Controller和Baseband resource management组成了蓝牙的基带(baseband)。

    Link Controller负责链路控制,主要是根据当前物理channel的参数、逻辑channel的参数、逻辑transport的参数将数据payload组装成bluetooth packet。另外,通过Link Control Protocol(对LE来说是LL Layer Protocol),可以实现流控、ack、重传等机制。

    Baseband resource management,主要用于管理RF资源。

    3)Link Manager

    Link Manager主要负责创建、修改、释放蓝牙逻辑连接(Logical Link),同时也负责维护蓝牙设备之间物理连接(Physical Link)的参数。它的功能主要是通过Link Management Protocol(LMP,for BR/EDR)和Link Layer Protocol(LL,for LE)完成。

    4)Device Manager

    Device Manager主要负责控制蓝牙设备的通用行为(蓝牙数据传输除外的行为),主要是:

    搜索附近的蓝牙设备

    连接到其他的蓝牙设备

    使得本地的蓝牙设备connectable和discoverable

    控制本地蓝牙设备的属性(例如本地蓝牙设备的名字、link key等)

    5)HCI(Host Controller Interface)

    我们在“蓝牙协议分析(1)_基本概念”介绍过,蓝牙系统分为Bluetooth Controller和Bluetooth Host两个大的block。它们之间通过HCI接口以HCI协议进行通信。

    6)L2CAP

    L2CAP位于Bluetooth Host中,包括两个子模块:

    Channel Manager主要负责创建、管理、释放L2CAP channel。

    L2CAP Resource Manager负责统一管理、调度L2CAP channel上传递的PDU(Packet Data Unit),以确保那些高QoS的packet可以获得对物理信道的控制权。

    7)SMP(Security Manager Protocol)

    SMP是一个点对点的协议,基于专用的L2CAP channel,用于生成加密(encryption)和识别(identity)用的密匙(keys)。

    8)SDP(Service Discover Protocol)

    SDP也是一个点对点的协议,基于专用的L2CAP channel,用于发现其它蓝牙设备能提供哪些profile以及这些profile有何特性。在了解清楚了其他蓝牙设备的profile以及特性之后,本蓝牙设备可以发起对自己感兴趣的蓝牙profile的连接动作。

    9)AMP Manager

    基于L2CAP channel,和对端的AMP manager交互,用于发现对方是否具备AMP功能,以及收集用于建立AMP物理链路的信息。

    10)GAP(Generic Access Profile)

    GAP是一个基础的蓝牙profile,用于提供蓝牙设备的通用访问功能,包括设备发现、连接、鉴权、服务发现等等。

    GAP 是所有其它应用模型的基础,它定义了在 Bluetooth 设备间建立基带链路的通用方法。还定义了一些通用的操作,这些操作可供引用 GAP 的应用模型以及实施多个应用模型的设备使用。GAP 确保了两个 蓝牙设备(不管制造商和应用程序)可以通过 Bluetooth 技术交换信息,以发现彼此支持的应用程序。

    展开全文
  • 蓝牙协议栈总结

    千次阅读 2022-06-04 09:07:47
    频带:2400-2483.5MHz,分为79个跳频信道,每个信道带宽为1MHz,上保护带宽3.51MHz,下保护带宽2MHz。蓝牙2.0 EDR模式对分组调制方式的修改:全世界所有蓝牙设备地址...只传输数据分组,不传输蓝牙音频电缆替代协议蓝牙
  • 移动通信实验报告

    2011-12-31 11:14:03
    通过具体的蓝牙服务发现协议: 了解网络的服务发现方式; 了解数据的表示方式; 掌握服务发现的工作流程; 掌握典型的客户-服务器工作模式
  • Android开发之——蓝牙-协议

    千次阅读 2021-12-14 16:51:52
    一 概述 传统蓝牙和低功耗蓝牙 蓝牙进行通信的四大必需任务 ...传统蓝牙模块:在2004年推出,主要代表是支持蓝牙2.1协议的模块,在智能手机爆发的时期得到广泛支持。 高速蓝牙模块:在2009年推出,速率提高到约24
  • 蓝牙协议简介

    万次阅读 2021-04-20 13:45:25
    从左到右依次为:经典蓝牙(BR/EDR)、双模蓝牙(同时支持BR/EDR/LE)和低功耗蓝牙(BLE)。其中经典蓝牙和低功耗蓝牙互不兼容。 其实看结构也可以看出双模蓝牙是经典蓝牙和低功耗蓝牙的合集。 (二)、蓝牙原理及...
  • 蓝牙相关协议解析

    千次阅读 2021-07-21 18:14:13
    1、ARM平台蓝牙协议栈移植详解: https://blog.csdn.net/gatieme/article/details/48751743 2、蓝牙协议栈各层功能简介: http://blog.chinaunix.net/uid-21411227-id-2780269.html 3、蓝牙广播通信相关技术分析...
  • 蓝牙蓝牙协议

    万次阅读 多人点赞 2019-03-14 09:46:25
    蓝牙协议学习整理(一)蓝牙的概述 转自: https://blog.csdn.net/guoxiaolongonly/article/details/78414870 传送门:(一)蓝牙的概述(二)蓝牙协议规范(射频、基带链路控制、链路管理)(三)蓝牙协议规范...
  • 蓝牙BLE(协议栈、OSAL、蓝牙APP工具)

    千次阅读 2021-12-18 09:33:42
    参考:千锋教育嗨哥_JDY-10M蓝牙模块教学视频 ...seid=539420550276958520&spm_id_from=333.337.0.0 JDY-10M蓝牙模块 ...使用AT指令,隐藏了底层的蓝牙通信协议栈 控制功能数据AT指令 手机APP通信 ...
  • c/c++ windows 通过winrt操作ble 蓝牙 #include #include #include #include <winrt/Windows.Foundation.Collections.h> #include #include #include #include #include <winrt/Windows.Storage.Streams.h>
  • 这年头协议栈开源的太多了,掌握基础蓝牙协议栈作为嵌入式软件工程师的进阶技能。如果有了解并应用的市面上大部分蓝牙芯片,不妨看看如下内容,对于理解并提升蓝牙协议了解有一定帮助。 本次文章主要说明如何去学习...
  • 蓝牙协议栈初识

    千次阅读 多人点赞 2018-12-03 10:30:02
    在学习的过程中一直有疑问,为什么蓝牙技术突然就产生了呢?蓝牙技术的目的是什么呢?蓝牙技术相对于它所替代的技术存在什么样的优势和劣势呢?蓝牙技术都做了些什么呢? 随着我们周围电子产品的增多电子产品之间的...
  • 蓝牙协议栈详解

    2021-05-24 02:31:08
    蓝牙协议体系中的协议蓝牙协议体系中的协议按SIG的关注程度分为四层:核心协议:BaseBand、LMP、L2CAP、SDP;电缆替代协议:RFCOMM;电话传送控制协议:TCS-Binary、AT命令集;选用协议:PPP、UDP/TCP/IP、OBEX、WAP...
  • 蓝牙协议BT&BLE

    千次阅读 2022-05-18 15:32:39
    目录 基本概念 概述 Basic Rate(BR) Low Energy(LE) 系统组成 BR/EDR vs LE vs AMP 芯片架构 协议架构 协议层次 物理层 ...蓝牙规范 基本概念 前言 自1994年由爱立信推出至今,蓝...
  • 蓝牙 4.0 BLE 协议栈基本概念

    千次阅读 2021-10-19 08:55:42
    协议栈的实现方式采用分层的思想,控制器部分包括:物理层、链路层、主机控制接口层;主机部分包括:逻辑链路控制及自适应协议层、安全管理层、属性协议层、通用访问配置文件层、通用属性配置文件层;上层可以调用...
  • 蓝牙协议及其源代码分析.rar

    热门讨论 2013-03-01 15:50:35
    1.1.3 蓝牙协议体系结构........ PAGEREF _Toc120615559 \h 14 1.1.4 蓝牙应用模型及协议栈................. PAGEREF _Toc120615560 \h 17 1.1.5 蓝牙技术的应用............ PAGEREF _Toc120615561 \h 19 1.2 金瓯...
  • BLE低功耗蓝牙协议

    千次阅读 2022-03-14 17:52:42
    (1)蓝牙核心协议(Bluetooth Core) (2)蓝牙应用层协议(Bluetooth Application) (3)BLE低功耗蓝牙核心协议层详解(Bluetooth Core) ① 物理层(PHY) ② 链路层(LL) ③ 主机控制接口层(HCI) ④ ...
  • Android SDP服务发现初始化、连接流程图(协议栈),非常详细的从btif-bta-btm-hci 数据流程走向,以及从controller收到数据到btm层,将Android 源码使用流程图的形式画了出来,使Android 蓝牙开发者更清楚数据收发...
  • 蓝牙协议栈记录—BTStack

    千次阅读 2021-05-24 02:30:05
    简介2.BTStack 架构BTStack在所实现的协议服务之间采用很多状态机实现相互作用,特点:<1>单线程.BTStack只有一个单独的循环。<2>没有阻塞,采用event事件方式。<3>No artficially limited ...
  • 吐血推荐历史最全的蓝牙协议栈介绍

    万次阅读 多人点赞 2020-07-21 18:29:00
    第二篇:Transport层介绍,主要介绍蓝牙协议栈跟蓝牙芯片之前的硬件传输协议,比如基于UART的H4,H5,BCSP,基于USB的H2等 第三篇:传统蓝牙controller介绍,主要介绍传统蓝牙芯片的介绍,包括射频层(RF),基带层...
  • 蓝牙应用层协议介绍

    千次阅读 2019-03-02 15:54:21
    蓝牙应用层协议介绍 本文主要简要介绍如下内容: 蓝牙术语 GAP SDAP SPP GOEP HFP DUN HSP A2DP AVRCP 未完待续。。。 一、蓝牙术语: 1,蓝牙用户接口(UI):蓝牙操作界面 2,蓝牙设备名称:蓝牙...
  • 1.蓝牙技术的诞生与发展 1994年,爱立信公司为了在移动电话及其附件之间探求一种新的低功耗、低成本的空中接口,要能够去除连接移动电话与耳机、笔记本电脑及其它设备之间繁杂的线缆,更主要的目的则是分析有多少种...
  • 二、低功耗蓝牙协议 1.协议组成图 2.控制器(Controller) 2.1 PHY物理层 2.2 链路层(LL) 2.3主机控制接口(HCI) 3.主机(HOST) 3.1 逻辑链路控制和适配协议(L2CAP) 3.2 通用属性规范(GATT)和属性...
  • Android 蓝牙开发底层的几种协议介绍

    千次阅读 2021-11-26 18:15:15
    Android 传统蓝牙开发1.HCI 协议2.RFcomm 协议L2CAP 协议SDP 协议ATT_GATT 协议HFP 协议SPP 协议 适用范围:经典蓝牙模块多用在蓝牙音频模块,大量数据传输,对耗电量没有严苛要求的设备,同时又分为传统蓝牙和高速...
  • SDP服务发现协议

    2011-09-30 10:42:43
    SDP 蓝牙服务发现协议 是一个很核心的协议 特别是对做产品的工程师 都需要比较深入的了解。
  • 蓝牙SSP&SMP协议介绍

    千次阅读 2021-10-25 16:20:06
    2.维护或提高蓝牙无线技术的安全性 通过提供一些关联模型来简化配对过程。这些模型具有适应不同设备输入/输出能力的灵活性。SSP也通过增加ECDH公钥加密来改进安全性,以防止配对过程中的被动窃听和中间人(MITM)...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,342
精华内容 4,936
热门标签
关键字:

蓝牙服务发现协议