L2CAP(1&2)

1 introduction

L2CAP向上层提供面向连接的和无连接的数据服务,包含了协议的多路复用功能和分段重组操作。L2CAP允许高层协议和应用发送和接收最大达64KB的数据包(L2CAP service data units, SDU),L2CAP也允许在每个信道上的流控和重传。
L2CAP层提供的逻辑信道称为L2CAP信道,由一个或多个逻辑链路组成。

1.1 L2CAP features

L2CAP的功能包括 协议/信道复用, 分段重组(segmentation and reassembly, SAR),各信道流控和错误控制。L2CAP面向底层是由以下一种组成:

  • BR/EDR Controller and zero or more AMP Controllers
  • BR/EDR/LE Controller(supporting BR/EDR and LE) and zero or more AMP Controllers
  • LE Controller(supporting LE only)



    上图描述了L2CAP的架构组成。Channel Manager提供了控制层面的功能,控制所有的内部信号,L2CAP点对点信号和上层和下层的信号。后面会描述它的状态机和消息格式。Retransmission and Flow Control 模块提供了各信道内的流控和利用包的重传实现错误恢复。Resource Manager负责提供需要转播服务到Channel Manager, Retransmission and Flow Control模块的帧,和一些不需要Retransmission and Flow Control的应用数据流。同时负责协调packets在底层设备提供的多路L2CAP信道间的传输和接收。

  • 协议/信道复用
    L2CAP支持独立的controller和多路复用的controller。一个L2CAP信道一次只能在一个controller上运行。在信道建立期间,L2CAP运用协议复用方式来将连接路由至正确的上层协议。
    对于数据传输,可用逻辑信道复用来区分不用的上层实体。有可能有多个上层实体使用相同的协议。
    这句话应该是说不同设备可以同时进行类似SDP操作,所以需要通过逻辑信道来区分。而建立的时候CID都是signaling,是通过建立不同的协议来区分的,建立好以后分配了不同的逻辑信道来用于后面识别数据传输。
  • 分段和重组
    Resource Manager提供的中继帧的长度由各自运行在L2CAP上的应用自己控制。如果L2CAP控制了PDU的长度,那么那些多路复用的应用会更方便,有如下好处:
    • 分段能够让应用数据单元满足延迟需求
    • 内存管理更容易
    • 利用重传进行的错误恢复会更有效
    • L2CAP PDU传输错误或丢包影响的数据量更小
    • 应用本身不再需要为将包映射到下层而需要做的分段了,由L2CAP做了。
  • L2CAP各信道流控
    controller为空中包提供了错误控制和流控, HCI传输上的数据HCI也提供了流控。当同一个controller上的数据流在不同的L2CAP信道上传输时,各个信道需要各自内部的流控机制,L2CAP提供了一个流控窗口。
  • 错误控制与重传
    当L2CAP信道从一个controller传输到另一个时,数据可能会丢失。有的应用要求的丢包率也可能远远小于一些controller可以提供的。此时,L2CAP提供了错误检查和重传L2CAP PDU机制。L2CAP的错误检测机制防止了controller错误的接收了通过controller内部检查的错包。L2CAP的错误检查和重传同时防止了由于controller flush导致的丢包。错误控制和流控协作,流控会向控制首次传输一样来控制后面的重传。
  • support for streaming
    流媒体应用如audio建立的L2CAP信道包含约定的传输速率,同时不需要流控,包括了controller也改变了流控。flush timout用来保持数据在发送端持续发送。streaming mode用来停止接收端的HCI和controller的流控。
  • 分片和重组
    一些controller有传输大小限制,帧大小限制和L2CAP分段的大小不一致。L2CAP以下的层可能需要继续分片重组成合适的大小。在一个L2CAP PDU的传输中,发送接收两端都可能发生不同层的分片和重组。
    HCI驱动或控制器可能会将L2CAP PDU分片至host controller接口传输机制限制的honor packet size。这会导致HCI的数据载荷包含了L2CAP PDU的start和continuation分片。同理controller可能会将L2CAP PDU分片至适应controller包的大小,导致controller包的载荷包含了L2CAP PDU的start和continuation分片。
    不同层的协议栈可能传输不同大小的L2CAP PDU碎片,不同设备间同一层的分片大小也可能不一样。但是PDU是在Stack中分片的,接收设备的L2CAP实体还是会将他们重组为原始的L2CAP PDU。
  • Quality of Service
    L2CAP连接的建立过程允许双方交换期待的Qos。每个L2CAP监控资源运用来满足之前沟通的Qos。
    对于BR/EDR或者BR/EDR/LE controller, L2CAP支持相同ACL逻辑链路上的同步或者异步的数据传输,通过设置HCI ACL数据包的Packet_Bundary_Flag来将包设置成自动刷新或非自动刷新的。自动刷新的LACP包将根据automatic flush timout来自动刷新,这个timeout值是L2CAP信道映射的时候设置在ACL逻辑链路上的。非自动刷新的L2CAP包不受automatic flush timout影响不会被刷新。所有的L2CAP包都可以通过HCI的flush命令来刷新。
    对于AMP controller,L2CAP会将所有发送到同一个设备的异步数据聚合在一个逻辑链路上。同步数据还是在各自的逻辑链路里传输。

1.2 Assumptions

协议设计遵循下列假设:

  • controller有序的提供数据包,尽管数据包可能不完整或者重复。对于BR/EDR或者BR/EDR/LE controller,两个设备之间不能有超过一个ACL-U逻辑链路,AMP controller可以有多个。BR/EDR/LE或则LE controller之间最多不能有超过一个LE-U逻辑链路
  • controller总是提供全双工通信的信道,这不意味着所有L2CAP的通信都是双向的,单向通信不需要双工信道。
  • L2CAP层提供一个可以评估controller的可靠性等级的信道,在这个增强的L2CAP层上可以进行包的分组重传错误检测。有的controller会对数据传输进行完整性检查,会不断重传直到收到成功的ack或者超时。有的controller会一直重传数据到需要flush的次数。因为ack有可能会丢失,即使数据成功传输仍有可能发生超时。同时需要注意的是,BR/EDR或BR/EDR/LE controller上的广播包是不可靠的,所有的广播包从拥有相同sequence bit的L2CAP分段开始。
  • controller对空中包提供错误控制和流控,HCI上的数据有HCI的流控,但是有的应用仍然需要更好的错误控制。在controller之间移动信道需要L2CAP层的流控和错误控制。流控和错误控制有四个模式,Enhanced Restransmission Mode和Restransmission Mode提供了分段,流控和L2CAP PDU的重传。Flow control Mode只提供分段和流控。Streaming mode提供分段和接收方数据的刷新。


1.3 Scope

L2CAP不提供:

  • L2CAP不传输SCO或者eSCO链路上的同步数据
  • L2CAP不支持可靠的广播信道

1.4 Terminology

2 General Operation

L2CAP是基于信道的概念的。每个信道的一端都可以用channel identifier(CID)标识。

2.1 Channel identifiers

一个CID是一个由设备逻辑信道一端表示的本地名,CID的范围与逻辑链路有关,如下图所示:



空标识(0x0000)不要用在目的端口。0x0001到0x003F保留给L2CAP功能,被称为固定信道。最小的标识是L2CAP的signaling channel,0x0001,或者是L2CAP LE signaling channel, 0x0005。如果支持0x0005,那么0x0004和0x0006也是支持的。可以通过Information Request/Response来得到远端设备的ACL-U逻辑链路的固定信道号。
每个固定信道的特征都是不同的,这些特征有配置参数(如可靠性,MTU,QoS),安全和通过L2CAP configuration机制来修改参数的能力,具体可见下表:




当ACL-U或者LE-U逻辑链路建立起来后固定信道就已经存在了。所有一般信道建立时需要的初始化工作,支持的固定信道在ACL-U或者LE-U逻辑链路建立的时候就都做好了。固定信道也只能在ACL-U或者LE-U上运行,不可移动。

剩下的信道可以自由命名CIDs,但是同一时期启用的L2CAP信道不能有相同的CID。ACL-U和LE-U逻辑链路拥有不同的CID命名空间,AMP-U与ACL-U分享CID命名空间。
CID的动态分配与不同的逻辑链路有关,一个设备可以独立的分配CID。因此,尽管分配给连接到本地设备的不同远端设备的CID可能相同,设备依然可以连接到不同的远端设备。更甚,相同的CID分配给连接到本地设备的同一个设备,依然能够区分,因为他们分属不同的逻辑链路。

2.2 Operation between devices

下图举例说明了CID在不同设备的L2CAP实体间通信时的用处。面向连接的数据意味着两个设备之间已建立连接,就会有一个CID绑在这个逻辑链路上来标识信道的一端。当进行广播时,无连接的信道使得数据是单向传输的,这个无连接信道可能是传输数据到piconet里的所有slave端的。 当进行单播传输时,这个无连接信道可能用于master和slave之间的任一方向传输。
固定信道CID 0x0001是signaling信道,用来创建面向连接的数据信道,沟通协商面向连接的数据信道的变化和发现ACL-U上的面向连接的信道。
L2CAP signaling信道和所有的固定信道在ACL-U建立好后就存在了。0x0002保留用来做所有的incoming和outgoing的无连接数据传输,不论是广播还是单播。无连接的数据可能在ACL-U建立起来后,发送设备确认远端设备支持无连接传输后立即传输。

2.3 Operation between layers

L2CAP需按下面的描述来架构。L2CAP在上层和下层之间传输数据。文中列举了很多L2CAP支持的服务。每个实现还必须支持signaling命令,还需支持接收从下层发上来的多个events,产生对应events发送到上层。


2.4 Modes of operation

每个L2CAP信道可从下列5个模式中选择一个:

  • Basic L2CAP Mode
  • Flow Control Mode
  • Retransmission Mode
  • Enhanced Retransmission Mode
  • Streaming Mode
  • LE Credit Based Flow Control Mode
    模式是通过配置过程启用的。Basic L2CAP Mode是默认模式, Enhanced Retransmission Mode 用于AMP-U和ACL-U上的可靠信道。Streaming Mode用于AMP-U和ACL-U上的流媒体应用。当双方L2CAP都支持时,Enhanced Retransmission Mode 或者Streaming Mode就应该启用,当不支持这两个模式时,才会启用Flow Control Mode或Retransmission Mode。
    在Flow Control Mode,Retransmission Mode和Enhanced Retransmission Mode中,传输的PDU会被计数和回复ack。PDU中的顺序号用来控制buffer,流控中也会用到TxWindow来限制所需的空间大小。
    Flow Control Mode中没有重传,但是丢失的PDU会报丢包。
    Retransmission Mode中有个timer来保证所有的PDU都传输成功了,超时重传。使用go-back-n 连接重传机制来简化协议和控制buffer开销。
    Enhanced Retransmission Mode类似Retransmission Mode。增加了一个POLL位来确保远端回复。增加SREJ S-frame来提升错误恢复的效率。增加RNR S-frame来取代R-bit来报告本地busy condition。
    Streaming Mode是为了实时传输同步数据的。PDU中有序号但是无需回复ack。发送端有一个flush timout值来控制没有发送的包的刷新,接收端的buffer如果满了,新的PDU会覆盖旧的PDU。丢失的PDU会上报丢包。没有TxWindow size。
    尽管ACL-U上的L2CAP信道可能是L2CAP Basic Mode,但是只有配置成Enhanced Retransmission Mode或者Streaming Mode的L2CAP信道才能转为AMP-U链路。
    L2CAP信道可用于多层复用,如果RFCOMM就能服务多种上层协议。当本地设备和远端设备都支持AMP和需要可靠性的服务(如RFCOMM)时,信道应该配置成Enhanced Retransmission Mode来保证没有被限制转移到AMP-U链路上。当本地设备和远端设备都支持AMP和不需要可靠性的服务时,信道应该配置成Streaming Mode来保证没有被限制转移到AMP-U链路上。
    Enhanced Retransmission Mode和Streaming Mode的参数选择需要慎重,尤其当他们使用beneath legacy profile来确保性能不会收到影响而差于在同一个ACL-U上的Basic mode时。当支持的服务不支持AMP或者不会在AMP下有益时,最好选择Basic Mode来最小化负面影响。

2.5 Mapping channels to logical links

L2CAP将信道映射到controller的逻辑链路上,逻辑链路轮流运行在controller的物理链路上。所有的本地设备和远端设备之间的逻辑链路都运行在一个屋里链路上。每个BR/EDR物理链路上都只有一个ACL-U逻辑链路,每个LE物理链路上都只有一个LE-U逻辑链路,但是AMP物理链路上可能有多个AMP-U逻辑链路。
两个设备之间的BR/EDR物理链路上的所有Best Effort和Guaranteed信道都映射到一个ACL-U逻辑链路上。AMP物理链路上的Best Effort信道都映射到一个AMP-U逻辑链路上,而Guaranteed信道都映射到各自的AMP-U逻辑链路上。两个设备间的LE物理链路上的所有信道都被看作是Best Effort,并被映射到同一个LE-U逻辑链路。
当一个Guaranteed信道被创建时,相关的Guaranteed逻辑链路也要被创建。Guaranteed逻辑链路的创建包含了准入控制,准入控制是用来确保guarantee的实现不需要对现有guarantee进行妥协。对AMP controller,L2CAP告诉controller要创建guaranteed逻辑链路,准入控制由controller来实现。对BR/EDR controller,准入控制由L2CAP来实现。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 158,847评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,208评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,587评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,942评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,332评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,587评论 1 218
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,853评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,568评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,273评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,542评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,033评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,373评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,031评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,073评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,830评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,628评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,537评论 2 269

推荐阅读更多精彩内容