CN101888288A - 解决全双工数据传输时ack互锁延时的方法和系统 - Google Patents

解决全双工数据传输时ack互锁延时的方法和系统 Download PDF

Info

Publication number
CN101888288A
CN101888288A CN2009100839523A CN200910083952A CN101888288A CN 101888288 A CN101888288 A CN 101888288A CN 2009100839523 A CN2009100839523 A CN 2009100839523A CN 200910083952 A CN200910083952 A CN 200910083952A CN 101888288 A CN101888288 A CN 101888288A
Authority
CN
China
Prior art keywords
equipment
window
local
ack
full
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN2009100839523A
Other languages
English (en)
Inventor
王尧
鲁冬梅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
IVT TECHNOLOGY (BEIJING) Inc
Original Assignee
IVT TECHNOLOGY (BEIJING) Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by IVT TECHNOLOGY (BEIJING) Inc filed Critical IVT TECHNOLOGY (BEIJING) Inc
Priority to CN2009100839523A priority Critical patent/CN101888288A/zh
Priority to PCT/CN2010/000683 priority patent/WO2010130156A1/zh
Priority to US13/319,716 priority patent/US8547881B2/en
Publication of CN101888288A publication Critical patent/CN101888288A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1832—Details of sliding window management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00—Arrangements for detecting or preventing errors in the information received
    • H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1867—Arrangements specially adapted for the transmitter end
    • H04L1/187—Details of sliding window management

Abstract

本发明公开了一种解决全双工数据传输时ACK互锁延时的方法、设备和系统。当传输双方的接收窗同时处于已满状态，会导致在ACK定时器超时前都不能继续发送任何新的I帧给对方，称为ACK互锁延时。在本发明中，当通信设备检测到本地接收窗和本地发送窗均已满时，通过主动发送ACK响应的S帧给通信对端来解决ACK互锁延时的问题，避免了等待ACK定时器超时发S帧ACK解除对方发送阻塞条件的时间浪费，提高了传输速度和建链速度。

Description

解决全双工数据传输时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.11(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互锁延时的通信设备，包括与通信对端之间相互传输数据的传输模块。该通信设备还包括：检测模块，用于检测本地接收窗和本地发送窗是否均已满；以及执行模块，用于当所述检测模块检测到本地接收窗已满而不能继续接收通信对端的信息帧，且检测到本地发送窗已满而不能继续发信息帧给该通信对端时，通过所述传输模块主动发送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射频、UWB射频至少其中之一的传输模块，常规功能的输入模块和显示模块等。第一设备和第二设备的传输窗(包括发送窗和接收窗)的窗长设定为1。
第一设备的高层协议由无关ACK响应的其它事件触发发送了“AMP_Discovery_Req”的请求给第一设备的eL2CAP层100，第一设备将该请求的发送序号标为0(“T SDU 0”)。第一设备的eL2CAP层将该“AMP_Discovery_Req”的请求作为I帧(发送序号TxSeq＝0，响应序号ReqSeq＝0)发送给第二设备的eL2CAP层101。
第二设备的高层协议由无关ACK响应的其它事件触发也发送了“AMP_Discovery_Req”(发送序号标为0，“T SDU 0”)的请求给第二设备的eL2CAP层102。第一设备和第二设备形成竞争关系。第二设备的eL2CAP层也将该“AMP_Discovery_Req”请求作为I帧发送给第一设备的eL2CAP层103，将该I帧的发送序号和响应序号分别标为0(TxSeq＝0，ReqSeq＝0)。
第一设备的eL2CAP层和第二设备的eL2CAP层分别将所收到对方的I帧以“AMP_Discovery_Ind”(接收序号标为0，“R SDU 0”)响应发送给它们的高层协议104，105。此时，第一设备和第二设备ACK定时器启动。
由于第一设备和第二设备分别接收到对方的一个I帧并且没有回复ACK，第一设备的本地接收窗和本地发送窗(即第二设备的接收窗)均已满。第一设备的高层协议发送给第一设备的eL2CAP层的可携带ACK的又一“AMP_Discovery_Rsp”请求(其中发送序号标为1，“T SDU 1”)106，由于第一设备的发送窗(即第二设备的接收窗已满)而无法发送给第二设备；同样地，第二设备的高层协议发送给第二设备的eL2CAP层的可携带ACK的“AMP_Discovery_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_Discovery_Rsp”(发送序号标为1，“T SDU 1”)请求作为携带ACK响应的I帧发送给第一设备的eL2CAP层(发送序号TxSeq＝1，响应序号ReqSeq＝1)111，其中该ACK响应是针对第一设备发送的“AMP_Discovery_Req”I帧(发送序号TxSeq＝0，响应序号ReqSeq＝0)的ACK响应，并由第一设备的eL2CAP层通过“AMP_Discovery_Rsp”响应(响应序号标为1，R SDU 1)发送给第一设备的高层协议112，使得第一设备的eL2CAP层也对本地发送清零(即第二设备的接收窗清零)113。第一设备的eL2CAP层对高层协议的“AMP_Discovery_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_Discovery_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帧并且没有回复ACK，则第一设备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_Discovery_Ind”响应(响应序号标为0，“R SDU 0”)发送给它们的高层协议402，405。第一设备400的高层协议402给第一设备400的eL2CAP层403发送携带ACK的“AMP_Discovery_Rsp”请求(发送序号标为1，“T SDU1”)，而第二设备401的高层协议405给第二设备401的eL2CAP层404发送携带ACK的“AMP_Discovery_Rsp”请求(发送序号标为1，“T SDU 1”)。
步骤211-214：第二设备401的本地发送窗已经清零(即第一设备的接收窗已清零)，则第二设备401的eL2CAP层404可将高层协议405发送的“AMP_Discovery_Rsp”请求作为携带ACK响应的I帧(发送序号TxSeq＝1，响应序号ReqSeq＝1)发送给第一设备400的eL2CAP层403，其中该ACK响应是回复第一设备发送的“AMP_Discovery_Req”I帧(发送序号TxSeq＝0，响应序号ReqSeq＝0)的，并由第一设备400的eL2CAP层403通过“AMP_Discovery_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_Discovery_Req”(其发送序号标为0号，“T SDU 0”)的请求给第一设备400的eL2CAP层，并由eL2CAP层403作为I帧(发送序号TxSeq＝0，响应序号ReqSeq＝0)发送给第二设备401的eL2CAP层。第二设备401的高层协议405也由无关ACK响应的其它事件触发发送了“AMP_Discovery_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_Discovery_Rsp”(发送序号标为1，T SDU 1)，由于第一设备400的发送窗(即第二设备401的接收窗)已满而无法发送给第二设备401；同样地，第二设备401的高层协议405发送给第二设备401的eL2CAP层404的携带ACK的请求“AMP_Discovery_Rsp”(发送序号标为1，T SDU 1)，因为第一设备400的接收窗已满而无法发送给第一设备400，即第一设备400和第二设备401之间形成了ACK互锁延时。当第一设备400的eL2CAP层403接收到高层协议402所发送的“AMP_Discovery_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_Discovery_Rsp”(发送序号标为1，“T SDU 1”)，作为携带ACK响应的I帧(发送序号TxSeq＝1，响应序号ReqSeq＝1)发送给第一设备400的eL2CAP层403，其中该ACK响应是回复第一设备发送的“AMP_Discovery_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帧的时间，提高了速度传输速度和建链速度。
虽然本发明是参考其优选实施例示出和描述的，但本领域的普通技术人员应该理解，在不脱离附属的权利要求书所限定的本发明的精神和范围的情况下，可以进行形式和细节的各种改变。

Claims (18)

1.一种解决全双工数据传输时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给第一设备的信息帧的帧数和本地发送窗的窗长，如果上述两者相等则认为检测到本地发送窗已满。
CN2009100839523A 2009-05-13 2009-05-13 解决全双工数据传输时ack互锁延时的方法和系统 Pending CN101888288A (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2009100839523A CN101888288A (zh) 2009-05-13 2009-05-13 解决全双工数据传输时ack互锁延时的方法和系统
PCT/CN2010/000683 WO2010130156A1 (zh) 2009-05-13 2010-05-13 在双向数据传输中发送ack响应的方法、设备和系统
US13/319,716 US8547881B2 (en) 2009-05-13 2010-05-13 Method, apparatus and system for transmitting ACK response in bidirectional data transmission

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN2009100839523A CN101888288A (zh) 2009-05-13 2009-05-13 解决全双工数据传输时ack互锁延时的方法和系统

Publications (1)

Publication Number Publication Date
CN101888288A true CN101888288A (zh) 2010-11-17

Family

ID=43074025

Family Applications (1)

Application Number Title Priority Date Filing Date
CN2009100839523A Pending CN101888288A (zh) 2009-05-13 2009-05-13 解决全双工数据传输时ack互锁延时的方法和系统

Country Status (3)

Country Link
US (1) US8547881B2 (zh)
CN (1) CN101888288A (zh)
WO (1) WO2010130156A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104734836A (zh) * 2013-12-23 2015-06-24 中兴通讯股份有限公司 传输确认信息的发送方法和系统
CN105657646A (zh) * 2016-01-29 2016-06-08 南京悦控智能科技有限公司 一种基于蓝牙4.0的设备间大数据通信方法
WO2017148334A1 (zh) * 2016-02-29 2017-09-08 华为技术有限公司 一种终端设备、网络设备、帧格式配置方法和系统

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9980122B2 (en) * 2014-02-07 2018-05-22 Lg Electronics Inc. Method and device for conducting discovery in wireless communication system
US10225061B2 (en) * 2014-06-19 2019-03-05 Lg Electronics Inc. Method and apparatus for receiving frame
FR3054399B1 (fr) * 2016-07-22 2018-08-03 Tap Sound System Pilotage de dispositifs multimedia bluetooth

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5835723A (en) * 1995-12-28 1998-11-10 Intel Corporation Dynamic assignment of multicast addresses
US7000025B1 (en) 2001-05-07 2006-02-14 Adaptec, Inc. Methods for congestion mitigation in infiniband
US7502322B2 (en) * 2003-09-30 2009-03-10 Nokia Corporation System, method and computer program product for increasing throughput in bi-directional communications
US8165088B2 (en) * 2006-09-13 2012-04-24 Toshiba America Research, Inc. MIH protocol state machine
JP5074872B2 (ja) * 2007-09-25 2012-11-14 キヤノン株式会社 プロトコル処理装置及び制御方法

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104734836A (zh) * 2013-12-23 2015-06-24 中兴通讯股份有限公司 传输确认信息的发送方法和系统
CN105657646A (zh) * 2016-01-29 2016-06-08 南京悦控智能科技有限公司 一种基于蓝牙4.0的设备间大数据通信方法
WO2017148334A1 (zh) * 2016-02-29 2017-09-08 华为技术有限公司 一种终端设备、网络设备、帧格式配置方法和系统
US11304143B2 (en) 2016-02-29 2022-04-12 Huawei Technologies Co., Ltd. Terminal device, network device, frame format configuration method, and system

Also Published As

Publication number Publication date
WO2010130156A1 (zh) 2010-11-18
US20120163246A1 (en) 2012-06-28
US8547881B2 (en) 2013-10-01

Similar Documents

Publication Publication Date Title
US7149181B2 (en) Apparatus and method for re-transmitting erroneous packet data
CN101753277B (zh) 无线链路控制层报文状态报告的发送方法
EP1768296A2 (en) Method and apparatus for transmitting signaling data messages in a wireless communications system
US6765882B2 (en) Method and system for data packet collision avoidance in a wireless communication system
CN101888288A (zh) 解决全双工数据传输时ack互锁延时的方法和系统
EP2996275B1 (en) Link processing method and mobile terminal in multiplexing control protocol
CN101677264A (zh) Ack发送方法
CN103391603A (zh) 无线传感器网络中大数据信息低功耗传输的方法
US8943362B2 (en) Control and monitoring for fast millimeter-wave link using out-of-band wireless channel
CN104618007A (zh) 一种同步卫星tcp协议分段连接优化方法
CN101753281B (zh) 无线链路控制层减少冗余报文重传的方法及系统
CN102868508A (zh) 一种无线链路控制传输的方法、系统及装置
JP5020470B2 (ja) 無線通信端末装置及びそのプログラム
CN103607311A (zh) 一种无缝重建tcp连接的系统及方法
CN107800515A (zh) 一种用于无线链路层的数据传输方法和系统
Cisco Configuring LLC2 and SDLC Parameters
JP3741421B2 (ja) データ通信方法及び通信端末装置
CN102045883B (zh) 无线通信系统中无线链路控制重配置后处理轮询的方法
JP2004187099A (ja) 通信制御方法、通信システム及び通信装置
KR100529931B1 (ko) 무선 네트워크망을 통해 통신하는 서버 시스템
JP4634135B2 (ja) 無線通信端末装置及びそのプログラム
JPH11168525A (ja) データ通信方法およびデータ通信装置
JP4998697B2 (ja) 移動通信システム及びその再送制御方法
CN105187277A (zh) 一种基于无线网络错误感知的sack丢失检测和快速重传的方法
JP4348168B2 (ja) 通信装置、送信機、通信システム、通信方法、及びプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20101117