CN116321094A - 蓝牙传输方法及*** - Google Patents

蓝牙传输方法及*** Download PDF

Info

Publication number
CN116321094A
CN116321094A CN202310304430.1A CN202310304430A CN116321094A CN 116321094 A CN116321094 A CN 116321094A CN 202310304430 A CN202310304430 A CN 202310304430A CN 116321094 A CN116321094 A CN 116321094A
Authority
CN
China
Prior art keywords
transmission
data
bluetooth
window
packet
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
CN202310304430.1A
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.)
Institute of Advanced Technology University of Science and Technology of China
Original Assignee
Institute of Advanced Technology University of Science and Technology of China
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 Institute of Advanced Technology University of Science and Technology of China filed Critical Institute of Advanced Technology University of Science and Technology of China
Priority to CN202310304430.1A priority Critical patent/CN116321094A/zh
Publication of CN116321094A publication Critical patent/CN116321094A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04B—TRANSMISSION
    • H04B5/00—Near-field transmission systems, e.g. inductive or capacitive transmission systems
    • H04B5/70—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes
    • H04B5/72—Near-field transmission systems, e.g. inductive or capacitive transmission systems specially adapted for specific purposes for local intradevice communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0289—Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/04—Error control
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

本发明公开一种蓝牙传输方法及***，方法包括发送多个蓝牙数据包的同时检测蓝牙连接；在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；若是则响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；若否则采用二分法在初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，传输窗口阈值小于初始最大传输窗口；重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输；本发明可提高蓝牙传输数据的效率。

Description

蓝牙传输方法及***
技术领域
本发明涉及无线通信技术领域，具体涉及一种蓝牙传输方法及***。
背景技术
随着信息时代的发展，智能化也随之深入到人们日常生活的各个方面，人们对便捷使用、省电、低成本的智能化产品需求越来越多。在电池技术还未取得革命性突破和大规模应用的今天，为满足对功耗和成本都有很高要求的无线方案，低功耗蓝牙(BluetoothLow Energy,BLE)应运而生。
蓝牙技术是由蓝牙技术联盟(Bluetooth Special Interest Group,BluetoothSIG,)提出，应用于短距离电子设备之间进行数据通信和信息交互的无线接口技术。由于其具有成本低、功率低、模块体积小、公开性强等特点，已经成为实现电子产品短距离连接的普遍技术。到目前为止，蓝牙技术一共经历了V1.1到V5.2等多个版本，从V4.0版本开始，蓝牙协议规范同时包含了三种蓝牙技术，即传统蓝牙(Basic Rate/Enhanced Data Rate,BR/EDR)、低功耗蓝牙(Low Energy,LE)和高速蓝牙。其中低功耗蓝牙因其具有待机时间长、连接速度快、发射和接收的高峰功率低等特点而被广泛使用，与蓝牙3.0相比，它有着低成本，低功耗，传输距离远等特点，随着各大手机厂商纷纷接入4.0规范，可穿戴式产品如雨后春笋般出现在人们的面前。中国信息通信研究院发布的《可穿戴设备研究报告》显示，2015年，中国智能可穿戴设备市场规模为125.8亿元，增速达471.8％，从2016年开始，部分垂直领域的巨大潜力将开始释放，可穿戴市场将正式进入启动期，而到了2017年中国智能可穿戴设备市场进入了快速发展期，据统计，2017年，仅小米手环的出货量就已超过1500万，全球的可穿戴设备市场已破千亿，到2021年，全球智能手表Q2出货量达到1800万，比去年同期增长了47％。如此大的市场吸引了众多科技公司参与进来，技术创新成为了各厂商竞相角逐的焦点，市场的快速发展，为基于低功耗蓝牙的智能穿戴产业链公司带来生机，移动互联网技术的成熟将给穿戴式设备带来良好的用户体验，由于目前可穿戴式设备市场仍处于起步阶段，未来的市场发展空间巨大，所以可穿戴式设备是前景比较光明的领域，在这个领域当中不仅仅要提高用户对可穿戴式设备的使用，同时，要极大的满足对可穿戴式设备配套的软件要求，因此完成可穿戴式产品的软件设计是一个艰巨的任务。
相关技术中，公布号为CN105827537A的专利文献提出的一种基于QUIC协议的拥塞改进方法，在拥塞算法中加入了时延信息，并通过上一次RTT与当前RTT的比较来做判断，但实际应用中数据传输速度仍较慢。
公布号为CN103826221A的专利文献提出的一种基于蓝牙的加密通信方法、相关***及方法中，通过双方认证机制确保双方身份合法方可保持建立蓝牙连接，身份验证合法后，双方以相同的密钥key2加密数据，再通过蓝牙同协议传输加密后的数据；但该方案中采用的是传统的3DES算法进行加密。
公布号为CN113541864A的专利文献提出的蓝牙接收方法中，接收基带信号并解析出负载数据和负载数据对应的循环冗余CRC校验信息，根据CRC校验信息得到CRC校验结果，在CRC校验错误且重传次数不小于预设重传门限时，结束重传；但该接收方法更偏向于硬件底层逻辑，并且没有详细阐明数据检验的具体细节。
但对低成本、低功耗、省电要求极高的单模蓝牙4.2智能穿戴设备而言，蓝牙4.2传统传输方案仍存在诸多不足之处，比如：
(1)采用单包ACK传输模式：基于***封装的单包ACK传输模式，大文件传输速度慢。
(2)QUIC拥塞控制算法：这种机制全靠丢包判断网络的拥挤，大量随机丢包发生在网络上，网络永远是再检测的，致使网络利用率大幅度降低，进一步造成了算法无法得到有效使用；同时，由于在计算丢包丢失概率的过程中采用了固定大小的窗口进行搜索，使得整个算法对网络状态变化敏感程度降低，从而造成算法运行效率低。另外，现实中网络环境通常都具有不稳定性，该算法窗口增长十分单一，窗口增长速度未按网络情况进行调整。在网络状况较差时，连接往返延迟增大，大量节点的延时转发势必会浪费设备节点的功耗。而且QUIC流量控制中最大接受窗口大小的更新频率以及更新时间如何取舍仍然是一个悬而未决。当首次传输时，接收方的数据接收量与理论值接收值一致，之后所有数据的传输均没有达到理论值，仅到理论值的一半。
(3)拉取数据慢：手机端应用从互联网上拉取数据慢，当手机端需要进行http/TCP响应来获取数据流时，传输较慢。
(4)队头阻塞和重传歧义：传统数据传输均使用TCP握手连接，一旦数据流发生丢失，后面的数据都会堵塞。
(5)设备没有应用层加密机制：现有的蓝牙传输***设备端没有应用层的加密机制，导致消息提醒等用户隐私信息明文发送的问题，所以应该增加应用层传输数据加密机制，以提供数据的保密性、保护用户隐私等。
(6)业务耦合：目前蓝牙传输***的协议的错误码、命令等直接和具体的业务耦合在一起，没有做到传输层和业务层解耦，也没有模块化。导致编码时无法避免会导致代码耦合，难以实现解耦的编码，甚至会直接诱导研发编写出完全耦合在一起的代码。
因此，针对特定场景下的低功耗蓝牙传输***的传输速度慢，能耗高的问题，迫切需要相应的优化方法。
发明内容
本发明所要解决的技术问题在于如何提高传输效率。
本发明通过以下技术手段解决上述技术问题的：
一方面，本发明提出了一种蓝牙传输方法，所述方法包括：
发送多个蓝牙数据包的同时检测蓝牙连接；
在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；
若是，则响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
若否，则采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
进一步地，所述重复计算若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输，包括：
去除若干次传输的最优窗口大小中的最大值和最小值，得到筛选后各窗口值，并计算筛选后各窗口值的和平均值的方差；
在和平均值的方差满足设定条件时，则将筛选后各窗口值中最小的数值作为所述最佳的蓝牙传输窗口；
在和平均值的方差未满足设定条件时，则重新重复计算若干次传输的最优窗口大小。
进一步地，在每次发送所述蓝牙数据包后，所述方法还包括：
若在设定时间内接收到正确ACK应答，则发送下一帧数据；
若在设定时间内接收到帧数据出错重传请求，则重传此帧数据；
若在设定时间未接收到ACK应答，则启用超时重传机制重传此帧数据；
在连续n次重传未成功时，则确定此帧数据传输失败。
进一步地，所述蓝牙数据包包括版本确认包、版本应答包、数据包和整体应答包；
所述版本确认包用于查询版本号；
所述版本应答包用于返回版本号；
所述数据包包含数据明文和数据密文；
所述整体应答包用于响应应答消息。
进一步地，在进行蓝牙传输时所采用的蓝牙传输协议满足条件：
所述蓝牙传输协议为单向传输通道，通信双方设备数据上下行对称，且分别使用一个特征；
所述蓝牙传输协议本身只关联所属业务模块；
由通信双方中的发送方控制是否需要应答以及超时处理。
进一步地，在每次发送所述蓝牙数据包之前，所述方法还包括：
通信双方在授权过程中生成三个关键加密数X、R0和R1，其中，X为原始加密数，R0和R1分别为智能设备端和客户端的传输随机数；
将所述原始加密数X与每次传输的session id按位异或操作，得到本次传输的AES加密密钥key Y；
所述智能设备端在接收到所述客户端第一次发送的加密数据时，基于所述传输随机数R0对所接收的数据进行校验；
所述客户端在接收到所述智能设备端发送的第一次发送的加密数据时，基于所述传输随机数R1对所接收的数据进行校验；
在数据传输解密成功时，通信双方将各自的传输随机数+1后作为下一次的发送NONCE值；
在数据传输解密未成功时，发送方将其对应的传输随机数+1后作为下一次的发送NONCE值。
进一步地，所述通信双方在授权过程中生成三个关键加密数X、R0和R1，包括：
客户端和智能设备端进行ECDH交互，生成ECDH公钥、ECDH密钥和绑定密钥；
使用授权过程中的ECDH共享密码P和所述绑定密钥进行异或，得到原始加密数X；
基于所述绑定密钥的部分字节，得到智能设备端的接收NONCE初始值作为传输随机数R0；
基于所述绑定密钥的另一部分字节，得到客户端的接收NONCE初始值作为传输随机数R1。
进一步地，在接收到对方发送的蓝牙数据包时，所述方法还包括：
校验所述蓝牙数据包的帧序号是否正确；
若帧序号正确则校验帧CRC是否匹配，若帧序号不正确则向对方响应帧数据出错请求重传正确帧；
若帧CRC匹配则判断传输层数据是否全部接收，若帧CRC不匹配则向对方响应帧数据出错请求重传正确帧；
若传输层数据未全部接收则向对方响应ACK帧数据正确接收，若传输层数据全部接收则校验传输层CRC是否匹配；
若传输层CRC匹配则向对方响应ACK帧数据正确接收，若传输层CRC不匹配则丢弃所接收的数据并向对方响应ACK数据出错。
进一步地，在发送多个蓝牙数据包之后，所述方法还包括：
当数据传输过程中网络上发生数据包丢失时，记录最近一次丢包事件发生时的往返时延的平均值RTTavg以及最近一次丢包时间发生时的拥塞窗口大小Wmax；
将最近一次丢包时记录的往返延迟的平均值RTTavg与重新访问窗口时的当前延时RTTcur的比值作为拥塞等级因子；
基于所述拥塞等级因子调整调整窗口大小cwnd，其中，cwnd＝NetstateC(ΔT-K)3+Wmax，Netstate＝RTTavg/RTTcur，C为拥塞窗口增加率，ΔT为从最后一个窗口开始缩减所需的时间，K为在没有丢包事件的情况下，将拥塞窗口尺寸增加到Wmax所需要的时间。
另一方面，本发明还提出了一种蓝牙传输***，所述***包括：
发送模块，用于发送多个蓝牙数据包；
判断模块，用于在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；
窗口调整模块，用于在所述判断模块输出结果为是时，响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
窗口寻优模块，用于在所述判断模块输出结果为否时，采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
窗口确定模块，用于重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
本发明的优点在于：
(1)本发明针对传统的蓝牙单通道传输数据慢的问题，为了增大数据传输量，放弃使用单包传输，而采用无ACK应答的多包传输模式，为解决在采用无ACK应答的多包传输模式发送数据时，如果发送的数据量过大势必会造成数据拥塞，会对通信造成严重影响，甚至卡顿崩溃的问题，在数据包发送时自动检测蓝牙连接，然后利用慢速启动和二分法对最大传输窗口进行探测，能够动态及时的对蓝牙传输窗口大小进行判断，防止传输初期数据量过大造成的数据拥塞，从而提高数据传输效率。
(2)针对目前的蓝牙传输协议业务层命令和profile层深度耦合、分包协议和业务层深度耦合等问题，本发明在Write without Response+Notify组合的模式的基础上重新设计协议，使得客户端和智能设备数据上下行对称，解决了客户端App和智能设备端通信协议不对称，导致设备端在类似eSIM和WiFi等业务里无法直接push数据到客户端App，需要通过低频事件处理导致处理速度较慢的问题，从而进一步提高了数据传输效率。
(3)为了解决当前所有设备没有应用层加密机制，导致消息提醒等用户隐私信息明文发送的问题，本发明增加应用层传输数据加密机制，以提供数据的保密性、保护用户隐私等。
(4)为了提高传输效率，本发明采用基于无ACK多包传输模式的协议，如此OS***底层的蓝牙就不再需要返回ACK信息，在没有ACK信息的情况下，一旦数据丢失，就会导致传输失败，甚至设备双方都不知道数据丢失；因此本发明设计出一套适当的校验与重传机制，以确保数据安全、可靠地传送，在校验部分将重点关注帧CRC和传输层CRC，以确保数据的可靠性和可用性。
(5)在基于互联网的智能手表的传输中，需要形成智能设备端即手表、客户端即手机和互联网构成信息传递的通路，这就需要互联网端实现较快的数据传输，而且还需要轻量级的通信，保证高数据率和高可靠性；本发明对Cubic算法进行优化，即引入基于网络延迟的网络拥塞检测机制，实现对延迟信息的综合评估和对拥塞窗口增长函数增长率的动态调整，并在仿真实验上验证了该方法能够有效减小网络吞吐率。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
图1是本发明实施例提出的蓝牙传输方法的流程示意图；
图2是本发明实施例中传输窗口的优化流程示意图；
图3是本发明实施例中蓝牙数据重传机制的流程示意图；
图4是本发明实施例中蓝牙通用协议的示意图；
图5是本发明实施例中传输包的信息表示意图；
图6是本发明实施例中版本确认包的信息表示意图；
图7是本发明实施例中数据包的信息表示意图；
图8是本发明实施例中整体应答包的信息表示意图；
图9是本发明实施例中Error code信息表示意图；
图10是本发明实施例中通信双方进行ECDH交互的流程示意图；
图11是本发明实施例中数据校验流程示意图；
图12是本发明实施例中拥塞窗口调整流程示意图；
图13是本发明实施例提出的蓝牙传输***的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
如图1至图2所示，本发明第一实施例提出了一种蓝牙传输方法，所述方法包括以下步骤：
S10、发送多个蓝牙数据包的同时检测蓝牙连接；
S20、在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答，若是则执行步骤S30，若否则执行步骤S40；
S30、响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
需要说明的是，将蓝牙最大传输窗口的初始值设置为一个包size个字节，每次发送以后，假如能够接收到正确的ACK应答则增大蓝牙的初始最大传输窗口，比如将蓝牙最大传输窗口的初始值翻倍。
S40、采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
需要说明的是，若在发送数据后未接收到正确的ACK应答，则采用二分法在所述初始最大传输窗口即一个包size个字节与传输窗口阈值比如size/2之间寻找当前次传输的最优窗口大小。
S50、重复执行上述步骤S10～S40，得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
本实施例针对传统的蓝牙单通道传输数据慢的问题，为了增大数据传输量，放弃使用单包传输，而采用无ACK应答的多包传输模式，但是由于不同的操作***最大传输窗口大小是不一致的，当采用无ACK应答的多包传输模式发送数据时，如果发送的数据量过大势必会造成数据拥塞，会对通信造成严重影响，甚至卡顿崩溃，因此需要找到智能设备端到客户端能够同时处理数据的最大传输窗口；如果客户端开始发送蓝牙数据包，并立即向智能设备端发送大量数据，很有可能出现蓝牙数据过载，因此在数据包发送时自动检测蓝牙连接，然后利用慢速启动和二分法对最大传输窗口进行探测，能够动态及时的对蓝牙传输窗口大小进行判断，防止传输初期数据量过大造成的数据拥塞，从而提高数据传输效率。
在一实施例中，所述步骤S50中，得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输，具体包括以下步骤：
S51、去除若干次传输的最优窗口大小中的最大值和最小值，得到筛选后各窗口值，并计算筛选后各窗口值的和平均值的方差；
S52、在和平均值的方差满足设定条件时，则将筛选后各窗口值中最小的数值作为所述最佳的蓝牙传输窗口；
S53、在和平均值的方差未满足设定条件时，则重新重复计算若干次传输的最优窗口大小。
具体地，假如连续重复10次，得到10个最优窗口，则去掉其中的两个最大值和两个最小值，然后计算剩余的各窗口值和平均值的方差。如果和平均值的方差结果不大于5，则认为本次嗅探结果取得了预期，随后将剩下的6个值当中最小的数值作为最佳的蓝牙传输窗口大小，如果和平均值的方差值大于5，则重新进行嗅探，直到取得预期范围内的结果。
需要说明的是，在实际应用中，因为蓝牙传输***需要考虑到不同的手机客户端，例如安卓或者苹果，不同的手机客户端的最大传输窗口是不一样的，所以没有一个固定的数值，也不可能所有手机都一致。本实施例通过多次重复测量得到不同次的最优窗口，通过不断地探测是为了更好的把握一个合适的窗口值大小，能够较为平稳的传输。
应当理解的是，本实施例通过计算多个传输窗口的和平均值的方差，可表征数据的稳定性，本实施例设置的设定条件具体取值为5仅为经过实验得出的经验值，设置的目的是为了更好的从统计角度进行分析，本领域技术人员也可根据实际情况设置其他的数值如10，20等，本实施例不作具体限定。
在一实施例中，如图3所示，在每次发送所述蓝牙数据包后，所述方法还包括以下步骤：
若在设定时间内接收到正确ACK应答，则发送下一帧数据；
若在设定时间内接收到帧数据出错重传请求，则重传此帧数据；
若在设定时间未接收到ACK应答，则启用超时重传机制重传此帧数据；
在连续n次重传未成功时，则确定此帧数据传输失败。
具体地，本实施例中进行帧数据重传的原因在于：
(1)数据发送端计时器超时
蓝牙传输层每次传输都会发送一个帧报文段，以便进行通信，与此同时会设定一组定时器，以确保报数据传输的及时性。如果计时器超时以后依旧没有收到来自应答方的响应ACK，则需要重新发出该帧报文段。报文丢失可能有两种原因：一是帧数据在传送进程中出现了损坏；二是帧仍在传送，但传输速度较慢。第一种情况下，接收端可能不知道这种情况已经发生，而第二种情况则可能会导致两个帧数据报文的内容完全一样。
(2)收到数据接收端ACK请求重传
在收到重传请求时，可能是由CRC校验未能通过或者帧序不正确导致的，因此需要重新传输该帧数据。
就Bluetooth数据传输而言，协议装配完成后，划分成多个帧发送出去，其中一个帧是由传输方发送过来的，另一帧则由接收端收到并通过计算得到，然后再发送到发送者那里。传输方向对方发送帧数据后，会触发计时器，当从计时器指定时间收到适当ACK时，然后接着传输下帧数据；若未达到规定的时间，则该帧数据被延迟一个周期再进行一次发送。相反，若收到不正确的ACK时，帧数据马上重传；如果超出了指定的时间仍未收到回应，然后重发数据。若每次重新发送都失败的话，则可以通过计算再次发送次数来确定是否发生了错误；若连续多次比如三次重发效果均未实现，则本次数据发送视为失败。
在一实施例中，在进行蓝牙传输时所采用的蓝牙传输协议满足条件：
(1)所述蓝牙传输协议为单向传输通道，通信双方设备数据上下行对称，且分别使用一个特征；
(2)所述蓝牙传输协议本身只关联所属业务模块；
(3)由通信双方中的发送方控制是否需要应答以及超时处理。
需要说明的是，目前的蓝牙传输协议业务层命令和profile层深度耦合、分包协议和业务层深度耦合，手机客户端App和手表智能设备端通信协议不对称，导致设备端在类似eSIM和WiFi等业务里无法直接push数据到手机端App，需要通过低频事件处理导致处理速度较慢。因此，本实施例所设计的协议需要使得手机端App和手表端设备数据上下行对称，分别使用一个特征。
蓝牙通用协议设计如图4所示，蓝牙4.0特征00000016-0000-3512-2118-0009af100700表示从手机客户端到手表客户端方向的下行通道使用特征，采用的是Writewithout response+Notify的通知方式；蓝牙4.0特征00000017-0000-3512-2118-0009af100700表示从手表客户端到手机客户端方向的上行通道使用特征，同样也采用Write without response+Notify的通知方式。
在一实施例中，所述蓝牙数据包包括版本确认包、版本应答包、数据包和整体应答包；
所述版本确认包用于查询版本号；
所述版本应答包用于返回版本号；
所述数据包包含数据明文和数据密文；
所述整体应答包用于响应应答消息。
具体地，在本实施例所设计的蓝牙通用协议下，如图5所，传输包分为Versionquery版本确认包(信息表如图6所示)、Version reply版本应答包、Data数据包(信息表如图7所示)和Reply整体应答包(信息表如图8所示)。
其中，如图7所示，Data数据包的信息表中：
FLAG_BEGIN：表示传输开始；
FLAG_END：表示传输结束；
FLAG_REQUIRE_REPLY：表示接收方需要回复reply；
FLAG_ENCRYPTION：表示是否选择加密；
App ID：表示会话过程中的App ID，当App作为发送方时代表自己；Device作为发送方时代表接收App；
Session ID：表示会话ID，在一次传输会话过程中需要保持不变；并建议发送方每次新传输比上一次加1；
Packet index：表示包索引；
Data total size：可选项，表示数据总大小，这里指的是明文或者有效数据的字节数；
Module：可选项，表示数据所属模块；
Data：表示所存放的实际数据；
R/NONCE：可选项，表示加密NONCE，加密会话的最后一个包包含；
Plain text CRC32：可选项，表示明文CRC32。此字段用于校验解密是否成功，加密会话的最后一个包会包含该信息；
Padding：可选项，表示明文的Padding，由于AES加密必须16个字节为单位，需要在明文+R/NONCE+Plain text CRC32长度不是16字节整数时，填充使得密文区长度满足16的整数倍；padding的内容不做校验。
进一步地，图8所示信息表中的Error code信息表见图9，对Reply整体应答包所属的Error code错误码进行细化定义：会导致包错误的几种情况：Data数据包的FLAG没有包含FLAG_BEGIN，但index＝0；Data数据包的FLAG包含了FLAG_BEGIN，但是index！＝0；Data数据包的FLAG包含了FLAG_BEGIN，但是后续数据中没有data total size；Data数据包长度不够；Mobile App下发的包里没有Source App ID；Device下发的包里没有Destination AppID。
需要说明的是，为了解决当前所有设备没有应用层加密机制，导致消息提醒等用户隐私信息明文发送的问题，增加应用层传输数据加密机制，以提供数据的保密性、保护用户隐私等，本实施例提出的加密方案综合考虑以下几点：
(1)加密本身的难破解度必须达到一定级别，不能被一般的抓包分析、模拟发送相同数据等手段破解；
(2)开发工作的复杂度，最好是利用当前设备BLE协议中已有的App绑定机制来降低工作量；
(3)BLE带宽等资源的有限程度。
所以采用AES对数据传输继续加密。经过验证，AES算法的性能在DA14697平台满足要求，对1M数据加密只需要耗时2.5s；它支持流式处理，边发送边加密，边接收边解密，降低传输时延的增加，不会导致传输数据的size按比例增加。该传输的加密时刻，从授权成功时就开始，智能设备端和手机客户端App双方必须保证在授权后的数据传输全部加密。
在进行一次传输之前，需要加密的数据应该同时满足以下条件：App查询版本号，固件返回数据中包含是否启动加密总开关状态是打开的；手机客户端App和智能设备daunt授权完毕。
在一实施例中，在每次发送所述蓝牙数据包之前，所述方法还包括以下步骤：
通信双方在授权过程中生成三个关键加密数X、R0和R1，其中，X为原始加密数，R0和R1分别为智能设备端和客户端的传输随机数；
将所述原始加密数X与每次传输的session id按位异或操作，得到本次传输的AES加密密钥key Y；
所述智能设备端在接收到所述客户端第一次发送的加密数据时，基于所述传输随机数R0对所接收的数据进行校验；
所述客户端在接收到所述智能设备端发送的第一次发送的加密数据时，基于所述传输随机数R1对所接收的数据进行校验；
在数据传输解密成功时，通信双方将各自的传输随机数+1后作为下一次的发送NONCE值；
在数据传输解密未成功时，发送方将其对应的传输随机数+1后作为下一次的发送NONCE值。
在一实施例中，如图10所示，所述通信双方在授权过程中生成三个关键加密数X、R0和R1，包括以下步骤：
客户端和智能设备端进行ECDH交互，生成ECDH公钥、ECDH密钥和绑定密钥；
使用授权过程中的ECDH共享密码P和所述绑定密钥进行异或，得到原始加密数X；
基于所述绑定密钥的部分字节，得到智能设备端的接收NONCE初始值作为传输随机数R0；
基于所述绑定密钥的另一部分字节，得到客户端的接收NONCE初始值作为传输随机数R1。
具体地，客户端和智能设备端进行ECDH交互中生成：
ECDH public key：ECDH公钥，智能设备端和手机客户端App发起ECDH交互流程时，会随机生成48字节的随机数。
ECDH private key：ECDH密钥，智能设备端和手机客户端App拿到对方的ECDHpublic key后，和各自端的public key计算得到一个24字节的密钥。
Binding Key：绑定密钥，通过ECDH交互密钥生成16字节的密匙，作用是绑定流程生成的AES key。
P：授权过程中的ECDH共享密码，授权过程中也会进行一次ECDH，生成的密码就是P。
Key/X：授权密钥+传输密钥，使用P的8-23字节(即最后的128bit)和Binding key进行异或得到。
R0：设备端的接收NONCE初始值，取P的0-3字节得到的uint32_t整数。
R1：App端的接收NONCE初始值，取P的4-7字节得到的uint32_t整数。
进一步地，在手机客户端App授权时，按照上述流程生成三个关键加密数X、R0和R1，其中，X是原始加密数，128bit数组，由绑定key和ECDH密钥的8-23字节异或生成。X用于和每次传输的session id按位异或(16个字节都和Y异或)，得到该次传输的AES加密key Y。
R0(uint32_t)是传输随机数，是ECDH密钥的的0-3字节，作为手机客户端App在加密后第一次发送数据时，智能设备端接收数据的校验；R0和R1的作用是避免重放攻击。由于传输设备不强制要求sessionid变化，因此需要R0和R1来作为NONCE。
R1和R0作用相反，用于手机客户端App校验，R1是ECDH密钥的4-7字节。
进一步地，在一次传输解密成功，发送和接收方都应该将R1+1或R0+1作为下一次的发送NONCE。如果解密失败，接收方不应该将R0值+1；发送方无论是否发送成功，都应该将下一次发送的R1值+1。对于接收方来说，必须要求R0发生增长，且变化f范围可以在1-100000之间，这是为了防止出现丢包的情况，导致后续所有传输解密失败。
在一实施例中，如图11所示，在接收到对方发送的蓝牙数据包时，所述方法还包括以下步骤：
校验所述蓝牙数据包的帧序号是否正确；
若帧序号正确则校验帧CRC是否匹配，若帧序号不正确则向对方响应帧数据出错请求重传正确帧；
若帧CRC匹配则判断传输层数据是否全部接收，若帧CRC不匹配则向对方响应帧数据出错请求重传正确帧；
若传输层数据未全部接收则向对方响应ACK帧数据正确接收，若传输层数据全部接收则校验传输层CRC是否匹配；
若传输层CRC匹配则向对方响应ACK帧数据正确接收，若传输层CRC不匹配则丢弃所接收的数据并向对方响应ACK数据出错。
需要说明的是，校验机制被用作校验数据传输正确性的一种，是传输***不可缺少的组成部分，本实施例提出的校验机制以帧校验为主，传输层校验为辅。校验是从发送端向接收端传输的一个完整流程，是由蓝牙的数据发送端计算出消息，然后在蓝牙数据接收端进行测试，为了保证资料准确可靠。校验结果可以用一个字或者多个字符进行表示，在校验结果出现差错，则抛弃这个帧或者段的消息。
本实施例采用32位标识的CRC校验能够有效地降低由碰撞造成的出错数据的几率，而且在传送层CRC和接受端CRC两层校验的支持下，这种情况发生的几率能够基本忽略不计。
需要说明的是，为了提高传输效率，本实施例采用基于无ACK多包传输模式(WriteWithout Response)的传输协议，这样，OS***底层的蓝牙就不再需要返回ACK信息，再辅以合适的校验以及重传机制，提高蓝牙传输速度。在没有ACK信息的情况下，一旦数据丢失，就会导致传输失败，甚至设备双方都不知道数据丢失。因此我们有必要设计出一套适当的校验与重传机制，防止多包传输发生错误，以确保安全、可靠地传送。考虑到蓝牙设备在进行数据传输时，由于其自身存在一些缺点，如传输速度较慢、容易收到其他蓝牙信号影响等原因，使得传输过程中出现了错误，为了保证蓝牙传输数据的准确，本实施例设计的校验部分将重点关注帧CRC和传输层CRC，以确保数据的可靠性和可用性。
在一实施例中，如图12所示，在发送多个蓝牙数据包之后，所述方法还包括以下步骤：
当数据传输过程中网络上发生数据包丢失时，记录最近一次丢包事件发生时的往返时延的平均值RTTavg以及最近一次丢包时间发生时的拥塞窗口大小Wmax；
将最近一次丢包时记录的往返延迟的平均值RTTavg与重新访问窗口时的当前延时RTTcur的比值作为拥塞等级因子；
基于所述拥塞等级因子调整调整窗口大小cwnd，其中，cwnd＝NetstateC(ΔT-K)3+Wmax，Netstate＝RTTavg/RTTcur，C为拥塞窗口增加率，可设置为0.4，ΔT为从最后一个窗口开始缩减所需的时间，K为在没有丢包事件的情况下，将拥塞窗口尺寸增加到Wmax所需要的时间。
需要说明的是，确定当前网络状态：RTT的变化可以用来确定当前拥塞通道上缓冲队列长度的变化，这样就可以从丢包时记录的RTTavg和重新访问窗口时得到的RTTcur来确定当前网络状态。在拥塞窗口增加到Wmax这一整个过程中，确定当前延迟RTTcur和最后一次丢包的延迟RTTavg之间的大小。如果RTTcur大于RTTavg，说明当前连接瓶颈处的缓冲队列长度大于上次连接瓶颈处的缓冲队列长度，这意味着连接上的拥塞程度比上次有所增加。如果RTTcur小于RTTavg，说明当前连接瓶颈处的缓冲队列长度小于上一次连接瓶颈处的缓冲队列长度，即拥塞程度比上次低。则据此根据当前的网络状况调整窗口大小：如果当时信道上的拥堵问题正在增加，则拥堵窗口大小就会以以递减的方式下降。如果当前信道上的拥堵程度变慢，则拥堵窗口大小增长就会更快。
而且与相关技术中采用上一次RTT与当前RTT的比较大小来做判断的方式相比，本实施例所采用的拥塞算法在实际应用中，数据传输速度比未优化前的快了28％左右。
需要说明的是，在基于互联网的智能手表的传输中，需要形成手表、手机和互联网构成信息传递的通路，这就需要互联网端实现较快的数据传输，而且还需要轻量级的通信，保证高数据率和高可靠性。QUIC这类新型互联网传输协议能够很好解决这类问题，并且对于高速通信的互联网环境，一般也会选择QUIC协议栈作为传输层，因为它具有极快的传输速度和高效的Cubic机制来控制网络拥堵。本实施例将蓝牙与QUIC结合应用于一套***中，但在将QUIC这类新型互联网传输协议应用与蓝牙传输时，由于Cubic机制全靠丢包判断网络的拥挤，大量随机丢包发生在网络上，网络永远是再检测的，致使网络利用率大幅度降低，进一步造成了算法无法得到有效使用；同时，由于在计算丢包丢失概率的过程中采用了固定大小的窗口进行搜索，使得整个算法对网络状态变化敏感程度降低，从而造成算法运行效率低。另外，现实中网络环境通常都具有不稳定性，该算法窗口增长十分单一，窗口增长速度未按网络情况进行调整，在网络状况较差时，连接往返延迟增大。
Cubic算法的一个重要优势是，它可以利用上一次探测到的数据，使窗口大小围绕Wmax缓慢增长。然而，Cubic只能根据记录的Wmax来确定网络的拥塞程度，这对拥挤程度的控制相对弱一些，而且对网络资源的利用不足。本实施例在网络中发生丢包时，结合往返延迟来更准确地判断当前网络是否处于拥塞状态，从而确定是否应该减少窗口大小。同时，当前的往返延迟和上次丢包的往返延迟可以用来确定当前网络与上次网络相比的拥堵程度，并改变增加拥堵窗口的速率，以提高网络性能和带宽利用率。
需要说明的是，本实施例将蓝牙与QUIC结合应用于一套***中，能够方便地实现多套拥塞控制算法，将拥塞控制算法流程抽象成多个回调接口，其中最核心的两个接口onAck和onLost用于让算法实现收到报文ack和检测到丢包时的处理逻辑。内部实现了多套拥塞控制算法，包括最常见的Cubic、New Reno。为了方便用数据驱动网络体验优化，将连接的丢包率、RTT、带宽等信息通过埋点数据采样和分析的方式，结合每个版本的算法调整进行效果分析。同时在实验环境下模拟真实用户的网络环境分布，更好地预先评估算法调整对于网络体验的改进效果，相较于普通的蓝牙+Http组合，无ACK+QUIC的模式相较之前传输速度快了将近30％。
此外，如图13所示，本发明第二实施例提出了一种蓝牙传输***，所述***包括：
发送模块10，用于发送多个蓝牙数据包；
判断模块20，用于在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；
窗口调整模块30，用于在所述判断模块输出结果为是时，响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
窗口寻优模块40，用于在所述判断模块输出结果为否时，采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
窗口确定模块50，用于重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
本实施例针对传统的蓝牙单通道传输数据慢的问题，为了增大数据传输量，放弃使用单包传输，而采用无ACK应答的多包传输模式，为解决在采用无ACK应答的多包传输模式发送数据时，如果发送的数据量过大势必会造成数据拥塞，会对通信造成严重影响，甚至卡顿崩溃的问题，在数据包发送时自动检测蓝牙连接，然后利用慢速启动和二分法对最大传输窗口进行探测，能够动态及时的对蓝牙传输窗口大小进行判断，防止传输初期数据量过大造成的数据拥塞，从而提高数据传输效率。
在一实施例中，所述窗口确定模块50，具体包括：
方差计算单元，用于去除若干次传输的最优窗口大小中的最大值和最小值，得到筛选后各窗口值，并计算筛选后各窗口值的和平均值的方差；
最佳窗口确定单元，用于在和平均值的方差满足设定条件时，则将筛选后各窗口值中最小的数值作为所述最佳的蓝牙传输窗口；
最优窗口重计算单元，用于在和平均值的方差未满足设定条件时，则重新重复计算若干次传输的最优窗口大小。
在一实施例中，所述***还包括重传模块，具体用于：
若在设定时间内接收到正确ACK应答，则发送下一帧数据；
若在设定时间内接收到帧数据出错重传请求，则重传此帧数据；
若在设定时间未接收到ACK应答，则启用超时重传机制重传此帧数据；
在连续n次重传未成功时，则确定此帧数据传输失败。
在一实施例中，所述蓝牙数据包包括版本确认包、版本应答包、数据包和整体应答包；
所述版本确认包用于查询版本号；
所述版本应答包用于返回版本号；
所述数据包包含数据明文和数据密文；
所述整体应答包用于响应应答消息。
在一实施例中，在进行蓝牙传输时所采用的蓝牙传输协议满足条件：
所述蓝牙传输协议为单向传输通道，通信双方设备数据上下行对称，且分别使用一个特征；
所述蓝牙传输协议本身只关联所属业务模块；
由通信双方中的发送方控制是否需要应答以及超时处理。
在一实施例中，所述***还包括加密模块，具体用于执行以下步骤：
通信双方在授权过程中生成三个关键加密数X、R0和R1，其中，X为原始加密数，R0和R1分别为智能设备端和客户端的传输随机数；
将所述原始加密数X与每次传输的session id按位异或操作，得到本次传输的AES加密密钥key Y；
所述智能设备端在接收到所述客户端第一次发送的加密数据时，基于所述传输随机数R0对所接收的数据进行校验；
所述客户端在接收到所述智能设备端发送的第一次发送的加密数据时，基于所述传输随机数R1对所接收的数据进行校验；
在数据传输解密成功时，通信双方将各自的传输随机数+1后作为下一次的发送NONCE值；
在数据传输解密未成功时，发送方将其对应的传输随机数+1后作为下一次的发送NONCE值。
在一实施例中，所述***还包括授权模块，用于执行以下步骤：
客户端和智能设备端进行ECDH交互，生成ECDH公钥、ECDH密钥和绑定密钥；
使用授权过程中的ECDH共享密码P和所述绑定密钥进行异或，得到原始加密数X；
基于所述绑定密钥的部分字节，得到智能设备端的接收NONCE初始值作为传输随机数R0；
基于所述绑定密钥的另一部分字节，得到客户端的接收NONCE初始值作为传输随机数R1。
在一实施例中，所述***还包括校验模块，具体用于执行以下步骤：
校验所述蓝牙数据包的帧序号是否正确；
若帧序号正确则校验帧CRC是否匹配，若帧序号不正确则向对方响应帧数据出错请求重传正确帧；
若帧CRC匹配则判断传输层数据是否全部接收，若帧CRC不匹配则向对方响应帧数据出错请求重传正确帧；
若传输层数据未全部接收则向对方响应ACK帧数据正确接收，若传输层数据全部接收则校验传输层CRC是否匹配；
若传输层CRC匹配则向对方响应ACK帧数据正确接收，若传输层CRC不匹配则丢弃所接收的数据并向对方响应ACK数据出错。
在一实施例中，所述***还包括拥塞优化模块，具体用于执行以下步骤：
当数据传输过程中网络上发生数据包丢失时，记录最近一次丢包事件发生时的往返时延的平均值RTTavg以及最近一次丢包时间发生时的拥塞窗口大小Wmax；
将最近一次丢包时记录的往返延迟的平均值RTTavg与重新访问窗口时的当前延时RTTcur的比值作为拥塞等级因子；
基于所述拥塞等级因子调整调整窗口大小cwnd，其中，cwnd＝NetstateC(ΔT-K)3+Wmax，Netstate＝RTTavg/RTTcur，C为拥塞窗口增加率，ΔT为从最后一个窗口开始缩减所需的时间，K为在没有丢包事件的情况下，将拥塞窗口尺寸增加到Wmax所需要的时间。
需要说明的是，本发明所述蓝牙传输***的其他实施例或具有实现方法可参照上述各方法实施例，此处不再赘余。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种蓝牙传输方法，其特征在于，所述方法包括：
发送多个蓝牙数据包的同时检测蓝牙连接；
在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；
若是，则响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
若否，则采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
2.如权利要求1所述的蓝牙传输方法，其特征在于，所述重复计算若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输，包括：
去除若干次传输的最优窗口大小中的最大值和最小值，得到筛选后各窗口值，并计算筛选后各窗口值的和平均值的方差；
在和平均值的方差满足设定条件时，则将筛选后各窗口值中最小的数值作为所述最佳的蓝牙传输窗口；
在和平均值的方差未满足设定条件时，则重新重复计算若干次传输的最优窗口大小。
3.如权利要求1所述的蓝牙传输方法，其特征在于，在每次发送所述蓝牙数据包后，所述方法还包括：
若在设定时间内接收到正确ACK应答，则发送下一帧数据；
若在设定时间内接收到帧数据出错重传请求，则重传此帧数据；
若在设定时间未接收到ACK应答，则启用超时重传机制重传此帧数据；
在连续n次重传未成功时，则确定此帧数据传输失败。
4.如权利要求1所述的蓝牙传输方法，其特征在于，所述蓝牙数据包包括版本确认包、版本应答包、数据包和整体应答包；
所述版本确认包用于查询版本号；
所述版本应答包用于返回版本号；
所述数据包包含数据明文和数据密文；
所述整体应答包用于响应应答消息。
5.如权利要求1所述的蓝牙传输方法，其特征在于，在进行蓝牙传输时所采用的蓝牙传输协议满足条件：
所述蓝牙传输协议为单向传输通道，通信双方设备数据上下行对称，且分别使用一个特征；
所述蓝牙传输协议本身只关联所属业务模块；
由通信双方中的发送方控制是否需要应答以及超时处理。
6.如权利要求1所述的蓝牙传输方法，其特征在于，在每次发送所述蓝牙数据包之前，所述方法还包括：
通信双方在授权过程中生成三个关键加密数X、R0和R1，其中，X为原始加密数，R0和R1分别为智能设备端和客户端的传输随机数；
将所述原始加密数X与每次传输的session id按位异或操作，得到本次传输的AES加密密钥key Y；
所述智能设备端在接收到所述客户端第一次发送的加密数据时，基于所述传输随机数R0对所接收的数据进行校验；
所述客户端在接收到所述智能设备端发送的第一次发送的加密数据时，基于所述传输随机数R1对所接收的数据进行校验；
在数据传输解密成功时，通信双方将各自的传输随机数+1后作为下一次的发送NONCE值；
在数据传输解密未成功时，发送方将其对应的传输随机数+1后作为下一次的发送NONCE值。
7.如权利要求6所述的蓝牙传输方法，其特征在于，所述通信双方在授权过程中生成三个关键加密数X、R0和R1，包括：
客户端和智能设备端进行ECDH交互，生成ECDH公钥、ECDH密钥和绑定密钥；
使用授权过程中的ECDH共享密码P和所述绑定密钥进行异或，得到原始加密数X；
基于所述绑定密钥的部分字节，得到智能设备端的接收NONCE初始值作为传输随机数R0；
基于所述绑定密钥的另一部分字节，得到客户端的接收NONCE初始值作为传输随机数R1。
8.如权利要求4所述的蓝牙传输方法，其特征在于，在接收到对方发送的蓝牙数据包时，所述方法还包括：
校验所述蓝牙数据包的帧序号是否正确；
若帧序号正确则校验帧CRC是否匹配，若帧序号不正确则向对方响应帧数据出错请求重传正确帧；
若帧CRC匹配则判断传输层数据是否全部接收，若帧CRC不匹配则向对方响应帧数据出错请求重传正确帧；
若传输层数据未全部接收则向对方响应ACK帧数据正确接收，若传输层数据全部接收则校验传输层CRC是否匹配；
若传输层CRC匹配则向对方响应ACK帧数据正确接收，若传输层CRC不匹配则丢弃所接收的数据并向对方响应ACK数据出错。
9.如权利要求1所述的蓝牙传输方法，其特征在于，在发送多个蓝牙数据包之后，所述方法还包括：
当数据传输过程中网络上发生数据包丢失时，记录最近一次丢包事件发生时的往返时延的平均值RTTavg以及最近一次丢包时间发生时的拥塞窗口大小Wmax；
将最近一次丢包时记录的往返延迟的平均值RTTavg与重新访问窗口时的当前延时RTTcur的比值作为拥塞等级因子；
基于所述拥塞等级因子调整调整窗口大小cwnd，其中，cwnd＝NetstateC(ΔT-K)3+Wmax，Netstate＝RTTavg/RTTcur，C为拥塞窗口增加率，ΔT为从最后一个窗口开始缩减所需的时间，K为在没有丢包事件的情况下，将拥塞窗口尺寸增加到Wmax所需要的时间。
10.一种蓝牙传输***，其特征在于，所述***包括：
发送模块，用于发送多个蓝牙数据包；
判断模块，用于在每次发送所述蓝牙数据包后，判断是否正确接收ACK应答；
窗口调整模块，用于在所述判断模块输出结果为是时，响应于正确接收ACK应答，增大蓝牙的初始最大传输窗口；
窗口寻优模块，用于在所述判断模块输出结果为否时，采用二分法在所述初始最大传输窗口与传输窗口阈值之间寻找当前次传输的最优窗口大小，所述传输窗口阈值小于所述初始最大传输窗口；
窗口确定模块，用于重复计算得到若干次传输的最优窗口大小，并基于若干次传输的最优窗口大小确定最佳的蓝牙传输窗口用于数据传输。
CN202310304430.1A 2023-03-24 2023-03-24 蓝牙传输方法及*** Pending CN116321094A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310304430.1A CN116321094A (zh) 2023-03-24 2023-03-24 蓝牙传输方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310304430.1A CN116321094A (zh) 2023-03-24 2023-03-24 蓝牙传输方法及***

Publications (1)

Publication Number Publication Date
CN116321094A true CN116321094A (zh) 2023-06-23

Family

ID=86834091

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310304430.1A Pending CN116321094A (zh) 2023-03-24 2023-03-24 蓝牙传输方法及***

Country Status (1)

Country Link
CN (1) CN116321094A (zh)

Similar Documents

Publication Publication Date Title
KR101577451B1 (ko) Ｒｌｃ 무한 재전송 오류를 검출하고 처리하는 방법
US9473600B2 (en) Higher layer compression with lower layer signaling
US20090319850A1 (en) Local drop control for a transmit buffer in a repeat transmission protocol device
KR20070033299A (ko) 무선 통신 시스템에서 상태 보고의 전송 지연을 개선하기위한 방법 및 장치
WO2010006557A1 (zh) 数据传输方法和装置
JP2008227642A (ja) 再送制御方法、および無線通信システム
CN109076475B (zh) 一种用于保持无连接传输中同步的方法和***
KR102046792B1 (ko) 송신 노드로부터 목적지 노드로의 데이터 전송 방법
KR20090113226A (ko) Ｔｃｐ ａｃｋ 패킷 전송 및 수신 방법과, 이를 지원하는 장치
TW200935812A (en) Status reporting for retransmission protocol
KR20060086273A (ko) 순환 중복 검사 잔류 오류 검출 및 처리 방법
WO2015066836A1 (zh) 视频业务数据传输方法、数据接收装置和数据发送装置
US10932159B2 (en) Data transmission method, data receiving device, and data sending device
WO2013159516A1 (zh) 无线侧tcp数据重传的方法和设备
WO2020147453A1 (zh) 数据传输方法及相关装置
Seytnazarov et al. Enhanced mathematical modeling of aggregation-enabled WLANs with compressed blockACK
WO2019144802A1 (zh) 一种数据的传输方法及其相关设备
WO2012083762A1 (zh) 数据传输方法、设备及***
US20080285493A1 (en) Method of Comparing State Variable or Packet Sequence Number for a Wireless Communications System and Related Apparatus
WO2011032482A1 (zh) 一种测量方法、装置和***
WO2020010511A1 (zh) 数据传输方法及基站
CN108429700B (zh) 一种发送报文的方法及装置
Oliver Characterizing the transport behaviour of the short message service
Peisa et al. Analytical model for TCP file transfers over UMTS
CN116321094A (zh) 蓝牙传输方法及***

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination