CN113573359A - 一种多链路通信方法及相关装置 - Google Patents

一种多链路通信方法及相关装置 Download PDF

Info

Publication number
CN113573359A
CN113573359A CN202010355213.1A CN202010355213A CN113573359A CN 113573359 A CN113573359 A CN 113573359A CN 202010355213 A CN202010355213 A CN 202010355213A CN 113573359 A CN113573359 A CN 113573359A
Authority
CN
China
Prior art keywords
link
ssn
winstart
receiving end
links
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.)
Granted
Application number
CN202010355213.1A
Other languages
English (en)
Other versions
CN113573359B (zh
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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202010355213.1A priority Critical patent/CN113573359B/zh
Priority claimed from CN202010355213.1A external-priority patent/CN113573359B/zh
Priority to PCT/CN2021/080316 priority patent/WO2021218435A1/zh
Publication of CN113573359A publication Critical patent/CN113573359A/zh
Priority to US17/971,843 priority patent/US20230040554A1/en
Application granted granted Critical
Publication of CN113573359B publication Critical patent/CN113573359B/zh

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/1607—Details of the supervisory signal
    • H04L1/1621—Group acknowledgement, i.e. the acknowledgement message defining a range of identifiers, e.g. of sequence numbers
    • 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/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • 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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • 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/1607—Details of the supervisory signal
    • H04L1/1642—Formats specially adapted for sequence numbers
    • 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
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/0001—Arrangements for dividing the transmission path
    • H04L5/0003—Two-dimensional division
    • H04L5/0005—Time-frequency
    • H04L5/0007—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT
    • H04L5/001—Time-frequency the frequencies being orthogonal, e.g. OFDM(A), DMT the frequencies being arranged in component carriers
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10—Small scale networks; Flat hierarchical networks
    • H04W84/12—WLAN [Wireless Local Area Networks]
    • 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/1607—Details of the supervisory signal
    • H04L1/1614—Details of the supervisory signal using bitmaps
    • 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/1607—Details of the supervisory signal
    • H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information

Abstract

本申请实施例公开了一种多链路聚合传输方法及相关装置。所述方法包括：接收端在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；所述接收端在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；所述接收端根据各条链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；所述接收端根据调整后的WinStart，对多链路上接收的数据帧进行处理。实施本申请，接收端可以自适应的调整WinStart，该方法不需要多条链路之间进行交互，同时也不需要更改现有的BAR帧，最大程度的节约信令开销并兼顾多条链路的传输。本申请可适用于802.11be及多种wifi系统中。

Description

一种多链路通信方法及相关装置
技术领域
本申请涉及通信技术领域，尤其涉及一种多链路通信方法及相关装置。
背景技术
随着无线技术的发展，多链路设备(multi-link device，MLD)可以支持多链路通信，例如同时在2.4GHz、5GHz以及60GHz频段上进行通信，即使在天线数受限的情况下，多链路设备也可以在不同的频段上进行切换，从而选择最佳的频段，保证其通信质量。随着越来越多的应用流量由无线网络承载，高速率是无线保真(wreless-fidelity，WiFi)系统的演进目标。为了提升多链路设备中的站点的峰值速率，多链路聚合通信已经成为下一代无线局域网(wireless local area networks，WLAN)技术的特性。
多链路聚合通信涉及多条链路之间的协调工作，数据发送端的同一业务标识符(Traffic Identifier，TID)的多个媒体接入控制协议数据单元(MAC protocol dataunit，MPDU)可以通过多条链路进行传输，以增大该TID数据包的传输速率。数据接收端根据每个MPDU帧头携带的序列号(sequence number,SN)对多条链路上接收的相同TID的数据包按照SN进行排序。协议要求MAC层必须按照顺序将完整的MSDU(MAC Service Data unit,MAC层服务数据单元)往上层递交。
现有技术中，通过记分板机制实现对发送端发送的MPDU的接收情况进行确认。但是，目前多链路聚合下，使用现有的记分板机制，对传输的MPDU的接收情况进行确认，会存在以下问题：
如果发送端通过一条链路(link)发送块确认请求(block acknowledgementrequirement,BAR)时，在BAR中设置了一个起始序列号(Starting sequence number，SSN)值，但其他链路上有小于该SSN值的待传MPDU，会导致接收端移动记分板的起始序列号(示意为：WinStart)，从而导致之后发送端发送的小于该SSN值的MPDUs即便是被接收端正确接收，也会被接收端丢弃。
发明内容
为解决上述技术问题，本申请实施例提供一种多链路聚合传输方法和设备，芯片系统，计算机可读存储介质和计算机程序产品。
本申请实施例第一方面，提供一种多链路聚合传输方法，应用于多链路聚合传输的接收端，包括：
接收端在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；
所述接收端在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
所述接收端根据所述多条链路中至少两条链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；其中，所述多条链路中至少两条链路对应的SSN，包括所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN；
所述接收端根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
本申请实施例第二方面，提供一种多链路设备，其作为多链路聚合传输的接收端，包括：
收发器，用于在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；
所述收发器，用于在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
处理器，用于根据所述多条链路中至少两条链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；其中，所述多条链路中至少两条链路对应的SSN，包括所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN；
所述处理器，还用于根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
本申请实施例第三方面，提供一种多链路聚合传输方法，应用于多链路聚合传输的接收端，包括：
接收端在与发送端之间的多条链路上接收数据帧；所述多条链路包括第一链路；
所述接收端在所述第一链路上接收块确认请求BAR帧；
所述接收端解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号；
所述接收端对所述多链路上接收的数据帧进行处理。
本申请实施例第四方面，提供一种多链路设备，其作为多链路聚合传输的接收端，包括：
收发器，用于在与发送端之间的多条链路上接收数据帧；所述多条链路包括第一链路；
所述收发器，还用于在所述第一链路上接收块确认请求BAR帧；
处理器，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号；
所述处理器，还用于对所述多链路上接收的数据帧进行处理。
本申请实施例第五方面，提供一种芯片系统，包括至少一个处理器和接口；其中，
所述接口，用于输入来自与发送端之间的多条链路上的数据帧；所述多条链路包括第一链路；
所述接口，还用于输入在所述第一链路上接收到的块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
处理器，用于根据所述多条链路中至少两条链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；其中，所述多条链路中至少两条链路对应的SSN，包括所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN；
所述处理器，还用于根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
本申请实施例第六方面，提供一种芯片系统，包括至少一个处理器和接口；其中，
所述接口，用于输入在与发送端之间的多条链路上接收到的数据帧；所述多条链路包括第一链路；
所述接口，还用于输入在所述第一链路上接收到的块确认请求BAR帧；
所述处理器，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号；
所述处理器，还用于对所述多链路上接收的数据帧进行处理。
本申请实施例第一至第六方面任一方面的第一种实现方式中，所述根据所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值，包括：
调整所述WinStart为SSN最小值；其中，SSN最小值为所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN中最小的SSN。
其中，所述根据调整后的WinStart，对所述多链路上接收的数据帧进行处理，包括：
接收到某链路发送的数据帧，所述数据帧的序列号SN满足WinEnd<SN<WinStart+2^11，调整所述WinStart为WinStart＝SN-WinSize+1；
将所述多条链路对应的SSN中，小于调整后的WinStart的SSN，更新为与所述调整后的WinStart相同。换句话说，凡是小于调整后的WinStart的各链路对应的SSN，都更新为调整之后的WinStart。
本申请实施例第一至第六方面任一方面的第二种实现方式中，根据各链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值，包括：
调整所述WinStart为WinStart最大值；
其中，WinStart最大值为接收所述BAR之前的WinStart与接收所述BAR后的WinStart中最大的WinStart；其中，接收所述BAR后的WinStart为SSN最小值；所述SSN最小值为所述第一链路对应的SSN_1的SSN_1和本地存储的其他链路对应的SSN中最小的SSN。
其中，所述根据调整后的WinStart，对所述多链路上接收的数据帧进行处理，包括：
接收到某条链路发送的数据帧，所述数据帧的序列号SN满足WinEnd<SN<WinStart+2^11，调整所述WinStart为WinStart＝SN-WinSize+1。
本申请实施例第一至第六方面任一方面的第一种或第二种实现方式中，所述SSN_1为所述第一链路下一个上被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号。
本申请实施例第七方面，提供一种多链路聚合传输方法，应用于多链路聚合传输的发送端，包括：
发送端在与接收端之间的多条链路上发送数据帧；所述多条链路包括第一链路；
所述发送端在所述第一链路上发送块确认请求BAR帧；所述BAR帧中携带有与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号。
本申请实施例第八方面，提供一种多链路设备，其作为多链路聚合传输的发送端，包括：
收发器，用于在与接收端之间的多条链路上发送数据帧；所述多条链路包括第一链路；
所述收发器，还用于在所述第一链路上发送块确认请求BAR帧；
所述处理器，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被所述发送端被丢弃的数据帧的序列号。
本申请第八方面，提供一种芯片系统，包括：至少一个处理器和接口；
所述接口，用于输出在与接收端之间的多条链路上发送的数据帧；所述多条链路包括第一链路；
所述接口，还用于输出在所述第一链路上发送的块确认请求BAR帧；
所述处理器，用于在所述BAR帧中携带与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被丢弃的数据帧的序列号。
本申请实施例第九方面，提供了一种第一多链路通信装置，该第一多链路通信装置被配置为实现上述第一方面或第三方面中接收端执行的方法和功能，由硬件/软件实现，其硬件/软件包括与上述功能相应的模块。
本申请实施例第十方面，提供了一种第二多链路通信装置，该第二多链路设备被配置为实现上述第七方面发送端所执行的方法和功能，由硬件/软件实现，其硬件/软件包括与上述功能相应的模块。
本申请实施例第十一方面，提供了一种包含指令的计算机程序产品，当其在计算机上运行时，使得计算机执行如前述第一方面或第三方面或第七方面的任一方面所述的方法。
本申请实施例第十二方面，提供一种计算机可读存储介质，所述计算机可读存储介质用于存储指令，当所述指令被执行时，使得如前述第一方面或第三方面或第七方面的任一方面所述的方法被实现。
本申请实施例第十三方面，提供了一种芯片，包括处理器，用于从存储器中调用并运行存储器中存储的指令，使得安装有芯片的通信设备执行上述第一方面或第三方面或第七方面的方法。
本申请实施例第十四方面，提供另一种芯片，该芯片可以为第一多链路设备或第二多链路设备内的芯片，该芯片包括：输入接口、输出接口和处理电路，输入接口、输出接口与电路之间通过内部连接通路相连，处理电路用于执行上述第一方面或第三方面或第七方面的方法。
本申请实施例第十五方面，提供另一种芯片，包括：输入接口、输出接口、处理器，可选的，还包括存储器，输入接口、输出接口、处理器以及存储器之间通过内部连接通路相连，处理器用于执行存储器中的代码，当代码被执行时，处理器用于执行上述第一方面或第三方面或第七方面的方法。
本申请实施例第十六方面，提供一种装置，用于实现上述任一方面的方法。
附图说明
为了更清楚地说明本申请实施例或背景技术中的技术方案，下面将对本申请实施例或背景技术中所需要使用的附图进行说明。
图1是本申请实施例提供的一种通信系统的架构示意图；
图2是本申请实施例提供的一种多链路设备之间传输的示意图；
图3A是本申请实施例提供的一种多链路设备的结构示意图；
图3B是本申请实施例提供的一种多链路通信装置的结构示意图；
图3C是本申请实施例提供的一种多链路通信装置的结构示意图；
图4是本申请实施例提供的一种芯片系统的结构示意图；
图5是一种BAR帧的示意图；
图6是一种BAR帧的又一示意图；
图7是一种BA帧的示意图；
图8是一种BA帧的又一示意图；
图9是一种多链路聚合传输示意图；
图10是一种多链路聚合传输架构图；
图11是一种被更改的BAR帧的示意图；
图12是又一种被更改的BAR帧的示意图；
图13是本申请实施例提供的一种多链路聚合传输的流程示意图；
图14是本申请实施例提供的又一多链路聚合传输的流程示意图；
图15是本申请实施例提出的又一多链路聚合传输的流程示意图；
图16是一种多链路聚合传输的流程示意图；
图17是本申请实施例提供的又一多链路聚合传输的流程示意图；
图18是本申请实施例提出的又一多链路聚合传输的流程示意图；
图19是本申请实施例提供的又一多链路聚合传输的流程示意图。
具体实施方式
下面结合本申请实施例中的附图对本申请实施例进行描述。
图1是本申请实施例提供的一种通信系统的架构示意图。该通信系统包括接入点设备和站点设备。通信系统中可以包含一个或多个接入点(access point，AP)，图1中只示意了1个。该通信系统中还包括一个或多个站点(station，STA)，例如图1中示意的STA1～STA6。其中，STA2与AP之间存在多条链路，STA2为多链路设备；STA4和STA5之间也存在多条链路，STA4和STA5也为多链路设备。本申请实施例中的多链路设备可以为站点设备，也可为接入点设备。
图1所示的架构也可以扩展至基站(base station，BS)和终端设备(userequipment，UE)的应用场景。其中，AP可以为移动用户进入有线网络的接入点，主要部署于家庭、大楼内部以及园区内部，典型覆盖半径为几十米至上百米，当然，也可以部署于户外。
AP相当于一个连接有线网和无线网的桥梁，主要作用是将各个无线网络客户端连接到一起，然后将无线网络接入以太网。具体的，AP可以是带有WiFi芯片的终端设备或者网络设备。AP可以为支持802.11be及未来的802.11标准制式的设备。AP也可以为支持802.11ax、802.11ac、802.11n、802.11g、802.11b及802.11a等多种无线局域网(wirelesslocal area networks，WLAN)制式的设备。STA可以为无线通讯芯片、无线传感器或无线通信终端。例如支持WiFi通讯功能的移动电话、支持WiFi通讯功能的平板电脑、支持WiFi通讯功能的机顶盒、支持WiFi通讯功能的智能电视、支持WiFi通讯功能的智能可穿戴设备、支持WiFi通讯功能的车载通信设备和支持WiFi通讯功能的计算机。可选地，STA可以支持802.11be及未来的802.11标准制式的设备。STA也可以支持802.11ax、802.11ac、802.11n、802.11g、802.11b及802.11a等多种WLAN制式。
虽然本申请实施例主要以部署IEEE 802.11的网络为例进行说明，本领域技术人员容易理解，本申请涉及的各个方面可以扩展到采用各种标准或协议的其它网络，例如，BLUETOOTH(蓝牙),高性能无线LAN(high performance radio LAN，HIPERLAN)(一种与IEEE802.11标准类似的无线标准，主要在欧洲使用)以及广域网(WAN)、无线局域网(wirelesslocal area network,WLAN)、个人区域网(personal area network,PAN)或其它现在已知或以后发展起来的网络。因此，无论使用的覆盖范围和无线接入协议如何，本申请提供的各种方面可以适用于任何合适的无线网络。
如图2所示，图2是本申请实施例提供的一种多链路设备之间的关联关系示意图。图2中所示的多链路设备包括第一多链路设备和第二多链路设备，第一多链路设备或第二多链路设备可以分别包括至少一个多链路逻辑实体，一个多链路逻辑实体可以包括一个或多个站点，每个站点分别工作在不同的链路上。其中，第一多链路设备中的STA1和STA2属于一个多链路逻辑实体，第一多链路设备中的STAn属于另一个多链路逻辑实体。第二多链路设备中的STA1和STA2属于一个多链路逻辑实体，第二多链路设备中的STAn属于另一个多链路逻辑实体。如果第一多链路设备需要与第二多链路设备进行通信，则需要第一多链路设备中的每个站点与第二多链路设备中对应的站点进行关联。
如图2所示，第一多链路设备中的STA1与第二多链路设备中的STA1相关联，工作在聚合链路1(简称链路1)上。第一多链路设备中的STA2与第二多链路设备中的STA2相关联，工作在聚合链路2(简称链路2)上。第一多链路设备中的STAn与第二多链路设备中的STAn相关联，工作在聚合链路n(链路n)上。使得第一多链路设备中每个站点可以在各自链路上与第二多链路设备中对应的站点建立连接，实现两个多链路设备之间的多链路通信。
本申请实施例中的所涉及的多链路设备，其可以包括硬件结构、软件模块，以硬件结构、软件模块、或硬件结构加软件模块的形式来实现上述各功能。上述各功能中的某个功能可以以硬件结构、软件模块、或者硬件结构加软件模块的方式来实现。
图3A为本申请实施例提供的一种多链路设备200的结构示意图。如图3A所示，该多链路设备200可包括：处理器201、收发器205，可选的还包括存储器202。
所述收发器205可以称为收发单元、收发机、或收发电路等，用于实现收发功能。收发器205可以包括接收器和发送器，接收器可以称为接收机或接收电路等，用于实现接收功能；发送器可以称为发送机或发送电路等，用于实现发送功能。
存储器202中可存储计算机程序或软件代码或指令204，该计算机程序或软件代码或指令204还可称为固件。处理器201可通过运行其中的计算机程序或软件代码或指令203，或通过调用存储器202中存储的计算机程序或软件代码或指令204，对MAC层和PHY层进行控制，以实现本申请下述各实施例。其中，处理器201可以为中央处理器(central processingunit，CPU)，存储器202例如可以为只读存储器(read-only memory，ROM)，或为随机存取存储器(random access memory，RAM)。
本申请中描述的处理器201和收发器205可实现在集成电路(integratedcircuit，IC)、模拟IC、射频集成电路RFIC、混合信号IC、专用集成电路(applicationspecific integrated circuit，ASIC)、印刷电路板(printed circuit board，PCB)、电子设备等上。
上述多链路设备200还可以包括天线206，该多链路设备200所包括的各模块仅为示例说明，本申请不对此进行限制。
请参见图3B，图3B是本申请实施例提供的一种第一多链路通信装置的结构示意图，该第一多链路通信装置可以用于实现本申请实施例中涉及第一多链路设备的任意方法和功能，第一多链路通信装置可以包括处理模块301、发送模块302。可选的，发送模块302对应第一多链路设备包括的一个基带电路和一个射频电路。该第一多链路通信装置作为多链路聚合传输的发送端，其中，各个模块的详细描述如下。
在一个实施例中：
发送模块302，用于在与第二多链路设备之间的多条链路上发送数据帧；所述多条链路包括第一链路；
所述发送模块302，还用于在所述第一链路上发送块确认请求BAR帧；
所述处理模块301，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被所述第一多链路设备丢弃的数据帧的序列号。
其中，数据帧和BAR帧包括的元素或字段的内容以及功能可参考后续方法实施例的描述，此处不再赘述。
请参见图3C，图3C是本申请实施例提供的一种第二多链路通信装置的结构示意图，该第二多链路通信装置可以用于实现本申请任意实施例中涉及第二多链路设备的任意方法和功能，第二多链路通信装置可以包括接收模块401以及处理模块402。其中，第二多链路通信装置作为多链路聚合传输的接收端，各个模块的详细描述如下。
一种实现方式中，
接收模块401，用于在与发送端之间的多条链路上接收数据帧；所述多条链路包括第一链路；
所述接收模块401，还用于在所述第一链路上接收块确认请求BAR帧；
处理模块402，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号；
所述处理模块402，还用于对所述多链路上接收的数据帧进行处理。
另一种实现方式中，
接收模块401，用于在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；
接收模块401，用于在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
处理模块402，用于根据所述多条链路中至少两条链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；其中，所述多条链路中至少两条链路对应的SSN，包括所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN；
应理解，本申请所说的各链路对应的SSN，是指的各条链路各自的SSN，各条链路各自的SSN的值可以相同，也可以各不相同；多链路通信装置可以对各条链路的SSN进行统一设置，也可以分别进行设置，本申请不做限定。
可选的，第二多链路通信装置还包括存储器或者缓存，用于存储多条链路各自的SSN；
所述处理器402，还用于根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
上述两种方式中的数据帧和BAR帧包括的元素或字段的内容以及功能可参考后续方法实施例的描述，此处不再赘述。
需要说明的是，各个模块的实现还可以对应本申请方法实施例的相应描述，执行上述实施例中第二多链路设备所执行的方法和功能。
本申请实施例还提供了一种处理器，用于与存储器耦合，用于执行本申请实施例中任一实施例中涉及第一多链路设备或第二多链路设备的任意方法和功能。
本申请实施例还提供了一种包含指令的计算机程序产品，其在计算机上运行时，使得计算机执行本申请各实施例中任一实施例中涉及第一多链路设备或第二多链路设备的任意方法和功能。
本申请实施例还提供了一种装置，用于执行上述本申请实施例中任一实施例中涉及第一多链路设备或第二多链路设备的任意方法和功能。
本申请实施例还提供一种无线通信系统，该系统包括本申请任一实施例中涉及的至少一个第一多链路设备和至少一个第二多链路设备。
如前所述，以上实施例描述中的多链路设备可以是接入点或者站点，但本申请中描述的多链路设备的范围并不限于此，而且多链路设备的结构可以不受图3A～图3C的限制。多链路设备可以是独立的设备或者可以是较大设备的一部分。例如所述多链路设备的实现形式可以是：
(1)独立的集成电路IC，或芯片，或，芯片系统或子系统；(2)具有一个或多个IC的集合，可选的，该IC集合也可以包括用于存储数据，指令的存储部件；(3)可嵌入在其他设备内的模块；(4)接收机、智能终端、无线设备、手持机、移动单元、车载设备、云设备、人工智能设备等等；(5)其他等等。
对于多链路设备的实现形式是芯片或芯片系统的情况，可参见图4所示的芯片的结构示意图。图4所示的芯片包括处理器501和接口502。其中，处理器501的数量可以是一个或多个，接口502的数量可以是多个。可选的，该芯片或芯片系统可以包括存储器503。
本申请实施例并且不限制权利要求书的保护范围和适用性。本领域技术人员可以在不脱离本申请实施例范围的情况下对本申请涉及的元件的功能和部署进行适应性更改，或酌情省略、替代或添加各种过程或组件。
为便于理解，下面先对本文涉及的相关技术方案或技术术语进行简单的介绍。
1、确认机制
对于MPDU是否被正确接收，通常是通过确认机制进行确认的，通常有如下三种确认方式：
基于ACK的确认方式：发送端发送一个MPDU，同时将服务质量(quality ofservice,QoS)字段中的确认策略子字段设置为正常接收，接收端如果正确接收到该MPDU，则向发送端返回一个ACK消息表示其正确接收到该MPDU。
基于正常确认的块确认方式：发送端发送一个聚合(aggregation MPDU，A-MPDU)，同时将QoS字段中的确认策略子字段设置为正常块确认，接收端分别解析其中的每个MPDU，根据每个MPDU是否接收成功，返回一个块确认(block acknowledgement，BA)帧。BA帧中会携带一个bitmap来指示对应的MPDU或者MSDU是否接收成功。如果某个MPDU或者MSDU接收成功，则将相应Bit置1，否则置0。
本申请后续的实施例中，将QoS字段中的确认策略子字段设置为正常块确认的MPDU简称为QoS数据帧或者数据帧(图中用data表示)。
基于请求的块确认(block acknowledgement request,BAR)：发送端可以发送一个或者A-MPDUs，同时将QoS字段中的确认策略子字段设置为请求块确认。只有当发送端发送一个BAR帧后，接收端才根据之前各个MPDU或者MSDU的接收情况，返回一个BA帧。
2、BAR帧
BAR帧的格式如图5所示，其包括：帧控制，时长，接收地址，发送地址，BAR控制，起始序列控制，帧校验序列等字段；其中，BAR控制字段包括：BAR确认策略，多TID，压缩点阵图，组播重传模式，TID/TID数目和保留(B5～B11)等子字段，各主要子字段的含义如下：
BAR确认策略：该指示位在延迟块确认时使用。对于一个延时块确认会话，如果该指示位置0，表示接收端收到BAR帧后，在短帧间间隔(short interframe space，SIFS)后回一个ACK；当该指示位置1时，表示接收端收到BAR帧后不需要回ACK。
压缩点阵图：如果被设置1，则表示该BAR要求接收端回一个带压缩点阵图的BA。
TID/TID数目：如果多TID指示位没有被置1，则该字段承载该块确认会话的TID。如果多TID指示位被置1，则该字段承载多TID BAR帧中的TID数目。
起始序列控制字段：该字段用其中的12bits(B4～B15)来携带起始序列号(Starting sequence number,SSN)。
多TID：该指示位用于指示该BAR是基本BAR帧还是多TID BAR帧，对于多TIDBAR帧，其帧格式如图6所示。
对于多TID BAR帧，每个TID都有一个每TID信息和起始序列控制字段。每TID信息字段包含TID值，紧跟这个字段的是对应于该TID的序列控制字段。
3、BA帧
BA的帧格式如图7所示。其包括：帧控制，时长，接收地址，发送地址，BA控制，起始序列控制，帧校验序列等字段；其中，BA控制包括BA确认策略，多TID，压缩点阵图，组播重传模式，TID/TID数目和保留(B5～B11)等子字段，各主要子字段的含义如下：
BA确认策略:该指示位在延迟块确认时使用。对于一个延时块确认回话，如果该指示位置0，表示接收端收到BA帧后，在SIFS后回一个ACK；当指示位置1时，接收端收到BAR帧后不需要回ACK。
压缩点阵图：如果被设置1，则表示该BA帧包含一个压缩的或8个八位元的块确认点阵图。如果设置为0，则BA帧包含非压缩的或者128个八位元的块确认点阵图。
TID/TID数目：如果多TID指示位没有被置1，则该字段承载该块确认会话的TID。如果多TID指示位被置1，则该字段承载多TID BA帧中的TID数目。
起始序列控制字段：该字段用其中的12bits来携带起始序列号SSN。
块确认点阵图：块确认点阵图可以是非压缩BA情况下的128个八位元，也可以是在压缩BA情况下的8个八位元。点阵图最多可标示64个MSDU的接收状态。在非压缩点阵图的情况下，每个MSDU由一个16位bits来表示，各个bit代表MSDU分片(如果有的话)。在压缩点阵图的情况下每个MSDU使用单个bit来表示，这种情况下不支持对每个分片接收状态的表示。
多TID：该指示位用于指示该BA是基本BA帧还是多TID BA帧，对于多TID BA帧，其帧格式如图8所示。
对于多TID BA帧，每个TID都有一个每TID信息字段、起始序列控制字段、BA点阵图字段。每TID信息字段包含TID值，紧跟这个字段的是对应于该TID的序列控制字段和BA点阵图。
4、块确认会话的建立过程
对于某个TID数据，如果想使用块确认机制，是通过交换建立块确认(Add BlockAcknowledgement，ADDBA)请求(request)/响应(response)帧来建立的。
具体的，块确认会话的初始化由发起端发送一个“ADDBA请求”帧开始。响应端发送一个ACK作为对正确收到的“ADDBA请求”帧的回应。在进一步的处理后，响应端发送一个“ADDBA响应”帧，如果发起端正确接收到此帧，则回应一个ACK。如果没有收到期望的ACK，则发起端与响应端将会重传“ADDBA请求”“ADDBA响应”。如果会话建立不成功，其会被发起端的无操作超时检测到。
其中，“ADDBA请求”与“ADDBA响应”帧携带以下主要信息：
块确认策略：该字段指示该会话是立即块确认还是延迟块确认会话。
TID：该字段给出了该会话所用的通信类别。
缓冲区大小：该字段指示响应端用来对帧进行重排序的帧缓冲区数目。如果这个值由发起端设置，则是期望值，响应端设置的值才是真实值。发起端在要求一个块确认之前，没有收到响应的MPDU数目不能超过此值。
块确认超时值：该字段给出了在此会话中没有帧交换时，块确认会话在多久后终止。
起始序列号：发起端发送的第一个数据帧的序列号。
5、记分板机制以及窗口起始序列号(WinStart)移动机制
对于块确认，接收端会维护一个记分板数据结构，以记录哪些MPDU已经被正确接收到。当接收端需要回BA时，会将记分板转换成一个点阵图(bitmap)，BA帧中会进一步指示bitmap中的第一个比特所对应的序列号，随后的比特则对应后续的序列号。目前协议中，MAC服务数据单元(MAC Service data unit,MSDU)的序列号是一个12bits，记分板表示一个大小为4096的序列号空间(Sequence Number Space)的一个窗口。记分板窗口由窗口起始序列号(WinStart)，窗口终止序列号(WinEnd)以及窗口长度(WinSize)定义。
多链路聚合通信涉及多个链路之间的协调工作。数据发送端(如图2所示第一多链路设备)的同一TID的MPDUs可以分别通过多条链路：链路1，链路2，链路3，链路n进行传输，以增大该TID数据的传输速率。数据接收端(例如第二多链路设备)根据每个MPDU帧头携带的序列号(SN)对多条链路上接收的相同TID的数据包按照SN进行排序。协议要求MAC层必须按照顺序将MPDUs往上层递交。
但是，本申请的发明人发现，在多链路聚合下BAR的发送会存在如下问题：如果一条link在发送BAR时设置了一个SSN值，根据现有的WinStart移动规则，接收端会移动WinStart，但其他link有小于该SSN的待传MPDU，接下来即使这些MPDUs被发送且被正确接收也会被接收端丢弃。
举例来说，如图9所示：
发送端分别在链路1和链路2上发送A-MPDU1和A-MPDU2，其中A-MPDU1所包含的MPDUs对应的SN为1～31；A-MPDU2所包含的MPDUs对应的SN为32～59。接收端分别在链路1和链路2上反馈BA给发送端，并指示哪些MPDUs被成功接收哪些MPDUs未被成功接收。假设链路2上发送的BA未被发送端成功接收，其接下来在链路2上发送一个BAR帧请求接收端回BA，并将BAR帧中的SSN设置为32。接收端收到BAR帧后会将WinStart移动到32，但这会导致A-MPDU1中未被正确接收的MPDUs在接下来的重传过程中，即使被接收端成功接收也会因为其SN小于WinStart而被丢弃。
为了解决上述多链路聚合场景下的技术问题，存在如下三种现有技术：
现有技术一：针对多链路聚合场景下的每条链路，单独使用记分板机制。
具体的，如图10所示的多链路聚合架构中，接收端除了设置有一个全局重排缓冲区(Global Reorder Buffer)，每条链路还有一个本地记分板或者本地重排缓冲区(LocalReorder Buffer)。为了避免MPDUs在本地缓冲区等待过长时间，需要引入一个新的BAR帧，称为本地BAR(Local BAR，L-BAR)，其帧格式如图11所示：
与图5所示的BAR帧不同之处在于，将保留比特(reserved bit)B5用来指示是否携带本链路传输的MPDU的SN点阵图指示信息，其用于指示在本link上传输的MPDUs所对应的SN范围，并且第一个bit对应的SN用起始序列号字段进行指示。
接收端接收到该L-BAR帧之后，根据其携带的本链路传输的MPDU的SN点阵图指示信息来判断如何移动本链路对应的记分板窗口的起始序列号(WinStart)。
现有技术一提供的技术方案，需要修改现有的BAR帧，并为每条链路增加一个本链路传输的MPDU的SN点阵图指示信息，信令开销巨大。
现有技术二：约束发送端发送的MPDU的SN。
具体的，参见图12，与图5所示的BAR帧结构不同之处在于，图12的BAR帧结构中，利用保留比特(reserved bit)B5指示接收端是否需要根据该BAR帧来移动记分板窗口的起始序列号(WinStart)，该B5对应的字段可以称为“是否移动指示”。
当发送端想要接收端根据BAR帧来移动记分板窗口的起始序列号(WinStart)时，发送端必须保证其发送的MPDU的SN大于BAR帧中携带的SSN，也即，MPDU的SN小于BAR帧中携带的SSN将不能被发送。
现有技术二提供的技术方案，同样需要修改现有的BAR帧，并且需要发送端的多条链路之间能够互相交互，以判断什么情况下可以让接收端移动记分板窗口的起始序列号(WinStart)，需要让接收端移动WinStart时，将“是否移动指示”置为1。这无疑增加了发送端的复杂度；并且，在非共址(non-colocation)场景下，各条链路之间的交互，会增加延时。
现有技术三：约束发送端发送的MPDU的SSN。
现有技术三中，发送端在某条链路上发送BAR时，需要保证其他链路上没有比该BAR中携带的SSN更低的待传MPDU。
现有技术三的技术方案，同样需要发送端的聚合链路之间能够交互，这无疑增加了发送端的复杂度；并且，在non-colocation场景下，各条链路之间的交互，会增加延时。。
本申请针对上述技术问题，以及上述三种现有技术存在的缺陷，针对多链路聚合传输，提供了一种记分板窗口起始序列号(WinStart)的移动规则。
本申请提供的一种记分板窗口起始序列号(WinStart)的移动规则，作用于接收端，综合参考多条链路各自的SSN以决策是否移动WinStart。
应理解，本申请所说的多条链路对应的SSN，是指的多条链路各自的SSN，各条链路各自的SSN的值可以相同，也可以部分不同，也可以是各不相同；发送端可以对各条链路的SSN进行统一设置，也可以分别进行设置，本申请不做限定。
还应理解，本申请在接收端综合考虑多条链路各自的SSN，包括如下几种情况；
一是在接收到某条链路上发送的BAR之后，将该BAR中携带的SSN，和接收端本地维护或存储的其他链路的SSN进行综合考虑；
二是在某一个时间点，接收端对其本地维护或存储的多条链路的SSN进行综合考虑；
三是在接收到多条链路同时发送的多个BAR之后，将该多个BAR中携带的与多条链路分别对应的SSN进行综合考虑。
应理解，本申请实施例涉及的多条链路，是指的发送端和接收端之间的多条链路；接收端在综合考虑多条链路各自的SSN决策是否移动WinStart时，可以考虑该多条链路中的全部链路各自的SSN，也可以考虑该多条链路中的至少两条链路对应的SSN。
一种实现中，为了兼顾多条链路上发送的MPDU，在接收端接收到某条链路发送的BAR帧时，接收端对WinStart进行调整的时候，不仅只考虑该BAR帧携带的SSN，还需要跟其他链路发送的BAR携带的SSN进行比较，取其中最小的值，以便将WinStart的值调整为多条链路发送的BAR的对应的SSN的最小值，从而不会出现发送的MPDU的SN小于WinStart的情况。应理解，其他链路发送的BAR携带的SSN已经在接收端本地存储，因此不需要发送端多条链路之间进行交互。
另外，在接收端接收到某条链路发送的MPDU时，如果某条链路发送的数据帧对应的SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，则调整WinStart，以便WinEnd等于该SN，如果本地存储的各链路对应的SSN中，有小于调整后的WinStart的SSN，则将本地存储的小于WinStart的SSN更新为WinStart。
发送端可以不改变现有BAR帧的SSN的设置规则，也不需要发送端多链路之间需要交互，接收端根据多条链路的接收情况来调整WinStart。该方法不需要更改现有的BAR帧，也不强制要求发送端多链路之间能够进行交互，这尤其适用于non-collocated多链路聚合场景。
举例来讲，本申请针对多链路聚合传输，提供的新的记分板窗口起始序列号(WinStart)的移动规则如下：
WinStart移动规则一
每条link的SSN都初始化为SSN_0,其携带在ADDBA Request/Response帧中；
当接收到一个BAR帧，则将WinStart移动到min(SSN_1,SSN_2,…,SSN_N)，其中SSN_i为聚合链路i上的SSN值；
当接收到一个QoS数据帧时，有以下3种情况：
如果数据帧的SN落在当前的记分板窗口内，即WinStart<＝SN<＝WinEnd，则记分板在SN表示的偏移量处置1；
如果数据帧的SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，则记分板右移以适应SN，即，将记分板窗口起始序列号设置为WinStart＝SN-WinSize+1。如果SSN_i小于WinStart，则更新SSN_i为WinStart，其中i＝1,…,N；
如果数据帧的SN超出窗口外一半序列空间以上，即WinStart+2^11<＝SN<＝WinStart，则不对记分板做任何改变。
另一种实现中，为了兼顾多条链路上发送的MPDU，在接收端接收到某条链路发送的BAR帧时，将该BAR帧携带的SSN值与其他链路对应的SSN的值中的最小值，记为WinStart_x；然后与接收该BAR帧前本地存储的WinStart_y进行比较，取两者中最大值作为当前的WinStart对记分板窗口进行调整；然后利用调整后的记分板窗口对各链路接收到的数据帧进行处理。
接收端可以自适应的调整WinStart，这样做的目的，是为了兼顾多条链路发送的MPDU，该方法不需要多条链路之间进行交互，同时也不需要更改现有的BAR帧，最大程度的节约信令开销并兼顾多条链路的传输。
举例来讲，本申请针对多链路聚合传输，提供的新的记分板窗口起始序列号(WinStart)的移动规则如下：
WinStart移动规则二：
每条link的SSN都初始化为SSN_0,其携带在ADDBA Request/Response帧中；
当接收端在某条链路(link i)上接收到一个BAR帧，将该BAR帧中携带的SSN_i和接收端本地存储的其他链路的SSN，取最小值，记为WinStart_x，即，将min(SSN_1,SSN_2,…,SSN_N)记为WinStart_x,收到BAR帧前的WinStart记为WinStart_y，则将WinStart移动到max(WinStart_x,WinStart_y)；
当接收端接收到一个QoS数据帧时，有以下3种情况：
如果数据帧的SN落在当前的记分板窗口内，即WinStart<＝SN<＝WinEnd，则记分板在SN表示的偏移量处置1；
如果数据帧的SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，则记分板右移以适应SN，且将记分板当前窗口起始序列号WinStart设置为WinStart＝SN-WinSize+1；
如果数据帧的SN超出窗口外一半序列空间以上，即WinStart+2^11<＝SN<＝WinStart，则不对记分板做任何改变。
基于上述发送端发送BAR的规则和接收端执行WinStart移动规则，本申请在图1所示的网络系统以及图2-图4所示的多链路设备的结构中，实现本申请提供的多链路聚合传输的方法如图13所示，包括：
步骤100，发送端在多条链路上向接收端发送数据帧(MPDUs)；其中，不同链路上发送的数据帧，其对应的SSN可以相同，也可以不同；
步骤101，接收端在多条链路上接收所述数据帧；
步骤102，发送端在所述第一链路上发送块确认请求BAR帧；所述BAR帧中携带有与第一链路对应的起始序列号SSN_1；
一种可选的实现方式中，所述SSN_1为所述第一链路下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号；
步骤103，接收端在所述第一链路上接收块确认请求BAR帧；
步骤104，接收端根据多条链路各自的SSN，调整当前的记分板窗口起始序列号WinStart值；
步骤105，接收端根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
需要说明的是，以上流程仅为举例，各条链路发送数据帧和BAR帧的先后顺序本申请不做限制，接收端接收数据帧和BAR帧的时间顺序本申请也不做限制。
其中，发送端可以是如图1所示的AP，相应的，接收端为STA2；或者发送端为STA2，接收端为AP；或者发送端为STA4，接收端为STA5；或者发送端为STA5，接收端为STA4。或者发送端是如图2第一多链路设备，接收端为第二多链路设备；多条链路分别为链路1，链路2，链路3…链路n。
上述发送端执行的步骤100和步骤102，可以通过如图3A所示的多链路设备200的收发器205执行，或者通过如图3B所示的第一多链路通信装置中的发送模块302执行；还可以通过如图4所示的芯片系统中的接口302执行。
上述接收端执行的步骤101和103，可以通过如图3A所示的多链路设备200的收发器205执行，步骤104可以通过处理器201执行。上述接收端执行的步骤101和103，还可以通过如图3B所示的第二多链路通信装置的接收模块401执行，步骤104和步骤105可以通过处理模块402执行。步骤101和103还可以通过如图4所示的芯片系统中的接口302执行，步骤104和步骤105还可以通过处理器301执行。
其中，在接收端还存储各条链路对应的SSN和记分板窗口参数等，例如WinStart，WinSize，可选的还可以存储WinEnd，可以通过如图3A所示的存储器202，或图4所示的存储器303实现，具体的形式不限于表格等等。
实施例一
本实施例一将描述本申请实现如图13所示的链路聚合传输技术方案中，记分板窗口起始序列号(WinStart)的移动规则一。
如图14所示，以发送端通过两条聚合链路向接收端发送MPDUs为例进行说明。MPDUs的确认策略字段都设置为基于请求的块确认策略，并且不存在某个MPDU的SN落在WinEnd<SN<WinStart+2^11的情况。
在这种场景下，在接收端执行WinStart的移动过程如下：
在初始时刻t0，将SSN_1和SSN_2都初始化为SSN_0，其中SSN_0为发送端发送的ADDBA请求和接收端向发送端发送ADDBA响应帧中携带的起始序列号，SSN_1和SSN_2分别为聚合链路1和聚合链路2上收到的BAR帧中所携带的SSN值。接收端将WinStart设置为min(SSN_1,SSN_2)＝min(0,0)＝0。
在时刻t1，接收端在聚合链路1上收到一个BAR帧，其携带的SSN_1为20，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(20,0)＝0；
在时刻t2，接收端在聚合链路2上收到一个BAR帧，其携带的SSN_2为30，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(20,30)＝20；
在时刻t3，接收端在聚合链路1上收到一个BAR帧，其携带的SSN_1为25，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(25,30)＝25；
在时刻t4，接收端在聚合链路1上收到一个BAR帧，其携带的SSN_1为28，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(28,30)＝28；
在时刻t5，接收端在聚合链路2上收到一个BAR帧，其携带的SSN_2为40，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(28,40)＝28；
在时刻t6，接收端在聚合链路1上收到一个BAR帧，其携带的SSN_1为45，然后接收端将WinStart设置为min(SSN_1,SSN_2)＝min(45,40)＝40；
以此类推。
本实施例一为了兼顾多条链路上发送的MPDU，在接收端接收到某条链路发送的BAR帧时，接收端对WinStart进行调整的时候，不仅只考虑该BAR帧携带的SSN，还需要跟其他链路发送的BAR携带的SSN进行比较，取其中最小的值，以便将WinStart的值调整为多条链路发送的BAR的对应的SSN的最小值，从而不会出现发送的MPDU的序列号小于WinStart而导致接收端即使正确接收也会被丢弃的情况出现。
实施例二
实施例二中，将描述本申请实现如图13所示的链路聚合传输技术方案中，记分板窗口起始序列号(WinStart)的移动规则一，以及在该WinStart移动规则一基础上，对多条链路上发送的MPDU的处理方式。
如图15所示，仍然以发送端的多链路设备通过两条链路Link1和Link2向接收端发送MPDUs，且记分板窗口为WinStart＝4，WinSize＝100，WinEnd＝103为例。
首先ADDBA请求/响应帧中SSN设置为4，SSN_1和SSN_2都初始化为4，假设link1和link2上都只采用块确认策略且之前发送端没有发送过BAR帧，而且没有发送过SN大于103的MPDU(图中示意为Data)。
T0时刻，发送端在Link1上向接收端发送的MPDU，其SN为103，满足WinStart<SN＝WinEnd＝103，因此在序列号空间(Sequence Number Space)中，在该SN对应的偏移量(即序列号为103)处，将对应的比特置1，表示SN＝103对应的MPDU被成功接收。
T1时刻，发送端在Link2上发送BAR帧，其中携带的SSN＝6；接收端将WinStart调整为两条链路对应的SSN的最小值，即WinStart＝min(SSN_1,SSN_2)＝min(4,6)＝4。将SSN_1＝4，SSN_2＝6,WinStart＝4，WinEnd＝103存储在接收端本地。
T2时刻，发送端在Link1上重传SN＝4的MPDU，满足WinStart＝SN<WinEnd，因此，在该SN对应的偏移量(即序列号为4)处，将对应的比特置1，表示SN＝4对应的MPDU被成功接收。将SSN_1＝4，SSN_2＝6,WinStart＝4，WinEnd＝103存储在接收端本地。
相比较而言，相同场景下，如果利用现有技术提供的记分板的起始序列号(WinStart)的移动规则，如图16所示，在T1时刻，发送端在Link2上发送BAR帧，其中携带的SSN＝6；接收端将WinStart调整为该BAR对应的SSN，即WinStart＝SSN_2＝6。
在T2时刻，发送端在Link1上发送SN＝4的MPDU，由于SN＝4<WinStart,即使该SN对应的MPDU被接收端成功接收，也会被接收端丢弃或者删除。
比较图15本申请提供的多链路传输方案和图16现有技术提供的多链路传输方案可知，利用本申请实施例提供的记分板窗口起始序列号(WinStart)的移动规则一，SN＝4对应的MPDU被接收端成功接收但不会被丢弃或者删除，并且该记分板窗口起始序列号(WinStart)的移动规则，并不要求发送端在发送BAR帧时需要确保其他链路上没有待传的MPDU的序列号小于该BAR帧中的SSN，更不需要修改现有的BAR帧，因此，在保持原有的BAR帧的结构上，极大程度节约了指示开销，并实现对多条链路的MPDU的正确接收。
图15仅为举例，应用本申请提供的记分板窗口起始序列号(WinStart)的移动规则，还可以解决诸如图9所示的问题，例如，发送端在Link2上发送的BAR携带的SSN_2＝32时，在Link1上发送的A-MPDU1中的SN为1～31的MPDUs，假设对应的SSN_1＝1,此时在接收端，将WinStart调整为两者中的最小值，即WinStart＝mini(SSN_1,SSN_2)＝mini(1，32)＝1,因此接下来在Link1上重传A-MPDU1中出错的MPDU时不会被接收端丢弃或删除。
实施本实施例二，接收端在接收到的BAR帧时，会根据该BAR帧携带的SSN和本地维护或存储的各链路的SSN中的最小值，对WinStart进行调整；从而避免对其他链路上待发送的MPDU(该MPDU的SN小于BAR帧携带的SSN)进行误操作。
实施例三
本实施例三将举例描述应用本申请提供的记分板窗口起始序列号(WinStart)的移动规则一的多链路传输技术方案。
如图17所示，假设记分板尺寸WinSize＝100,ADDBA请求/响应帧中SSN设置为0，接收端本地存储的SSN_1和SSN_2都初始化为0，假设链路1和链路2上都只采用块确认策略且之前发送端没有发送过BAR帧，而且没有发送过SN大于99的数据帧。
T0时刻，发送端在链路1上发送了一个SN＝103的数据帧，由于其落在了记分板窗口之外但位于序列号空间范围内的一半，所以接收端会将WinStart移动到4。由于SSN_1＝0,SSN_2＝0,SSN_1<WinStart,SSN_2<WinStart，则在接收端本地，更新SSN_1和SSN_2为WinStart，即SSN_1＝4,SSN_2＝4。
T1时刻，发送端在链路2上发送了一个SSN＝6的BAR帧，则接收端本地将SSN_2更新为SSN_2＝6,并将WinStart移动到min(SSN_1,SSN_2)＝min(4,6)＝4。
T2时刻，发送端在链路2上发送了一个SN＝98的数据帧，由于其落在了记分板窗口之内，接收端在序列号空间中，将其对应的偏移量(98)置为1，表示正确接收且不被删除或丢弃，接收端不移动WinStart。
T3时刻，发送端在链路1上发送了一个SSN＝10的BAR帧，接收端在本地将SSN_1更新为SSN_1＝10,并将WinStart移动到min(SSN_1,SSN_2)＝min(10,6)＝6。
T4时刻，发送端在链路1上发送了一个SN＝107的数据帧，由于其落在了记分板窗口之外但位于序列号空间范围内的一半，所以接收端会将WinStart移动到WinEnd-WinSize+1＝107-100+1＝8，以便能正确接收SN＝107的数据帧，并将其在序列号空间中对应的偏移量置为1。由于SSN_1＝10,SSN_2＝6,SSN_1>WinStart,SSN_2<WinStart，则接收端在本地，将SSN_2更新为WinStart，即SSN_2＝WinStart＝8；SSN_1＝10保持不变。
应理解，将SN＝107对应的偏移量置1和调整WinStart的操作，不分时间先后顺序。
实施本实施例三，接收端在接收到的BAR帧时，会根据该BAR帧携带的SSN和本地维护或存储的各链路SSN中的最小值，对WinStart进行调整；接收到某条链路发送的数据帧时，也可以根据数据帧对应的SN，对WinStart进行调整，并且适应性的调整本地存储的SSN的值。实施本实施例三，可以保证多条链路发送的数据帧都被正确接收并不会被误删除，提升了数据传输的效率。
实施例四
实施例四中，将描述本申请实现如图13所示的链路聚合传输技术方案中，记分板窗口起始序列号(WinStart)的移动规则二，以及在该WinStart移动规则二基础上，对多条链路上发送的MPDU的处理方式。
详见图18，仍然以发送端的多链路设备通过两条链路Link1和Link2向接收端发送MPDUs，且记分板窗口为WinStart＝4，WinSize＝100，WinEnd＝103为例。
首先ADDBA请求/响应帧中SSN设置为0，SSN_1和SSN_2都初始化为0，假设link1和link2上都只采用块确认策略且之前发送端没有发送过BAR帧，而且没有发送过SN大于99的MPDU(图18中示意为Data)。
T0时刻，发送端在Link1上向接收端发送的MPDU，其SN为103，满足数据帧的SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，则记分板右移以适应SN，且将记分板当前窗口起始序列号设置为WinStart＝SN-WinSize+1＝103-100+1＝4，同时在序列号空间(Sequence Number Space)中，在该SN对应的偏移量(即序列号为103)处，将对应的比特置1，表示SN＝103对应的MPDU被成功接收。
与实施例二应用移动规则一不同，本实施例四中，应用移动规则二，此时，接收端本地存储的SSN_1和SSN_2不进行更新，仍然为SSN_1＝0，SSN_2＝0。
T1时刻，发送端在Link2上发送BAR帧，其中携带的SSN＝6；接收端记两条链路对应的SSN的最小值为WinStart_x，即WinStart_x＝min(SSN_1,SSN_2)＝min(0,6)＝0。接收端将接收BAR帧前的WinStart_y(即T0时刻的WinStart)与WinStart_x比较，取其中最大值作为当前的WinStart，即WinStart＝max{WinStart_x，WinStart_y}＝max{0,4}＝4；
接收端将SSN_1＝0，SSN_2＝6,WinStart＝4存储在本地。
T2时刻，发送端在Link1上发送SN＝4的MPDU，满足WinStart＝SN<WinEnd，因此，在该SN对应的偏移量(即序列号为4)处，将对应的比特置1，表示SN＝4对应的MPDU被成功接收。
此时，接收端本地存储的仍然是SSN_1＝0，SSN_2＝6,WinStart＝4。
T3时刻，发送端在Link1上发送BAR，其中携带的SSN＝10；接收端记两条链路对应的SSN的最小值为WinStart_x，即WinStart_x＝min(SSN_1,SSN_2)＝min(10,6)＝6。接收端将接收BAR帧前的WinStart_y(即T2时刻的WinStart)与WinStart_x比较，取其中最大值作为当前的WinStart，即WinStart＝max{WinStart_x，WinStart_y}＝max{6,4}＝6；
接收端将SSN_1＝10，SSN_2＝6,WinStart＝6存储在本地。
T4时刻，发送端在Link 2上发送SN＝107的MPDU，其满足SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，记分板右移以适应SN，且将记分板当前窗口起始序列号设置为WinStart＝SN-WinSize+1＝107-100+1＝8；此时，SN＝107落在调整后的记分板窗口中，将其对应的比特置1。
接收端将SSN_1＝10，SSN_2＝6,WinStart＝8存储在本地。
相比较而言，相同场景下，如果利用现有技术提供的记分板的起始序列号(WinStart)的移动规则，如图16所示，在T1时刻，发送端在Link2上发送BAR帧，其中携带的SSN＝6；接收端将WinStart调整为该BAR对应的SSN，即WinStart＝SSN_2＝6。
在T2时刻，发送端在Link1上发送SN＝4的MPDU，由于SN＝4<WinStart,因此，该SN对应的MPDU即便是被接收端成功接收，也会被接收端丢弃或者删除。
在T3时刻，发送端在Link1上发送BAR，其中携带的SSN＝10；接收端将WinStart调整为调整为该BAR对应的SSN，即WinStart＝SSN_1＝10，对应的，WinEnd＝109。
在T4时刻，发送端在Link 2上发送SN＝107的MPDU，其满足SN落在当前的记分板窗口内，即WinStart<SN<WinEnd，将其对应的比特置1。
比较图18本申请提供的多链路传输方案和图16现有技术提供的多链路传输方案可知，利用本申请实施例提供的记分板窗口起始序列号(WinStart)的移动规则，SN＝4对应的MPDU被接收端成功接收但不会被丢弃或者删除，并且该记分板窗口起始序列号(WinStart)的移动规则，并不要求发送端在发送BAR帧时需要确保其他链路上没有待传的MPDU的序列号小于该BAR帧中的SSN，更不需要修改现有的BAR帧，因此，在保持原有的BAR帧的结构上，极大程度节约了指示开销，并实现对多条链路的MPDU的正确接收。
图18仅为举例，应用本申请提供的记分板窗口起始序列号(WinStart)的移动规则二，还可以解决诸如图9所示的问题，例如，发送端在Link2上发送的BAR携带的SSN_2＝32时，在Link1上发送的A-MPDU1中的SN为1～31的MPDUs，假设对应的SSN_1＝1,此时在接收端，将WinStart调整为两者中的最小值，即WinStart＝mini(SSN_1,SSN_2)＝mini(1，32)＝1,因此接下来在Link1上重传A-MPDU1中出错的MPDU时不会被接收端丢弃或删除。
实施本实施例四，接收端在接收到的BAR帧时，会根据该BAR帧携带的SSN和本地维护或存储的SSN中的最小值，以及接收BAR帧之前的WinStart，对WinStart进行调整；接收到某条链路发送的数据帧时，也可以根据数据帧对应的SN，对WinStart进行调整；从而避免对其他链路上待发送的MPDU(该MPDU的SSN小于BAR帧携带的SSN)进行误操作。
实施例五
本实施例五将举例描述应用本申请提供的记分板窗口起始序列号(WinStart)的移动规则二的多链路传输技术方案。
首先ADDBA请求/响应帧中SSN设置为0，SSN_1和SSN_2都初始化为0，假设link1和link2上都只采用块确认策略且之前发送端没有发送过BAR帧，而且没有发送过SN大于99的MPDU(图19中示意为Data)。
T0时刻，发送端在Link1上向接收端发送的MPDU，其SN为103，满足数据帧的SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，则记分板右移以适应SN，且将记分板当前窗口起始序列号设置为WinStart＝SN-WinSize+1＝103-100+1＝4，同时在序列号空间(Sequence Number Space)中，在该SN对应的偏移量(即序列号为103)处，将对应的比特置1，表示SN＝103对应的MPDU被成功接收。
与实施例三应用移动规则一不同，本实施例五中，应用移动规则二，此时，接收端本地存储的SSN_1和SSN_2不进行更新，仍然为SSN_1＝0，SSN_2＝0。
T1时刻，发送端在Link2上发送BAR帧，其中携带的SSN＝6；接收端记两条链路对应的SSN的最小值为WinStart_x，即WinStart_x＝min(SSN_1,SSN_2)＝min(0,6)＝0。接收端将接收BAR帧前的WinStart_y(即T0时刻的WinStart)与WinStart_x比较，取其中最大值作为当前的WinStart，即WinStart＝max{WinStart_x，WinStart_y}＝max{0,4}＝4；
接收端将SSN_1＝0，SSN_2＝6,WinStart＝4存储在本地。
T2时刻，发送端在Link1上发送SN＝98的MPDU，满足WinStart＝SN<WinEnd，因此，在该SN对应的偏移量(即序列号为98)处，将对应的比特置1，表示SN＝98对应的MPDU被成功接收。
此时，接收端本地存储的仍然是SSN_1＝0，SSN_2＝6,WinStart＝4。
T3时刻，发送端在Link1上发送BAR，其中携带的SSN＝10；接收端记两条链路对应的SSN的最小值为WinStart_x，即WinStart_x＝min(SSN_1,SSN_2)＝min(10,6)＝6。接收端将接收BAR帧前的WinStart_y(即T2时刻的WinStart)与WinStart_x比较，取其中最大值作为当前的WinStart，即WinStart＝max{WinStart_x，WinStart_y}＝max{6,4}＝6；
接收端将SSN_1＝10，SSN_2＝6,WinStart＝6存储在本地。
T4时刻，发送端在Link 2上发送SN＝107的MPDU，其满足SN落在当前的记分板窗口外，但位于序列窗口空间范围的一半内，即WinEnd<SN<WinStart+2^11，记分板右移以适应SN，且将记分板当前窗口起始序列号设置为WinStart＝SN-WinSize+1＝107-100+1＝8；此时，SN＝107落在调整后的记分板窗口中，将其对应的比特置1。
接收端将SSN_1＝10，SSN_2＝6,WinStart＝8存储在本地。
实施本实施例五，接收端在接收到的BAR帧时，会根据该BAR帧携带的SSN和本地维护或存储的SSN中的最小值，以及接收BAR帧之前的WinStart，对WinStart进行调整；接收到某条链路发送的数据帧时，也可以根据数据帧对应的SN，对WinStart进行调整。实施本实施例五，可以保证多条链路发送的数据帧都被正确接收并不会被误删除，提升了数据传输的效率。
应理解，上述如图13所示的方法实施例，以及实施例一～实施例五，在多链路聚合下，接收端可能同时收到多个帧，可以是数据帧(MPDU)，也可以是BAR帧，还可以同时包括数据帧和BAR帧，这时候接收端可以按照任意顺序一个一个处理。
综上所述，上述如图13所示的方法实施例，以及实施例一～实施例五，均不需要在BAR帧中针对每条链路增加一个本链路传输的MPDU的SN点阵图指示信息，节约了信令开销；与现有技术二和现有技术三相比，不需要对发送端发送的BAR帧中的SSN设置进行限制，不需要发送端多链路之间进行交互。
可选的，在上述实施例的基础上，本申请实施例还提出一种BAR发送规则，不要求多链路之间进行交互，也不对现有的BAR帧进行修改，而是在发送端在某条链路上发送BAR时，将其携带的SSN设置为该链路上即将发送的MAC协议数据单元(MAC Protocol dataunit，MPDU)的序列号，或者大于该链路发送的MPDU但被发送端删除或丢弃的MPDU的序列号。
简言之，本申请实施例针对发送端发送BAR规则如下：
每条聚合链路上发送的BAR中携带的SSN可以设置为该link上下一个要被发送的MPDU的序列号或者一个大于被丢弃MPDU的序列号的一个值。
如此，通过发送BAR来冲刷重排缓冲区，将超时重传的MSDU所代表的空洞给冲刷掉，这样后继的完整MSDU才不至于被无谓地挂起来以等待序列变得完整。在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘solid state disk(SSD))等。
以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种多链路聚合传输方法，应用于多链路聚合传输的接收端，其特征在于，包括：
接收端在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；
所述接收端在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
所述接收端根据所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值；
所述接收端根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
2.一种多链路设备，其作为多链路聚合传输的接收端，其特征在于，包括：
收发器，用于在与发送端之间的多条链路上接收数据帧和BAR帧中的至少一种；所述多条链路包括第一链路；
所述收发器，用于在所述第一链路上接收块确认请求BAR帧，所述BAR帧中携带所述第一链路对应的SSN_1；
处理器，用于根据所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN，调整当前的记分板窗口起始序列号WinStart；
所述处理器，还用于根据调整后的WinStart，对所述多链路上接收的数据帧进行处理。
3.如权利要求1所述的方法或权利要求2所述的设备，其特征在于，所述接收端根据所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值，包括：
接收端调整所述WinStart为SSN最小值；其中，SSN最小值为所述第一链路对应的SSN_1以及所述接收端本地存储的其他链路对应的SSN中最小的SSN。
4.如权利要求3所述的方法或设备，其特征在于，所述根据调整后的WinStart，对所述多链路上接收的数据帧进行处理，包括：
接收到某链路发送的数据帧，所述数据帧的序列号SN满足WinEnd<SN<WinStart+2^11，调整所述WinStart为WinStart＝SN-WinSize+1；
将所述多条链路对应的SSN中，小于调整后的WinStart的SSN，更新为与所述调整后的WinStart相同。
5.如权利要求1所述的方法或权利要求2所述的设备，其特征在于，所述接收端根据各链路对应的SSN，调整当前的记分板窗口起始序列号WinStart值，包括：
接收端调整所述WinStart为WinStart最大值；
其中，WinStart最大值为接收所述BAR之前的WinStart与接收所述BAR后的WinStart中最大的WinStart；其中，接收所述BAR后的WinStart为SSN最小值；所述SSN最小值为所述第一链路对应的SSN_1的SSN_1和所述接收端本地存储的其他链路对应的SSN中最小的SSN。
6.如权利要求5所述的方法或设备，其特征在于，所述根据调整后的WinStart，对所述多链路上接收的数据帧进行处理，包括：
接收到某条链路发送的数据帧，所述数据帧的序列号SN满足WinEnd<SN<WinStart+2^11，调整所述WinStart为WinStart＝SN-WinSize+1。
7.如权利要求4或6所述的方法或设备，其特征在于，所述SSN_1为所述第一链路下一个上被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号。
8.一种多链路聚合传输方法，应用于多链路聚合传输的发送端，其特征在于，包括：
发送端在与接收端之间的多条链路上发送数据帧；所述多条链路包括第一链路；
所述发送端在所述第一链路上发送块确认请求BAR帧；所述BAR帧中携带有与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被发送端丢弃的数据帧的序列号。
9.一种多链路设备，其作为多链路聚合传输的发送端，其特征在于，包括：
收发器，用于在与接收端之间的多条链路上发送数据帧；所述多条链路包括第一链路；
所述收发器，还用于在所述第一链路上发送块确认请求BAR帧；
所述处理器，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被所述发送端被丢弃的数据帧的序列号。
10.一种芯片系统，其特征在于，包括：至少一个处理器和接口；
所述接口，用于输入来自与发送端之间的多条链路上的数据帧；所述多条链路包括第一链路；
所述接口，还用于输入所述第一链路上接收到的块确认请求BAR帧；
所述处理器，用于解析所述BAR帧中携带的与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被丢弃的数据帧的序列号；
所述处理器，还用于对所述多链路上接收的数据帧进行处理。
11.一种芯片系统，其特征在于，包括至少一个处理器和接口；
所述接口，用于输出在与接收端之间的多条链路上发送的数据帧；所述多条链路包括第一链路；
所述接口，还用于输出在所述第一链路上发送的块确认请求BAR帧；
所述处理器，用于在所述BAR帧中携带与第一链路对应的起始序列号SSN_1；其中所述SSN_1为所述第一链路上下一个被发送的数据帧的序列号，或者所述SSN_1大于所述第一链路上被丢弃的数据帧的序列号。
12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质用于存储指令，当所述指令被执行时，使得如权利要求1,3～7,8中任一项所述的方法被实现。
CN202010355213.1A 2020-04-29 2020-04-29 一种多链路通信方法及相关装置 CN113573359B (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN202010355213.1A CN113573359B (zh) 2020-04-29 一种多链路通信方法及相关装置
PCT/CN2021/080316 WO2021218435A1 (zh) 2020-04-29 2021-03-11 一种多链路通信方法及相关装置
US17/971,843 US20230040554A1 (en) 2020-04-29 2022-10-24 Multi-link communication method and related apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202010355213.1A CN113573359B (zh) 2020-04-29 一种多链路通信方法及相关装置

Publications (2)

Publication Number Publication Date
CN113573359A true CN113573359A (zh) 2021-10-29
CN113573359B CN113573359B (zh) 2024-05-03

Family

ID=

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023071699A1 (zh) * 2021-10-30 2023-05-04 华为技术有限公司 组播业务的数据传输方法、通信装置及存储介质
WO2023130713A1 (zh) * 2022-01-10 2023-07-13 华为技术有限公司 多链路通信的方法和多链路设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090235066A1 (en) * 2008-03-17 2009-09-17 Henry Ptasinski Method and system for secure block acknowledgment (block ack) with protected mac sequence number
US20170006608A1 (en) * 2015-07-01 2017-01-05 Samsung Electronics Co., Ltd Methods to enable efficient wideband operations in local area networks using ofdma
CN106716901A (zh) * 2014-09-12 2017-05-24 三星电子株式会社 用于在无线通信系统中发射和接收确认的方法和设备
US20180034595A1 (en) * 2015-02-03 2018-02-01 Lg Electronics Inc. Method for transmitting and receiving policy indicator-based acknowledgement/non-acknowledgement signal in wireless lan system, and device therefor
CN110199549A (zh) * 2017-01-19 2019-09-03 高通股份有限公司 基于分组的链路聚合架构

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090235066A1 (en) * 2008-03-17 2009-09-17 Henry Ptasinski Method and system for secure block acknowledgment (block ack) with protected mac sequence number
CN106716901A (zh) * 2014-09-12 2017-05-24 三星电子株式会社 用于在无线通信系统中发射和接收确认的方法和设备
US20180034595A1 (en) * 2015-02-03 2018-02-01 Lg Electronics Inc. Method for transmitting and receiving policy indicator-based acknowledgement/non-acknowledgement signal in wireless lan system, and device therefor
US20170006608A1 (en) * 2015-07-01 2017-01-05 Samsung Electronics Co., Ltd Methods to enable efficient wideband operations in local area networks using ofdma
CN110199549A (zh) * 2017-01-19 2019-09-03 高通股份有限公司 基于分组的链路聚合架构

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023071699A1 (zh) * 2021-10-30 2023-05-04 华为技术有限公司 组播业务的数据传输方法、通信装置及存储介质
WO2023130713A1 (zh) * 2022-01-10 2023-07-13 华为技术有限公司 多链路通信的方法和多链路设备

Also Published As

Publication number Publication date
WO2021218435A1 (zh) 2021-11-04
US20230040554A1 (en) 2023-02-09

Similar Documents

Publication Publication Date Title
US11424862B2 (en) Data retransmission method and device, data response method and device, and storage medium
US8832515B2 (en) Block acknowledgement mechanism including sequence number acknowledgement and retry bit
US8897209B2 (en) Systems and methods for parallel communication with legacy WLAN receivers
US8413002B2 (en) Method of performing ARQ procedure for transmitting high rate data
US20220014311A1 (en) Communication devices and communication methods for multi-band traffic streams
US20160080115A1 (en) Methods for efficient acknowledgement in wireless systems
US9219569B2 (en) Method and apparatus for optimizing rate control based on packet aggregation considerations
JP7383161B2 (ja) データフレームの受信状況を決定するための方法および通信装置
CN117793790A (zh) 数据传输的方法和装置
US20130028189A1 (en) Method and apparatus for using physical layer error control to direct media access layer error control
WO2020210940A1 (zh) 无线局域网的通信方法、装置、终端及可读存储介质
US10932179B2 (en) Support of A-MSDU in A-MPDU
US20230040554A1 (en) Multi-link communication method and related apparatus
EP3790213B1 (en) Mac-based hybrid automatic repeat request (harq)
CN113573359B (zh) 一种多链路通信方法及相关装置
CN116963175A (zh) 数据传输方法、装置及系统
CN116097624A (zh) 数据传输方法、装置、计算机设备及存储介质
WO2023151250A1 (zh) 多链路通信方法及装置
US11362771B2 (en) Base station and automatic retransmission scheduling method thereof
US20220173872A1 (en) Apparatus and method for block acknowledgement within reduced duration
US20240098016A1 (en) Method for performing adaptive multi-link aggregation dispatching control in multi-link operation architecture, and associated apparatus
WO2023130713A1 (zh) 多链路通信的方法和多链路设备
CN117480810A (zh) 记分板状态更新方法、装置、设备及存储介质
TW202345652A (zh) 用於多鏈路設備網路的網路譯碼
TW202408300A (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