专利名称：解决全双工数据传输时ack互锁延时的方法和系统的制作方法
技术领域：
本发明涉及通信技术，具体地涉及一种在双向数据传输过程中的ACK响应的方法。
背景技术：
2009年4月21日，蓝牙技术联盟(Bluetooth SIG)正式颁布了新一代标准规 范 “Bluetooth Core Specification Version 3. 0+High Speed，，(蓝牙核心规范 3. 0 版 +高速)，可简称为“蓝牙3. 0+HS”，或者“蓝牙3. 0”。“蓝牙3. 0+HS”的核心是“Generic Alternate MAC/PHY”(简称AMP)。这是一种全新的交替射频技术，允许蓝牙协议栈针对任 一任务动态地选择正确的射频，在兼容原有蓝牙2. 1+EDR前提下，增加了对802. Il(WiFi) 和ECMA368 (UWB)等高速传输层的支持。在传统蓝牙控制器时代，纠错与重传工作是由蓝牙控制器端负责，主机端无需做 出特别处理即可保证数据传输的可靠性；而根据蓝牙AMP架构，高速传输介质的控制器 不再负责确保数据传输的可靠性，因此需要主机端做出立即纠正与重传机制，而传统蓝牙 L2CAP的RT (重传)/FC(流控)模式存在设计缺陷当发送端检测到丢包时，强行重传所 有未响应帧，而且最多仅能使用半传输窗传输数据。“蓝牙3. 0+HS”规范定义了 eL2CAP的 ERTM(增强重传)/SM(流)模式，针对原有RT (重传)/FC(流控)模式的设计缺陷进行了升 级，主要变化在于遵照HDLC协议子集，增加了 SREJ (选择性拒绝帧)/RNR(接收端未准备 就绪)的控制帧；增加了“Poll-Final”比特域，当检测到丢帧时，发送端首先通过“RR(Poll =1) ”信令询问接收端当前的接收状态，随后决策用何种策略进行重传，因此避免了 RT模 式下检测到丢帧时强行连续重传帧带来的额外传输开销，并可实现全传输窗传输，速度较 RT模式最大半传输窗传输有大幅度提高。ERTM模式仍是基于传输响应的滑动窗传输模型。在发送端和接收端的数据传输过程中，包含信息帧(I帧)和控制帧(S帧)，其中 I帧用来传送高层协议信息和一些控制信息(例如流量控制和差错控制)，它携带发送序号 和接收序号；S帧则专门用来传送差错控制和流量控制的控制信息，主要功能是请求和挂 起传输、报告状态信息及确认接收到I帧，它只携带接收序号。而ACK(Acknowledge)是用 于流量控制的一个传输控制字符，表示确认发送端发送的一个或多个I帧已经接收无误 当发送端接收到接收端的ACK响应时，发送端就可以发送下一组I帧给接收端；如果发送端 没有收到ACK响应，那么发送端可能会重发当前I帧，也可能停止传送I帧。当ACK响应有 I帧可以“搭乘”时，通过I帧“携带”的方式进行ACK响应；否则只能通过S帧ACK响应，例 如上述的“RR(Poll = 1)，，信令就是S帧的ACK响应。当使用ERTM传输模式时，某些“请求——响应模型”的高层协议要求使用传输窗 (接收窗和发送窗)为 1,例如 A2MP 协议(Alternate MAC/PHY Manager Protocol)。此时， 常规的传输逻辑为接收端接收到一帧I帧后直接进行S帧的主动ACK响应，以避免因发送 端的发送窗满而不能发送I帧给接收端的阻塞现象，使得发送端可以继续发下一帧的I帧。 在初级优化中，考虑到“请求——响应模型”中的高层协议的I帧往往可以“携带”ACK响应，因此ERTM传输层需创建一个响应ACK的定时器(ACK-Timer)，以监控高层协议是否在ACK 定时器超时前传输了“携带”ACK响应的I帧，通过这种方式减少S帧的ACK响应的数量，提
高传输效率。但这种模型仅考虑了单向的“请求——响应”模型的通信路径，而由于通信双方有 传输数据的对称性，很可能出现双方互相各发起一条请求。在这种竞争发送关系下，双方的 接收窗和传输窗均满，导致在ACK定时器超时发送S帧的ACK响应之前都不能继续发送任 何新的I帧给对方，而只能等待ACK定时器超时后为对方发送S帧的ACK响应，来清除对方 的发送阻塞条件(即清除“本地接收窗满”)。我们将上述ACK定时器超时前双方均不能发 送I帧的情形称为ACK互锁延时。在ACK互锁延时的情况下，双方不得不等待ACK定时器 的超时才能恢复数据传输，降低了建链或者传输过程的效率。另外，在不限定接收窗的窗长为1的其它传输协议中，也有可能发生ACK互锁延时 的情况(虽然发生的概率比较小)，但一旦发生ACK互锁延时，也必然会在一定程度上影响 传输速度或建链速度。
发明内容
本发明的目的就是公开了解决全双工数据传输时ACK互锁延时的方法、设备和系 统，避免在ACK互锁延时的情况下等待ACK定时器超时的时间浪费，以提高建链或数据传输 的速度。本发明的一方面，提出了一种解决全双工数据传输时ACK互锁延时的方法，用于 至少包括两个通信设备第一设备和第二设备的系统，第一设备和第二设备之间互相传输数 据。第一设备检测本地接收窗和本地发送窗是否已满；当第一设备检测到本地接收窗已满 而不能继续接收第二设备的信息帧，且第一设备检测到本地发送窗已满而不能继续发信息 帧给第二设备时，第一设备主动发送ACK响应的控制帧给第二设备。优选地，当第一设备从第二设备接收到信息帧，或者当第一设备要发信息帧给第 二设备时，第一设备检测本地接收窗是否已满以及检测本地发送窗(即第二设备的接收 窗)是否已满。优选地，第一设备检测第一设备未响应ACK给第二设备的信息帧的帧数和本地接 收窗的窗长，如果上述两者相等则认为检测到本地接收窗已满而不能继续接收第二设备的 信息帧，否则第一设备检测到本地未响应ACK给第二设备的信息帧的帧数小于本地接收窗 的窗长，认为检测到的本地接收窗未满。优选地，第一设备检测第二设备未响应ACK给第一设备的信息帧的帧数和本地发 送窗的窗长，如果上述两者相等则认为检测到本地发送窗(即第二设备的接收窗)已满而 不能继续发信息帧给第二设备，否则第一设备检测到第二设备未响应ACK给第一设备的信 息帧的帧数小于本地发送窗的窗长，认为检测到的本地发送窗未满。该方法可通用于各传输协议中的ACK互锁延时问题。而对于第一设备和第二设备 的发送窗和接收窗的窗长均为1的情况下，因其较为容易发生ACK互锁延时的问题而显得 更为适用。本发明的另一方面，提出了一种解决全双工数据传输时ACK互锁延时的通信设 备，包括与通信对端之间相互传输数据的传输模块。该通信设备还包括检测模块，用于检
5测本地接收窗和本地发送窗是否均已满；以及执行模块，用于当所述检测模块检测到本地 接收窗已满而不能继续接收通信对端的信息帧，且检测到本地发送窗已满而不能继续发信 息帧给该通信对端时，通过所述传输模块主动发送ACK响应的控制帧给该通信对端。优选地，当所述传输模块从通信对端接收到信息帧，或者所述传输模块要发信息 帧给通信对端时，所述检测模块进行检测本地接收窗是否已满以及检测本地发送窗(即通 信对端的接收窗)是否已满。优选地，所述检测模块被用于检测本地未响应ACK给通信对端的信息帧的帧数和 本地接收窗的窗长，如果上述两者相等则认为检测到本地接收窗已满而不能继续接收通信 对端的信息帧，否则所述检测模块检测到本地未响应ACK给通信对端的信息帧的帧数小于 本地接收窗的窗长，认为检测到本地接收窗未满。优选地，所述检测模块被用于检测第二设备未响应ACK给本地的信息帧的帧数和 本地发送窗的窗长，如果上述两者相等则认为检测到本地发送窗已满而不能继续发信息帧 给该通信对端，否则所述检测模块检测到通信对端未响应ACK给本地的信息帧的帧数小于 本地发送窗的窗长，认为检测到本地发送窗未满。在一个实施例中，所述通信设备的本地接收窗和本地发送窗的窗长均为1。本发明的又一方面，提出了 一种解决全双工数据传输时ACK互锁延时的系统，至 少包括两个通信设备第一设备和第二设备，第一设备和第二设备之间互相传输数据。第一 设备检测本地接收窗和本地发送窗是否均已满；当第一设备检测到本地接收窗已满而不能 继续接收第二设备的信息帧，且第一设备检测到本地发送窗已满而不能继续发信息帧给第 二设备时，第一设备主动发送ACK响应的控制帧给第二设备。优选地，当第一设备从第二设备接收到信息帧，或者当第一设备要发信息帧给第 二设备时，第一设备检测本地接收窗是否已满以及检测本地发送窗(即第二设备的接收 窗)是否已满。优选地，第一设备检测第一设备未响应ACK给第二设备的信息帧的帧数和本地接 收窗的窗长，如果上述两者相等则认为检测到本地接收窗已满而不能继续接收第二设备的 信息帧，否则第一设备检测到本地未响应ACK给第二设备的信息帧的帧数小于本地接收窗 的窗长，认为检测到的本地接收窗未满。优选地，第一设备检测第二设备未响应ACK给第一设备的信息帧的帧数和本地发 送窗的窗长，如果上述两者相等则认为检测到本地发送窗已满而不能继续发信息帧给第二 设备，否则第一设备检测到第二设备未响应ACK给第一设备的信息帧的帧数小于本地接收 窗的窗长，认为检测到的本地发送窗未满。在一个实施例中，所述第一设备和第二设备的发送窗和接收窗的窗长均为1。本发明在初级优化中采用ACK定时器减少S帧主动响应ACK的数量的前提下，一 旦检测到ACK互锁延时情况的发生，就发出必要的主动S帧的ACK响应，使得双方不会因等 待ACK超时而阻塞数据的发送。本发明提高了双方数据的传输效率，而这种传输效率的提 高，往往出现在高层协议(例如A2MP协议)的建链过程中，对建链速度的提高显得尤为重 要。
通过借助优选实施例附图详细描述本发明的流程，将有助于理解本发明的目的和 优点。其中图1是全双工数据传输时ACK互锁延时的流程示意图；图2是根据本发明的第一优选实施例，给出解决全双工数据传输时ACK互锁延时 的方法的流程示意图；图3是根据本发明的第二优选实施例，给出解决全双工数据传输时ACK互锁延时 的方法的流程示意图；图4是根据本发明的优选实施例，给出解决全双工数据传输时ACK互锁延时的通 信设备和系统的结构示意图。
具体实施例本发明实施例中以含有eL2CAP (ERTM/SM模式)的蓝牙“V3. 0+HS”规范为例，在图 1中示出了蓝牙3.0规范中的某些高层协议(例如A2MP协议)在全双工数据传输过程中出 现ACK互锁延时情况的流程示意图，并在图2和图3中分别示出了在两种优选实施例中解 决全双工数据传输时ACK互锁延时的方法的流程示意图。但本领域的技术人员应该明白， 本发明不限定于解决蓝牙eL2CAP中的ACK互锁延时问题，也适合解决其它传输协议中的 ACK互锁延时问题。为了方便描述，本发明以ERTM模式下例如A2MP等高层协议(请求-响 应模型)要求使用传输窗(发送窗和接收窗)的窗长为1的情况来举例说明，但本发明同 样并不局限于“接收窗和发送窗的窗长均为1”的高层协议，也适用解决“传输窗的窗长大 于1”的其它高层协议全双工数据传输时的ACK互锁延时问题。图1是蓝牙3.0规范ERTM模式下全双工数据传输时ACK互锁延时的流程示意图。如图1所示，第一设备和第二设备之间互相传输数据。为了方便描述，本实施例仅 将第一设备和第二设备中的eL2CAP层和高层协议(例如A2MP协议)分别示出。但本领域 中的技术人员应该明白，第一设备和第二设备还可选择包括其它功能模块，例如包含蓝牙 射频、WiFi射频、UffB射频至少其中之一的传输模块，常规功能的输入模块和显示模块等。 第一设备和第二设备的传输窗(包括发送窗和接收窗)的窗长设定为1。第一设备的高层协议由无关ACK响应的其它事件触发发送了 “AMP_DiSC0Very_ Req”的请求给第一设备的eL2CAP层100，第一设备将该请求的发送序号标为0( “T SDU 0”)。第一设备的eL2CAP层将该“AMP_DiSC0Very_Req”的请求作为I帧(发送序号TxSeq =0，响应序号ReqSeq = 0)发送给第二设备的eL2CAP层101。第二设备的高层协议由无关ACK响应的其它事件触发也发送了 “AMP_DisC0Very_ Req”(发送序号标为0，“Τ SDU 0”)的请求给第二设备的eL2CAP层102。第一设备和第 二设备形成竞争关系。第二设备的eL2CAP层也将该“AMP_DiSC0Very_Req”请求作为I帧 发送给第一设备的eL2CAP层103，将该I帧的发送序号和响应序号分别标为0 (TxSeq = 0， ReqSeq = 0)。第一设备的eL2CAP层和第二设备的eL2CAP层分别将所收到对方的I帧以“AMP_ Discoveryjnd”(接收序号标为0，“R SDU 0，，)响应发送给它们的高层协议104，105。此 时，第一设备和第二设备ACK定时器启动。
7
由于第一设备和第二设备分别接收到对方的一个I帧并且没有回复ACK，第一设 备的本地接收窗和本地发送窗(即第二设备的接收窗)均已满。第一设备的高层协议发 送给第一设备的eL2CAP层的可携带ACK的又一 “AMP_DiSC0Very_RSp”请求(其中发送序 号标为1，“T SDU 1”)106，由于第一设备的发送窗(即第二设备的接收窗已满)而无法发 送给第二设备；同样地，第二设备的高层协议发送给第二设备的eL2CAP层的可携带ACK的 “AMP_DiSC0Very_RSp”请求(其中发送序号标为1，“T SDU 1”)107，也由于第一设备的接 收窗已满(即第二设备的发送窗已满)而无法发送给第一设备。在这种情况下，第一设备 和第二设备之间形成了 ACK互锁延时，只能等待ACK定时器超时才能给对方S帧的ACK响 应，以清除对方的发送阻塞条件(即清除“本地接收窗满”)。第一设备等待ACK定时器超时。ACK定时器超时后108，针对第二设备发送的I帧 (发送序号TxSeq = 0，响应序号ReqSeq = 0)，第一设备的eL2CAP层主动发送了 S帧的ACK 响应“RR” (响应序号ReqSeq = 1)给第二设备的eL2CAP层109，使得第二设备的eL2CAP层 对本地发送窗清零(即第一设备的接收窗清零)110。第二设备的eL2CAP层将高层协议发送 的“AMP_DiSC0Very_RSp”(发送序号标为1，“T SDU 1”)请求作为携带ACK响应的I帧发送 给第一设备的eL2CAP层(发送序号TxSeq = 1，响应序号ReqSeq = 1) 111，其中该ACK响应 是针对第一设备发送的“AMP_DiSC0Very_Req” I帧(发送序号TxSeq = 0，响应序号ReqSeq =0)的ACK响应，并由第一设备的eL2CAP层通过“AMP_Discovery_Rsp”响应(响应序号标 为1，R SDU 1)发送给第一设备的高层协议112，使得第一设备的eL2CAP层也对本地发送清 零(即第二设备的接收窗清零)113。第一设备的eL2CAP层对高层协议的“AMP_DiSC0Very_ Rsp”(发送序号标为1，“T SDU 1”)请求，以携带ACK响应的I帧(发送序号TxSeq = 1，响 应序号ReqSeq = 2)发送给第二设备的eL2CAP层114，其中该ACK响应是针对第二设备发送 的“AMP_Discovery_Req” I帧(发送序号TxSeq = 1，响应序号ReqSeq = 1)的ACK响应，并 由第二设备的eL2CAP层通过“AMP_Discovery_Rsp”响应(响应序号标为1，R SDU 1)发送给 第二设备的高层协议115。第一设备和第二设备恢复正常的数据传输。从上述不难看出，在第一设备和第二设备之间出现ACK互锁延时的情况下，必须 等待ACK定时器超时来发送S帧的ACK响应。在等待ACK定时器超时的时间内，双方无法 互传数据，影响了数据传输速度。尤其是ACK互锁延时发生在建链过程时，会引起建链速度 缓慢，直接给用户的使用带来不便。图2是根据本发明的第一优选实施例，给出解决全双工数据传输时ACK互锁延时 的方法的流程示意图。在本实施例中，第一设备400和第二设备401之间互相传输数据，而且第一设备 400和第二设备401的传输窗(发送窗和接收窗)的窗长为1。其中第一设备400和第二设 备401组成的结构框图如图4所示。第一设备400和第二设备401分别包括高层协议402， 405、eL2CAP层403，404和底层的传输模块406，407 (例如蓝牙射频、WiFi射频、UWB射频中 的一种或多种组合)。与现有蓝牙设备不同的是，在第一设备400的eL2CAP层403还包括 检测模块408，用于检测本地接收窗和本地发送窗是否已满；以及执行模块409，用于当检 测模块408检测到本地接收窗已满而不能继续接收第二设备401的I帧，且检测到本地发 送窗已满而不能继续发I帧给第二设备401时，主动发送ACK响应的S帧给第二设备。第 二设备401可以是现有的蓝牙设备，也可以是与第一设备400具备相同功能的蓝牙设备，即第二设备401的eL2CAP层404也包括具备上述相同功能的检测模块410和执行模块411。为了方便描述，在图2中省略了第一设备400和第二设备401的传输模块406， 407。但本领域的技术人员应该明白，第一设备400和第二设备401之间收发数据通过传输 模块406，407来实现。步骤200-202 第一设备400的高层协议402由无关ACK响应的其它事件触发发 送了 "AMP_Discovery_Req"(发送序号标为0号，“T SDU 0，，)的请求给第一设备400的 eL2CAP层403，第一设备400的eL2CAP层403将该请求作为I帧(发送序号TxSeq = 0， 响应序号ReqSeq = 0)发送给第二设备401的eL2CAP层404。此时，第二设备401的高层 协议405由无关ACK响应的其它事件触发也发送了 “AMP_DiSC0Very_Req” (发送序号标为 0号，“T SDU 0”)的请求给第二设备401的eL2CAP层404。第一设备400和第二设备401 形成竞争关系。步骤203-206 第二设备 401 的 eL2CAP 层 404 将该 “AMP_Discovery_Req” 请求 作为I帧(发送序号TxSeq = 0，响应序号ReqSeq = 0)发送给第一设备400的eL2CAP层 403。由于第一设备400和第二设备401分别接收到对方的一个I帧并且没有回复ACKJlJ 第一设备400的本地接收窗和本地发送窗(即第二设备401的接收窗)均已满。当第一设 备400的eL2CAP层403接收到第二设备401发送的I帧后，检测模块408开始检测本地接 收窗和本地发送窗是否已满。此时，第一设备400检测模块408检测到本地接收窗和本地 发送窗均已满，则第一设备400的执行模块409主动发送S帧的ACK响应“RR” (响应序号 ReqSeq = 1)给第二设备401的eL2CAP层404，其中该ACK响应是回复第二设备发送的I 帧(发送序号TxSeq = 0，响应序号ReqSeq = 0)的，使得第二设备401的eL2CAP层404对 本地发送窗清零(即第一设备的接收窗清零)。步骤207-210 第一设备400的eL2CAP层403和第二设备401的eL2CAP层404分 别将所收到对方的I帧以“AMP_DisC0Very_Ind”响应(响应序号标为0，“R SDU 0”)发送 给它们的高层协议402，405。第一设备400的高层协议402给第一设备400的eL2CAP层 403发送携带ACK的"AMP_Discovery_Rsp"请求(发送序号标为1，"T SDUl “)，而第二设 备401的高层协议405给第二设备401的eL2CAP层404发送携带ACK的“AMP_Discovery_ Rsp，，请求(发送序号标为1，“T SDU 1，，)。步骤211-214 第二设备401的本地发送窗已经清零(即第一设备的接收窗已清 零)，则第二设备401的eL2CAP层404可将高层协议405发送的“AMP_DiSC0Very_RSp”请 求作为携带ACK响应的I帧(发送序号TxSeq = 1，响应序号ReqSeq= 1)发送给第一设备 400的eL2CAP层403，其中该ACK响应是回复第一设备发送的“AMP_Discovery_Req” I帧 (发送序号TxSeq = 0，响应序号ReqSeq = 0)的，并由第一设备400的eL2CAP层403通过 “AMP_DiSC0Very_RSp”响应(响应序号标为1，“R SDU 1”)发送给第一设备400的高层协 议402，使得第一设备400的eL2CAP层403也对本地发送窗清零(即第二设备的接收窗清 零)。此时，第一设备400的eL2CAP层403对高层协议402的“AMP_Discovery_Rsp” (发 送序号标为1，“T SDU 1”)请求，以携带ACK响应的I帧(发送序号TxSeq = 1，响应序号 ReqSeq = 2)发送给第二设备401的eL2CAP层404，其中该ACK响应是回复第二设备发送 的“AMP_Discovery_Req” I帧(发送序号TxSeq = 1，响应序号ReqSeq = 1)的，并由第二 设备401的eL2CAP层404通过“AMP_Discovery_Rsp”响应(响应序号标为1，“R SDU 1”)发送给第二设备401的高层协议405。在上述过程中，由于eL2CAP层403的检测模块408在接收到第二设备401的I帧 数据时，就及时检测到本地接收窗和本地发送窗已满，触发执行模块409主动发送S帧的 ACK响应给第二设备401，避免了因ACK互锁延时而等待ACK定时器超时所发生的数据“阻 塞”，提高了速度传输速度和建链速度。图3是根据本发明的第二优选实施例，给出解决全双工数据传输时ACK互锁延时 的方法的流程示意图。图3所示的实施例与图2所示的实施例相类似，第一设备400和第二设备401组 成的结构框图也如图4所示，各功能模块的组成及其功能都与图2所示实施例中相同，不再 详细描述。所不同的是，在图3所示的实施例中，当第一设备400的eL2CAP层403要发送I 帧给第二设备401时，检测模块408开始检测本地接收窗和本地发送窗是否已满；而在图2 所示的实施例中，当第一设备400的eL2CAP层403从第二设备401接收到I帧时，检测模 块408开始检测本地接收窗和本地发送窗是否已满。第一设备400和第二设备401之间互相传输数据，第一设备400和第二设备401 的传输窗(发送窗和接收窗)的窗长均为1。为了方便描述，在图3中也省略了第一设备 400和第二设备401的传输模块406，407。但本领域的技术人员应该明白，第一设备400和 第二设备401之间收发数据通过传输模块406，407来实现。步骤300-305 第一设备400的高层协议402由无关ACK响应的其它事件触发发 送了“AMP_DiSC0Very_Req”(其发送序号标为0号，“T SDU 0”)的请求给第一设备400的 eL2CAP层，并由eL2CAP层403作为I帧(发送序号TxSeq = 0，响应序号ReqSeq = 0)发 送给第二设备401的eL2CAP层。第二设备401的高层协议405也由无关ACK响应的其它 事件触发发送了“AMP_DiSC0Very_Req”(其发送序号标为0号，“T SDU 0”)的请求给第二 设备401的eL2CAP层404。第一设备400和第二设备401形成竞争关系。第二设备401的 eL2CAP层404也将该请求作为I帧(发送序号TxSeq = 0，响应序号ReqSeq = 0)发送给 第一设备400的eL2CAP层403。第一设备400的eL2CAP层403和第二设备401的eL2CAP 层404分别将所收到对方的I帧以“AMP_Discovery_Ind” (响应序号标为0，"R SDU 0” ) 响应发送给它们的高层协议402，405。此时第一设备400和第二设备401分别接收到对方 的一个I帧而没有回复ACK，则第一设备400的接收窗和第二设备401的接收窗均已满。第 一设备400和第二设备401的ACK定时器启动。步骤306-310 第一设备400的高层协议402发送给第一设备400的eL2CAP层403 的携带ACK的请求“AMP_DiSC0Very_RSp”(发送序号标为1，T SDU 1)，由于第一设备400的 发送窗(即第二设备401的接收窗)已满而无法发送给第二设备401 ；同样地，第二设备401 的高层协议405发送给第二设备401的eL2CAP层404的携带ACK的请求“AMP_DisC0Very_ Rsp"(发送序号标为1，T SDU 1)，因为第一设备400的接收窗已满而无法发送给第一设备 400，即第一设备400和第二设备401之间形成了 ACK互锁延时。当第一设备400的eL2CAP 层403接收到高层协议402所发送的“AMP_DiSC0Very_RSp”请求(发送序号标为1，“T SDU 1”)时，检测模块408开始检测地接收窗和本地发送窗(即第二设备401的接收窗)是否 已满。此时，第一设备400的检测模块408检测到本地接收窗和本地发送窗均已满。第一 设备400的执行模块409主动发送S帧的ACK响应“RR”(响应序号ReqSeq = 1)给第二设备401的eL2CAP层404，其中该ACK响应是针对第二设备发送的“AMP_Discovery_Req” I 帧(发送序号TxSeq = 0，响应序号ReqSeq = 0)的ACK响应，使得第二设备401的eL2CAP 层404对本地发送窗(即第一设备400的接收窗)清零。步骤311-314 第一设备400的接收窗清零后，第二设备401的eL2CAP层404便 可将高层协议405发送的“AMP_DiSC0Very_RSp”(发送序号标为1，“T SDU 1”)，作为携 带ACK响应的I帧(发送序号TxSeq = 1，响应序号ReqSeq = 1)发送给第一设备400的 eL2CAP层403，其中该ACK响应是回复第一设备发送的“AMP_DiSC0Very_Req”I帧(发送序 号 TxSeq = 0，响应序号 ReqSeq = 0)的，并由 eL2CAP 层 403 通过“AMP_Discovery_Rsp”响 应(响应序号标为1，“R SDU 1”)发送给第一设备400的高层协议402，使得第一设备400 的eL2CAP层403也对本地发送窗(即第二设备401的接收窗)清零。此时，第一设备400 的eL2CAP层403对高层协议402的“AMP_Discovery_Rsp” (发送序号标为1，“T SDU 1”) 请求，以携带ACK响应的I帧(发送序号TxSeq= 1，接收序号ReqSeq = 2)发送给第二设 备401的eL2CAP层404，其中该ACK响应是回复第二设备发送的“AMP_Discovery_Req”I帧 (发送序号 TxSeq= 1，响应序号 ReqSeq= 1)的，并由 eL2CAP 层 404 通过“AMP_Discovery_ Rsp”响应(响应序号标为1，“R SDU 1，，)发送给高层协议405。在上述过程中，由于第一设备400的检测模块408在发送I帧给第二设备401时， 检测到本地接收窗和本地发送窗(即第二设备接收窗)均已满，从而触发执行模块409主 动发送S帧的ACK响应给第二设备401，减少了等待ACK定时器超时而响应S帧的时间，提 高了速度传输速度和建链速度。虽然本发明是参考其优选实施例示出和描述的，但本领域的普通技术人员应该理 解，在不脱离附属的权利要求书所限定的本发明的精神和范围的情况下，可以进行形式和 细节的各种改变。
权利要求
一种解决全双工数据传输时ACK互锁延时的方法，用于至少包括两个通信设备第一设备和第二设备的系统，第一设备和第二设备之间互相传输数据，其特征在于第一设备检测本地接收窗和本地发送窗是否均已满；当第一设备检测到本地接收窗已满而不能继续接收第二设备的信息帧，且第一设备检测到本地发送窗已满而不能继续发信息帧给第二设备时，第一设备主动发送ACK响应的控制帧给第二设备。
2.根据权利要求1所述的方法，其特征在于当第一设备从第二设备接收到信息帧时，第一设备检测本地接收窗是否已满以及检测 本地发送窗是否已满。
3.根据权利要求1所述的方法，其特征在于当第一设备要发信息帧给第二设备时，第一设备检测本地接收窗是否已满以及检测本 地发送窗是否已满。
4.根据权利要求1-3其中之一所述的方法，其特征在于第一设备的本地接收窗和本地发送窗的窗长均为1。
5.根据权利要求1-3其中之一所述的方法，其特征在于第一设备检测本地未响应ACK给第二设备的信息帧的帧数和本地接收窗的窗长，如果 上述两者相等则认为检测到本地接收窗已满。
6.根据权利要求1-3其中之一所述的方法，其特征在于第一设备检测第二设备未响应ACK给第一设备的信息帧的帧数和本地发送窗的窗长， 如果上述两者相等则认为检测到第一设备的发送窗已满。
7.一种解决全双工数据传输时ACK互锁延时的通信设备，包括与通信对端之间相互传 输数据的传输模块，其特征在于，还包括检测模块，用于检测本地接收窗和本地发送窗是否已满；以及执行模块，用于当所述检测模块检测到本地接收窗已满而不能继续接收通信对端的信 息帧，且检测到本地发送窗已满而不能继续发信息帧给该通信对端时，通过所述传输模块 主动发送ACK响应的控制帧给该通信对端。
8.根据权利要求7所述的通信设备，其特征在于当所述传输模块从通信对端接收到信息帧时，所述检测模块检测本地接收窗是否已满 以及检测本地发送窗是否已满。
9.根据权利要求7所述的通信设备，其特征在于当所述发送模块要发信息帧给通信对端时，所述检测模块检测本地接收窗是否已满以 及检测本地发送窗是否已满。
10.根据权利要求7-9其中之一所述的通信设备，其特征在于所述本地接收窗和本地发送窗的窗长均为1。
11.根据权利要求7-9其中之一所述的通信设备，其特征在于所述检测模块被用于检测本地未响应ACK给通信对端的信息帧的帧数和本地接收窗 的窗长，如果上述两者相等则认为检测到本地接收窗已满。
12.根据权利要求7-9其中之一所述的通信设备，其特征在于所述检测模块被用于检测通信对端未响应ACK的信息帧的帧数和本地发送窗的窗长，如果上述两者相等则认为检测到本地发送窗已满。
13.一种解决全双工数据传输时ACK互锁延时的系统，至少包括两个通信设备第一设 备和第二设备，第一设备和第二设备之间互相传输数据，其特征在于第一设备检测本地接收窗和本地发送窗是否均已满；当第一设备检测到本地接收窗已满而不能继续接收第二设备的信息帧，且第一设备检 测到本地发送窗已满而不能继续发信息帧给第二设备时，第一设备主动发送ACK响应的控 制帧给第二设备。
14.根据权利要求13所述的系统，其特征在于当第一设备从第二设备接收到信息帧时，第一设备检测本地接收窗是否已满以及检测 本地发送窗是否已满。
15.根据权利要求13所述的系统，其特征在于当第一设备要发信息帧给第二设备时，第一设备检测本地接收窗是否已满以及检测本 地发送窗是否已满。
16.根据权利要求13-15其中之一所述的系统，其特征在于第一设备的本地接收窗和本地发送窗的窗长均为1。
17.根据权利要求13-15其中之一所述的系统，其特征在于第一设备检测本地未响应ACK给第二设备的信息帧的帧数和本地接收窗的窗长，如果 上述两者相等则认为检测到本地接收窗已满。
18.根据权利要求13-15其中之一所述的系统，其特征在于第一设备检测第二设备未响应ACK给第一设备的信息帧的帧数和本地发送窗的窗长， 如果上述两者相等则认为检测到本地发送窗已满。
全文摘要
本发明公开了一种解决全双工数据传输时ACK互锁延时的方法、设备和系统。当传输双方的接收窗同时处于已满状态，会导致在ACK定时器超时前都不能继续发送任何新的I帧给对方，称为ACK互锁延时。在本发明中，当通信设备检测到本地接收窗和本地发送窗均已满时，通过主动发送ACK响应的S帧给通信对端来解决ACK互锁延时的问题，避免了等待ACK定时器超时发S帧ACK解除对方发送阻塞条件的时间浪费，提高了传输速度和建链速度。
文档编号H04L1/16GK101888288SQ20091008395
公开日2010年11月17日 申请日期2009年5月13日 优先权日2009年5月13日
发明者王尧, 鲁冬梅 申请人:艾威梯科技(北京)有限公司