建立多链路汇聚数据包传输进程的方法及装置
阅读说明：本技术 建立多链路汇聚数据包传输进程的方法及装置 (Method and device for establishing multilink convergence data packet transmission process ) 是由 吴昊 谢芳 廖杨 于 2020-06-06 设计创作，主要内容包括：本申请公开了一种建立多链路汇聚数据包传输进程的方法及装置,该方法包括：消息发起方的第一逻辑实体发送ADDBA请求消息给消息响应方的第二逻辑实体,所述ADDBA请求消息包含参数STA-ML-BA Policy；消息发起方的第一逻辑实体接收消息响应方的第二逻辑实体发送的ADDBA响应消息,所述ADDBA响应消息包含参数AP-ML-BA Policy；如果ADDBA响应消息中的AP-ML-BA Policy指示同意使用多链路协同块确认策略,消息发起方的第一逻辑实体在发送数据包中指示消息响应方的第二逻辑实体需要反馈块确认消息,消息发起方的其他逻辑实体在发送数据包中指示消息响应方对等的逻辑实体不需要反馈块确认消息。本申请通过统一数据管理,降低了数据发送和接收管理的复杂度,并提高了网络吞吐率和效率。(The application discloses a method and a device for establishing a multilink convergence data packet transmission process, wherein the method comprises the following steps: a first logic entity of a message initiator sends an ADDBA request message to a second logic entity of a message responder, wherein the ADDBA request message comprises a parameter STA-ML-BA Policy; a first logic entity of a message initiator receives an ADDBA response message sent by a second logic entity of a message responder, wherein the ADDBA response message comprises a parameter AP-ML-BA Policy; if the AP-ML-BA Policy in the ADDBA response message indicates agreement to use the multi-link cooperative block acknowledgement Policy, the first logical entity of the message initiator indicates in the send data packet that the second logical entity of the message responder needs the feedback block acknowledgement message, and the other logical entities of the message initiator indicates in the send data packet that the peer logical entities of the message responder do not need the feedback block acknowledgement message. By unified data management, the complexity of data sending and receiving management is reduced, and the network throughput rate and efficiency are improved.)
技术领域
本申请涉及无线通信领域，尤其涉及一种建立多链路汇聚数据包传输进程的方法及装置。
背景技术
802.11be网络，也称为Extremely High Throughput(EHT)网络，通过一系列系统特性和多种机制增强功能以实现极高的吞吐量。随着无线局域网(WLAN)的使用持续增长，对于在许多环境(例如家庭，企业和热点)中提供无线数据服务越来越重要。特别是，视频流量将继续是许多WLAN部署中的主要流量类型。由于出现了4k和8k视频(20Gbps的未压缩速率)，这些应用的吞吐量要求正在不断发展。诸如虚拟现实或增强现实，游戏，远程办公室和云计算之类的新型高吞吐量，低延迟应用程序将会激增(例如，实时游戏的延迟低于5毫秒)。
鉴于这些应用程序的高吞吐量和严格的实时延迟要求，用户期望通过WLAN支持其应用程序时，吞吐量更高，可靠性更高，延迟和抖动更少，电源效率更高。用户期望改进与时敏网络(TSN)的集成，以支持异构以太网和无线LAN上的应用程序。802.11be网络旨在通过进一步提高总吞吐量和降低延迟来确保WLAN的竞争力，同时确保与旧版技术标准向后兼容和共存。在2.4GHz，5GHz和6GHz频段运行的802.11兼容设备。
在802.11be网络中，为实现上述的目标，提出了终端与接入点之间可以建立多条数据传输链路，通过多条链路同时传输，来提高传输速率。
发明内容
在802.11网络中，为了保障网络的可靠性，发送方每发送一个数据包，接收方都需要给发送方返回一个ACK消息，用于告诉发送方是否正确接收到该数据包。随着网络数据速率的提高，网络允许发送方发送多个数据包之后，接收方对这多个数据包进行反馈，这样针对多个数据包进行反馈的消息称为块确认(Block ACK，BA)消息。
在多链路的操作场景中，按照现有技术实施，每条链路上都需要反馈Block ACK，而实际上接收和发送的物理实体都分别只有一个，也就是数据包的分发主体只有一个，在多条链路上分别反馈ACK就需要将数据包严格的进行划分之后再分发到各条链路上进行发送，因为发送方需要根据接收方反馈的Block ACK来调整发送的数据包窗口，由此：
第一，增加了数据发送和接收管理的复杂度，在进行数据分发之前需要根据网络条件来进行数据分发，并需要使用多套数据包序列号来进行数据收发管理，不仅给数据发送方增加了复杂度，接收方在数据合并和重排序的操作上也增加了复杂度；
第二，在网络条件发送变化时，不能灵活调整数据收发方案，可能会导致某条链路上由于网络条件恶化而导致数据缓存较多，而必须遵守严格的数据分发策略，不能使用其他网络条件好的链路进行发送，降低了网络吞吐率和效率。
本申请提出一种在多链路场景下对数据包收发管理的方案，通过统一数据管理，解决上述问题。
第一方面，提供一种建立多链路汇聚数据包传输进程的方法，包括：消息发起方的第一逻辑实体发送添加块确认(ADDBA)请求消息给消息响应方的第二逻辑实体，所述ADDBA请求消息包含参数STA-ML-BA Policy，用于指示消息发起方是否请求使用多链路协同块确认策略；消息发起方的第一逻辑实体接收消息响应方的第二逻辑实体发送的ADDBA响应消息，所述ADDBA响应消息包含参数AP-ML-BA Policy，用于指示消息响应方是否同意使用多链路协同块确认策略；如果ADDBA响应消息中的AP-ML-BA Policy指示同意使用多链路协同块确认策略，消息发起方的第一逻辑实体在发送数据包中指示消息响应方的第二逻辑实体需要反馈块确认消息，消息发起方的其他逻辑实体在发送数据包中指示消息响应方对等的逻辑实体不需要反馈块确认消息。
可选地，还包括：消息发起方的多个逻辑实体分别发送汇聚数据包给消息响应方对等的逻辑实体；消息发起方的第一逻辑实体接收消息响应方的第二逻辑实体发送的块确认消息，所述块确认消息包括消息响应方其他逻辑实体的数据接收状态。
示例性地，消息发起方的第一逻辑实体采用显示块确认请求方式或隐式块确认请求方式指示消息响应方需要反馈块确认消息，所述显示块确认请求方式是指发送单独的块确认请求消息，所述隐式块确认请求方式是指在发送的数据包的控制字段中进行设置，指示请求块确认。
可选地，还包括：消息发起方的第一逻辑实体将块确认消息中的成功接收到的数据包或/和未成功接收到的数据包信息发送给消息发起方的数据包收发管理单元(PDU-TRMU)；消息发起方PDU-TRMU设置多条链路上下一个汇聚数据包的数据包，并分别将汇聚后的数据包发送给消息发起方的多个逻辑实体，或者分别将数据包信息发送给消息发起方的多个逻辑实体。
在一种可能的设计中，还包括：消息响应方的第二逻辑实体接收消息发起方的第一逻辑实体发送的ADDBA请求消息，并发送多链路协同块确认策略请求消息给消息响应方的数据包收发管理单元(PDU-TRMU)，所述多链路协同块确认策略请求消息包含ADDBA请求消息中的业务标识(TID)、消息发起方地址(TA)和STA-ML-BA Policy；消息响应方PDU-TRMU如果同意使用多链路协同块确认策略，发送包含TID、TA和AP-ML-BA Policy的消息给消息响应方的所有逻辑实体，其中，AP-ML-BA Policy设置为指示同意使用多链路协同块确认策略；消息响应方的所有逻辑实体将消息响应方PDU-TRMU发送的消息中的TID、TA和AP-ML-BAPolicy存储在本地；消息响应方的第二逻辑实体发送ADDBA响应消息给消息发起方的第一逻辑实体。
可选地，还包括：消息响应方的多个逻辑实体分别接收消息发起方的多个逻辑实体发送的汇聚数据包，如果本地的AP-ML-BA Policy指示同意使用多链路协同块确认策略，将汇聚数据包中的数据包信息发送给消息响应方的数据包收发管理单元(PDU-TRMU)；消息响应方PDU-TRMU统计消息响应方的多个逻辑实体成功接收到的数据包或/和未成功接收到的数据包，并将成功接收到的数据包或/和未成功接收到的数据包信息反馈给消息响应方的第二逻辑实体；消息响应方的第二逻辑实体根据消息响应方PDU-TRMU反馈的信息构建块确认消息的内容；消息响应方的第二逻辑实体发送块确认消息给消息发起方的第一逻辑实体。
在另一种可能的设计中，还包括：消息响应方的第二逻辑实体接收消息发起方的第一逻辑实体发送的ADDBA请求消息，如果消息响应方同意使用多链路协同块确认策略，消息响应方的第二逻辑实体发送包含ADDBA请求消息中的业务标识(TID)、消息发起方地址(TA)和STA-ML-BA Policy的消息给消息响应方的其他逻辑实体；消息响应方的其他逻辑实体将消息响应方第二逻辑实体发送的消息中的TID、TA和STA-ML-BA Policy存储在本地；消息响应方的第二逻辑实体发送ADDBA响应消息给消息发起方的第一逻辑实体。
可选地，还包括：消息响应方的多个逻辑实体分别接收消息发起方的多个逻辑实体发送的汇聚数据包，如果本地的STA-ML-BA Policy指示使用多链路协同块确认策略，消息响应方的其他逻辑实体将汇聚数据包中的数据包信息发送给消息响应方的第二逻辑实体；消息响应方的第二逻辑实体统计消息响应方的多个逻辑实体成功接收到的数据包或/和未成功接收到的数据包，并根据统计的信息构建块确认消息的内容；消息响应方的第二逻辑实体发送块确认消息给消息发起方的第一逻辑实体。
第二方面，提供一种建立多链路汇聚数据包传输进程的装置，包括分别操作在不同链路上的多个逻辑实体，当该装置作为消息发起方时，所述逻辑实体用于执行以下操作：第一逻辑实体发送添加块确认(ADDBA)请求消息，所述ADDBA请求消息包含参数STA-ML-BAPolicy，用于指示消息发起方是否请求使用多链路协同块确认策略；第一逻辑实体接收ADDBA响应消息，所述ADDBA响应消息包含参数AP-ML-BA Policy，用于指示消息响应方是否同意使用多链路协同块确认策略；如果ADDBA响应消息中的AP-ML-BA Policy指示同意使用多链路协同块确认策略，第一逻辑实体在发送数据包中指示消息响应方对等的逻辑实体需要反馈块确认消息，其他逻辑实体在发送数据包中指示消息响应方对等的逻辑实体不需要反馈块确认消息；
当该装置作为消息响应方时，所述逻辑实体用于执行以下操作：第二逻辑实体接收ADDBA请求消息；第二逻辑实体发送ADDBA响应消息。
可选地，当该装置作为消息发起方时，所述逻辑实体还用于执行以下操作：多个逻辑实体发送汇聚数据包；第一逻辑实体接收块确认消息，所述块确认消息包括消息响应方所有逻辑实体的数据接收状态。
在一种可能的设计中，该装置还包括数据包收发管理单元(PDU-TRMU)，当该装置作为消息发起方时，所述逻辑实体还用于执行以下操作：第一逻辑实体将块确认消息中的成功接收到的数据包或/和未成功接收到的数据包信息发送给PDU-TRMU；所述PDU-TRMU执行以下操作：设置多条链路上下一个汇聚数据包的数据包，并分别将汇聚后的数据包发送给多个逻辑实体，或者分别将数据包信息发送给多个逻辑实体；
当该装置作为消息响应方时，所述逻辑实体还用于执行以下操作：第二逻辑实体发送多链路协同块确认策略请求消息给PDU-TRMU，所述多链路协同块确认策略请求消息包含ADDBA请求消息中的业务标识(TID)、消息发起方地址(TA)和STA-ML-BA Policy；所有逻辑实体将PDU-TRMU发送的消息中的TID、TA和AP-ML-BA Policy存储在本地；所述PDU-TRMU执行以下操作：PDU-TRMU如果同意使用多链路协同块确认策略，发送包含TID、TA和AP-ML-BA Policy的消息给所有逻辑实体，其中，AP-ML-BA Policy设置为指示同意使用多链路协同块确认策略。
可选地，当该装置作为消息响应方时，所述逻辑实体还用于执行以下操作：多个逻辑实体接收汇聚数据包；如果本地的AP-ML-BA Policy指示同意使用多链路协同块确认策略，多个逻辑实体将汇聚数据包中的数据包信息发送给PDU-TRMU；第二逻辑实体根据PDU-TRMU反馈的信息构建块确认消息的内容，并发送块确认消息；所述PDU-TRMU还用于执行以下操作：统计成功接收到的数据包或/和未成功接收到的数据包，并将成功接收到的数据包或/和未成功接收到的数据包信息反馈给第二逻辑实体。
在另一种可能的设计中，当该装置作为消息响应方时，所述逻辑实体还用于执行以下操作：如果消息响应方同意使用多链路协同块确认策略，第二逻辑实体发送包含ADDBA请求消息中的业务标识(TID)、消息发起方地址(TA)和STA-ML-BA Policy的消息给其他逻辑实体；其他逻辑实体将第二逻辑实体发送的消息中的TID、TA和STA-ML-BA Policy存储在本地。
可选地，当该装置作为消息响应方时，所述逻辑实体还用于执行以下操作：多个逻辑实体接收汇聚数据包；如果本地的STA-ML-BA Policy指示使用多链路协同块确认策略，其他逻辑实体将汇聚数据包中的数据包信息发送给第二逻辑实体；第二逻辑实体统计多个逻辑实体成功接收到的数据包或/和未成功接收到的数据包，根据统计的信息构建块确认消息的内容，并发送块确认消息。
本申请在主链路上发送ADDBA请求消息和ADDBA响应消息，在ADDBA请求消息和ADDBA响应消息中添加参数ML-BA Policy来指示是否请求和是否同意使用多链路协同块确认策略，如果使用多链路协同块确认策略，则只在主链路上发送BAR消息和BA消息，BA消息中包括其他链路上的数据接收状态，通过引入协调收发数据包的PDU-TRMU逻辑单元或引入在多链路设备内部的逻辑实体之间的交互接口，同步接收到的数据包的信息(消息响应方)，以及BA中对成功接收到的数据包或/和未成功接收到的数据包的信息(消息发起方)，实现统一数据管理，降低了数据发送和接收管理的复杂度，并提高了网络吞吐率和效率。
附图说明
本申请将通过实施例并参照附图的方式说明，其中：
图1为本申请一个实施例的建立多链路汇聚数据包传输进程的方法示意图；
图2为本申请另一个实施例的建立多链路汇聚数据包传输进程的方法示意图；
图3为本申请又一个实施例的建立多链路汇聚数据包传输进程的方法示意图；
图4为本申请又一个实施例的建立多链路汇聚数据包传输进程的方法示意图。
具体实施方式
下面将结合附图，对本申请中的技术方案进行描述。
在本申请实施例中，“示例地”、“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。
除非另外定义，本申请使用的技术术语或者科学术语应当为本申请所属领域内具有一般技能的人士所理解的通常意义。本申请中使用的“第一”、“第二”以及类似的词语并不表示任何顺序、数量或者重要性，而是仅用于区分描述。“包括”或者“包含”等类似的词语意指出现该词前面的元件或者物件涵盖出现在该词后面列举的元件或者物件及其等同，而不排除其他元件或者物件。术语“和/或”包括一个或多个相关联的所列项目的任何和所有组合。
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合具体实施例，对本申请进行进一步详细的说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
在本申请中，我们把发起数据传输的多链路设备(Multi-link Device，MLD)称为消息发起方，把响应数据传输的MLD称为消息响应方。在以下各实施例中，为了使方案更加清晰明了，本申请仅以两条链路作为示例进行说明，但是本申请构思不限于此，并且同样适用于多于两条链路的情况。
在以下实施例中，MLD1是消息发起方，STA1和STA2是MLD1内分别操作在链路1和链路2上的逻辑实体，MLD2是消息响应方，STA3和STA4是MLD2内分别操作在链路1和链路2上的逻辑实体。
多链路协同块确认策略：在本申请中定义为通过协调，消息响应方只在一条链路上发送BA，并且BA包括其他链路上的数据接收状态。
本申请的建立多链路汇聚数据包传输进程的方法，消息发起方只在主链路上发送ADDBA请求消息，通过在ADDBA请求消息中添加参数ML-BA Policy来指示是否请求使用多链路协同块确认策略，如果消息响应方同意使用多链路协同块确认策略，则只在主链路上指示消息响应方需要反馈块确认消息。该方法包括：
消息发起方的第一逻辑实体发送添加块确认(ADDBA)请求消息给消息响应方的第二逻辑实体，所述ADDBA请求消息包含参数STA-ML-BA Policy，用于指示消息发起方是否请求使用多链路协同块确认策略；消息发起方的第一逻辑实体接收消息响应方的第二逻辑实体发送的ADDBA响应消息，所述ADDBA响应消息包含参数AP-ML-BA Policy，用于指示消息响应方是否同意使用多链路协同块确认策略；如果ADDBA响应消息中的AP-ML-BA Policy指示同意使用多链路协同块确认策略，消息发起方的第一逻辑实体在发送数据包中指示消息响应方的第二逻辑实体需要反馈块确认消息，消息发起方的其他逻辑实体在发送数据包中指示消息响应方对等的逻辑实体不需要反馈块确认消息。其中，如果消息发起方的某一逻辑实体与消息响应方的某一逻辑实体是在同一条链路上发送和接收数据，那么这两个逻辑实体就是对等的，如：STA1通过链路1发送数据给STA3，STA2通过链路2发送数据给STA4，STA3通过链路1反馈数据给STA1，STA4通过链路2反馈数据给STA2，那么STA1和STA3是对等的，STA2和STA4是对等的。
在一些实施例中，消息发起方和消息响应方均可以包括数据包收发管理单元(PDU-TRMU)，PDU-TRMU可以是消息发起方和消息响应方的内部逻辑单元，也可以是消息发起方和消息响应方的外部逻辑单元。消息响应方会将接收到的ADDBA请求消息及汇聚数据包中的相应信息发送给其PDU-TRMU，消息响应方PDU-TRMU确定ADDBA响应消息中参数ML-BAPolicy的设置，并统计消息响应方在所有链路上的数据包接收状态。消息发起方会将接收到的BA消息中的相应信息发送给其PDU-TRMU，消息发起方PDU-TRMU设置多条链路上下一个汇聚数据包的数据包。或者，引入在多链路设备内部的逻辑实体之间的交互接口，同步接收到的数据包的信息(消息响应方)，以及BA中对成功接收到的数据包或/和未成功接收到的数据包的信息(消息发起方)。
本申请对主链路的选择方法不做限制，本申请的发明构思不在于此。示例性地，主链路可通过在交互的信息中包含相应参数进行设置，如：消息响应方在反馈连接响应消息或重连接响应消息中包含参数Primary Link来指示多链路操作中的主链路，消息发起方也可以在连接请求消息或重连接请求消息中包含参数Primary Link来指示其期望使用的主链路。
图1为本申请一个实施例的建立多链路汇聚数据包传输进程的方法示意图。在该实施例中，消息发起方采用显示块确认请求方式指示消息响应方需要反馈块确认消息，即发送单独的BAR消息给消息响应方。建立多链路汇聚数据包传输进程的方法包括：
1.STA1发送ADDBA请求(request)消息给STA3，示例地，消息中包含：
TID：业务标识，用于标识当前发送数据所属的业务；
ML-BA Policy：用于指示消息发起方是否请求使用多链路协同块确认策略，如：
“0”：表示不使用多链路协同块确认策略；
“1”：表示使用多链路协同块确认策略；
本申请示例实施例中设置为“1”；
TA：消息发起方地址，可用于标识一个发送数据的MLD。
2.STA3发送ACK消息给STA1，指示STA3已经接收到STA1发送的ADDBA request消息。
3.STA3发送多链路协同块确认策略请求消息给PDU-TRMU，示例地，消息中包含：
TID：业务标识；
ML-BA Policy：用于指示消息发起方是否请求使用多链路协同块确认策略；
TA：消息发起方地址。
4.PDU-TRMU如果同意使用多链路协同块确认策略，发送消息给所有STA，本申请实施例中为STA3和STA4，消息中包含TID、TA和ML-BA Policy，ML-BA Policy的值设置为“1”，即使用多链路协同块确认策略。PDU-TRMU如果不同意使用多链路协同块确认策略，可以发送消息给所有STA，也可以不发送消息给所有STA，若发送消息，则ML-BA Policy的值设置为“0”，即不使用多链路协同块确认策略，若不发送消息，则默认为不使用多链路协同块确认策略，本申请对此不做限制。
5.STA3和STA4将TID、TA和ML-BA Policy存储在本地。
6.STA3发送ADDBA response给STA1，示例地，消息中包含：
ML-BA Policy：用于指示消息响应方是否同意使用多链路协同块确认策略，如：
“0”：表示不使用多链路协同块确认策略；
“1”：表示使用多链路协同块确认策略；
本申请示例实施例中设置为“1”。
7.STA1发送ACK消息给STA3，指示STA1已经接收到STA3发送的ADDBA response消息。
8.STA1和STA2分别在链路1和链路2上发送汇聚数据包到STA3和STA4，数据包中包含TID和TA。
9.数据包发送完后，STA1发送BA request消息给STA3。
10.STA3和STA4在接收到汇聚的数据包以后，示例地，如果接收到的数据包中的TA和TID对应的ML-BA Policy指示为“1”，则将汇聚数据包中的数据包信息发送给PDU-TRMU。
11.PDU-TRMU统计STA3和STA4中的成功接收到的数据包，或/和未成功接收到的数据包，并将成功接收到的数据包，或/和未成功接收到的数据包信息反馈给STA3。
12.STA3根据PDU-TRMU反馈的信息构建BA消息的内容。
13.STA3发送BA消息给STA1。
14.STA1将BA消息中的成功接收到的数据包，或/和未成功接收到的数据包信息发送给PDU-TRMU；
15.PDU-TRMU设置链路1和链路2上下一个汇聚数据包的数据包，并分别将汇聚后的数据包发送给STA1和STA2，或者分别将数据包信息发送给STA1和STA2。
16.STA1和STA2根据数据包信息发送相应的汇聚数据包。
图2为本申请另一个实施例的建立多链路汇聚数据包传输进程的方法示意图。在该实施例中，消息发起方同样采用显示块确认请求方式指示消息响应方需要反馈块确认消息，但是MLD不包含PDU-TRMU，通过引入在MLD内部的逻辑实体之间的交互接口，同步接收到的数据包的信息(消息响应方)，以及BA中对成功接收到的数据包或/和未成功接收到的数据包的信息(消息发起方)。建立多链路汇聚数据包传输进程的方法包括：
1.STA1发送ADDBA request消息给STA3，示例地，消息中包含：
TID：业务标识，用于标识当前发送数据所属的业务；
ML-BA Policy：用于指示消息发起方是否请求使用多链路协同块确认策略，如：
“0”：表示不使用多链路协同块确认策略；
“1”：表示使用多链路协同块确认策略；
本发明示例实施例中设置为“1”；
TA：消息发起方地址，可用于标识一个发送数据的MLD。
2.STA3发送ACK消息给STA1，指示STA3已经接收到STA1发送的ADDBA request消息。
3.如果消息响应方同意使用多链路协同块确认策略，STA3给STA4发送消息，消息中包含：
TID：业务标识；
ML-BA Policy：用于指示消息发起方是否请求使用多链路协同块确认策略；
TA：消息发起方地址。
4.STA4将TID、TA和ML-BA Policy存储在本地。
5.STA3发送ADDBA response给STA1，示例地，消息中包含：
ML-BA Policy：用于指示消息响应方是否同意使用多链路协同块确认策略，如：
“0”：表示不使用多链路协同块确认策略；
“1”：表示使用多链路协同块确认策略；
本申请示例实施例中设置为“1”。
6.STA1发送ACK消息给STA3，指示STA1已经接收到STA3发送的ADDBA response消息。
7.STA1和STA2分别在链路1和链路2上发送汇聚数据包到STA3和STA4，数据包中包含TID和TA。
8.数据包发送完后，STA1发送BA request消息给STA3。
9.STA3和STA4在接收到汇聚的数据包以后，示例地，如果接收到的数据包中的TA和TID对应的ML-BA Policy指示为“1”，STA4将汇聚数据包中的数据包信息发送给STA3。
10.STA3统计STA3和STA4中的成功接收到的数据包，或/和未成功接收到的数据包。
11.STA3根据统计的信息构建BA消息的内容。
12.STA3发送BA消息给STA1。
图3为本申请又一个实施例的建立多链路汇聚数据包传输进程的方法示意图。在该实施例中，消息发起方采用隐式块确认请求方式指示消息响应方需要反馈块确认消息，即在发送的数据包的控制字段中进行设置，指示请求块确认。例如，在数据包的QoScontrol field中，将ACK policy字段设置为“00”，表示需要消息响应方发送BA消息。该实施例的其余部分与图1所示的实施例相同，这里不再赘述。
图4为本申请又一个实施例的建立多链路汇聚数据包传输进程的方法示意图。在该实施例中，消息发起方采用隐式块确认请求方式指示消息响应方需要反馈块确认消息，即在发送的数据包的控制字段中进行设置，指示请求块确认。例如，在数据包的QoScontrol field中，将ACK policy字段设置为“00”，表示需要消息响应方发送BA消息。该实施例的其余部分与图2所示的实施例相同，这里不再赘述。
本申请实施例还提供一种建立多链路汇聚数据包传输进程的装置，该装置可以作为消息发起方，也可以作为消息响应方，包括分别操作在不同链路上的多个逻辑实体(STA)，在一些实施例中，该装置还可以包括数据包收发管理单元(PDU-TRMU)。
本实施例提供的建立多链路汇聚数据包传输进程的装置用于实现图1或图2或图3或图4所示实施例的建立多链路汇聚数据包传输进程的方法，本实施例提供的建立多链路汇聚数据包传输进程的装置实现原理和技术效果类似，此处不再赘述。
应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，部分或全部步骤可以并行执行或先后执行，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，网络设备或者终端设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM)磁碟或者光盘等各种可以存储程序代码的介质。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
取决于语境，如在此所使用的词语“如果”或“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关硬件来完成，所述的程序可以存储于一个设备的可读存储介质中，该程序在执行时，包括上述全部或部分步骤，所述的存储介质，如：FLASH、EEPROM等。
以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。
- 上一篇：一种医用注射器针头装配设备
- 下一篇：基于DPDK的新型多路径传输方案