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