协作通信方法、装置及系统与流程

文档序号:23553017发布日期:2021-01-05 21:13阅读:196来源:国知局
协作通信方法、装置及系统与流程

本申请涉及通信技术领域,尤其涉及协作通信方法、装置及系统。



背景技术:

多基本服务集合(basicserviceset,bss)中多链路并发传输称之为接入点(accesspoint,ap)协作。图1为现有的上行(uplink,ul)数据传输的ap协作流程示意图。其中,主ap(masterap)通过竞争接入信道之后,向协作ap(slaveap)发送公告(announcement)帧。协作ap在接收到announcement帧之后和主ap分别发送触发(trigger)帧发送。其中,主ap向其关联的站点(station,sta)1发送trigger帧1(以下简称trigger1),trigger1用于触发sta1发送基于触发帧的(triggerbased,tb)物理层协议数据单元(physicalprotocoldataunit,ppdu)1;协作ap向其关联站点sta2发送trigger帧2(以下简称trigger2),trigger2用于触发sta2发送tbppdu2,trigger1和trigger2同时传输结束。trigger1和trigger2传输结束短帧间距(shortinter-framespace,sifs)时间之后,sta1向主ap发送tbppdu1,sta2向slaveap发送tbppdu2,tbppdu1和tbppdu2同时结束。tbppdu1和tbppdu2传输结束sifs时间之后,主ap向其关联的sta1发送块确认(blockacknowledgement,ba1),协作ap向其关联的sta2发送ba2。

然而,图1中的主ap发送公告announcement帧给协作ap时,协作ap关联的sta2可能会被设置基本(basic)网络分配矢量(networkallocationvector,nav),从而可能无法向协作ap发送tbppdu2,进而导致协作流程无法进行。



技术实现要素:

本申请实施例提供协作通信方法、装置及系统,用于解决现有技术中主ap发送公告帧给协作ap时,协作ap关联的第二站点可能会被设置nav,从而可能无法向协作ap发送第二tbppdu,进而导致协作流程无法进行的问题。

为达到上述目的,本申请的实施例采用如下技术方案:

第一方面,提供了一种协作通信方法,该方法包括:协作接入点从主接入点接收公告帧,该公告帧包括持续时间duration字段,该duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标触发帧的结束时刻或者第一时长的结束时刻不晚于目标基于触发帧的tb物理层协议数据单元ppdu的开始时刻,该目标触发帧为该公告帧的下一个无线帧,该目标tbppdu为该目标触发帧的响应帧,其中,该目标触发帧包括第二触发帧,该目标tbppdu包括第二tbppdu;协作接入点向该协作接入点关联的第二站点发送该第二触发帧;协作接入点从该第二站点接收该第二tbppdu。基于该方案,由于公告帧的duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标触发帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,而目标触发帧可以包括协作接入点向协作接入点关联的第二站点发送的第二触发帧,目标tbppdu可以包括协作接入点关联的第二站点向协作接入点发送的第二tbppdu,因此当协作ap关联的第二站点被第二触发帧触发之后,在发送第二tbppdu之前第二站点中被设置的basicnav已经减为0,因此可以在假设第二站点的物理载波侦听为空闲的前提下,顺利向关联的协作接入点发送第二tbppdu,从而解决了现有技术中,当协作接入点关联的第二站点被协作接入点发送的第二触发帧触发进行响应时,由于此时该第二站点中的basicnav不为0,因此可能无法向协作接入点发送第二tbppdu,进而导致协作流程无法进行的问题。

在一种可能的设计中,该第二触发帧的duration字段的值是根据预设规则确定的。由于该方式不需要通过主ap进行指示,因此可以节省信令的开销。

一个示例中,该预设规则包括:第二触发帧的duration字段的值被设置为等于sifs的时间长度+该第二tbppdu的传输时间长度+该sifs的时间长度+第二块确认ba的传输时间长度+该sifs的时间长度+固定时间长度,第二ba为第二tbppdu的响应帧。这样,可以保证第二ba的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果第二ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过第二ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

另一个示例中,第二触发帧的duration字段的值被设置为等于该sifs的时间长度+该第二tbppdu的传输时间长度+该sifs的时间长度+该第二ba的传输时间长度+该sifs的时间长度。这样,可以保证第二ba的下一个无线帧传输开始时不会受到其他站点发起竞争带来的干扰,即以最高优先级接入信道。如果第二ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过第二ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

又一个示例中,第二触发帧的duration字段的值被设置为等于该sifs的时间长度+该第二tbppdu的传输时间长度+该sifs的时间长度+该第二ba的传输时间长度。其中,该预设规则适用于第二ba是当前txop的最后一个无线帧的情况下,这样,可以保证第二ba传输时不会受到其他站点发起竞争带来的干扰。

在一种可能的设计中,该固定时间长度为一个确定ack帧的传输时间长度;或者,该固定时间长度为一个公告帧按照最低速率传输的时间长度;或者,该固定时间长度为一个公告帧传输的时间长度。

在一种可能的设计中,在协作接入点向该第二站点发送第二触发帧之前,该方法还包括:协作接入点确定该公告帧的发送地址与该协作接入点记录的为该协作接入点设置基本网络分配矢量basicnav的站点的媒体接入控制mac地址相同。基于该方案,可以解决协作ap被公告帧设置basicnav或者协作ap被比公告帧更早的来自主ap的无线帧设置了basicnav,此时,由于basicnav的数值不为0,协作ap可能无法发送第二触发帧的问题。

第二方面,提供了一种协作通信方法,该方法包括:主接入点发送公告帧,该公告帧包括持续时间duration字段,该duration字段的值被设置为第一时长,该第一时长的结束时刻不晚于目标触发帧的结束时刻或者该第一时长的结束时刻不晚于目标基于触发帧的tb物理层协议数据单元ppdu的开始时刻,该目标触发帧为该公告帧的下一个无线帧,该目标tbppdu为该目标触发帧的下一个无线帧,其中,该目标触发帧包括第一触发帧,该目标tbppdu包括第一tbppdu;主接入点向该主接入点关联的第一站点发送该第一触发帧;主接入点从该第一站点接收该第一tbppdu。基于该方案,由于公告帧的duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标触发帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,而目标触发帧可以包括协作接入点向协作接入点关联的第二站点发送的第二触发帧,目标tbppdu可以包括协作接入点关联的第二站点向协作接入点发送的第二tbppdu,因此当协作ap关联的第二站点被第二触发帧触发之后,在发送第二tbppdu之前第二站点中被设置的basicnav已经减为0,因此可以在假设第二站点的物理载波侦听为空闲的前提下,顺利向关联的协作接入点发送第二tbppdu,从而解决了现有技术中,当协作接入点关联的第二站点被协作接入点发送的第二触发帧触发进行响应时,由于此时该第二站点中的basicnav不为0,因此可能无法向协作接入点发送第二tbppdu,进而导致协作流程无法进行的问题。

在一种可能的设计中,该目标触发帧还包括第二触发帧,该目标tbppdu还包括第二tbppdu;第二触发帧为协作接入点向协作接入点关联的第二站点发送的触发帧,第二tbppdu为协作接入点关联的第二站点向协作接入点发送的tbppdu。

在一种可能的设计中,该第一触发帧的duration字段的值是根据预设规则确定的。由于该方式不需要通过主ap进行指示,因此可以节省信令的开销。

在一个示例中,该预设规则包括:该第一触发帧的duration字段的值被设置为等于sifs的时间长度+该第一tbppdu的传输时间长度+该sifs的时间长度+该主接入点需要发送的第一块确认ba的传输时间长度+该sifs的时间长度+固定时间长度。这样,可以保证第一ba的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果第一ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过第一ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

另一个示例中,该第一触发帧的duration字段的值被设置为等于该sifs的时间长度+该第一tbppdu的传输时间长度+该sifs的时间长度+该第一ba的传输时间长度+该sifs的时间长度。这样,可以保证第一ba的下一个无线帧传输开始时不会受到其他站点发起竞争带来的干扰,即以最高优先级接入信道。如果第一ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过第一ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

又一个示例中,该第一触发帧的duration字段的值被设置为等于该sifs的时间长度+该第一tbppdu的传输时间长度+该sifs的时间长度+该第一ba的时间长度。该预设规则适用于第一ba是当前txop的最后一个无线帧的情况下,这样,可以保证第一ba传输时不会受到其他站点发起竞争带来的干扰。

在一种可能的设计中,该固定时间长度为一个确定ack帧的传输时间长度;或者,该固定时间长度为一个公告帧按照最低速率传输的时间长度;或者,该固定时间长度为一个公告帧传输的时间长度。

结合上述第一方面或第二方面,在一种可能的设计中,该公告帧包括预设时间字段;相应的,该目标触发帧的duration字段的值是根据该预设时间字段的值设置的。由于预设时间字段的值可以由主ap灵活设定,因此该方案可以提高设置目标触发帧的duration字段的值的灵活性。

一个示例中,该预设时间字段的值被设置为等于sifs的时间长度+该目标tbppdu的传输时间长度+该sifs的时间长度+目标块确认ba的传输时间长度+该sifs的时间长度+该目标ba的下一个无线帧的传输时间长度,该目标ba为该目标tbppdu的响应帧。这样,可以保证目标ba的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果目标ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过目标ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

又一个示例中,在目标ba是当前txop的最后一个无线帧的情况下,该预设时间字段的值被设置为等于该sifs的时间长度+该目标tbppdu的传输时间长度+该sifs的时间长度+该目标ba的传输时间长度。这样,可以保证目标ba传输时不会受到其他站点发起竞争带来的干扰。

结合上述第一方面或第二方面,在一种可能的设计中,该第一时长的结束时刻不晚于目标触发帧的结束时刻,包括:该第一时长≤短帧间距sifs的时间长度+该目标触发帧的传输时间长度。一个示例中,第一时长的起始时刻为公告帧的结束时刻。

结合上述第一方面或第二方面,在一种可能的设计中,该第一时长的结束时刻不晚于目标tbppdu的开始时刻,包括:该第一时长≤sifs的时间长度+该目标触发帧的传输时间长度+该sifs的时间长度。一个示例中,第一时长的起始时刻为公告帧的结束时刻。

第三方面,提供了一种协作通信方法,该方法包括:协作接入点关联的第二站点从该协作接入点接收第二触发帧;第二站点确定该第二站点记录的为该第二站点设置第三基本网络分配矢量basicnav的站点为该协作接入点对应的主接入点;第二站点向该协作接入点发送第二基于触发帧的tb物理层协议数据单元ppdu。基于该方案,由于本申请实施例中引入一种特定规则,在协作ap关联的第二站点确定第二站点记录的为第二站点设置第三basicnav的站点为协作ap对应的主ap的情况下,协作ap关联的第二站点向协作ap发送第二tbppdu,因此解决了现有技术中,当协作ap关联的第二站点被协作ap发送的第二触发帧触发进行响应时,由于此时该第二站点中的basicnav不为0,因此可能无法向协作ap发送第二tbppdu,进而导致协作流程无法进行的问题。

在一种可能的设计中,在第二站点从该协作接入点接收第二触发帧之前,该方法还包括:第二站点接收公告帧,其中,该公告帧为该第二触发帧的上一个无线帧;第二站点确定该第二站点记录的为该第二站点设置第三basicnav的站点为该协作接入点所关联的主接入点,包括:第二站点确定该公告帧的发送地址与该协作接入点记录的为该协作接入点设置第三basicnav的站点的媒体接入控制mac地址相同。

在一种可能的设计中,该第二触发帧包括该协作接入点对应的主接入点的mac地址;该第二站点确定该第二站点记录的为该第二站点设置第三basicnav的站点为该协作接入点所关联的主接入点,包括:第二站点确定该主接入点的mac地址与该协作接入点记录的为该协作接入点设置第三basicnav的站点的mac地址相同。

在一种可能的设计中,该第二触发帧中包括发送地址字段,该发送地址字段的值被设置为该协作接入点对应的主接入点的mac地址;第二站点确定该第二站点记录的为该第二站点设置第三basicnav的站点为该协作接入点所关联的主接入点,包括:第二站点确定该第二触发帧的发送地址与该协作接入点记录的为该协作接入点设置第三basicnav的站点的mac地址相同。需要说明的是,该实现方式中,在接收第二触发帧时,第二站点要能够准确识别被触发的站点是否是自己。若是根据关联标识aid来确认,则在aid分配的过程中要避免第二站点的aid与主bss中的关联站点(如主ap关联的第一站点)的aid相同。

在一种可能的设计中,在第二站点向该协作接入点发送第二tbppdu之前,该方法还包括:第二站点将该第三basicnav设置为0,这样则无需修改现有basicnav的使用规则。

在一种可能的设计中,在该第二站点向该协作接入点发送第二tbppdu之前,该方法还包括:第二站点忽略该第三basicnav之后,确定该第二站点中的第四basicnav的数值为0。这样可以少修改现有basicnav的使用规则。

第四方面,提供了一种协作通信方法,该方法包括:协作接入点从主接入点接收公告帧;协作接入点确定该公告帧的发送地址与该协作接入点记录的为该协作接入点设置第一基本网络分配矢量basicnav的站点的媒体接入控制mac地址相同;协作接入点向该协作接入点关联的第二站点发送下一个无线帧。基于该方案,由于本申请实施例中引入一种特定规则,在协作ap确定公告帧的发送地址与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同的情况下,协作ap向协作ap关联的第二站点发送下一个无线帧,因此解决了现有技术中,当协作ap关联的第二站点被协作ap发送的第二触发帧触发进行响应时,由于此时第二站点中的basicnav不为0,因此可能无法向协作ap发送第二tbppdu,进而导致协作流程无法进行的问题。

在一种可能的设计中,该下一个无线帧为第二触发帧;该方法还包括:协作接入点从该第二站点接收第二基于触发帧的tb物理层协议数据单元ppdu。即该方案可以适用于上行数据传输。

在一种可能的设计中,该第二触发帧包括该主接入点的mac地址。

在一种可能的设计中,该第二触发帧中包括发送地址字段,其中,该发送地址字段的值被设置为该主接入点的mac地址。

在一种可能的设计中,该第二站点的关联标识aid与该主接入点关联的站点的aid不同。

在一种可能的设计中,该下一个无线帧为第二ppdu。即该方案可以适用于下行数据传输。

在一种可能的设计中,在协作接入点向该第二站点发送第二触发帧之前,该方法还包括:协作接入点将该第一basicnav设置为0。这样则无需修改现有basicnav的使用规则。

在一种可能的设计中,在协作接入点向该第二站点发送第二触发帧之前,该方法还包括:协作接入点忽略该第一basicnav之后,确定该协作接入点中的第二basicnav的数值为0。这样可以少修改现有basicnav的使用规则。

第五方面,提供了一种通信装置用于实现上述各种方法。该通信装置可以为上述第一方面或第四方面中的协作接入点,或者包含上述协作接入点的装置;或者,该通信装置可以为上述第二方面中的主接入点,或者包含上述主接入点的装置;或者,该通信装置可以为上述第三方面中的协作接入点关联的第二站点,或者包含上述协作接入点关联的第二站点的装置。该通信装置包括实现上述方法相应的模块、单元、或手段(means),该模块、单元、或means可以通过硬件实现,软件实现,或者通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块或单元。

第六方面,提供了一种通信装置,包括:处理器和存储器;该存储器用于存储计算机指令,当该处理器执行该指令时,以使该通信装置执行上述任一方面所述的方法。该通信装置可以为上述第一方面或第四方面中的协作接入点,或者包含上述协作接入点的装置;或者,该通信装置可以为上述第二方面中的主接入点,或者包含上述主接入点的装置;或者,该通信装置可以为上述第三方面中的协作接入点关联的第二站点,或者包含上述协作接入点关联的第二站点的装置。

第七方面,提供了一种通信装置,包括:处理器;该处理器用于与存储器耦合,并读取存储器中的指令之后,根据该指令执行如上述任一方面所述的方法。该通信装置可以为上述第一方面或第四方面中的协作接入点,或者包含上述协作接入点的装置;或者,该通信装置可以为上述第二方面中的主接入点,或者包含上述主接入点的装置;或者,该通信装置可以为上述第三方面中的协作接入点关联的第二站点,或者包含上述协作接入点关联的第二站点的装置。

第八方面,提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机可以执行上述任一方面所述的方法。

第九方面,提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机可以执行上述任一方面所述的方法。

第十方面,提供了一种通信装置(例如,该通信装置可以是芯片或芯片系统),该通信装置包括处理器,用于实现上述任一方面中所涉及的功能。在一种可能的设计中,该通信装置还包括存储器,该存储器,用于保存必要的程序指令和数据。该通信装置是芯片系统时,可以由芯片构成,也可以包含芯片和其他分立器件。

其中,第五方面至第十方面中任一种设计方式所带来的技术效果可参见上述第一方面至第四方面中不同设计方式所带来的技术效果,此处不再赘述。

第十一方面,提供了一种协作通信系统,该通信系统包括上述第一方面所述的协作接入点和上述第二方面所述的主接入点;或者,该通信系统包括上述第三方面所述的协作接入点关联的第二站点和上述第四方面所述的协作接入点。

附图说明

图1为现有的上行数据传输的ap协作流程示意图;

图2为本申请实施例提供的一种wlan通信系统的结构示意图;

图3为本申请实施例提供的一种通信设备的结构示意图;

图4为本申请实施例提供的协作通信方法的流程示意图一;

图5为本申请实施例提供的协作通信方法的流程示意图二;

图6为现有的下行数据传输的ap协作流程示意图;

图7为本申请实施例提供的多ap信道测量流程示意图;

图8为本申请实施例提供的协作通信方法的流程示意图三;

图9为现有的murts帧结构示意图;

图10为本申请实施例提供的协作通信方法的流程示意图四;

图11为本申请实施例提供的协作ap的结构示意图;

图12为本申请实施例提供的主ap的结构示意图;

图13为本申请实施例提供的协作ap关联的第二sta的结构示意图。

具体实施方式

为了方便理解本申请实施例的技术方案,首先给出本申请相关技术的简要介绍如下。

第一,传统的无线局域网(wirelesslocalareanetwork,wlan)网络中每个站点通过信道竞争,例如增强的分布式信道接入(enhanceddistributedchannelaccess,edca),获得信道使用权之后进行本站点的数据发送,而不会协调相邻bss中的站点进行并发传输。这种方式比较简单,但是效率较低,通过两个或多个相邻bss的站点协调而形成并发传输的话可以提高系统的效率。

电气和电子工程师协会(instituteofelectricalandelectronicsengineers,ieee)802.11ax系统中引入了空间复用(spatialreuse,sr)技术,可以形成多个链路并行发送的效果,但是它不是两个链路相互协商的结果,而是先有一个初始链路进行发送,在初始链路发送的过程中空间复用站点根据接收到初始链路的信道强度以及复用参数指示等信息来判断是否可以发起空间复用链路。这种并发方式开始之前不需要两个bss之间的站点进行协商,两个链路也不是同时开始传输的。

更进一步的,多bss中多链路并发传输在本专利中称为ap协作。其具体协作形式可以分为很多不同的类型,这里将其归纳为四类:

第一类协作方式为协作空间复用,即在多个bss中形成多个并发链路。这种协作方式一般是通过用户选择和功率控制来形成多个互不干扰的链路,多个链路之间的站点不需要交互数据,也不需要交互信道信息。

第二类协作方式为协作正交频分多址(orthogonalfrequencydivisionmultipleaccess,ofdma),即通过两个或多个bss中站点的协调同时发送两个或多个并发链路。这种协作方式一般是通过不同bss选择ofdma传输中不同的资源单元(resourceunit,ru)来形成多个互不干扰的链路,多个链路之间的站点不需要交互数据,也不需要交互信道信息。

第三类协作方式是协作波束成型,即两个或多个bss中的发送站点首先获取其与本bss接收站点以及协作bss中接收站点之间的信道信息,然后通过波束成型的方式使得每一个发送站点发送的信号对非目标接收站点的干扰置零或者显著降低,从而使得多个链路可以并发传输。这种协作方式中多个链路之间不需要交互数据,但是需要交互信道信息。

第四类协作方式是联合传输,即两个或多个bss中的发送站点交互发送数据,并且每个发送站点需要获取其与所有接收站点之间的信道信息。然后多个站点联合起来向接收站点发送数据。这种协作方式中多个链路之间即需要交互数据,也需要交互信道信息。

需要说明的是,从广义上来讲,本申请实施例中的站点包括ap或者ap关联的sta,在此统一说明,以下不再赘述。

第二,wlan系统工作在非授权频段,其无线信道是共享的。通常,在一个站点进行发送之前需要先进行信道接入。下面给出信道接入流程的简要介绍如下:

具体的,当一个站点进行发送之前需要先侦听其它的站点是否正在进行发送(forastatotransmit,itshallsensethemediumtodetermineifanotherstaistransmitting)。如果信道侦听结果为忙,则发送流程将暂时会被挂起,直到信道变为空闲。当信道变为空闲之后,在一个站点进行发送之前还需要先进行随机退避,通过随机退避来应对多个潜在发送站点之间的碰撞。当在信道空闲的状态下随机退避过程结束之后,该站点就可以进行发送。此外,在一个站点进行发送之前,该站点还可以与目标站点先进行一个短的控制帧交互,例如请求-发送(request-to-send,rts)/确认-发送(clear-to-send,cts),用来进一步减小碰撞带来的吞吐量的损失。因为短的控制帧交互碰撞之后,发送站点能尽快知晓已经发生碰撞,它将重新进行随机退避之后再接入信道,避免了发生碰撞时直接发送长的数据帧,而将整个数据帧都传输失败的问题。信道接入的具体流程可以参见ieee802.11标准,这里就不再详述。

其中,本申请实施例中的侦听分为物理载波侦听和虚拟载波侦听两种。物理载波侦听是通过侦听信道上的能量以及wlan无线帧信号实现的,当接收能量或者接收到的wlan无线帧强度小于某一个阈值时,物理载波侦听为空闲;反之物理载波侦听为繁忙。虚拟载波侦听是通过设置nav来实施的,它维护一个nav,当nav数值不为0时,虚拟载波侦听为繁忙,当nav数值为0时,虚拟载波侦听为空闲。通常物理载波侦听和虚拟载波侦听都为空闲时,站点才允许进行随机退避,进而进行后续的发送流程。

早期的wlan系统中站点只有一个nav。当站点正确接收到一个无线帧之后,可以根据该无线帧中的持续时间(duration)字段的值来更新nav。当无线帧的接收地址是自身的媒体接入控制(mediumaccesscontrol,mac)地址的情况下,该站点不更新nav。对于其它的无线帧,当其duration字段的值大于该站点当前的nav数值时则根据duration字段的值来更新nav。nav机制可以有效地解决隐藏节点带来的碰撞问题。其中,这里的隐藏节点是指不在发送站点的信号覆盖范围内,但是其发送信号可以干扰接收站点的站点。在发送站点发送无线帧的过程中,隐藏节点由于无法感知发送站点的发送,因而也同时进行了无线帧的发送,这样就导致接收站点受到干扰而无法正确进行无线帧的接收。使用了虚拟载波侦听之后,当发送站点竞争到信道之后,可以先和接收站点进行一个短的控制帧交互,交互的两个短帧中都通过其duration字段使得两者周围的非目标站点设置nav,从而保证在nav保护的时间内隐藏节点不会再进行信道竞争和无线帧发送。nav保护的这段时间通常称为传输机会(transmissionopportunity,txop)。

在ieee802.11ax标准中引入了两个nav来进行更精细的管理,其中一个叫做bss内(intra-bss)nav,另一个叫做基本(basic)nav。intra-bssnav通过intra-bssppdu来更新,basicnav通过bss间(inter-bss)ppdu或者不能区分是intra-bss的ppdu还是inter-bss的ppdu来更新。inter-bssppdu简单来说就是来自本bss之外的sta或ap发送的ppdu,intra-bssppdu简单来说就是来自本bss的ap或sta发送的ppdu。inter-bssppdu和intra-bssppdu的具体辨别方式可以参见ieee802.11ax的标准,这里就不再详述。

一个不是txop持有者(holder)的ap或sta当且仅当接收到的无线帧(以下简称接收帧)满足以下所有条件的情况下才更新intra-bssnav:

第一,接收帧是一个intra-bss帧。

第二,接收线帧的duration字段数值大于站点当前的intra-bssnav数值。

第三,接收帧的目的地址不是该站点的mac地址,或者该接收帧不会触发该站点进行立即响应,或者该接收帧是一个trigger帧。

一个站点当且仅当接收帧满足以下所有条件的情况下才更新basicnav:

第一,接收帧是一个inter-bss帧,或者不能分辨是intra-bss帧还是inter-bss帧。

第二,接收帧的duration字段数值大于站点当前的basicnav数值。

第三,接收帧的目的地址不是该站点的mac地址。

在站点主动进行无线帧发送的情况下,当intra-bssnav数值和basicnav数值都等于0时,虚拟载波侦听才为空闲,此时若物理载波侦听也为空闲,站点才可以进行随机退避。当站点被关联ap触发进行立即响应时,若站点的物理载波侦听为空闲,并且basicnav数值为0即可进行响应,不需要关注intra-bssnav数值是否为0。如果basicnav数值不为0,则即使物理载波侦听结果为空闲也不可以进行响应。

下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。需要说明的是,本申请实施例描述的网络架构以及业务场景是为了更加清楚的说明本申请实施例的技术方案,并不构成对于本申请实施例提供的技术方案的限定,本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请实施例提供的技术方案对于类似的技术问题,同样适用。

为方便描述,本申请以wlan通信系统为例进行说明,如图2所示,为本申请实施例提供的一种wlan通信系统20,该wlan通信系统20包括主ap,以及与主ap协作的一个或多个协作ap(图2中示例性的画出一个协作ap),其中,主ap所在的bss可以称之为主bss,协作ap所在的bss可以称之为协作bss,主ap可以与协作ap通信。此外,该wlan通信系统20还包括主ap关联的一个或多个sta(可以称之为第一sta)以及协作ap关联的一个或多个sta(可以称之为第二sta)。其中,主ap关联的一个或多个sta例如可以为图2中的sat1和sta3,协作ap关联的一个或多个sta例如可以为图2中的sat2和sta4。

需要说明的是,该wlan通信系统20不仅适用于单用户的上行或下行(downlink,dl)传输,也可以适用于多用户的上行或下行传输,本申请实施例对此不作具体限定。

基于该wlan通信系统20进行协作通信的方法可参考后续方法实施例,在此不再赘述。

可选的,本申请实施例中的主ap或者协作ap或者协作ap关联的第二sta的相关功能可以由一个设备实现,也可以由多个设备共同实现,还可以是由一个设备内的一个或多个功能模块实现,本申请实施例对此不作具体限定。可以理解的是,上述功能既可以是硬件设备中的网络元件,也可以是在专用硬件上运行的软件功能,或者是硬件与软件的结合,或者是平台(例如,云平台)上实例化的虚拟化功能。

例如,本申请实施例中的主ap或者协作ap或者协作ap关联的第二sta的相关功能可以通过图3中的通信设备300来实现。图3所示为本申请实施例提供的通信设备300的结构示意图。该通信设备300包括一个或多个处理器301,通信线路302,以及至少一个通信接口(图3中仅是示例性的以包括通信接口304,以及一个处理器301为例进行说明),可选的还可以包括存储器303。

处理器301可以是一个通用中央处理器(centralprocessingunit,cpu),微处理器,特定应用集成电路(application-specificintegratedcircuit,asic),或一个或多个用于控制本申请方案程序执行的集成电路。

通信线路302可包括一通路,用于连接不同组件之间。

通信接口304,可以是收发模块用于与其他设备或通信网络通信,如以太网,ran,无线局域网(wirelesslocalareanetworks,wlan)等。例如,所述收发模块可以是收发器、收发机一类的装置。可选的,所述通信接口304也可以是位于处理器301内的收发电路,用以实现处理器的信号输入和信号输出。

存储器303可以是具有存储功能的装置。例如可以是只读存储器(read-onlymemory,rom)或可存储静态信息和指令的其他类型的静态存储设备,随机存取存储器(randomaccessmemory,ram)或者可存储信息和指令的其他类型的动态存储设备,也可以是电可擦可编程只读存储器(electricallyerasableprogrammableread-onlymemory,eeprom)、只读光盘(compactdiscread-onlymemory,cd-rom)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质,但不限于此。存储器可以是独立存在,通过通信线路302与处理器相连接。存储器也可以和处理器集成在一起。

其中,存储器303用于存储执行本申请方案的计算机执行指令,并由处理器301来控制执行。处理器301用于执行存储器303中存储的计算机执行指令,从而实现本申请实施例中提供的协作通信方法。

或者,可选的,本申请实施例中,也可以是处理器301执行本申请下述实施例提供的协作通信方法中的处理相关的功能,通信接口304负责与其他设备或通信网络通信,本申请实施例对此不作具体限定。

可选的,本申请实施例中的计算机执行指令也可以称之为应用程序代码,本申请实施例对此不作具体限定。

在具体实现中,作为一种实施例,处理器301可以包括一个或多个cpu,例如图3中的cpu0和cpu1。

在具体实现中,作为一种实施例,通信设备300可以包括多个处理器,例如图3中的处理器301和处理器308。这些处理器中的每一个可以是一个单核(single-cpu)处理器,也可以是一个多核(multi-cpu)处理器。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(例如计算机程序指令)的处理核。

在具体实现中,作为一种实施例,通信设备300还可以包括输出设备305和输入设备306。输出设备305和处理器301通信,可以以多种方式来显示信息。例如,输出设备305可以是液晶显示器(liquidcrystaldisplay,lcd),发光二级管(lightemittingdiode,led)显示设备,阴极射线管(cathoderaytube,crt)显示设备,或投影仪(projector)等。输入设备306和处理器301通信,可以以多种方式接收用户的输入。例如,输入设备306可以是鼠标、键盘、触摸屏设备或传感设备等。

上述的通信设备300有时也可以称为通信装置,其可以是一个通用设备或者是一个专用设备。例如该通信设备300可以为服务器、路由器、交换机或者网桥等ap,或者,该通信设备300可以为手机、平板电脑,电脑笔记本,智能手表,智能电视等sta,本申请实施例不限定通信设备300的类型。

下面将结合图1至图3对本申请实施例提供的协作通信方法进行具体阐述。

需要说明的是,本申请下述实施例中各个网元之间的消息名字或消息中各参数的名字等只是一个示例,具体实现中也可以是其他的名字,本申请实施例对此不作具体限定。

需要说明的是,本申请实施例中的协作方式可以为协作空间复用、协作ofdma、协作波束成型或者联合传输中的任何一种,当然还可以是其他的协作方式,在此统一说明,以下不再赘述。其中,协作空间复用、协作ofdma、协作波束成型或者联合传输的相关描述可参考具体实施方式前序部分,在此不再赘述。

需要说明的是,本申请实施例中的流程中,主ap发送完announcement帧之后,接收端可以发送响应于announcement帧的ack,也可以不发送ack。本申请实施例中以主ap发送完announcement帧之后,接收端不发送响应于announcement帧的ack为例进行介绍,但是其实施方式同样适用于主ap发送完announcement帧之后,接收端发送响应于announcement帧的ack的流程,在此统一说明,以下不再赘述。

以图2所述的wlan通信系统的主ap、主ap关联的任意一个第一sta(如sta1)、协作ap、协作ap关联的任意一个第二sta(如sta2)之间的通信为例,如图4所示,为本申请实施例提供的一种协作通信方法,该协作通信方法通过逐步扩展txop时长实现,包括如下步骤:

s401、主ap向协作ap发送announcement帧。相应的,协作ap从主ap接收announcement帧。

其中,该announcement帧包括持续时间(duration)字段,该announcement帧的duration字段的值被设置为第一时长(即第一时长是由主ap设置的),第一时长的结束时刻不晚于目标触发(trigger)帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,该目标trigger帧为announcement帧的下一个无线帧,该目标tbppdu为目标trigger帧的响应帧,其中,目标trigger帧包括主ap将要发送给sta1的第一trigger帧(以下称之为trigger1),和/或,协作ap将要发送给sta2的第二trigger帧(以下称之为trigger2)。目标tbppdu包括trigger1的响应帧第一tbppdu(以下称之为tbppdu1),和/或,trigger2的响应帧第二tbppdu(以下称之为tbppdu2)。

可选的,该announcement帧中还包括目标trigger的传输时间长度、目标tbppdu的传输时间长度和目标ba的传输时间长度;或者,目标trigger的传输时间长度、目标tbppdu的传输时间长度和目标ba的传输时间长度也可以是根据announcement帧中携带的相关参数(例如帧长和传输速率)计算得到的,具体描述可参考现有技术,在此不予赘述。其中,目标ba为目标tbppdu的响应帧,包括tbppdu1的响应帧第一ba(以下称之为ba1),和/或,tbppdu2的响应帧第二ba(以下称之为ba2),在此统一说明,以下不再赘述。

可选的,本申请实施例中的duration字段也可以称之为duration/标识(identification,id)字段,在此统一说明,以下不再赘述。

可选的,本申请实施例中,第一时长的结束时刻不晚于目标trigger帧的结束时刻,包括:第一时长≤sifs的时间长度+目标trigger帧的传输时间长度;第一时长的结束时刻不晚于目标tbppdu帧的结束时刻,包括:第一时长≤sifs的时间长度+目标trigger帧的传输时间长度+sifs的时间长度。可选的,若目标tbppdu在收到目标trigger帧的间隔sifs后发送,第一时长的结束时刻不晚于目标tbppdu帧的结束时刻等同于第一时长的结束时刻不晚于目标trigger帧的结束时刻+sifs的时间长度,在此统一说明,以下不再赘述。可选的,对于主ap发送完announcement帧之后,接收端可以发送响应于announcement帧的ack的情形,第一时长的结束时刻不晚于目标trigger帧的结束时刻,包括:第一时长≤sifs的时间长度+ack的传输时间长度+目标trigger帧的传输时间长度;第一时长的结束时刻不晚于目标tbppdu帧的结束时刻,包括:第一时长≤sifs的时间长度+ack的传输时间长度+目标trigger帧的传输时间长度+sifs的时间长度。可选的,对于trigger帧之前还包括其他帧的情形,第一时长可适应性地调整,以使得第一时长的结束时刻不晚于目标trigger帧的结束时刻或目标tbppdu帧的结束时刻,此处不再赘述。可选的,第一时长的起始时刻为所述公告帧的结束时刻。

此外,本申请实施例中,在主ap向协作ap发送announcement帧时,主ap关联的sta1和协作ap关联的sta2也可能接收到该announcement帧,从而sta1可能被设置intra-bssnav,sta2可能被设置basicnav,该intra-bssnav和basicnav的值均等于上述第一时长的值。

s402、主ap向主ap关联的sta1发送trigger1。相应的,主ap关联的sta1从主ap接收trigger1。

其中,trigger1包括duration字段,本申请实施例对trigger1的duration字段的值不作具体限定。

s403、协作ap向协作ap关联的sta2发送trigger2。相应的,协作ap关联的sta2从协作ap接收trigger2。

其中,trigger2包括duration字段,本申请实施例对trigger2的duration字段的值不作具体限定。

需要说明的是,本申请实施例中,因为主ap是txopholder,因此trigger2的duration字段要和trigger1的duration字段设置相等的数值,在此统一说明,以下不再赘述。

可选的,本申请实施例中,主ap向主ap关联的sta1发送trigger1与协作ap向协作ap关联的sta2发送trigger2是同时发生的,即trigger1和trigger2同时传输结束,在此统一说明,以下不再赘述。需要说明的是,基于收发机的工作原理,本实施例所涉及到的“同时”是实质的同时,不需要严格限定在上述主ap和协作ap的处理没有任何时间上的差异,只需要满足整体上上述处理在时间维度大致相同即可。

需要说明的是,本申请实施例中对trigger帧(包括trigger1或trigger2)的格式不作限定,只要是能触发sta1或sta2进行响应的无线帧都可以称之为trigger帧,在此统一说明,以下不再赘述。

s404、主ap关联的sta1接收trigger1之后,向主ap发送tbppdu1。相应的,主ap从主ap关联的sta1接收tbppdu1。

本申请实施例中,tbppdu1中包括的duration字段的值是根据trigger1的duration字段的值确定的,如tbppdu1中的duration字段的值=trigger1的duration字段的值-sifs的时间长度-tbppdu1的传输时间长度。

如具体实施方式前序部分所述,当站点被关联ap触发进行立即响应时,若站点的物理载波侦听为空闲,并且basicnav数值为0即可进行响应,不需要考虑intra-bssnav数值是否为0。本申请实施例假设主ap关联的sta1接收trigger1之后,sta1的物理载波侦听为空闲,并且sta1的basicnav数值为0,因此sta1可以向主ap发送tbppdu1。当然,若sta1的物理载波侦听为繁忙,或者sta1的basicnav数值不0,则sta1无法向主ap发送tbppdu1,即不执行上述步骤s404,在此统一说明,以下不再赘述。

s405、协作ap关联的sta2接收trigger2之后,向协作ap发送tbppdu2。相应的,协作ap从协作ap关联的sta2接收tbppdu2。

由于本申请实施例中,announcement帧的duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标trigger帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,而目标trigger帧包括trigger2,目标tbppdu包括tbppdu2,因此当协作ap关联的sta2被trigger2触发之后,在发送tbppdu2之前sta2中被设置的basicnav已经减为0,由于当站点被关联ap触发进行立即响应时,不需要考虑intra-bssnav数值是否为0,因此在假设sta2的物理载波侦听为空闲的前提下,sta2可以顺利向关联的协作ap发送tbppdu2。

本申请实施例中,tbppdu2中包括的duration字段的值是根据trigger2的duration字段的值确定的,如tbppdu2中的duration字段的值=trigger2的duration字段的值-sifs的时间长度-tbppdu2的传输时间长度。

可选的,本申请实施例中,tbppdu1和tbppdu2可以同时传输结束。

s406、主ap接收tbppdu1之后,向关联的sta1发送ba1。相应的,主ap关联的sta1从主ap接收ba1。

本申请实施例中,ba1中包括的duration字段的值是根据tbppdu1的duration字段的值确定的,如ba1中的duration字段的值=tbppdu1的duration字段的值-sifs的时间长度-ba1的传输时间长度。

s407、协作ap接收tbppdu2之后,向关联的sta2发送ba2。相应的,协作ap关联的sta2从协作ap接收ba2。

本申请实施例中,ba2中包括的duration字段的值是根据tbppdu2的duration字段的值确定的,如ba2中的duration字段的值=tbppdu2的duration字段的值-sifs的时间长度-ba2的传输时间长度。

可选的,本申请实施例中,主ap也可能不向主ap关联的sta1发送trigger1,进而主ap关联的sta1不会向主ap发送tbppdu1,主ap不会向关联的sta1发送ba1。也就是说,本申请实施例同样适用于主ap暂时将txop使用权交给协作ap的场景,本申请实施例对此不作具体限定。

基于本申请实施例提供的协作通信方法,由于announcement帧的duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标trigger帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,而目标trigger帧包括trigger2,目标tbppdu包括tbppdu2,因此当协作ap关联的sta2被trigger2触发之后,在发送tbppdu2之前sta2中被设置的basicnav已经减为0,因此可以在假设sta2的物理载波侦听为空闲的前提下,顺利向关联的协作ap发送tbppdu2,从而解决了现有技术中,当协作ap关联的sta2被协作ap发送的trigger2触发进行响应时,由于此时该sta2中的basicnav不为0,因此可能无法向协作ap发送tbppdu2,进而导致协作流程无法进行的问题。

上述步骤s401至s407中的主ap、协作ap或者协作ap关联的sta2的动作可以由图3所示的通信设备300中的处理器301调用存储器303中存储的应用程序代码来执行,本申请实施例对此不作任何限制。

一种可能的实现方式中,步骤s401中announcement帧还包括预设时间字段,相应的,步骤s402中trigger1的duration字段的值以及步骤s403中trigger2的duration字段的值均是根据预设时间字段的值设定的。

可选的,本申请实施例中,trigger1的duration字段的值以及步骤s403中trigger2的duration字段的值均是根据预设时间字段的值设定的,可以包括:trigger1的duration字段的值以及步骤s403中trigger2的duration字段的值等于预设时间字段的值;或者,trigger1的duration字段的值以及步骤s403中trigger2的duration字段的值是根据预设时间字段的值推导得到的,本申请实施例对此不作具体限定。

一个示例中,预设时间字段的值可以被设置为等于sifs的时间长度+目标tbppdu的传输时间长度+sifs的时间长度+目标ba的传输时间长度+sifs的时间长度+目标ba的下一个无线帧的传输时间长度,目标ba为目标tbppdu的响应帧。这样,可以保证目标ba的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果目标ba的下一个无线帧有响应帧或者还有待传输数据,则可以通过目标ba的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

另一个示例中,在目标ba是当前txop的最后一个无线帧的情况下,预设时间字段的值被设置为等于sifs的时间长度+目标tbppdu的传输时间长度+sifs的时间长度+目标ba的传输时间长度。这样,可以保证目标ba传输时不会受到其他站点发起竞争带来的干扰。

当然,在具体实现时,预设时间字段的值也可以被设置为其它数值,本申请实施例对此不作具体限定。

在announcement帧中携带用于确定目标trigger帧的duration字段的值的预设时间字段,由于预设时间字段的值可以由主ap灵活设定,因此可以提高设置目标trigger帧的duration字段的值的灵活性。

另一种可能的实现方式中,步骤s402中trigger1的duration字段的值以及步骤s403中trigger2的duration字段的值均是根据预设规则确定的,该预设规则可以是标准预先定义好的。由于该方式不需要通过主ap进行指示,因此可以节省信令的开销。

一个示例中,主ap中的预设规则可以包括:trigger1的duration字段的值被设置为等于sifs的时间长度+tbppdu1的传输时间长度+sifs的时间长度+ba1的传输时间长度+sifs的时间长度+固定时间长度。这样,可以保证ba1的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果ba1的下一个无线帧有响应帧或者还有待传输数据,则可以通过ba1的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

另一个示例中,主ap中的预设规则可以包括:trigger1的duration字段的值被设置为等于sifs的时间长度+tbppdu1的传输时间长度+sifs的时间长度+ba1的传输时间长度+sifs的时间长度。这样,可以保证ba1的下一个无线帧传输开始时不会受到其他站点发起竞争带来的干扰,即以最高优先级接入信道。如果ba1的下一个无线帧有响应帧或者还有待传输数据,则可以通过ba1的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

又一个示例中,主ap中的预设规则可以包括:trigger1的duration字段的值被设置为等于sifs的时间长度+tbppdu1的传输时间长度+sifs的时间长度+ba1的传输时间长度。该预设规则适用于ba1是当前txop的最后一个无线帧的情况下,这样,可以保证ba1传输时不会受到其他站点发起竞争带来的干扰。

一个示例中,协作ap中的预设规则可以包括:trigger2的duration字段的值被设置为等于sifs的时间长度+tbppdu2的传输时间长度+sifs的时间长度+ba2的传输时间长度+sifs的时间长度+固定时间长度。这样,可以保证ba2的下一个无线帧传输时不会受到其他站点发起竞争带来的干扰。如果ba2的下一个无线帧有响应帧或者还有待传输数据,则可以通过ba2的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

另一个示例中,协作ap中的预设规则可以包括:trigger2的duration字段的值被设置为等于sifs的时间长度+tbppdu2的传输时间长度+sifs的时间长度+ba2的传输时间长度+sifs的时间长度。这样,可以保证ba2的下一个无线帧传输开始时不会受到其他站点发起竞争带来的干扰,即以最高优先级接入信道。如果ba2的下一个无线帧有响应帧或者还有待传输数据,则可以通过ba2的下一个无线帧的duration字段将txop时间进一步延长,本申请实施例对此不作具体限定。

又一个示例中,协作ap中的预设规则可以包括:trigger2的duration字段的值被设置为等于sifs的时间长度+tbppdu2的传输时间长度+sifs的时间长度+ba2的传输时间长度。其中,该预设规则适用于ba2是当前txop的最后一个无线帧的情况下,这样,可以保证ba2传输时不会受到其他站点发起竞争带来的干扰。

一个示例中,本申请实施例中的固定时间长度可以为一个确认(acknowledgement,ack)帧的传输时间长度;或者,该固定时间长度可以为一个announcement帧按照最低速率传输的时间长度;或者,该固定时间长度可以为一个announcement帧传输的时间长度。其中,这里的最低速率例如可以是调制与编码策略(modulationandcodingscheme,mcs)为0,在此不作具体限定。

需要说明的是,本申请实施例中,trigger1和trigger2进行txop时长扩展时,需要注意扩展后的txop时长不能超过txoplimit的限制,即trigger1的duration字段的值和trigger2的duration字段的值不大于txoplimit时长,在此统一说明,以下不再赘述。

在以上描述中我们假定协作ap在收到announcement帧之后是可以发送trigger2的,如果出现协作ap被announcement帧设置basicnav(例如announcement帧的接收地址(receiveraddress,ra)设置为广播地址),或者协作ap被比announcement帧更早的来自主ap的无线帧设置了basicnav,此时,由于basicnav的数值不为0,协作ap可能无法发送trigger2。其中,在announcement帧之前还有其它的无线帧是很常见的,例如当主ap通过竞争接入信道之后先与主ap关联的sta1使用rts/cts帧交互进行信道保护;又例如,主ap先与其它协作ap进行协作,然后再在同一个txop中与上述协作ap进行协作。

基于此,本申请实施例提供的协作通信方法还可以包括:在协作ap确定announcement帧的发送地址(transmitaddress,ta)与协作ap记录的为该协作ap设置basicnav的站点的mac地址相同的情况下,协作ap向协作ap关联的sta2发送trigger2。也就是说,announcement帧的发送地址为主ap的mac地址,且协作ap记录的为该协作ap设置basicnav的站点的mac地址为主ap的mac地址,则协作ap向协作ap关联的sta2发送trigger2,不用关注协作ap中的basicnav是否为0。

类似的,由于协作通信中sta2可能被主ap直接调度,若出现sta2被比announcement帧更早的来自主ap的无线帧设置了basicnav,此时,由于basicnav的数值不为0,sta2可能无法回复响应帧,因此sta2也需要采用以上协作ap相同的处理规则。即sta2记录给它设置basicnav的站点的mac地址。当sta2接收到trigger帧之后,对比trigger帧的发送地址是否与sta2记录的为该sta2设置basicnav的站点的mac地址相同,如果相同则允许响应该trigger帧。也就是说,trigger帧的发送地址为主ap的mac地址,且sta2记录的为该sta2设置basicnav的站点的mac地址为主ap的mac地址,则允许响应该trigger帧,不用关注sta2中的basicnav是否为0。

上述实施例使用了逐步扩展txop时长的方式,其中讨论了主ap如何设置announcement帧的duration字段,但是没有考虑若在announcement帧之前主ap已经有其它无线帧发送的情况下应该如何设置announcement帧之前的其它无线帧的duration数值。其中,若在announcement帧之前的无线帧已经将txop时长设置为很长,即txop时长的结束时刻超过了tbppdu2的开始时刻,则由于txop长度不能缩短(除非使用无竞争-结束(contentionfreeend,cf-end)将信道进行释放),因此即使将announcement帧的duration字段的值设置为上述第一时长,但是该协作ap关联的sta2已经设置了比announcement帧中指示的第一时长更长的basicnav,因此不会基于该announcement帧更新basicnav。这样的结果就是协作ap关联的sta2被trigger2触发之后由于basicnav的数值不为0,而无法回复tbppdu2。

为解决该问题,本申请实施例中,当主ap设置announcement帧之前的其它无线帧的duration字段的时长时,其设置的duration字段的时长的结束时刻不能超过announcement帧/目标trigger帧/目标tbppdu/目标ba这个交互流程中的目标tbppdu帧的开始时刻。也就是说,当在同一个txop中有多个协作流程时,在前一个协作流程中设置nav时就需要考虑后一个协作流程的nav设置限制。

以图2所述的wlan通信系统的主ap、主ap关联的任意一个第一sta(如sta1)、协作ap、协作ap关联的任意一个第二sta(如sta2)之间的通信为例,如图5所示,为本申请实施例提供的另一种协作通信方法,该协作通信方法通过对协作ap以及协作ap关联的sta2引入特性规则实现,包括如下步骤:

s501、主ap向协作ap发送announcement帧。相应的,协作ap从主ap接收announcement帧。该announcement帧的duration字段的相关描述可参考现有技术,在此不再赘述。

s502、协作ap确定announcement帧的发送地址与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同。

s503、协作ap向协作ap关联的sta2发送第二trigger帧(以下称之为trigger2)。相应的,协作ap关联的sta2从协作ap接收trigger2。

也就是说,本申请实施例中引入一种规则,在协作ap确定announcement帧的发送地址(即主ap的mac地址)与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同的情况下,协作ap可以向协作ap关联的sta2发送trigger2,不用考虑协作ap中的basicnav是否已经减为0。可选的,announcement帧的发送地址不仅限于为主ap的mac地址,还可以为主ap的其他地址,例如主ap的aid等。

本申请实施例中,trigger2的duration字段的相关描述可参考现有技术,在此不再赘述。

s504、协作ap关联的sta2接收trigger2之后,确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap。

s505、协作ap关联的sta2向协作ap发送tbppdu2。相应的,协作ap从协作ap关联的sta2接收tbppdu2。

也就是说,本申请实施例中引入一种规则,协作ap关联的sta2接收trigger2之后,确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap的情况下,协作ap关联的sta2可以向协作ap发送tbppdu2,不用考虑协作ap关联的sta2中的basicnav是否已经减为0。

本申请实施例中,tbppdu2的duration字段的相关描述可参考现有技术,在此不再赘述。

一种可能的实现方式中,协作ap关联的sta2接收trigger2之前,本申请实施例提供的协作通信方法还包括:协作ap关联的sta2接收announcement帧,其中,该announcement帧为trigger2的上一个无线帧;进而,协作ap关联的sta2确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap,可以包括:协作ap关联的sta2确定announcement帧的发送地址与协作ap记录的为协作ap设置第三basicnav的站点的mac地址相同。

也就是说,对于协作ap关联的sta2,它需要记录给它设置第三basicnav的站点(如主ap)的mac地址。当它先接收到一个由给它设置第三basicnav的站点发送的announcement帧(接收地址不需要是sta2),然后紧接着(通常为sifs时间之后)又接收到一个由关联ap(如协作sp)发送的trigger2,若该trigger2触发自己进行回复,则sta2可以直接进行回复,而不用管第三basicnav是否为0。

另一种可能的实现方式中,trigger2包括协作ap对应的主ap的mac地址;进而,协作ap关联的sta2确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap,可以包括:协作ap关联的sta2确定trigger2中携带的主ap的mac地址与协作ap记录的为协作ap设置第三basicnav的站点的mac地址相同。

也就是说,对于协作ap关联的sta2,它需要记录给它设置第三basicnav的站点(如主ap)的mac地址。当它收到一个由关联ap(如协作ap)发送的trigger2,如果该trigger2触发自己进行回复,则对比trigger2中携带的主ap的mac地址与给自己设置第三basicnav的站点的mac地址是否相同,若相同则sta2可以直接进行回复,而不用管第三basicnav是否为0。

再一种可能的实现方式中,trigger2包括发送地址字段,该发送地址字段的值被设置为协作ap对应的主ap的mac地址;进而,协作ap关联的sta2确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap,可以包括:协作ap关联的sta2确定trigger2的发送地址字段中的地址与协作ap记录的为协作ap设置第三basicnav的站点的mac地址相同。

也就是说,对于协作ap关联的sta2,它需要记录给它设置第三basicnav的站点(如主ap)的mac地址。当它收到一个发送地址设置为主ap的trigger2,如果该trigger2触发自己进行回复,则sta2可以直接进行回复,而不用管第三basicnav是否为0。

需要说明的是,该实现方式中,在接收trigger2时,sta2要能够准确识别被触发的站点是否是自己。若是根据关联标识(associationidentifier,aid)(即一个小区内识别站点的唯一标识)来确认,则在aid分配的过程中要避免sta2的aid与主bss中的关联站点(如主ap关联的sta1)的aid相同。aid相同则无法唯一确定被调度的是哪一个站点。当然,若主ap和协作ap在分配aid时没有进行协调(即两个bss中的站点的aid可能相同),则需要采用其他方式来进行站点识别,例如在trigger2中携带bss颜色(color),或者直接使用sta2的mac地址进行调度,本申请实施例对此不作具体限定。

s506、协作ap接收tbppdu2之后,向关联的sta2发送第二ba(以下称之为ba2)。相应的,协作ap关联的sta2从协作ap接收ba2。

本申请实施例中,ba2的duration字段的相关描述可参考现有技术,在此不再赘述。

当然,本申请实施例中,主ap也可以向主ap关联的sta1发送trigger1;主ap关联的sta1接收trigger1之后,可以向主ap发送tbppdu1;主ap接收tbppdu1之后,可以向关联的sta1发送第一ba(以下称之为ba1),相关实现可参考现有技术,在此不再赘;或者,本申请实施例同样适用于主ap暂时将txop使用权交给协作ap的场景。即在announcement帧之后,只有协作ap发送trigger2,主ap不发送trigger1,在此统一说明,以下不再赘述。

基于本申请实施例提供的协作通信方法,由于本申请实施例中引入一种特定规则,在协作ap确定announcement帧的发送地址与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同的情况下,协作ap向协作ap关联的sta2发送trigger2;在协作ap关联的sta2确定sta2记录的为sta2设置第三basicnav的站点为协作ap对应的主ap的情况下,协作ap关联的sta2向协作ap发送tbppdu2,因此解决了现有技术中,当协作ap关联的sta2被协作ap发送的trigger2触发进行响应时,由于此时该sta2中的basicnav不为0,因此可能无法向协作ap发送tbppdu2,进而导致协作流程无法进行的问题。

上述步骤s501至s506中的主ap、协作ap或者协作ap关联的sta2的动作可以由图3所示的通信设备300中的处理器301调用存储器303中存储的应用程序代码来执行,本申请实施例对此不作任何限制。

基于图5所示的协作通信方法,一种可能的实现方式中,本申请实施例中,对于协作ap,当协作ap被announcement帧触发之后,如果发现该announcement帧是由给它设置第一basicnav的主ap发送的,则将该第一basicnav设置为0,进而响应announcement帧发送trigger2。也就是说,在协作ap向协作ap关联的sta2发送trigger2之前,协作ap首先将自己的第一basicnav设置为0,这样则无需修改现有basicnav的使用规则。

类似的,基于图5所示的协作通信方法,一种可能的实现方式中,本申请实施例中,对于协作ap关联的sta2,当被协作ap发送的trigger2触发之后,如果自己的第三basicnav是由主ap设置的,则将第三basicnav设置为0,进而响应trigger2帧发送tbppdu2。也就是说,在协作ap关联的sta2向协作ap发送tbppdu2之前,协作ap关联的sta2首先将自己的第三basicnav设置为0,这样则无需修改现有basicnav的使用规则。

基于图5所示的协作通信方法,另一种可能的实现方式中,本申请实施例中,当协作ap被announcement帧触发之后,如果发现该announcement帧是由给它设置第一basicnav的主ap发送的,则将主ap为协作ap设置的第一basicnav进行忽略。这里将主ap为协作ap设置的第一basicnav进行忽略与直接将第一basicnav设置为0是不同的,因为若协作ap的basicnav曾经被多个站点设置过的话,忽略主ap为协作ap设置的第一basicnav之后,其他站点为协作ap设置的basicnav不一定为0。若此时协作ap确定其他站点为协作ap设置的第二basicnav的数值为0,则可以响应announcement帧发送trigger2,否则协作ap不能响应announcement帧发送trigger2。

类似的,基于图5所示的协作通信方法,另一种可能的实现方式中,本申请实施例中,对于协作ap关联的sta2,当被协作ap发送的trigger2触发之后,如果自己的第三basicnav是由主ap设置的,则将主ap为sta2设置的第三basicnav进行忽略。这里将主ap为sta2设置的第三basicnav进行忽略与直接将第三basicnav设置为0是不同的,因为若sta2的basicnav曾经被多个站点设置过,忽略主ap为sta2设置的第三basicnav之后,其他站点为sta2设置的basicnav不一定为0。若此时sta2确定其他站点为sta2设置的第四basicnav的数值为0,则可以响应trigger2发送tbppdu2,否则sta2不能响应trigger2发送tbppdu2。

图6为现有的下行数据传输的ap协作流程示意图。其中,主ap通过竞争接入信道之后,向协作ap发送announcement帧。协作ap在接收到announcement帧之后和主ap同时分别进行下行数据发送。其中,主ap向主ap关联的sta1发送ppdu1,协作ap向关联的sta2发送ppdu2,其中,ppdu1和ppdu2同时传输结束。ppdu1和ppdu2传输结束sifs之后,sta1向主ap发送ba1,sta2向协作ap发送ba2。在某些情况下,例如传输单个(single)聚合媒体接入控制协议数据单元(aggregatedmacprotocoldataunit,a-mpdu),这里的ba1也可以为ack1,这里的ba2也可以为ack2,在此不作具体限定。

在上述下行数据传输的ap协作流程中,我们假定协作ap在接收到announcement帧之后是可以发送ppdu2的,如果出现协作ap被announcement帧设置第一basicnav(例如announcement帧的接收地址ra设置为广播地址),或者协作ap被比announcement帧更早的来自主ap的无线帧设置了第一basicnav,此时,由于第一basicnav的数值不为0,协作ap可能无法发送ppdu2。其中,在announcement帧之前还有其它的无线帧是很常见的,例如当主ap通过竞争接入信道之后先与主ap关联的sta1使用rts/cts帧交互进行信道保护;又例如,主ap先与其它协作ap进行协作,然后再在同一个txop中与上述协作ap进行协作。

基于此,本申请实施例提供的协作通信方法还可以包括:协作ap从主ap接收announcement帧之后,在协作ap确定announcement帧的发送地址(即主ap的mac地址)与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同的情况下,协作ap向协作ap关联的sta2发送ppdu2。也就是说,本申请实施例中引入一种特定规则,在协作ap确定announcement帧的发送地址与协作ap记录的为协作ap设置第一basicnav的站点的mac地址相同的情况下,协作ap向协作ap关联的sta2发送ppdu2。从而解决了现有技术中,协作ap接收announcement帧之后,由于协作ap中的第一basicnav的数值不为0,协作ap可能无法发送ppdu2的问题。

在上述下行数据传输的ap协作流程中,一种可能的实现方式中,对于协作ap,当协作ap被announcement帧触发之后,如果发现该announcement帧是由给它设置第一basicnav的主ap发送的,则将该第一basicnav设置为0,进而响应announcement帧发送ppdu2。也就是说,在协作ap向协作ap关联的sta2发送ppdu2之前,协作ap首先将自己的第一basicnav设置为0,这样则无需修改现有basicnav的使用规则。

类似的,基于图5所示的协作通信方法,一种可能的实现方式中,本申请实施例中,对于协作ap关联的sta2,当被协作ap发送的trigger2触发之后,如果自己的第三basicnav是由主ap设置的,则将第三basicnav设置为0,进而响应trigger2帧发送tbppdu2。也就是说,在协作ap关联的sta2向协作ap发送tbppdu2之前,协作ap关联的sta2首先将自己的第三basicnav设置为0,这样则无需修改现有basicnav的使用规则。

在上述下行数据传输的ap协作流程中,另一种可能的实现方式中,当协作ap被announcement帧触发之后,如果发现该announcement帧是由给它设置第一basicnav的主ap发送的,则将主ap为协作ap设置的第一basicnav进行忽略。这里将主ap为协作ap设置的第一basicnav进行忽略与直接将第一basicnav设置为0是不同的,因为若协作ap的basicnav曾经被多个站点设置过的话,忽略主ap为协作ap设置的第一basicnav之后,其他站点为协作ap设置的basicnav不一定为0。若此时协作ap确定其他站点为协作ap设置的第二basicnav的数值为0,则可以响应announcement帧发送ppdu2,否则协作ap不能响应announcement帧发送ppdu2。

在一些场景中,主ap需要将txop使用权暂时转让给协作ap,此时关联在协作ap的站点或者关联在主ap的站点有可能不能响应协作ap的调度。例如,图7所示为多ap信道测量流程,在多ap信道测量流程中,主ap首先发送一个空数据包公告(nulldatapacketannouncement,ndpa)帧,并在ndpa帧发送结束后间隔sifs时间发送一个空数据包(nulldatapacket,ndp)1帧。ndpa帧用于调度主ap对应的协作ap在ndp1发送结束后间隔sifs时间发送ndp2帧。进一步的,主ap关联的sta1通过ndp1帧测量自身与主ap之间的信道信息,sta1通过ndp2帧测量自身与协作ap之间的信道信息;以及,协作ap关联的sta2通过ndp1帧测量自身与主ap之间的信道信息,sta2通过ndp2帧测量自身与协作ap之间的信道信息。ndp2帧发送结束后间隔sifs时间由主ap发送一个触发帧,用于触发sta1和sta2分别向主ap反馈它们各自与主ap之间的信道信息,如图7中sta1和sta2分别向主ap发送波束成型汇报(beamformingreport,bfr)(记作bfr(主ap))。当然,若一次触发不能完成所有信道信息的反馈,或者反馈过程中出现错误,则主ap可以再次发送触发帧来触发sta1和sta2继续进行反馈。当sta1和sta2将它们与主ap之间的信道信息反馈完毕之后,主ap通过一个转让帧(transferframe)将txop使用权暂时转让给协作ap,由协作ap发送一个触发帧,用于触发sta1和sta2分别向协作ap反馈它们各自与协作ap之间的信道信息,如图7中sta1和sta2分别向协作ap发送bfr(记作bfr(协作ap))。当协作ap完成传输之后,可以将txop的使用权归还给主ap。例如如图7所示,协作ap可以使用返回帧(returnframe)将txop的使用权归还给主ap。进而,主ap可以继续发送后续的无线帧1,该无线帧1例如可以是发给协作ap的一个控制帧,或者例如可以是发送给主ap关联的sta的一个下行的数据ppdu,或者例如可以是是用于触发主ap关联的sta进行上行数据发送的一个触发帧,在此不做限定。需要说明的是,上述图7中的bfr仅是触发帧的响应帧的一个示例,当然,触发帧的响应帧也可以为其他无线帧,在此不做限定。

然而,一方面,在主ap将txop使用权暂时转让给协作ap之后,当协作ap发送触发帧以触发sta1和sta2分别向协作ap反馈它们各自与协作ap之间的信道信息时,sta1由于被关联的主ap设置了intra-bssnav;sta2由于被主ap设置了basicnav,因此sta1和sta2均可能无法响应协作ap发送的触发帧。另一方面,在协作ap将txop的使用权归还给主ap之后,sta1可能由于被协作ap扩展txop之后设置basicnav,而无法响应主ap调度。

以图2所述的wlan通信系统的主ap和协作ap之间的通信为例,如图8所示,为本申请实施例提供的一种协作通信方法,该方法包括如下步骤:

s801、主ap向协作ap发送transferframe。相应的,协作ap从主ap接收transferframe。

该transferframe包括duration字段,该duration字段的值设置为第二时长,第二时长的结束时刻不晚于触发帧的结束时刻或者第二时长的结束时刻不晚于触发帧的下一个无线帧的开始时刻。

此外,该transferframe中还可以携带剩余的(remain)txop字段,该remaintxop字段用于指示该txop允许使用的剩余时间,这样,当协作ap接收到transferframe之后就可以自己扩展txop,但是扩展后的txop不能超过remaintxop指示的结束时间点。这里需要说明的是,为了防止一个站点获得信道之后长时间连续使用,而导致其他站点无法接入,标准中规定了一个txoplimit,用于标识单个txop时间段允许使用的最长时间,这里remaintxop字段的值受限于该txoplimit,具体地,remaintxop所指示的结束时间点不能超过txoplimit所指示的结束时间点,在此统一说明,以下不再赘述。

本申请实施例中,在主ap向协作ap发送transferframe时,主ap关联的sta1和协作ap关联的sta2也可能接收到该transferframe,从而sta1可能被设置intra-bssnav,sta2可能被设置basicnav,该intra-bssnav和basicnav的值均等于上述第二时长的值。

s802、协作ap向主ap发送returnframe。相应的,主ap从协作ap接收returnframe。

该returnframe包括duration字段,该duration字段的值设置为第三时长,该第三时长的结束时刻不晚于returnframe之后主ap发送的第一个无线帧(即图7中的无线帧1)的结束时刻再加上sifs时间。

需要说明的是,本申请实施例中,在步骤s802之前,还可能存在一些无线帧的交互流程,如图7中由协作ap发送一个触发帧,用于触发sta1和sta2分别向协作ap发送bfr(记作bfr(协作ap)),本申请实施例对此不作具体限定。此外,在步骤s801之前和步骤s802之后也可能存在一些无线帧的交互流程,具体可参考图7,在此不再赘述。

需要说明的是,在本申请实施例中,对于主ap如何将txop使用权转让给协作ap不做具体限定,并且对transferframe和returnframe的具体结构不做限定。本申请实施例是以图7中的流程为例进行解释,其不限定于只在多ap协作信道测量的流程,所有涉及到主ap需要将txop使用权暂时转让给协作ap,由协作ap单独进行发送的流程中均可以使用本申请实施例的方案,在此统一说明,以下不再赘述。

一方面,由于transferframe的duration字段的值被设置为第二时长,第二时长的结束时刻不晚于触发帧的结束时刻或者第二时长的结束时刻不晚于触发帧的下一个无线帧的开始时刻,因此当协作ap发送触发帧以触发sta1和sta2分别向协作ap反馈它们各自与协作ap之间的信道信息时,在sta1向协作ap反馈sta1与协作ap之间的信道信息之前,sta1中被设置的intra-bssnav已经减为0,因此可以在假设sta1的物理载波侦听为空闲、且sta1的basicnav为0的前提下,顺利向协作ap发送下一个无线帧(如图7中的bfr(协作ap));同时,在sta2向协作ap反馈sta2与协作ap之间的信道信息之前,sta2中被设置的basicnav已经减为0,因此可以在假设sta2的物理载波侦听为空闲的前提下,顺利向关联的协作ap发送下一个无线帧(如图7中的bfr(协作ap))。另一方面,由于returnframe包括duration字段,该duration字段的值设置为第三时长,该第三时长的结束时刻不晚于returnframe之后主ap发送的第一个无线帧的结束时刻再加上sifs时间,也就是说,在returnframe之后主ap发送第一个无线帧为触发帧时,在回复tbppdu之前sta1被协作ap设置的basicnav可以减为0,从而可以解决当主ap调度其关联的sta1时,sta1可能由于被协作ap扩展txop之后设置basicnav,而无法响应主ap调度的问题。

上述步骤s801至s802中的主ap或协作ap的动作可以由图3所示的通信设备300中的处理器301调用存储器303中存储的应用程序代码来执行,本申请实施例对此不作任何限制。

上述实施例使用了逐步扩展txop时长的方式,其中讨论了主ap如何设置transferframe的duration字段,但是没有考虑若在transferframe之前主ap已经有其它无线帧发送的情况下应该如何设置transferframe之前的其它无线帧的duration数值。其中,若在transferframe之前的无线帧已经将txop时长设置为很长,即txop时长的结束时刻超过了触发帧的下一个无线帧的开始时刻,则由于txop长度不能缩短(除非使用cf-end将信道进行释放),因此即使将transferframe的duration字段的值设置为上述第二时长,但是该协作ap关联的sta2已经设置了比transferframe中指示的第二时长更长的basicnav,因此不会基于该transferframe更新basicnav。这样的结果就是协作ap关联的sta2被触发帧触发之后由于basicnav的数值不为0,而无法回复下一个无线帧。

为解决该问题,本申请实施例中,当主ap设置transferframe之前的其它无线帧的duration字段的时长时,其设置的duration字段的时长的结束时刻不能超过主ap将txop使用权暂时转让给协作ap之后的触发帧的下一个无线帧的开始时刻。也就是说,在对transferframe之前的无线帧设置nav时就需要考虑transferframe的nav设置限制。

通常在进行数据传输之前要先进行信道预留,例如使用rts/cts(针对单站点)或者多用户(multi-user,mu)-rts/cts(针对多站点)交互。考虑到rts/cts只能与单个的sta进行交互效率很低,而本申请实施例中涉及到多个bss中的多个ap和多个sta的通信,因此使用mu-rts/cts更为合适。

图9为现有的murts帧结构,包括帧控制字段、时长字段、ra字段、ta字段、一个或多个公共信息字段(图9中示例性的画出两个公共信息字段)、用户信息字段、……、填充字段和帧序列校验字段。其中,用户信息字段包括aid12字段、ru分配(ruallocation)字段、上行前向纠错(forwarderrorcorrection,fec)编码类型(ulfeccodingtype)字段、上行mcs(ulmcs)字段、上行双载波调制(dualcarriermodulation,dcm)(uldcm)字段、空间流(spatialstream,ss)分配/随机接入资源单元(randomaccessresourceunit,ra-ru)信息(ssallocation/ra-ruinformation)字段、上行目标接收信号强度指示(receivedsignalstrengthindication,rssi)(ultargetrssi)字段和预留(reserved)字段。目前,ulmcs字段、ulfeccodingtype字段、uldcm字段、ssallocation/ra-ruinformation字段和ultargetrssi字段也为预留字段,具体每个字段的描述可参考现有murts帧结构的相关说明,在此不再赘述。

但是,目前的mu-rts/cts不能支持跨bss进行交互,如果多个ap分别就自己关联的sta进行交互也存在问题,因为当主ap与自己的关联的sta进行mu-rts/cts交互之后,协作ap及其关联的sta都被设置basicnav,而无法回应cts帧。因此,如何通过mu-rts/cts交互在多ap协作场景下进行信道保护,是目前亟待解决的一个问题。

以图2所述的wlan通信系统的主ap、主ap关联的任意一个第一sta(如sta1)、协作ap、协作ap关联的任意一个第二sta(如sta2)之间的通信为例,如图10所示,为本申请实施例提供的一种协作通信方法,该方法包括如下步骤:

s1001、主ap发送mu-rts帧。该mu-rts帧的发送地址字段的值被设置为主ap的mac地址,该mu-rts帧的接收地址字段的值被设置为广播地址。

如图10所示,本申请实施例中,主ap发送的mu-rts帧可以被主ap关联的sta1、协作ap、协作ap以及协作ap关联的sta2接收。

一种可能的实现方式中,主ap给主ap关联的sta、主ap对应的协作ap、以及协作ap关联的sta都分配一个唯一的aid。并且,主ap为主ap关联的sta、协作ap以及协作ap关联的sta分别分配一个用户信息字段,该用户信息字段包括aid12字段,aid12字段的值被设置为对应主ap关联的sta的aid的低12位比特、协作ap的aid的低12位比特或者协作ap关联的sta的aid的低12位比特。也就是说,步骤s1001中的mu-rts帧包括主ap关联的sta1的用户信息字段,协作ap的用户信息字段以及协作ap关联的sta2的用户信息字段。主ap关联的sta1的用户信息字段包括第一aid12字段,第一aid12字段的值被设置为主ap关联的sta1的aid的低12位比特。协作ap的用户信息字段包括第二aid12字段,第二aid12字段的值被设置为协作ap的aid的低12位比特。协作ap关联的sta2的用户信息字段包括第三aid12字段,第三aid12字段的值被设置为协作ap关联的sta2的aid的低12位比特。其中,主ap为主ap关联的sta1、协作ap以及协作ap关联的sta2分配的aid均不同。

当然,主ap关联的sta的用户信息字段,主ap对应的协作ap的用户信息字段以及协作ap关联的sta的用户信息字段中还可以包括图9中所示的ruallocation字段、ulfeccodingtype字段、ulmcs字段、uldcm字段、ssallocation/ra-ruinformation字段、ultargetrssi字段和reserved字段,本申请实施例对此不作具体限定。

可选的,该实现方式中,主ap给协作ap关联的sta分配aid时,可以是主ap先将协作ap关联的sta的aid知会给协作ap,然后由协作ap转发给协作ap关联的sta;也可以由主ap预先给协作ap分配一段aid空间,协作ap在该aid空间内选择aid分配给协作ap关联的每个sta;还可以是主ap直接通过交互给协作ap关联的sta分配aid,本申请实施例对此不作具体限定。

由于主ap关联的sta的aid、主ap对应的协作ap的aid以及协作ap关联的sta的aid是由主ap分配的,具有唯一性,因此被调度的主ap关联的sta、协作ap以及协作ap关联的sta均可以根据调度响应cts帧(如执行下述步骤s1002-s1004),从而实现了通过mu-rts/cts交互在多ap协作场景下进行信道保护的目的。

另一种可能的实现方式中,可以不修改现有的aid分配机制,即与主ap关联的sta的aid以及主ap对应的协作ap的aid由主ap分配,与协作ap关联的sta的aid由协作ap进行分配。也就是说,主bss中的sta的aid和协作bss中的sta的aid将不再具有唯一性。并且,主ap为主ap关联的sta、协作ap以及协作ap关联的sta分别分配一个用户信息字段,该用户信息字段包括aid12字段,aid12字段的值被设置为对应主ap关联的sta的aid的低12位比特、协作ap的aid的低12位比特或者协作ap关联的sta的aid的低12位比特。此外,用户信息字段中还包括设定字段,设定字段用于指示对应站点关联的bss的bsscolor,其中,对于主ap关联的sta,其bsscolor设置为主bss的bsscolor;对于协作ap关联的sta,其bsscolor设置为各自关联bss的bsscolor,对于协作ap,其bsscolor设置为协作bss的bsscolor。也就是说,步骤s1001中的mu-rts帧包括主ap关联的sta1的用户信息字段,协作ap的用户信息字段、协作ap关联的sta2的用户信息字段。主ap关联的sta1的用户信息字段包括第一aid12字段和第一设定字段,第一aid12字段的值被设置为主ap关联的sta1的aid的低12位比特,第一设定字段用于指示第一bsscolor,该第一bsscolor为sta1关联的主bss的bsscolor。协作ap的用户信息字段包括第二aid12字段和第二设定字段,第二aid12字段的值被设置为协作ap的aid的低12位比特,第二设定字段用于指示第二bsscolor,该第二bsscolor为协作ap关联的协作bss的bsscolor。协作ap关联的sta2的用户信息字段包括第三aid12字段和第三设定字段,第三aid12字段的值被设置为协作ap关联的sta2的aid的低12位比特,第三设定字段用于指示第三bsscolor,该第三bsscolor为sta2关联的协作bss的bsscolor。

一个示例中,由于图9所示的用户信息字段中的ulmcs字段、ulfeccodingtype字段、uldcm字段、ssallocation/ra-ruinformation字段和ultargetrssi字段为预留字段,因此本申请实施例中,上述的设定字段(包括第一设定字段、第二设定字段或第三设定字段)可以为ulmcs字段、ulfeccodingtype字段、uldcm字段、ssallocation/ra-ruinformation字段和ultargetrssi字段中的部分字段,即可以使用ulmcs字段、ulfeccodingtype字段、uldcm字段、ssallocation/ra-ruinformation字段和ultargetrssi字段中的部分字段来指示对应的bsscolor。例如,可以通过用户信息字段中的ssallocation/ra-ruinformation字段中的6比特指示对应的bsscolor;或者,可以通过用户信息字段中的ulfeccodingtype字段中的1比特、ulmcs字段中的4比特和uldcm字段中的1比特指示对应的bsscolor。

可选的,该实现方式中,用户信息字段还可以进一步使用辅助指示,以使得接收站点明确该用户信息字段是否携带了bsscolor。例如可以使用用户信息字段中的ulmcs字段、ulfeccodingtype字段、uldcm字段、ssallocation/ra-ruinformation字段和ultargetrssi字段中的一个比特来指示是否携带了对应的bsscolor。该比特设置为0代表不携带对应的bsscolor,该比特设置为1代表携带了对应的bsscolor。

可选的,该实现方式中,可以使用另一种触发类型(triggertype)来指示目前发送的是跨bss的mu-rts。其中,triggertype是图9中的公共信息字段的一个子字段,用于区分触发帧的类型,在此不再赘述。

通过用户信息字段中的设定字段以及aid12字段,被调度的主ap关联的sta、协作ap以及协作ap关联的sta均可以根据调度响应cts帧(如执行下述步骤s1002-s1004),从而实现了通过mu-rts/cts交互在多ap协作场景下进行信道保护的目的。

s1002、主ap关联的sta1从主ap接收mu-rts帧,并根据mu-rts帧的调度,向主ap发送第一cts帧。相应的,主ap从主ap关联的sta1接收第一cts帧。

本申请实施例中,主ap关联的sta1根据mu-rts帧的调度,向主ap发送第一cts帧,包括:主ap关联的sta1根据mu-rts帧中的sta1的用户信息字段,可以获知mu-rts帧用于调度sta1,进而sta1可以在确定basicnav为0,且物理载波侦听结果为空闲的情况下,向主ap发送第一cts帧。

s1003、协作ap从主ap接收mu-rts帧,并根据mu-rts帧的调度,向主ap发送第二cts帧。相应的,主ap从协作ap接收第二cts帧。

本申请实施例中,协作ap根据mu-rts帧的调度,向主ap发送第二cts帧,包括:协作ap根据mu-rts帧中的协作ap的用户信息字段,可以获知mu-rts帧用于调度协作ap,并且协作ap确定协作ap记录的为协作ap设置basicnav的站点的mac地址与mu-rts帧的发送地址相同,进而在确定intra-bssnav为0,且物理载波侦听结果为空闲的情况下,向主ap发送第二cts帧。即,本申请实施例引入一种规则,mu-rts帧的发送地址为主ap的mac地址,且协作ap记录的为协作ap设置basicnav的站点的mac地址为主ap的mac地址,则在协作ap确定intra-bssnav为0,且物理载波侦听结果为空闲的情况下,向主ap发送第二cts帧,不用考虑协作ap中的basicnav是否为0。

s1004、协作ap关联的sta2从主ap接收mu-rts帧,并根据mu-rts帧的调度,向主ap发送第三cts帧。相应的,主ap从协作ap关联的sta2接收第三cts帧。

需要说明的是,在上述流程中,并不要求步骤s1002至s1004全部都发生,步骤s1002至s1004中的至少一个步骤发生,主ap就可以确认mu-rts/cts交互成功。此外,步骤s1001中主ap发送的mu-rts也可以携带主ap关联的sta的用户信息字段,协作ap的用户信息字段以及协作ap关联的sta的用户信息字段中的至少一种用户信息字段,例如,在实际应用中,主ap需要保护与协作ap之间的信道,则ap发送的mu-rts可只携带协作ap的用户信息字段。

本申请实施例中,协作ap关联的sta2根据mu-rts帧的调度,向主ap发送第三cts帧,包括:协作ap关联的sta2根据mu-rts帧中的sta2的用户信息字段,可以获知mu-rts帧用于调度sta2,并且sta2确定sta2记录的为sta2设置basicnav的站点的mac地址与mu-rts帧的发送地址相同,进而在确定intra-bssnav为0,且物理载波侦听结果为空闲的情况下,向主ap发送第三cts帧。即,本申请实施例引入一种规则,mu-rts帧的发送地址为主ap的mac地址,且协作ap关联的sta2记录的为sta2设置basicnav的站点的mac地址为主ap的mac地址,则在sta2确定intra-bssnav为0,且物理载波侦听结果为空闲的情况下,向主ap发送第三cts帧,不用考虑sta2中的basicnav是否为0。

上述步骤s1001至s1004中的主ap、主ap关联的sta1、协作ap或者协作ap关联的sta2的动作可以由图3所示的通信设备300中的处理器301调用存储器303中存储的应用程序代码来执行,本申请实施例对此不作任何限制。

需要说明的是,本申请上述实施例均是以协作ap关联的sta有两个nav为例进行说明,当协作ap关联的sta只有一个nav时,协作ap关联的sta也会被主ap的announcement帧设置nav,从而无法响应触发帧,其问题是相同的。通过本申请上述实施例提供的协作通信方法也同样可以解决该问题,即本申请实施例提供的协作通信方法也同样使用于协作ap关联的sta只支持一个nav的情况,在此统一说明,以下不再赘述。

可以理解的是,以上各个实施例中,由主ap实现的方法和/或步骤,也可以由可用于主ap的部件实现;由协作ap实现的方法和/或步骤,也可以由可用于协作ap的部件实现;由协作ap关联的第二站点实现的方法和/或步骤,也可以由可用于协作ap关联的第二站点的部件实现。

上述主要从各个网元之间交互的角度对本申请实施例提供的方案进行了介绍。相应的,本申请实施例还提供了通信装置,该通信装置可以为上述方法实施例中的主ap,或者包含上述主ap的装置,或者为可用于主ap的部件;或者,该通信装置可以为上述方法实施例中的协作ap,或者包含上述协作ap的装置,或者为可用于协作ap的部件;或者,该通信装置可以为上述方法实施例中的协作ap关联的第二站点,或者包含上述协作ap关联的第二站点的装置,或者为可用于协作ap关联的第二站点的部件。可以理解的是,该通信装置为了实现上述功能,其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本申请的范围。

比如,以通信装置为上述方法实施例中的协作ap或协作ap内的芯片为例,图11示出了一种通信装置110的结构示意图,该通信装置110可以用于实现上述实施例中协作ap的任意功能。该通信装置110包括收发模块1101和处理模块1102。所述收发模块1101,也可以称为收发单元用以实现收发功能,例如可以是收发电路,收发机,收发器或者通信接口。

一种可能的实现方式中,收发模块1101,用于从主接入点接收公告帧,公告帧包括duration字段,duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标触发帧的结束时刻或者第一时长的结束时刻不晚于目标tbppdu的开始时刻,目标触发帧为公告帧的下一个无线帧,目标tbppdu为目标触发帧的响应帧,其中,目标触发帧包括第二触发帧,目标tbppdu包括第二tbppdu;处理模块1102,用于生成第二触发帧;收发模块1101,还用于向协作接入点关联的第二站点发送第二触发帧;收发模块1101,还用于从第二站点接收第二tbppdu。

可选的,处理模块1102,还用于在收发模块1101向第二站点发送第二触发帧之前,确定公告帧的发送地址与通信装置110记录的为协作接入点设置basicnav的站点的mac地址相同。

另一种可能的实现方式中,收发模块1101,用于从主接入点接收公告帧;处理模块1102,用于确定公告帧的发送地址与协作接入点记录的为协作接入点设置第一basicnav的站点的mac地址相同;收发模块1101,还用于向协作接入点关联的第二站点发送下一个无线帧。

可选的,收发模块1101,还用于从第二站点接收第二tbppdu。

可选的,处理模块1102,还用于在收发模块1101向第二站点发送第二触发帧之前,将第一basicnav设置为0。

可选的,收发模块1101,还用于在收发模块1101向第二站点发送第二触发帧之前,忽略第一basicnav之后,确定协作接入点中的第二basicnav的数值为0。

其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。

在本实施例中,该通信装置110以采用集成的方式划分各个功能模块的形式来呈现。这里的“模块”可以指特定asic,电路,执行一个或多个软件或固件程序的处理器和存储器,集成逻辑电路,和/或其他可以提供上述功能的器件。在一个简单的实施例中,本领域的技术人员可以想到该通信装置110可以采用图3所示的通信设备300的形式。

比如,图3所示的通信设备300中的处理器301可以通过调用存储器303中存储的计算机执行指令,使得通信设备300执行上述方法实施例中的协作通信方法。

具体的,图11中的收发模块1101和处理模块1102的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现。或者,图11中的处理模块1102的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现,图11中的收发模块1101的功能/实现过程可以通过图3中所示的通信设备300中的通信接口304来实现。

由于本实施例提供的通信装置110可执行上述的协作通信方法,因此其所能获得的技术效果可参考上述方法实施例,在此不再赘述。

图12示出了一种通信装置120的结构示意图,该通信装置120可以为上述方法实施例中的主ap或主ap内的芯片,可以实现上述实施例中主ap所涉及的方法和功能。该通信装置120包括收发模块1201和处理模块1202。所述收发模块1201,也可以称为收发单元用以实现收发功能,例如可以是收发电路,收发机,收发器或者通信接口。

其中,处理模块1202,用于生成公告帧,公告帧包括duration字段,duration字段的值被设置为第一时长,第一时长的结束时刻不晚于目标触发帧的结束时刻或者第一时长的结束时刻不晚于目标的tbppdu的开始时刻,目标触发帧为公告帧的下一个无线帧,目标tbppdu为目标触发帧的下一个无线帧,其中,目标触发帧包括第一触发帧,目标tbppdu包括第一tbppdu;收发模块1201,用于发送公告帧;处理模块1202,还用于生成第一触发帧;收发模块1201,还用于向主接入点关联的第一站点发送第一触发帧;收发模块1201,还用于从第一站点接收第一tbppdu。

其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。

在本实施例中,该通信装置120以采用集成的方式划分各个功能模块的形式来呈现。这里的“模块”可以指特定asic,电路,执行一个或多个软件或固件程序的处理器和存储器,集成逻辑电路,和/或其他可以提供上述功能的器件。在一个简单的实施例中,本领域的技术人员可以想到该通信装置120可以采用图3所示的通信设备300的形式。

比如,图3所示的通信设备300中的处理器301可以通过调用存储器303中存储的计算机执行指令,使得通信设备300执行上述方法实施例中的通信方法。

具体的,图12中的收发模块1201和处理模块1202的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现。或者,图12中的处理模块1202的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现,图12中的收发模块1201的功能/实现过程可以通过图3中所示的通信设备300中的通信接口304来实现。

由于本实施例提供的通信装置120可执行上述的通信方法,因此其所能获得的技术效果可参考上述方法实施例,在此不再赘述。

图13示出了一种通信装置130的结构示意图,该通信装置130可以为协作ap关联的第二站点和第二站点内的芯片,用于实现上述方法实施例中第二站点的方法和功能。该通信装置130包括收发模块1301和处理模块1302。所述收发模块1301,也可以称为收发单元用以实现收发功能,例如可以是收发电路,收发机,收发器或者通信接口。

其中,收发模块1301,用于从协作接入点接收第二触发帧;处理模块1302,用于确定通信装置130记录的为通信装置130设置第三basicnav的站点为协作接入点对应的主接入点;收发模块1301,还用于向协作接入点发送第二tbppdu。

可选的,收发模块1301,还用于接收公告帧,其中,公告帧为第二触发帧的上一个无线帧;处理模块1302,还用于确定通信装置130记录的为通信装置130设置第三basicnav的站点为协作接入点所关联的主接入点,包括:处理模块1302,还用于确定公告帧的发送地址与协作接入点记录的为协作接入点设置第三basicnav的站点的mac地址相同。

可选的,第二触发帧包括协作接入点对应的主接入点的mac地址;处理模块1302,用于确定通信装置130记录的为通信装置130设置第三basicnav的站点为协作接入点所关联的主接入点,包括:处理模块1302,用于确定主接入点的mac地址与协作接入点记录的为协作接入点设置第三basicnav的站点的mac地址相同。

可选的,第二触发帧中包括发送地址字段,发送地址字段的值被设置为协作接入点对应的主接入点的mac地址;处理模块1302,用于确定通信装置130记录的为通信装置130设置第三basicnav的站点为协作接入点所关联的主接入点,包括:处理模块1302,用于确定第二触发帧的发送地址与协作接入点记录的为协作接入点设置第三basicnav的站点的mac地址相同。

可选的,处理模块1302,还用于在收发模块1301向协作接入点发送第二tbppdu之前,将第三basicnav设置为0。

可选的,处理模块1302,还用于在收发模块1301向协作接入点发送第二tbppdu之前,忽略第三basicnav之后,确定通信装置130中的第四basicnav的数值为0。

其中,上述方法实施例涉及的各步骤的所有相关内容均可以援引到对应功能模块的功能描述,在此不再赘述。

在本实施例中,该协作ap关联的通信装置130以采用集成的方式划分各个功能模块的形式来呈现。这里的“模块”可以指特定asic,电路,执行一个或多个软件或固件程序的处理器和存储器,集成逻辑电路,和/或其他可以提供上述功能的器件。在一个简单的实施例中,本领域的技术人员可以想到该协作ap关联的通信装置130可以采用图3所示的通信设备300的形式。

比如,图3所示的通信设备300中的处理器301可以通过调用存储器303中存储的计算机执行指令,使得通信设备300执行上述方法实施例中的通信方法。

具体的,图13中的收发模块1301和处理模块1302的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现。或者,图13中的处理模块1302的功能/实现过程可以通过图3所示的通信设备300中的处理器301调用存储器303中存储的计算机执行指令来实现,图13中的收发模块1301的功能/实现过程可以通过图3中所示的通信设备300中的通信接口304来实现。

由于本实施例提供的通信装置130可执行上述的通信方法,因此其所能获得的技术效果可参考上述方法实施例,在此不再赘述。

需要说明的是,以上模块或单元的一个或多个可以软件、硬件或二者结合来实现。当以上任一模块或单元以软件实现的时候,所述软件以计算机程序指令的方式存在,并被存储在存储器中,处理器可以用于执行所述程序指令并实现以上方法流程。该处理器可以内置于soc(片上系统)或asic,也可是一个独立的半导体芯片。该处理器内处理用于执行软件指令以进行运算或处理的核外,还可进一步包括必要的硬件加速器,如现场可编程门阵列(fieldprogrammablegatearray,fpga)、pld(可编程逻辑器件)、或者实现专用逻辑运算的逻辑电路。

当以上模块或单元以硬件实现的时候,该硬件可以是cpu、微处理器、数字信号处理(digitalsignalprocessing,dsp)芯片、微控制单元(microcontrollerunit,mcu)、人工智能处理器、asic、soc、fpga、pld、专用数字电路、硬件加速器或非集成的分立器件中的任一个或任一组合,其可以运行必要的软件或不依赖于软件以执行以上方法流程。

可选的,本申请实施例还提供了一种通信装置(例如,该通信装置可以是芯片或芯片系统),该通信装置包括处理器,用于实现上述任一方法实施例中的方法。在一种可能的设计中,该通信装置还包括存储器。该存储器,用于保存必要的程序指令和数据,处理器可以调用存储器中存储的程序代码以指令该通信装置执行上述任一方法实施例中的方法。当然,存储器也可以不在该通信装置中。该通信装置是芯片系统时,可以由芯片构成,也可以包含芯片和其他分立器件,本申请实施例对此不作具体限定。

其中,在本申请的描述中,除非另有说明,“/”表示前后关联的对象是一种“或”的关系,例如,a/b可以表示a或b;本申请中的“和/或”仅仅是一种描述关联对象的关联关系,表示可以存在三种关系,例如,a和/或b,可以表示:单独存在a,同时存在a和b,单独存在b这三种情况,其中a,b可以是单数或者复数。并且,在本申请的描述中,除非另有说明,“多个”是指两个或多于两个。“以下至少一项(个)”或其类似表达,是指的这些项中的任意组合,包括单项(个)或复数项(个)的任意组合。例如,a,b,或c中的至少一项(个),可以表示:a,b,c,a-b,a-c,b-c,或a-b-c,其中a,b,c可以是单个,也可以是多个。另外,为了便于清楚描述本申请实施例的技术方案,在本申请的实施例中,采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样并不对数量和执行次序进行限定,并且“第一”、“第二”等字样也并不限定一定不同。同时,在本申请实施例中,“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言,使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念,便于理解。

在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时,可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digitalsubscriberline,dsl))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质(例如,软盘、硬盘、磁带),光介质(例如,dvd)、或者半导体介质(例如固态硬盘(solidstatedisk,ssd))等。

尽管在此结合各实施例对本申请进行了描述,然而,在实施所要求保护的本申请过程中,本领域技术人员通过查看所述附图、公开内容、以及所附权利要求书,可理解并实现所述公开实施例的其他变化。在权利要求中,“包括”(comprising)一词不排除其他组成部分或步骤,“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施,但这并不表示这些措施不能组合起来产生良好的效果。

尽管结合具体特征及其实施例对本申请进行了描述,显而易见的,在不脱离本申请的精神和范围的情况下,可对其进行各种修改和组合。相应地,本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明,且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1