[0035] 下面将结合附图，对本申请中的技术方案进行描述。
[0036] 在本申请实施例中，“示例地”、“例如”等词用于表示作例子、例证或说明。本申请中被描述为“示例”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用示例的一词旨在以具体方式呈现概念。
[0037] 为了使本申请的目的、技术方案及优点更加清楚明白，以下结合具体实施例，对本申请进行进一步详细的说明。应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
[0038] 在本申请中，我们把发起数据传输的多链路设备(Multi‑link Device，MLD)称为消息发起方，把响应数据传输的MLD称为消息响应方。在以下各实施例中，为了使方案更加清晰明了，本申请仅以两条链路作为示例进行说明，但是本申请构思不限于此，并且同样适用于多于两条链路的情况。
[0039] 在以下实施例中，MLD1是消息发起方，STA1和STA2是MLD1内分别操作在链路1和链路2上的逻辑实体，MLD2是消息响应方，STA3和STA4是MLD2内分别操作在链路1和链路2上的逻辑实体。
[0040] 多链路协同块确认策略：当有多条链路收发数据场景下，需要将不同链路上的数据包接收状态进行整合，然后在一条链路或者多条链路上发送BA消息，该BA消息包括所有链路上的数据包接收状态。
[0041] 本申请的对多链路接收数据响应的方法包括：消息发起方分别在多条链路上发送添加块确认(ADDBA)请求消息给消息响应方；消息发起方分别从多条链路上接收消息响应方发送的ADDBA响应消息，所述ADDBA响应消息包含参数ML‑BA Policy，用于指示消息响应方同意多链路协同块确认策略的使用方式；消息发起方分别在多条链路上发送汇聚数据包给消息响应方。
[0042] 在一些实施例中，上述方法还包括消息发起方根据ADDBA响应消息中的参数ML‑BA Policy在一条或多条链路上发送BA请求(BAR)消息给消息响应方法，消息响应方在一条或多条链路上发送BA消息给消息发起方。
[0043] 在一些实施例中，消息发起方和消息响应方均可以包括数据包收发管理单元(PDU‑TRMU)，PDU‑TRMU可以是消息发起方和消息响应方的内部逻辑单元，也可以是消息发起方和消息响应方的外部逻辑单元。消息响应方会将接收到的ADDBA请求消息及汇聚数据包中的相应信息发送给其PDU‑TRMU，消息响应方PDU‑TRMU确定多链路协同块确认策略执行表来确定多链路协同块确认策略的具体使用方式，指示ADDBA响应消息中参数ML‑BA Policy的设置，并统计消息响应方在所有链路上的数据包接收状态。消息发起方会将接收到的BA消息中的相应信息发送给其PDU‑TRMU，消息发起方PDU‑TRMU设置多条链路上下一个汇聚数据包的数据包。
[0044] 图1为本申请一个实施例的对多链路接收数据响应的方法示意图。在该实施例中，消息发起方采用显示块确认请求方式发送BAR消息给消息响应方，即消息发起方发送单独的BAR消息数据包给消息响应方。对多链路接收数据响应的方法包括：
[0045] 1.STA1发送ADDBA请求(request)消息给STA3，消息中包含：
[0046] TID：业务标识，用于标识当前发送数据所属的业务；
[0047] TA：用于指示消息发起方的地址。
[0048] 在一些实施例中，ADDBA request消息中还可以包含参数ML‑BA Policy，用于指示消息发起方请求多链路协同块确认策略的使用方式。示例地，参数ML‑BA Policy可以设置为：
[0049] “0”：表示不使用多链路协同块确认策略；
[0050] “1”：表示使用多链路协同块确认策略，并且该链路传输多链路协同块确认策略消息；
[0051] “2”：表示使用多链路协同块确认策略，并且该链路不传输多链路协同块确认策略消息。
[0052] 2.STA3发送ACK消息给STA1，指示STA3已经接收到STA1发送的ADDBA request消息。
[0053] 3.STA2发送ADDBA request消息给STA4，消息中包含：
[0054] TID：业务标识，用于标识当前发送数据所属的业务；
[0055] TA：用于指示消息发起方的地址。
[0056] 在一些实施例中，ADDBA request消息中还可以包含参数ML‑BA Policy，用于指示消息发起方请求多链路协同块确认策略的使用方式。示例地，参数值的设置与步骤1中相同。
[0057] 4.STA4发送ACK消息给STA2，指示STA4已经接收到STA2发送的ADDBA request消息。
[0058] 5.STA3发送ADDBA响应(response)消息给STA1，消息中包含：
[0059] ML‑BA Policy：用于指示消息响应方同意多链路协同块确认策略的使用方式。
[0060] 示例地，参数ML‑BA Policy可以设置为：
[0061] “0”：表示不使用多链路协同块确认策略；
[0062] “1”：表示使用多链路协同块确认策略，并且该链路传输多链路协同块确认策略消息；
[0063] “2”：表示使用多链路协同块确认策略，并且该链路不传输多链路协同块确认策略消息。
[0064] 6.STA1发送ACK消息给STA3，指示STA1已经接收到STA3发送的ADDBA response消息。
[0065] 7.STA4发送ADDBA response消息给STA2，消息中包含：
[0066] ML‑BA Policy：用于指示消息响应方同意多链路协同块确认策略的使用方式。示例地，参数值的设置与步骤5中相同。
[0067] 8.STA2发送ACK消息给STA4，指示STA2已经接收到STA4发送的ADDBA response消息。
[0068] 9.STA1和STA2分别在链路1和链路2上发送汇聚数据包到STA3和STA4。可选地，在发送数据中可以保持两条链路上数据包发送的结束时间相同。
[0069] 10.当前两条链路数据包发送完毕后，STA1和STA2根据接收到的ADDBA response消息中的ML‑BA Policy参数决定是否发送BA request消息。示例地，
[0070] 如果STA1接收到的ADDBA response消息中ML‑BA Policy为“1”，则发送BA request消息给STA3；如果ML‑BA Policy为“2”，则不发送BA request消息给STA3；
[0071] 如果STA2接收到的ADDBA response消息中ML‑BA Policy为“1”，则发送BA request消息给STA4；如果ML‑BA Policy为“2”，则不发送BA request消息给STA4。
[0072] 在一些实施例中，MLD1和MLD2还可以包括数据包收发管理单元(PDU‑TRMU)，PDU‑TRMU可以是包含在MLD1和MLD2内部的逻辑单元，也可以是独立于MLD1和MLD2的其他装置，本申请实施例中，PDU‑TRMU是包含在MLD1和MLD2内部的逻辑单元，如图1所示。MLD1和MLD2包括PDU‑TRMU时，对多链路接收数据响应的方法包括：
[0073] 1.STA1发送ADDBA请求(request)消息给STA3，消息中包含：
[0074] TID：业务标识，用于标识当前发送数据所属的业务；
[0075] TA：用于指示消息发起方的地址。
[0076] 在一些实施例中，ADDBA request消息中还可以包含参数ML‑BA Policy，用于指示消息发起方请求多链路协同块确认策略的使用方式。示例地，参数ML‑BA Policy可以设置为：
[0077] “0”：表示不使用多链路协同块确认策略；
[0078] “1”：表示使用多链路协同块确认策略，并且该链路传输多链路协同块确认策略消息；
[0079] “2”：表示使用多链路协同块确认策略，并且该链路不传输多链路协同块确认策略消息。
[0080] 2.STA3发送ACK消息给STA1，指示STA3已经接收到STA1发送的ADDBA request消息。
[0081] 3.STA2发送ADDBA request消息给STA4，消息中包含：
[0082] TID：业务标识，用于标识当前发送数据所属的业务；
[0083] TA：用于指示消息发起方的地址。
[0084] 在一些实施例中，ADDBA request消息中还可以包含参数ML‑BA Policy，用于指示消息发起方请求多链路协同块确认策略的使用方式。示例地，参数值的设置与步骤1中相同。
[0085] 4.STA4发送ACK消息给STA2，指示STA4已经接收到STA2发送的ADDBA request消息。
[0086] 5.STA3和STA4将各自接收到的ADDBA request消息中的参数信息发送给MLD2的PDU‑TRMU。示例地，STA3和STA4将各自接收到的ADDBA request消息中的TID和TA发送给MLD2的PDU‑TRMU，如果ADDBA request消息中还包括参数ML‑BA Policy，STA3和STA4还会将ML‑BA Policy与TID和TA一起进行发送。
[0087] 6.消息响应方PDU‑TRMU确定多链路协同块确认策略执行表。
[0088] 示例地，PDU‑TRMU可以是根据本地的能力或策略决定，或者根据STA3和STA4提供的消息发起方的ADDBA request中的参数决定，比如，ADDBA request中TID是否相同，或ADDBA request中是否指示需要使用多链路协同块确认策略等，本申请不做限制。示例地，多链路协同块确认策略执行表的设置如表1所示。
[0089] 表1
[0090]
[0091]
[0092] 或，当TID是唯一的分配给一个消息发起方，则TID也可以标识消息发起方，也可以不需要TA信息，此时，多链路协同块确认策略执行表的设置如表2所示。
[0093] 表2
[0094]
[0095] 7.消息响应方PDU‑TRMU根据多链路协同块确认策略执行表发送消息给消息响应方STA。示例地，具体如下：
[0096] 如果ML‑BA enable为“1”，向ML‑BA STA list中的STA发送消息，指示其在回复消息发起方的ADDBA response消息中将ML‑BA Policy设置为“1”，向不在ML‑BA STA list中的STA发送消息，指示其在回复消息发起方的ADDBA response消息中将ML‑BA Policy设置为“2”。
[0097] 8.STA3发送ADDBA响应(response)消息给STA1，消息中包含：
[0098] ML‑BA Policy：用于指示消息响应方同意多链路协同块确认策略的使用方式。示例地，如果接收到了PDU‑TRMU消息中对该参数的设置，则按照PDU‑TRMU发送的消息进行设置，否则设置为“0”。
[0099] 9.STA1发送ACK消息给STA3，指示STA1已经接收到STA3发送的ADDBA response消息。
[0100] 10.STA4发送ADDBA response消息给STA2，消息中包含：
[0101] ML‑BA Policy：用于指示消息响应方同意多链路协同块确认策略的使用方式。示例地，如果接收到了PDU‑TRMU消息中对该参数的设置，则按照PDU‑TRMU发送的消息进行设置，否则设置为“0”。
[0102] 11.STA2发送ACK消息给STA4，指示STA2已经接收到STA4发送的ADDBA response消息。
[0103] 12.STA1和STA2分别在链路1和链路2上发送汇聚数据包到STA3和STA4。可选地，在发送数据中可以保持两条链路上数据包发送的结束时间相同。
[0104] 13.当前两条链路数据包发送完毕后，STA1和STA2根据接收到的ADDBA response消息中的ML‑BA Policy参数决定是否发送BA request消息。示例地，
[0105] 如果STA1接收到的ADDBA response消息中ML‑BA Policy为“1”，则发送BA request消息给STA3；如果ML‑BA Policy为“2”，则不发送BA request消息给STA3；
[0106] 如果STA2接收到的ADDBA response消息中ML‑BA Policy为“1”，则发送BA request消息给STA4；如果ML‑BA Policy为“2”，则不发送BA request消息给STA4。
[0107] 14.STA3和STA4在接收到汇聚的数据包以后，将汇聚数据包中的数据包编号和TID发送给MLD2的PDU‑TRMU。
[0108] 15.MLD2的PDU‑TRMU统计STA3和STA4中的成功接收到的数据包，或/和未成功接收到的数据包，根据TID或/和TA查询本地信息，如果对应的ML‑BA enable指示使用多链路协同块确认策略，则将成功接收到的数据包，或/和未成功接收到的数据包信息反馈给ML‑BA STA list中的STA；
[0109] 16.ML‑BA STA list中的STA发送BA消息给消息发起方中对应的STA。
[0110] 例如：
[0111] 如果ML‑BA STA list中为“STA3”，则STA3发送BA消息给STA1；
[0112] 如果ML‑BA STA list中为“STA4”，则STA4发送BA消息给STA2；
[0113] 如果ML‑BA STA list中为“STA3，STA4”，则STA3发送BA消息给STA1，和STA4发送BA消息给STA2。
[0114] 17.STA1或/和STA2将BA消息中的成功接收到的数据包，或/和未成功接收到的数据包信息发送给消息发起方PDU‑TRMU；
[0115] 18.消息发起方PDU‑TRMU设置链路1和链路2上下一个汇聚数据包的数据包，并分别将汇聚后的数据包发送给STA1和STA2，或者分别将数据包信息发送给STA1和STA2。
[0116] 19.STA1和STA2根据接收到的信息发送相应的汇聚数据包。
[0117] 图2为本申请另一个实施例的对多链路接收数据响应的方法示意图。在该实施例中，消息发起方采用隐示块确认请求方式发送BAR消息给消息响应方，即消息发起方在发送的数据包中包含隐式BAR消息给消息响应方。例如，在数据包的QoS control field中，将ACK policy字段设置为“00”，表示需要消息响应方发送BA消息。该实施例的其余部分与图1所示的实施例相同，这里不再赘述。
[0118] 本申请实施例还提供一种对多链路接收数据响应的装置，该装置可以作为消息发起方，也可以作为消息响应方，包括分别操作在不同链路上的多个逻辑实体(STA)，在一些实施例中，该装置还可以包括数据包收发管理单元(PDU‑TRMU)。
[0119] 本实施例提供的对多链路接收数据响应的装置用于实现图1或图2所示实施例的对多链路接收数据响应的方法，本实施例提供的对多链路接收数据响应的装置实现原理和技术效果类似，此处不再赘述。
[0120] 应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，部分或全部步骤可以并行执行或先后执行，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。
[0121] 本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
[0122] 所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0123] 在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
[0124] 所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
[0125] 另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。
[0126] 所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，网络设备或者终端设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、ROM、RAM)磁碟或者光盘等各种可以存储程序代码的介质。
[0127] 在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
[0128] 取决于语境，如在此所使用的词语“如果”或“若”可以被解释成为“在……时”或“当……时”或“响应于确定”或“响应于检测”。类似地，取决于语境，短语“如果确定”或“如果检测(陈述的条件或事件)”可以被解释成为“当确定时”或“响应于确定”或“当检测(陈述的条件或事件)时”或“响应于检测(陈述的条件或事件)”。
[0129] 本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关硬件来完成，所述的程序可以存储于一个设备的可读存储介质中，该程序在执行时，包括上述全部或部分步骤，所述的存储介质，如：FLASH、EEPROM等。
[0130] 以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。
