CN102801507B - 无线通信设备 - Google Patents

无线通信设备 Download PDF

Info

Publication number
CN102801507B
CN102801507B CN201210247057.2A CN201210247057A CN102801507B CN 102801507 B CN102801507 B CN 102801507B CN 201210247057 A CN201210247057 A CN 201210247057A CN 102801507 B CN102801507 B CN 102801507B
Authority
CN
China
Prior art keywords
frame
terminal
time
data
transmission
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.)
Active
Application number
CN201210247057.2A
Other languages
English (en)
Other versions
CN102801507A (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.)
Toshiba Corp
Original Assignee
Toshiba Corp
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 Toshiba Corp filed Critical Toshiba Corp
Publication of CN102801507A publication Critical patent/CN102801507A/zh
Application granted granted Critical
Publication of CN102801507B publication Critical patent/CN102801507B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

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/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
    • H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
    • 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/1854—Scheduling and prioritising arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access, e.g. scheduled or random access
    • H04W74/08—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access]
    • H04W74/0808—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using carrier sensing, e.g. as in CSMA
    • H04W74/0816—Non-scheduled or contention based access, e.g. random access, ALOHA, CSMA [Carrier Sense Multiple Access] using carrier sensing, e.g. as in CSMA carrier sensing with collision avoidance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/18—Negotiating wireless communication parameters
    • H04W28/22—Negotiating communication rate
    • 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]

Abstract

一种无线通信设备（202），用于与发起站（201）执行双向通信。对该设备分配用于从发起站进行数据发送的分配时段。该设备包括用于生成包括针对从所述发起站接收到的数据的确认帧（310）的第一物理帧并生成聚集有寻址到所述发起站的多个传输数据帧（312到315）的第二物理帧的装置。该设备还包括用于在所述分配时段期间按第一传输率发送所述第一物理帧并按第二传输率发送所述第二物理帧的装置。

Description

无线通信设备
本申请是申请日为2006年3月27日、申请号为200680017109.X、发明名称为“按第一发送率在额外物理帧中发送确认的响应器(例如802.11N)”的发明专利申请的分案申请。
技术领域
本发明涉及实现无线通信方案，在包括诸如通过无线介质执行数据发送/接收的蜂窝电话和无线LAN之类的无线通信设备的无线通信系统中，该无线通信方案即使在差无线传播环境下也是鲁棒的。
背景技术
根据针对IEEE 802.11标准规范实现了与介质访问控制（MAC）层的服务质量（QoS）相关联的增强效果的无线LAN规范IEEE802.11e，作为获取其中发送端通信设备（发起站）可以发送数据的发送机会（TXOP）时段的方法，存在增强型分布式信道接入（EDCA）方案和HCF受控信道接入（HCCA）方案。（见IEEE 802.11e草案13.0和IEEE P802.11e/D13.0，2005年1月）。
在以更快的传输为目标的IEEE 802.11n中，已提出了诸如聚集MAC协议数据单元（A-MPDU）和高吞吐量PHY（HTP）突发串之类的多个聚集方法，以减少在IEEE 802.11e中的发送/接收操作中在各个帧之间存在的开销。
根据A-MPDU，发送通过用一个物理层（PHY）帧合并多个MAC帧与而获得的聚集帧，其中一个字段被附加到各帧的头部，每个所述字段用于标识一个MAC帧。（见TGn Sync Proposal TechnicalSpecification,IEEE 802.11-04/889r6,2005年5月.）。
在HTP突发串中，按比用于常规突发传输技术的短帧间间隔（SIFS）时段要短的缩减帧间间隔（RIFS）的间隔发送PHY帧。根据HTP突发方式，当要按不同发送率或不同发送功率向多个接收端通信设备（响应器，responder）发送帧时，在各个PHY帧之间设置RIFS时间以按不同发送率或不同发送功率发送相应的PHY帧。（见TGnSync Proposal Technical Specification,IEEE 802.11-04/889r6,2005年5月和WWiSE Proposal:High throughout extension to the 802.11Standard,IEEE 802.11-05/0149r2,2005年3月。）
在IEEE 802.11n中，已提出一种通过如下技术来改进传输效率的方法，所述技术通过使获得TXOP时间的发起站将所述TXOP时间（TXOP分配时间）的一部分分配给响应器，而在由发起站获得的TXOP时间期间基于捎带确认（piggyback）技术执行双向通信，即，反向（RD）技术方案。
在IEEE 802.11n中，当将A-MPDU用于RD方案（其中发起站在通过EDCA方案或HCCA方案获得的TXOP时间期间利用捎带确认技术与响应器执行双向通信）时，发起站发送发起站聚集控制（IAC）帧，然后响应器在该帧的发送之后SIFS时间时返回响应器聚集控制（RAC）帧，由此执行IAC-RAC帧交换。若在执行了这种IAC-RAC帧交换的假设下采用RD方案，则发起站向响应器发送IAC帧，在该IAC帧中写有表示在获得的TXOP时间期间采用RD方案的信息。当接收到IAC帧并且被通知表示在TXOP时间内将RD方案用于通信的信息时，响应器在RAC帧中写入该响应器在分配了该TXOP时间的一部分时可以发送的数据帧的数量和传输数据率之后发送寻址到发起站的该RAC帧。发起站根据在RAC帧中写有的数据帧数量和传输数据率来确定反向准予（RDG）持续时间作为待分配给响应器的TXOP时间的一部分。发起站将所确定的RDG持续时间写在IAC帧中，将该IAC帧附加到待发送的聚集帧的头部，然后在完成接收前一RAC帧之后SIFS时间时发送聚集帧。
在此情况下，数据帧确认方法（AckPolicy）是BlockAck方案。若采用在IEEE 802.11e中定义的立即BlockAck方案（其中当接收到确认请求帧（BlockAck请求帧）时，响应器在经过了SIFS时间之后发送确认帧（BlockAck帧））作为该BlockAck方案，则还将BlockAckRequest帧与待从发起站发送的聚集帧的末端并合。（然而，注意，在IEEE 802.11n中提出的隐式块确认方案中，略去了BlockAckRequest。）
在上述情况下，当在从发起站接收到聚集帧之后经过了SIFS时间时，响应器必须通过块确认帧发送接收状态。在RD方案中，当在经过了SIFS时间之后要从响应器返回块确认帧时，响应器如捎带确认技术那样发送并合有多个数据帧和一块确认帧的聚集帧。发送该聚集帧所花费的时间必须不超过IAC帧中写有的RDG持续时间。当请求发送聚集帧的RDG持续时间时，响应器在RAC帧中插入准备待发送的数据帧（即，此时安排要发送的帧）的数量和传输数据率，并在将该帧附加到此时待发送的聚集帧的头部时返回该帧。（见TGn SyncProposal Technical Specification,IEEE 802.11-04/889r6,2005年5月）。
然而，在上述RD方案中，由于将BlockAck帧和BlockAckRequest帧与待发送的数据帧并合成一个PHY帧，因此按同一传输率发送这些数据帧、BlockAck帧以及BlockAckRequest帧。因此，在这些数据帧、BlockAck帧以及BlockAckRequest帧中由于无线传播环境的劣化或冲突的出现而产生的传输错误的概率变得几乎相同。
总的来说，由于在采用高传输率时传输错误概率会增大，因此必须降低聚集帧的传输率以增大BlockAck帧和BlockAckRequest帧的传输成功概率。然而，降低传输率将延长聚集帧的传输长度，导致吞吐量的降低。
发明内容
相对照的是，由于增大传输率以实现对数据帧的高速传输/接收，BlockAck帧和BlockAckRequest帧的传输成功概率会降低。结果，未能接收到BlockAck帧或BlockAckRequest帧的发起站或响应器需要再发送它。这会导致通信效率的极度劣化，即，吞吐量的很大减小。本发明被提出来以解决上述问题，并以增大用于确认的帧（例如BlockAck帧或BlockAckRequest帧）的传输成功概率为其目的。
根据本发明的一个方面，提供了一种与发起站执行双向通信的无线通信设备。从发起站对该设备分配用于进行数据传输的分配时段。该设备包括如下装置：该装置用于生成包括有针对从发起站接收到的多个数据帧的确认帧的第一物理帧，并生成聚集有寻址到发起站的多个传输数据帧的第二物理帧。该设备还包括用于在所述分配时段期间按第一传输率发送第一物理帧并按第二传输率发送第二物理帧的装置。
附图说明
图1是根据第一实施例的无线通信设备的框图；
图2是根据第一实施例的时序图；
图3是与第一实施例中的终端A的操作相关联的流程图；
图4是与第一实施例中的终端B的操作相关联的流程图；
图5是示出第一实施例中的终端之间的位置关系的图；
图6是根据第一实施例的第二修改例的无线通信设备的框图；
图7是与根据第一实施例的第二修改例的终端A的操作相关联的流程图；
图8是与根据第一实施例的第二修改例的终端B的操作相关联的流程图；
图9是根据第一实施例的第三修改例的无线通信设备的框图；
图10是与根据第一实施例的第三修改例的终端A的操作相关联的流程图；
图11是与根据第一实施例的第三修改例的终端B的操作相关联的流程图；
图12是根据第一实施例的第四修改例的无线通信设备的时序图；
图13是根据第二实施例的时序图；
图14是根据第三实施例的时序图；
图15是与第四实施例中的终端B的操作相关联的流程图；
图16是示出第四实施例中的终端之间的位置关系的图；
图17是根据第五实施例的时序图；
图18是与第五实施例中的终端A的操作相关联的流程图；
图19是与第五实施例中的终端B的操作相关联的流程图；
图20是根据第六实施例的时序图；
图21是与第六实施例中的终端A的操作相关联的流程图；
图22是根据第七实施例的时序图；
图23A到23D是示出第十实施例中的帧配置的图；
图24是根据第十一实施例的时序图；以及
图25是根据第十二实施例的时序图。
具体实施方式
（第一实施例）
图1是与支持在IEEE 802.11n无线LAN通信规范中提出的内容的无线通信设备101的示例有关的框图。即，将在如下假设下进行以下描述：支持IEEE 802.11n中提出的多输入多输出（MIMO）方案中的高传输率和将频带从20MHz频带扩展到40MHz频带的传输方案。
假设下述IEEE 802.11n中提出的内容包括所有IEEE 802.11标准规范、IEEE 802.11a/b/g/e等（包括那些被视为修正、推荐准则等的内容）。
不必说，IEEE 802.11n是一示例，总体上可以将本发明应用于无线通信方案。
无线通信设备101包括传输数据管理单元102、访问控制单元103、帧生成/传输处理单元104以及接收处理单元105。
传输数据管理单元102包括对传输数据进行缓冲的传输队列106。传输数据管理单元102对传输队列106中的传输数据进行管理。
访问控制单元103执行诸如帧发送/接收处理和再发送处理的访问控制。由访问控制单元103处理的帧包括多个数据（Data）帧，这些数据帧包括在传输队列106中缓冲的传输数据。此外，这些帧包括控制和管理帧，如确认帧（BlockAck帧等）、IAC帧、RAC帧、RTS帧以及CTS帧。访问控制单元103包括发送/接收方法确定单元107、发送/接收状态管理单元108以及载波侦听单元109。
发送/接收方法确定单元107确定包括聚合方案、反向（RD）方案以及对RTS-CTS帧交换的执行/不执行在内的发送/接收方法。
发送/接收状态管理单元108执行访问控制，如与由数据发送/接收方法确定单元107确定的发送/接收方法相关联的发送/接收定时管理和再发送处理。
载波侦听单元109对接收处理单元105进行监测，并执行在由接收帧的持续时间字段中写有的网络分配向量（NAV）所表示的时间期间被设定为“忙”的虚拟载波侦听处理，和在接收功率大于预定值时被设定为“忙”的载波侦听处理。
帧生成/传输处理单元104生成控制帧和数据帧。帧生成/传输处理单元104还在执行帧聚集时执行发送处理。
接收处理单元105执行接收处理，如对接收帧的识别处理和对确认位图的生成。
图2是用于说明在按照RD方案执行发送/接收时通过采用HTP突发方案按不同传输率发送BlockAck帧和多个数据帧的方法的时序图。图3是与终端A 201的操作相关联的流程图。图4是与终端B202的操作相关联的流程图。
以下在如下假设下对双向通信进行描述：来自作为发起站的终端A 201的所有发送数据都寻址到作为响应器的终端B 202，并且来自终端B 202的所有发送数据都寻址到终端A 201。终端A 201和终端B 202均具有与无线通信设备101的布置相同的布置，并由与图1中的标号相同的标号来表示各终端的组成要素。
如图5所示，在该双向通信中，除了终端A 201和终端B 202以外，终端A 201和终端B 202所属的无线通信系统还包括发送数据不寻址到的终端C 203、终端D 204、终端E 205以及终端F 206。
当终端A 201和终端B 202开始执行双向通信时，终端C 203位于可以接收到来自终端A 201的发送波的范围207内和可以接收到来自终端B 202的发送波的范围208内。
当终端A 201和终端B 202开始执行双向通信时，终端D 204位于可以接收到来自终端A 201的发送波的范围207内但是位于可以接收到来自终端B 202的发送波的范围208之外。
当终端A 201和终端B 202开始执行双向通信时，终端E 205位于可以接收到来自终端A 201的发送波的范围207之外但是位于可以接收到来自终端B 202的发送波的范围208之内。
假设终端F 206在终端A 201和终端B 202开始执行双向通信时不能接收来自终端A 201和终端B 202的发送波，但是在终端A 201和终端B 202开始执行双向通信之后（即，在完成了RTS-CTS交换之后）可以接收来自终端A 201和终端B 202的发送波。
假设采用IEEE 802.11n中提出的BlockAck方案的ImplicitBlockAckRequest方案作为数据帧确认方法（AckPolicy）。在BlockAck方案中，接收器发送BlockAck帧作为对发送器所发送的帧的确认。在ImplicitBlockAckRequest方案中，发送器并不发送确认请求帧（BlockAckRequest帧）作为BlockAck帧发送请求。
假设终端A 201预先执行诸如与终端B 202的关联之类的管理帧交换，并且知道终端B 202支持RD方案以及终端B 202希望发送给终端A 201的数据量。
假设在该管理帧交换中要执行基于RD方案的协商。在此情况下，通过将对应的信息写在管理帧中，使得终端A 201和终端B 202都知道它们将在终端A 201首先发送的聚集帧304之后发送其间设置有RIFS时间的两个PHY帧。随后，终端A 201和终端B 202在基于RD方案的通信中在待命状态下等待其间设置有RIFS时间的两个PHY帧。
然而，可以限定成使得当（在不执行管理帧交换的情况下）要执行基于RD方案的双向通信时，两个终端将等待其间设置有RIFS时间的两个PHY帧。
还可以限定成：在基于RD方案的通信中的待命状态下，两个终端将等待其间设置有RIFS时间的3个或更多个PHY帧。
作为另一种选择，当终端A 201充当基站时，这样就足够了：在从终端A 201发送的信标帧中写入表示在采用RD方案的情况下在终端A 201发送第一聚集帧304之后发送其间设置有RIFS时间的两个PHY帧的信息。
（1-1-1.从终端A发送RTS帧）
在终端A201中，当在双向通信开始之前将数据存储在传输队列106中时，传输数据管理单元102将所存储的传输数据的优先级、量以及发送目的地传送给发送/接收状态管理单元108（图3中的步骤1）。
发送/接收状态管理单元108针对传输数据的所接收到的优先级，询问载波侦听单元109是否可以发送该传输数据。载波侦听单元109对接收功率是否等于或大于预定值（“空闲”还是“忙”）进行监测（载波侦听处理）。载波侦听单元109还对是否预留有传输频带进行监测（虚拟载波侦听处理）。若由载波侦听单元109获得的载波侦听结果和虚拟载波侦听结果均为“空闲”，并且未预留传输频带的时段持续AIFS+回退时间（在某些情况下可以不执行回退；以下同样），则发送/接收状态管理单元108确定可以执行发送。当确定可以执行发送时，发送/接收状态管理单元108将传输数据的优先级、量以及发送目的地传送给发送/接收方法确定单元107（图3中的步骤2）。
发送/接收方法确定单元107确定对RTS帧301与CTS帧303的交换的执行、基于RD方案的双向通信的执行、TXOP时间中的频带预留时间（NAV时间）的长度（在本实施例中等于TXOP时间）、以及TXOP时间的分配给终端B 202的部分（TXOP分配时间）的长度（图3中的步骤3）。
在此情况下，例如，NAV时间和TXOP分配时间可以是预定值或者可以通过任何计算方法来计算。对要采用的计算方法的描述将被略去，因为它对于本发明实施例来说不重要。
发送/接收状态管理单元108根据由发送/接收方法确定单元107确定的信息将待写在RTS帧301中的持续时间字段中的NAV值传送给帧生成/传输处理单元104（图3中的步骤4）。将写在RTS帧301中的NAV值处理成在RD方案中采用的TXOP限的一倍。
帧生成/传输处理单元104生成RTS帧301（其中在持续时间字段中将所接收到的TXOP时间长度写成NAV值），并按第一传输率发送该帧（图3中的步骤5）。
第一传输率例如是在802.11a规范中限定的传输率或基本速率。作为另一种选择，该速率是802.11n中的较低传输率或基本速率。例如，如果不支持802.11n但是支持802.11a的终端位于可以接收来自终端A201或终端B202的发送波的位置处，则第一传输率是802.11a中限定的传输率。与之对照的是，如果只支持802.11n的终端位于可以接收来自终端A 201或终端B 202的发送波的位置处，则第一传输率是802.11n中限定的较低传输率或基本速率。如果存在不支持802.11n的终端但是针对不支持802.11n的终端已经执行了频带预留，则第一传输率是802.11n中限定的较低传输率或基本速率。已由终端A201发送的寻址到终端B202的RTS帧301还被终端C203或终端D204接收。当确定所接收到的RTS帧301寻址到终端B202时，终端C203和终端D204仅在NAV时间禁止利用对应的持续时间字段执行通信。结果，可以为终端A 201预留传输频带。
当对RTS帧301的发送完成时，接收处理单元105等待来自终端B202的CTS帧303仅与SIFS时间与1时隙时间之和相对应的时间。如果接收处理单元105不能在与SIFS时间与1时隙时间之和相对应的时间内开始接收CTS帧303，则启动用于再发送RTS帧301的回退处理（图3中的步骤6）。
（1-1-2.终端B对RTS帧的接收和对CTS帧的发送）
终端B202的接收处理单元105接收RTS帧301，并在该接收完成之后SIFS时间时按第一传输率发送CTS帧303（图4中的步骤101）。将通过从RTS帧301中写有的NAV值减去SIFS时间和用于发送CTS帧303的时间而获得的值写为CTS帧303中的NAV值（由于预先知道各帧的长度并且预先确定了传输率，因此知道用于发送的时间）。RTS帧301和CTS帧303与作为已有规范的IEEE 802.11中的通用RTS-CTS交换中的那些帧相同，因此终端B202此时并不知道终端A201采用RD方案。
当对CTS帧303的发送完成时，接收处理单元105等待对数据帧的接收（图4中的步骤102）。
终端E 205还接收已从终端B 202发送的寻址到终端A 201的CTS帧303。当确定所接收到的CTS帧303寻址到终端A 201时，终端E 205禁止它自己在与CTS帧303内写有的NAV值相对应的时间内采用对应的传输频带执行通信。结果，为终端A 201进行了传输频带预留。
（1-1-3.终端A对CTS帧的接收和对聚集帧的发送）
当接收处理单元105从终端B 202接收CTS帧303时，终端A 201向发送/接收状态管理单元108传送表示对CTS帧303的接收的值和在CTS帧303中写有的NAV值（图3中的步骤7）。
发送/接收状态管理单元108提取缓冲在传输队列106中的传输数据，并将该数据连同由发送/接收方法确定单元107确定的TXOP分配时间一起传送给帧生成/传输处理单元104（图3中的步骤8）。
帧生成/传输处理单元104根据传输数据生成数据1-A 305作为QoS Cf-轮询+数据帧，和数据2-A 306、数据3-A 307、数据4-A 308作为数据帧。此外，帧生成/传输处理单元104在将用于标识各帧的字段附加到帧头部时通过将数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308按命名的顺序并合起来，生成聚集帧304（图3中的步骤9）。
在数据1-A 305的QoS控制字段中写入TXOP分配时间，作为QoS Cf-轮询+数据帧。在本实施例中，对于聚集帧304，TXOP分配时间是RIFS时间、发送（稍后要描述的）聚集帧311所需的时间、SIFS时间以及发送BlockAck帧310所需的时间之和。在数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308中的每一个中，写入通过从发自终端B 202的CTS帧303中写有的NAV值减去SIFS时间和发送聚集帧304所需的时间而获得的值，作为NAV值。该NAV值表示从完成发送聚集帧304到TXOP时间结束的时间长度。
在由接收处理单元105完成从终端B 202对CTS帧303的接收之后SIFS时间时，帧生成/传输处理单元104开始发送聚集帧304（图3中的步骤10）。按比第一传输率更高的第二传输率执行该发送。第二传输率是IEEE 802.11n规范中的较高传输率，例如，基于MIMO技术的高速率。
当对聚集帧304的发送完成时，接收处理单元105等待来自终端B202的BlockAck帧310仅对应于SIFS时间与1时隙时间之和的时间。如果接收处理单元105在对应于SIFS时间与1时隙时间之和的时间内不能接收BlockAck帧310，则接收处理单元105再发送聚集帧304（图3中的步骤11）。
在此情况下，由于终端A201知道它采用RD方案，因此终端A201使得接收处理单元105在随后的待命状态下等待其间设置有RIFS时间的两个PHY帧。
（1-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
已接收到聚集帧304的终端B202的接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值、在数据1-A 305中写有的TXOP分配时间、以及在数据1-A 305、数据2-A 306、数据3-A 307、数据4-A 308中的每一个中写有的NAV值。接收处理单元105根据对从终端A 201发送的数据1-B 312、数据2-B 313、数据3-B 314、数据4-B 315中的每一个的接收成功/失败状态，生成用于将确认通知给远程终端的位图，并将该位图传送给发送/接收状态管理单元108（图4中的步骤103）。
当接收到具有用于通知已分配了TXOP分配时间的轮询帧的功能的QoS Cf-轮询+数据帧时，终端B 202第一次知道终端A 201将采用RD方案。当确定采用RD方案时，终端B 202在TXOP分配时间内发送传输数据作为它希望发送给终端A 201的数据帧。
当确定终端A 201将采用RD方案时，终端B 202使得接收处理单元105在随后的待命状态下等待其间设置有RIFS时间的两个PHY帧。
发送/接收状态管理单元108根据表示对QoS Cf-轮询+数据帧的接收的值而确定终端A 201正在按RD方案执行通信。发送/接收状态管理单元108接着提取传输队列106中缓冲的传输数据，并将该数据连同TXOP分配时间、从接收处理单元105接收到的NAV值以及用于将确认通知给远程终端的位图一起传送给帧生成/传输处理单元104（图4中的步骤104）。稍后将对从传输队列106提取的传输数据的量进行描述。
帧生成/传输处理单元104通过利用用于将确认通知给远程终端的位图，生成针对从终端A201发送的数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308的确认（BlockAck）帧。帧生成/传输处理单元104还根据传输数据来生成数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315作为数据帧，并通过将数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315并合来生成聚集帧311。
帧生成/传输处理单元104将通过从所接收到的NAV值减去SIFS时间和发送BlockAck帧310所需的时间而获得的值作为NAV值写在BlockAck帧310中。该NAV值表示从完成发送BlockAck帧310到TXOP时间结束的时间长度。
帧生成/传输处理单元104将通过从BlockAck帧310中写有的NAV值减去RIFS时间和发送聚集帧311所需的时间而获得的值作为NAV值写在数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个中。该NAV值表示从完成发送聚集帧311到TXOP时间结束的时间长度（图4中的步骤105）。
以下将通过在BlockAck帧与聚集帧之间插入RIFS帧而获得的帧称为HTP突发帧（待在第十实施例中详细描述）。将发送/接收状态管理单元108从传输队列106提取并传送给帧生成/传输处理单元104的传输数据的量限定成使得HTP突发帧351的帧长度不超过数据1-A 305中写有的TXOP分配时间。帧生成/传输处理单元104在由接收处理单元105完成了对从终端A 201发送的聚集帧304的接收之后SIFS时间时开始发送所生成的突发帧351。
以下将详细描述对突发帧351的发送。首先，开始发送BlockAck帧310（图4中的步骤106）。假设对BlockAck帧310的传输率是第一传输率。
帧生成/传输处理单元104在完成了对BlockAck帧310的发送之后等待开始发送聚集帧311仅RIFS时间（图4中的步骤107）。在该时段期间，帧生成/传输处理单元104将传输率从第一传输率改变成第二传输率。
帧生成/传输处理单元104在完成发送BlockAck帧310之后RIFS时间时按第二传输率发送聚集帧311（图4中的步骤108）。
当完成发送聚集帧311时，接收处理单元105等待来自终端A 201的帧（图4中的步骤109）。
（1-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
以下在当接收到HTP突发帧351时将待发送给终端B 202的数据存储在传输队列106中的情况下对终端A 201的操作进行描述。
已接收到HTP突发帧351的终端A 201的接收处理单元105根据对数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的接收成功/失败状态来生成用于将确认通知给远程终端的位图，并将该位图连同在数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个中写有的NAV值一起传送给发送/接收状态管理单元108。接收处理单元105还将所接收到的写在BlockAck帧310中的位图传送给发送/接收状态管理单元108（图3中的步骤12）。
假设在所接收到的位图中，在数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308中的每一个中写有表示未发送的值。在此情况下，发送/接收状态管理单元108将这些数据帧插入（稍后要描述的）聚集帧318中以再发送它们。发送/接收状态管理单元108还提取传输队列106中缓冲的传输数据，并将该数据连同从发送/接收方法确定单元107接收到的TXOP分配时间、从接收处理单元105接收到的NAV值以及传输位图一起传送给帧生成/传输处理单元104（图3中的步骤13）。
帧生成/传输处理单元104通过利用所接收到的传输位图，针对从终端B 202发送的数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315生成BlockAck帧317。帧生成/传输处理单元104还生成聚集帧318，聚集帧318包括作为QoS Cf-轮询+数据帧的数据5-A 319和作为数据帧的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322。注意，若存在待发送的数据帧，则将待发送的数据帧附加在待新生成的数据帧之前。然而，若存在许多待发送的数据帧，则减少待新生成的数据帧的数量或不附加新数据帧。在此情况下，帧生成/传输处理单元104将通过从自接收处理单元105接收到的NAV值减去SIFS时间和发送BlockAck帧317所需的时间而获得的值作为NAV值写在BlockAck帧317中。该NAV值表示从完成发送BlockAck帧317到TXOP时间结束的时间长度。
帧生成/传输处理单元104将TXOP分配时间写在数据1-A 305中作为QoS Cf-轮询+数据帧。
帧生成/传输处理单元104将通过从在BlockAck帧317中写有的NAV值减去RIFS时间和发送聚集帧318所需的时间而获得的值作为NAV值写在数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A322中的每一个中。该NAV值表示从完成发送聚集帧318到TXOP时间结束的时间长度（图3中的步骤14）。帧生成/传输处理单元104在由接收处理单元105完成了对从终端B202发送的HTP突发帧351的接收之后SIFS时间时开始发送所生成的HTP突发帧352。
以下将详细描述对HTP突发帧352的发送。首先，开始发送BlockAck帧317（图3中的步骤15）。假设对BlockAck帧317的传输率是第一传输率。
帧生成/传输处理单元104在完成了对BlockAck帧317的发送之后等待开始发送聚集帧318仅RIFS时间（图3中的步骤16）。在该时段期间，帧生成/传输处理单元104将传输率从第一传输率改变成第二传输率。
帧生成/传输处理单元104在完成发送BlockAck帧317之后RIFS时间时按第二传输率发送聚集帧318（图3中的步骤17）。
终端F 206不能接收从终端A 201发送的RTS帧301或从终端B202发送的CTS帧303，因为终端F 206处于当帧被发送时不能接收这些帧的状态。然而，当终端F 206在被设定成它可以接收通信的状态之后接收到BlockAck帧或聚集帧时，终端F 206知道该帧中写有的NAV值，并禁止它自己采用对应的传输频带执行通信与该NAV值相对应的时间。结果，可以针对终端F 206为终端A 201进行传输频带预留。
即使终端F 206不支持802.11n因而不能接收基于MIMO技术按高传输率发送的聚集帧或帧，由于在数据帧之前按甚至终端F 206也可以接收BlockAck帧317的第一传输率发送该帧，因此终端F 206可以在接收到作为聚集帧318发送的各数据帧之前从BlockAck帧317中知道各数据帧的地址和NAV值。对该地址和NAV值的知晓使得：即使终端F 206不能接收此后发送的任何数据帧，该终端也可以知道已进行了频带预留连同预留长度。
当完成了对HTP突发帧352的发送时，接收处理单元105等待来自终端A 201的BlockAck帧324对应于SIFS时间与1时隙时间之和的时间。如果接收处理单元105在对应于SIFS时间与1时隙时间之和的时间内不能接收BlockAck帧324，那么接收处理单元105再发送HTP突发帧352（图3中的步骤18）。
（1-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
已接收到其间设置有RIFS时间的两个PHY帧（即，HTP突发帧352）的终端B 202的接收处理单元105根据对数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个的接收成功/失败状态而生成用于将确认通知给远程终端的位图。接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值、在数据5-A 319中写有的TXOP分配时间、在数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个中写有的NAV值、用于将确认通知给远程终端的位图、以及在BlockAck帧317中写有的位图（图4中的步骤110）。
如果在所接收到的位图中写有表示对数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的未发送的值，那么发送/接收状态管理单元108将这些数据帧插入（稍后要描述的）聚集帧325中以再发送它们。发送/接收状态管理单元108还提取传输队列106中缓冲的传输数据，并将该数据连同从接收处理单元105接收到的NAV值和用于将确认通知给远程终端的位图一起传送给帧生成/传输处理单元104（图4中的步骤111）。稍后将描述从传输队列106中提取的传输数据的量。
帧生成/传输处理单元104通过利用用于将确认通知给远程终端的位图，针对从终端A 201发送的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322生成BlockAck帧324。
帧生成/传输处理单元104根据传输数据而生成数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329作为数据帧。帧生成/传输处理单元104通过将数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329并合而生成聚合帧325（图4中的步骤112）。
帧生成/传输处理单元104将通过从所接收到的NAV值减去SIFS时间和发送BlockAck帧324所需的时间而获得的值作为NAV值写在BlockAck帧324中。该NAV值表示从完成发送BlockAck帧324到TXOP时间结束的时间长度。
此外，帧生成/传输处理单元104将通过从BlockAck帧324中写有的NAV值减去RIFS时间和发送聚合帧325所需的时间而获得的值作为NAV值写在数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329中的每一个中。该NAV值表示从完成发送聚合帧325到TXOP时间结束的时间长度。将发送/接收状态管理单元108从传输队列106提取并传送给帧生成/传输处理单元104的传输数据的量限定成使得通过在BlockAck帧324与聚合帧325之间插入RIFS时间而获得的HTP突发帧的帧长度不超过在作为QoS Cf-轮询+数据帧的数据5-A 319中写有的TXOP分配时间。然而，如果存在待再发送的数据帧，那么在此情况下待生成的数据帧的数量会因此减少。即，将发送/接收状态管理单元108从传输队列106提取并传送给帧生成/传输处理单元104的传输数据的量限定成使得由BlockAck帧324、RIFS时间以及聚合帧325所形成的HTP突发帧353的帧长度不超过TXOP分配时间。
帧生成/传输处理单元104在由接收处理单元105完成了对从终端A 201发送的HTP突发帧的接收之后SIFS时间时开始发送所生成的HTP突发帧353。
以下将详细描述对HTP突发帧353的发送。首先，开始发送BlockAck帧324（图4中的步骤113）。假设对BlockAck帧324的传输率是第一传输率。
帧生成/传输处理单元104在完成了对BlockAck帧324的发送之后等待开始发送聚集帧318仅RIFS时间（图4中的步骤114）。在该时段期间，帧生成/传输处理单元104将传输率从第一传输率改变成第二传输率。
帧生成/传输处理单元104在完成发送BlockAck帧324之后RIFS时间时按第二传输率发送聚集帧325（图4中的步骤115）。
当对HTP突发帧353的发送完成时，接收处理单元105等待来自终端A201的帧（图4中的步骤116）。
（1-1-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
在如下情况下对在NAV时间结束时终端A 201的操作进行描述：当接收到HTP突发帧353时，在传输队列106中没有待发送给终端B202的数据并且没有待再发送的数据帧或者在TXOP时间接近结束时不再可以继续进行发送。
已接收到其间设置有RIFS时间的两个PHY帧（即，HTP突发帧353）的终端A 201的接收处理单元105根据对数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329中的每一个的接收成功/失败状态而生成表示确认的位图，并将该位图连同在数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329中的每一个中写有的NAV值一起传送给发送/接收状态管理单元108。接收处理单元105还将所接收到的写在BlockAck帧324中的位图传送给发送/接收状态管理单元108（图3中的步骤19）。
发送/接收状态管理单元108根据所接收到的位图对数据5-A 319数据6-A 320、数据7-A 321以及数据8-A 322中的每一个的发送成功/失败进行检查。发送/接收状态管理单元108将从接收处理单元105接收到的NAV值传送给帧生成/传输处理单元104（图3中的步骤20）。
帧生成/传输处理单元104通过利用所接收到的位图，生成针对从终端B 202发送的数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329的BlockAck帧331。
帧生成/传输处理单元104将通过从接收处理单元105接收到的NAV值减去SIFS时间和发送BlockAck帧331所需的时间而获得的值作为NAV值写在BlockAck帧331中。该NAV值表示从完成发送BlockAck帧331到TXOP时间结束的时间长度（图3中的步骤21）。
帧生成/传输处理单元104在由接收处理单元105完成了对从终端A 201发送的HTP突发帧353的接收之后SIFS时间时开始发送所生成的BlockAck帧331（图3中的步骤22）。假设对BlockAck帧331的传输率是第一传输率。
（1-1-8.TXOP时间的结束）
当在对BlockAck帧331的发送结束之后经过了与从终端A 201发送的BlockAck帧331中写有的NAV值相对应的时间时，释放频带预留，并结束终端A 201与终端B 202之间的双向通信。当该双向通信终止时，终端A 201和终端B 202中的每一个的接收处理单元105停止等待其间设置有RIFS时间的两个PHY帧，并被设定成普通待命状态。当还要执行该双向通信时，在自频带预留释放起经过了AIFS+回退时间之后再次从“1-1-1”的序列执行上述处理。作为另一种选择，当要与另一终端执行如本实施例中那样的双向通信或普通通信时，假设另一终端是终端B 202，在自频带预留释放起经过了AIFS+回退时间之后再次执行从“1-1-1”起的序列的上述处理。
如上所述，根据本实施例，按低传输率发送控制帧（BlockAck帧等），并按高传输率发送数据帧。
按低传输率进行发送可以抑制由于噪声等而出现传输错误。按高传输率进行发送使得可以执行高速传输。
本发明既可以满足对抑制响应器由于接收控制帧（BlockAck帧、BlockAckRequest帧等）的失败而发出再发送请求的要求，也可以满足对实现数据帧的高速传输的要求。
假设本实施例中的终端A 201和终端B 202采用40MHz频带（如在IEEE 802.11n中提出的两个20MHz频带的组合）作为用于发送数据的频带，而不采用IEEE 802.11a/b/g等中使用的常规20MHz频带。在此情况下，利用40MHz频带发送普通传输数据，并在保持模拟单元的40MHz频带不变的同时，在数字处理单元的PHY层上将传输频带切换到20MHz频带时在20MHz频带中作为帧发送写有NAV值的帧（例如，RTS帧301、CTS帧303、以及BlockAck帧305、310、317、324以及331）。这使得可以将NAV值通知给仅采用如IEEE802.11a/b/g等中那样的20MHz频带的终端。
假设不必通过使用控制帧将NAV通知给采用20MHz频带的无线通信设备，因为没有仅采用20MHz频带的终端或者已为仅采用20MHz频带的终端设定了NAV。在此情况下，在40MHz频带中将BlockAck帧的传输率降低到较低传输率使得可以增大BlockAck帧将到达无线通信系统中的所有终端的可能性。此外，本实施例例示了通过RTS-CTS帧交换来通知NAV值的情况，即，从终端A201发送RTS帧301并从终端B202发送CTS帧303。然而，通知NAV值的方法并不限于此。显然，也可以按在经过了SIFS时间（其间执行所谓的IAC-RAC帧交换或发送CTS自身帧）之后发送聚集帧的方法发送如本实施例中那样的HTP突发帧。
若如在采用HCCA方案的通信中那样在HCCA时间中通过来自基站的NAV进行了频带预留，则可以在不执行RTS-CTS帧交换的情况下从发送聚集帧启动RD方案。
本实施例还例示了将TXOP分配时间写在QoS Cf-轮询+数据帧中的情况。然而，可以将QoS Cf-轮询+数据帧分成QoS Cf-轮询帧和数据帧，并且可以将TXOP分配时间写在QoS Cf-轮询帧的QoS控制字段中。
此外，本实施例例示了终端A 201与终端B 202之间的双向通信。然而，即使终端A 201或终端B 202是基站或终端站，也不会出现问题。然而，如果终端A 201是基站，当在释放了预留的传输频带之后要发送RTS帧时，可以采用EDCA方案（在该方案中在释放频带之后AIFS+回退时间时开始访问）进行访问。作为另一种选择，可以采用HCCA方案（在该方案中在经过了RIFS时间之后发送RTS帧、QoS Cf-轮询帧或数据帧）进行访问。
（第一实施例的第一修改例）
在第一实施例中，终端A 201将TXOP分配时间写在QoS Cf-轮询+数据帧中。即，终端A 201将TXOP分配时间通知给终端B 202。终端B 202发送不超过与所分配的TXOP分配时间相对应的量的传输数据量。
然而，可以将终端B 202设计成发送如它希望发送的那样多的传输数据，而不管TXOP分配时间。
在这种情况下，终端A 201不必将TXOP分配时间写在QoS Cf-轮询+数据帧中。任意设定发送/接收状态管理单元108在图4中的步骤105或112中从传输队列106提取然后传送给帧生成/传输处理单元104的传输数据的量就足够了。
即使在该配置中，终端A 201也可以没有任何问题地接收传输数据，因为只有从终端B 202发送了BlockAck帧之后RIFS时间时发送的聚集帧的长度改变了。结果，终端A 201不必计算TXOP分配时间。
（第一实施例的第二修改例）
图6是示出了根据第二修改例的无线通信设备1101的示例的框图。图7是与终端A 201的操作相关联的流程图。图8是与终端B 202的操作相关联的流程图。
第一实施例已经例示了如下情况：终端A 201和终端B 202均采用通过从写在自远程终端接收的控制帧或数据帧中的NAV值减去发送来自自身终端的帧所需的时间、SIFS时间以及下一次发送来自远程终端的BlockAck帧所需的时间而获得的值，作为待写在本终端要发送的帧中的NAV值。
本修改例将例示如下配置：采用通过从由计时器110计得的到NAV时间结束的剩余时间减去发送来自自身终端的帧所需的时间、SIFS时间以及下一次发送来自远程终端的BlockAck帧所需的时间而获得的值，作为待写在本终端要发送的帧中的NAV值。
假设终端A 201和终端B 202均具有与接下来要描述的无线通信设备1101的配置相同的配置。
除了图1所示的无线通信设备101的配置以外，无线通信设备1101还包括计时器110。计时器110向发送/接收状态管理单元108提供到给定时刻的剩余时间的信息。
其他配置与图1中的无线通信设备101的配置相同。
（1-3-1.从终端A发送RTS帧）
图7中的步骤1001到1004与图3中的步骤1到步骤4相同。
帧生成/传输处理单元104通过使用所接收到的TXOP分配时间的长度作为NAV值将RTS帧301写在持续时间字段中，然后按第一传输率发送该帧。当对RTS帧301的发送开始时，计时器110以NAV值为初值开始倒计时（图7中的步骤1005）。
该操作之后的步骤1006与图3中的步骤6相同。
（1-3-2.终端B对RTS帧的接收和对CTS帧的发送）
终端B 202以由接收处理单元105接收到的RTS帧301中的NAV值为初值开始倒计时。
接收处理单元105在完成接收RTS帧301之后SIFS时间时按第一传输率发送CTS帧303（图8中的步骤1101）。将通过从由计时器110计得的到NAV时间结束的剩余时间减去SIFS时间和发送CTS帧303所需的时间而获得的值作为NAV值写在CTS帧303中。
该操作之后的步骤1102与图4中的步骤102相同。
（1-3-3.终端A对CTS帧的接收和对聚集帧的发送）
当接收处理单元105从终端B202接收到CTS帧303时，终端A201将表示对CTS帧303的接收的值传送给发送/接收状态管理单元108（图7中的步骤1007）。
该操作之后的步骤2008与图3中的步骤8相同。
帧生成/传输处理单元104根据传输数据来生成作为QoS Cf-轮询+数据帧的数据1-A305和作为数据帧的数据2-A 306、数据3-A 307以及数据4-A 308。此外，帧生成/传输处理单元104在将用于标识各帧的字段附加到帧头部时通过将数据1-A 305、数据2-A 306、数据3-A307以及数据4-A 308按命名的顺序并合起来，生成聚集帧304（图7中的步骤1009）。
在数据1-A 305中写入TXOP分配时间作为QoS Cf-轮询+数据帧。在数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308中的每一个中，写入通过从由计时器110计得的到NAV时间结束的剩余时间减去SIFS时间和发送聚集帧304所需的时间而获得的值，作为NAV值。
该操作之后的步骤1010和1011与图3中的步骤10和11相同。
（1-3-4.终端B对聚集帧的接收和对HTP突发帧的发送）
已接收到聚集帧304的终端B 202的接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值和在数据1-A 305中写有的TXOP分配时间。接收处理单元105还根据对从终端A 201发送的数据1-B 312、数据2-B 313、数据3-B 314、数据4-B 315中的每一个的接收成功/失败状态，生成用于将确认通知给远程终端的位图，并将该位图传送给发送/接收状态管理单元108（图8中的步骤1103）。
发送/接收状态管理单元108根据表示对QoS Cf-轮询+数据帧的接收的值而确定终端A 201正在按RD方案执行通信。发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同TXOP分配时间和所述位图一起传送给帧生成/传输处理单元104（图8中的步骤1104）。
帧生成/传输处理单元104通过利用该位图，针对从终端A 201发送的数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308生成BlockAck帧310。帧生成/传输处理单元104还根据传输数据而生成数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315作为数据帧。帧生成/传输处理单元104通过将数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315并合而生成聚合帧311。
此时，帧生成/传输处理单元104将通过从由计时器110计得的到NAV时间结束的剩余时间减去SIFS时间和发送BlockAck帧310所需的时间而获得的值作为NAV值写在BlockAck帧310中。该NAV值表示从完成发送BlockAck帧310到TXOP时间结束的时间长度。
帧生成/传输处理单元104将通过从BlockAck帧310中写有的NAV值减去RIFS时间和发送聚集帧311所需的时间而获得的值作为NAV值写在数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个中。（图8中的步骤1105）。
该操作之后的步骤1106到1109与图4中的步骤106到109相同。
（1-3-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
已接收到HTP突发帧351的终端A 201的接收处理单元105根据对数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的接收成功/失败状态来生成表示确认的位图，并将该位图传送给发送/接收状态管理单元108（图7中的步骤1012）。
发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同从发送/接收方法确定单元107接收到的TXOP分配时间和从接收处理单元105接收到的位图一起传送给帧生成/传输处理单元104（图7中的步骤1013）。
帧生成/传输处理单元104通过利用所接收到的位图，针对从终端B 202发送的数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315生成BlockAck帧317。帧生成/传输处理单元104还根据传输数据生成聚集帧318，聚集帧318包括作为QoS Cf-轮询+数据帧的数据5-A 319和作为数据帧的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322。
在此情况下，帧生成/传输处理单元104将通过从由计时器110计得的到TXOP时间结束的剩余时间减去SIFS时间和发送BlockAck帧317所需的时间而获得的值作为NAV值写在BlockAck帧317中。帧生成/传输处理单元104将TXOP分配时间写在数据1-A 305中作为QoS Cf-轮询+数据帧。帧生成/传输处理单元104将通过从在BlockAck帧317中写有的NAV值减去RIFS时间和发送聚集帧318所需的时间而获得的值作为NAV值写在数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个中（图7中的步骤1014）。
该操作之后的步骤1015到1018与图3中的步骤15到18相同。
（1-3-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
已接收到其间设置有RIFS时间的两个PHY帧（即，HTP突发帧352）的终端B 202的接收处理单元105根据对数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个的接收成功/失败状态而生成表示确认的位图。接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值和所生成的位图（图8中的步骤1110）。
发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同从接收处理单元105接收到的位图一起传送给帧生成/传输处理单元104（图8中的步骤1111）。
帧生成/传输处理单元104通过利用所述位图，针对从终端A 201发送的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322生成BlockAck帧324。帧生成/传输处理单元104根据传输数据而生成数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329作为数据帧。帧生成/传输处理单元104接着通过将数据5-B 326、数据6-B327、数据7-B 328以及数据8-B 329并合而生成聚合帧325。
此时，帧生成/传输处理单元104将通过从由计时器110计得的到NAV时间结束的剩余时间减去SIFS时间和发送BlockAck帧324所需的时间而获得的值作为NAV值写在BlockAck帧324中。
帧生成/传输处理单元104还将通过从BlockAck帧324中写有的NAV值减去RIFS时间和发送聚合帧325所需的时间而获得的值作为NAV值写在数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329中的每一个中（图8中的步骤1112）。
该操作之后的步骤1113到1116与图4中的步骤113到116相同。（1-3-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
已接收到其间设置有RIFS时间的两个PHY帧（即，HTP突发帧353）的终端A201的接收处理单元105根据对数据1-B312、数据2-B313、数据3-B314以及数据4-B315中的每一个的接收成功/失败状态而生成表示确认的位图，并将该位图传送给发送/接收状态管理单元108（图7中的步骤1019）。
发送/接收状态管理单元108将从接收处理单元105接收到的位图传送给帧生成/传输处理单元104（图7中的步骤1019）。
帧生成/传输处理单元104通过利用所接收到的位图，生成针对从终端B202发送的数据5-B326、数据6-B327、数据7-B328以及数据8-B329的BlockAck帧331。
帧生成/传输处理单元104将通过从接收处理单元105接收到的NAV值减去SIFS时间和发送BlockAck帧331所需的时间而获得的值作为NAV值写在BlockAck帧331中。
帧生成/传输处理单元104接着将通过从由计时器110计得的到NAV时间结束的剩余时间减去SIFS时间和发送BlockAck帧331所需的时间而获得的值作为NAV值写在BlockAck帧331中（图7中的步骤1020）。
该操作之后的步骤1021到1022与图3中的步骤21到22相同。（1-3-8.TXOP分配时间的结束）
当终端B202的计时器110结束倒计时，释放频带预留，并结束终端A201与终端B202之间的双向通信。当还要执行该双向通信时，在自频带预留释放起经过了AIFS+回退时间之后再次从序列“1-3-1”执行上述处理。
如上所述，将通过从由计时器110计得的到NAV时间结束的剩余时间减去发送来自自身终端的帧所需的时间而获得的值设定为待写在自身终端发送的帧中的NAV值。这使得即使从远程终端接收到的控制帧或数据帧中存在错误，自身终端也可以可靠地认识到NAV时间的结束。
（第一实施例的第三修改例）
图9是与根据第三修改例的无线通信设备2101的示例相关联的框图。图10是与终端A201的操作相关联的流程图。图11是与终端B202的操作相关联的流程图。
第一实施例已经例示了如下情况：终端A201和终端B202均采用通过从写在自远程终端接收的控制帧或数据帧中的NAV值减去发送来自自身终端的帧所需的时间、SIFS时间以及下一次发送来自远程终端的BlockAck帧所需的时间而获得的值，作为待写在自身终端要发送的帧中的NAV值。
本修改例将例示根据由RTC（实时时钟）111提供的时间来计算NAV值的配置。更具体来说，在以下要描述的该配置中，通过利用从RTC 111获得的时间信息预先记录NAV时间的结束时间，并将通过从所记录的时间减去来自自身终端的帧的发送起始时间、SIFS时间以及下一次发送来自远程终端的BlockAck帧所需的时间而获得的值设定为待写在要从自身终端发送的帧中的NAV值。
以下将在来自作为发起站的终端A201的所有传输数据都寻址到作为响应器的终端B202并且来自终端B202的所有传输数据都寻址到终端A201的假设下对双向通信进行描述。
假设终端A201和终端B202均具有与接下来要描述的无线通信设备2101的配置相同的配置。
除了图1所示的无线通信设备101的配置以外，无线通信设备2101还包括RTC 111。RTC 111向发送/接收状态管理单元108提供时间信息。
其他配置与图1中的无线通信设备101的那些配置相同。（1-4-1.从终端A发送RTS帧）
图10中的步骤2001到2006与图3中的步骤1到步骤3相同。（1-4-2.终端B对RTS帧的接收和对CTS帧的发送）
终端B202的发送/接收状态管理单元108将由接收处理单元105接收到的RTS帧301中的NAV值存储为NAV时间的结束时间。接收处理单元105在完成接收RTS帧301之后SIFS时间时按第一传输率发送CTS帧303（图11中的步骤2101）。将通过从NAV时间的结束时间减去发送CTS帧303的估计完成时间而获得的值作为NAV值写在CTS帧303中。根据从RTC 111获得的时间和发送CTS帧303所需的时间来计算发送CTS帧303的估计完成时间。
该操作之后的步骤2102与图4中的步骤102相同。
（1-4-3.终端A对CTS帧的接收和对聚集帧的发送）
当接收处理单元105从终端B202接收到CTS帧303时，终端A201将表示对CTS帧303的接收的值传送给发送/接收状态管理单元108（图10中的步骤2007）。
该操作之后的步骤2008与图3中的步骤8相同。
帧生成/传输处理单元104根据传输数据来生成作为QoS Cf-轮询+数据帧的数据1-A305和作为数据帧的数据2-A306、数据3-A307以及数据4-A308。此外，帧生成/传输处理单元104在将用于标识各帧的字段附加到帧头部时通过将数据1-A305、数据2-A306、数据3-A307以及数据4-A308按命名的顺序并合起来，生成聚集帧304（图10中的步骤2009）。在数据1-A305中写入TXOP分配时间作为QoS Cf-轮询+数据帧。在数据1-A305、数据2-A306、数据3-A307以及数据4-A308中的每一个中，写入通过从NAV时间的结束时间减去聚集帧304的发送起始时间和发送聚集帧304所需的时间而获得的值，作为NAV值。将聚集帧304的发送起始时间确定为CTS帧303的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算聚集帧304的发送起始时间。
该操作之后的步骤2010和2011与图3中的步骤10和11相同。（1-4-4.终端B对聚集帧的接收和对HTP突发帧的发送）
已接收到聚集帧304的终端B202的接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值和在数据1-A 305中写有的TXOP分配时间。接收处理单元105还根据对从终端A 201发送的数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的接收成功/失败状态，生成表示确认的位图，并将该位图传送给发送/接收状态管理单元108（图11中的步骤2103）。
发送/接收状态管理单元108根据表示对QoS Cf-轮询+数据帧的接收的值来确定终端A 201正在按RD方案执行通信。发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同TXOP分配时间和所述位图一起传送给帧生成/传输处理单元104（图11中的步骤2104）。
帧生成/传输处理单元104通过利用该位图，针对从终端A 201发送的数据1-A 305、数据2-A 306、数据3-A 307以及数据4-A 308生成BlockAck帧310。帧生成/传输处理单元104还根据传输数据而生成数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315作为数据帧。帧生成/传输处理单元104通过将数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315并合而生成聚合帧311。
帧生成/传输处理单元104将通过从NAV时间的结束时间减去BlockAck帧310的发送起始时间和发送BlockAck帧310所需的时间而获得的值作为NAV值写在BlockAck帧310中。
将BlockAck帧310的发送起始时间确定为聚集帧304的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算BlockAck帧310的发送起始时间。
帧生成/传输处理单元104将通过从NAV时间的结束时间减去聚集帧311的发送起始时间和发送聚集帧311所需的时间而获得的值作为NAV值写在数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个中。
将聚集帧311的发送起始时间确定为聚集帧304的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算聚集帧311的发送起始时间（图11中的步骤2105）。
该操作之后的步骤2106到2109与图4中的步骤106到109相同。（1-4-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
已接收到HTP突发帧的终端A 201的接收处理单元105根据对数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的接收成功/失败状态来生成表示确认的位图，并将该位图传送给发送/接收状态管理单元108（图10中的步骤2012）。
发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同从发送/接收方法确定单元107接收到的TXOP分配时间和从接收处理单元105接收到的位图一起传送给帧生成/传输处理单元104（图10中的步骤2013）。
帧生成/传输处理单元104通过利用所接收到的位图，针对从终端B 202发送的数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315生成BlockAck帧317。帧生成/传输处理单元104还根据传输数据生成聚集帧318，聚集帧318包括作为QoS Cf-轮询+数据帧的数据5-A 319和作为数据帧的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322。
此时，帧生成/传输处理单元104将通过从NAV时间的结束时间减去BlockAck帧317的发送起始时间和发送BlockAck帧317所需的时间而获得的值作为NAV值写在BlockAck帧317中。帧生成/传输处理单元104将TXOP分配时间写在数据1-A 305中作为QoS Cf-轮询+数据帧。将BlockAck帧317的发送起始时间确定为聚集帧311的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算BlockAck帧317的发送起始时间。
帧生成/传输处理单元104将通过从NAV时间的结束时间减去聚集帧318的发送起始时间和发送聚集帧318所需的时间而获得的值作为NAV值写在数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个中。将聚集帧318的发送起始时间确定为聚集帧311的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算聚集帧318的发送起始时间（图10中的步骤2014）。
该操作之后的步骤2015到2018与图3中的步骤15到18相同。（1-4-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
已接收到HTP突发帧的终端B 202的接收处理单元105根据对数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322中的每一个的接收成功/失败状态而生成表示确认的位图。接收处理单元105向发送/接收状态管理单元108传送表示对QoS Cf-轮询+数据帧的接收的值、在数据5-A 319中写有的TXOP分配时间以及所生成的位图（图11中的步骤2110）。
发送/接收状态管理单元108提取传输队列106中缓冲的传输数据，并将该数据连同从接收处理单元105接收到的位图一起传送给帧生成/传输处理单元104（图11中的步骤2111）。
帧生成/传输处理单元104通过利用所述位图，针对从终端A 201发送的数据5-A 319、数据6-A 320、数据7-A 321以及数据8-A 322生成BlockAck帧324。帧生成/传输处理单元104还根据传输数据而生成数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329作为数据帧。帧生成/传输处理单元104接着通过将数据5-B 326、数据6-B327、数据7-B 328以及数据8-B 329并合而生成聚合帧325。
此时，帧生成/传输处理单元104将通过从NAV时间的结束时间减去BlockAck帧324的发送起始时间和发送BlockAck帧324所需的时间而获得的值作为NAV值写在BlockAck帧324中。
将BlockAck帧324的发送起始时间确定为聚集帧318的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算BlockAck帧324的发送起始时间。
帧生成/传输处理单元104将通过从NAV时间的结束时间减去聚集帧325的发送起始时间和发送聚合帧325所需的时间而获得的值作为NAV值写在数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329中的每一个中。将聚集帧325的发送起始时间确定为聚集帧318的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算聚集帧325的发送起始时间（图11中的步骤2112）。
该操作之后的步骤2113到2116与图4中的步骤113到116相同。
（1-4-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
已接收到HTP突发帧的终端A 201的接收处理单元105根据对数据1-B 312、数据2-B 313、数据3-B 314以及数据4-B 315中的每一个的接收成功/失败状态而生成表示确认的位图，并将该位图传送给发送/接收状态管理单元108（图10中的步骤2019）。
发送/接收状态管理单元108将从接收处理单元105接收到的位图传送给帧生成/传输处理单元104（图10中的步骤2020）。
帧生成/传输处理单元104通过利用所接收到的位图，生成针对从终端B 202发送的数据5-B 326、数据6-B 327、数据7-B 328以及数据8-B 329的BlockAck帧331。帧生成/传输处理单元104将通过从NAV时间的结束时间减去BlockAck帧331的发送起始时间和发送BlockAck帧331所需的时间而获得的值作为NAV值写在BlockAck帧331中。将BlockAck帧331的发送起始时间确定为聚集帧325的接收完成时间之后SIFS时间。因此，可以根据从RTC 111获得的时间来计算BlockAck帧331的发送起始时间（图10中的步骤2021）。
该操作之后的步骤2021与图3中的步骤22相同。
（1-4-8.TXOP分配时间的结束）
当NAV时间期满时，释放频带预留，并结束终端A 201与终端B 202之间的双向通信。当还要执行该双向通信时，在自频带预留释放起经过了AIFS+回退时间之后再次从序列“1-4-1”执行上述处理。
如上所述，通过利用从RTC 111获得的时间信息预先记录NAV时间的结束时间，并将通过从所记录的时间减去来自自身终端的帧的发送起始时间和发送该帧所需的时间而获得的值设定为待写在要从自身终端发送的帧中的NAV值。这使得即使从远程终端接收到的控制帧或数据帧中存在错误，终端也可以可靠地认识到NAV时间的结束。
（第一实施例的第四修改例）
图12是在与第一实施例中不一样的采用具有附加到数据帧的聚集帧的末端的BAR（BlockAckRequest）帧的BlockAckRequest的情形的时序图。
在本修改例中，在发送第一实施例中的聚集帧3304之后RIFS时间时发送BAR帧3309。在此期间，帧生成/传输处理单元104将传输率从第二传输率（已按该传输率发送聚集帧3304）改变成第一传输率。帧生成/传输处理单元104以第一传输率发送所述BAR帧3309。
在按第二传输率发送了聚集帧3311、3318以及3325中的对应的一个之后RIFS时间时，帧生成/传输处理单元104按第一传输率发送BAR帧3316、3323以及3330中的每一个。
注意，本修改例中的HTP突发帧包括其间设置有RIFS时间的3个PHY帧。即，在本修改例中，从终端A 3201发送的HTP突发帧3352具有位于图2所示的HTP突发帧352之后的BAR帧3323（其间设置有RIFS时间），从终端B 3202发送的HTP突发帧3351具有位于图2所示的HTP突发帧351之后的BAR帧3316（其间设置有RIFS时间）。
假设如果将终端B 3202设计成通过关联或管理帧交换来执行RD方案的建立，那么该终端知道终端A 3201将在第一聚集帧3304之后发送其间设置有RIFS时间的3个PHY帧。
作为另一种选择，当终端A 3201要充当基站时，如果要采用RD方案，那么可以将表示终端A 3201将在第一聚集帧3304之后发送其间设置有RIFS时间的3个PHY帧的信息写在从终端A 3201发送的信标帧中。
在此情况下，在图3中的步骤11之后终端A 3201的接收处理单元105等待3个PHY帧，在相应的PHY帧之间设置有RIFS时间。此外，在图4中的步骤103之后终端A 3201的接收处理单元105等待3个PHY帧，在相应的PHY帧之间设置有RIFS时间。如上所述，按低传输率发送包括BAR帧在内的控制帧，而按高传输率发送数据帧。按低传输率进行发送可以抑制由于噪声等而出现传输错误。按高传输率进行发送使得可以执行高速传输。这使得既可以满足对抑制响应器由于接收包括BAR帧在内的控制帧的失败而发出再发送请求的要求，也可以满足对实现数据帧的高速传输的要求。
（第二实施例）
图13是第二实施例的时序图。注意，终端A 4201根据与图3所示的第一实施例中的终端A 201的操作相关联的流程图进行操作，终端B 4202根据与图4所示的第一实施例中的终端B 202的操作相关联的流程图进行操作。
第一实施例例示了如下情况：将在由终端A 201启动的RD方案中从对发自终端A 201的RTS帧301和发自终端B 202的CTS帧303中的每一个的发送完成时间到TXOP分配时段的结束的时间长度作为NAV值写在每个帧中。
在本实施例中，待写在来自发送方的RTS帧中的NAV值是从由发送方发送的第一聚集帧到由接收方响应于该聚集帧而返回的BlockAck帧的发送完成的时间值。以下将描述这样的配置：自身终端发送BlockAck帧，然后在该BlockAck帧之后RIFS时间时发送多个数据帧的聚集帧，并且每当针对聚集帧接收到BlockAck帧时将NAV时间4361延长该BlockAck帧中写有的NAV值。
（2-1-1.从终端A发送RTS帧）
图3中的步骤1和2保持不变。
与第一实施例不同，在步骤3中确定的NAV时间4361的长度是从对RTS帧4301的发送开始到对由终端B4202发送的BlockAck帧4310的接收完成的时间。
步骤4到6保持不变。
（2-1-2.终端B对RTS帧的接收和对CTS帧的发送）
图4中的步骤4101和4102保持不变。
（2-1-3.终端A对CTS帧的接收和对聚集帧的发送）
图3中的步骤7到11保持不变。
（2-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
图4中的步骤103和104保持不变。
在步骤105中，帧生成/传输处理单元104将通过将RIFS时间、发送聚集帧4311所需的时间、SIFS时间以及下一次发送来自终端A4201的BlockAck帧4317所需的时间相加而获得的值作为NAV值写在BlockAck帧4310中。该NAV值表示从完成发送BlockAck帧4310到完成下一次发送来自终端A 4201的BlockAck帧4317的时间长度。
步骤106到109保持不变。
当对BlockAck帧4310的接收完成时，终端C 203禁止自己通过采用用于终端A 4201与终端B 4202之间的双向通信的频带来执行通信仅由BlockAck帧4310中写有的NAV值所表示的时间。
随后，将从由RTS帧4301中的NAV值所限定的频带预留的结束时间到由BlockAck帧4310中写有的NAV值所限定的频带预留的结束时间的时间长度设定为NAV额外时间4362。
（2-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
图3中的步骤12和13保持不变。
在步骤14中，帧生成/传输处理单元104将通过将RIFS时间、发送聚集帧4318所需的时间、SIFS时间以及下一次发送来自终端B4202的BlockAck帧4324所需的时间相加而获得的值作为NAV值写在BlockAck帧4317中。该NAV值表示从完成发送BlockAck帧4317到完成下一次发送来自终端B4202的BlockAck帧4324的时间长度。
步骤15到18保持不变。
在此情况下，当对BlockAck帧4317的接收完成时，终端C 203禁止自己通过采用用于终端A 4201与终端B 4202之间的双向通信的频带来执行通信仅由BlockAck帧4317中写有的NAV值所表示的时间。
随后，将从由BlockAck帧4310中的NAV值所限定的频带预留的结束时间到由BlockAck帧4317中写有的NAV值所限定的频带预留的结束时间的时间长度设定为NAV额外时间4363。
（2-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
步骤110和111保持不变。
在步骤112中，帧生成/传输处理单元104将通过将RIFS时间、发送聚集帧325所需的时间、SIFS时间以及下一次发送来自终端A4201的BlockAck帧4331所需的时间相加而获得的值作为NAV值写在BlockAck帧4324中。该NAV值表示从完成发送BlockAck帧4324到完成下一次发送来自终端A 4201的BlockAck帧4331的时间长度。
步骤113到116保持不变。
当对BlockAck帧4324的接收完成时，终端C 203禁止自己通过采用用于终端A 4201与终端B 4202之间的双向通信的频带来执行通信仅由BlockAck帧4324中写有的NAV值所表示的时间。
随后，将从由BlockAck帧4317中的NAV值所限定的频带预留的结束时间到由BlockAck帧4324中写有的NAV值所限定的频带预留的结束时间的时间长度设定为NAV额外时间4364。
（2-1-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
图3中的步骤19和20保持不变。
在步骤21中，帧生成/传输处理单元104将0写成NAV值。该NAV值表示对频带预留的释放，即，NAV时间4361的结束。步骤22保持不变。
如上所述，在本实施例中，可以将最初所设定的NAV时间一次延长NAV额外时间。
注意，在本实施例中，NAV值必须短于NAV时间的预定最大限度（TXOP限）。
当要监测仅终端A 4201的NAV值以使其不超过TXOP限时，例如，执行以下操作。将TXOP分配限写在由终端A 4201发送的作为QoS Cf-轮询+数据帧的数据1-A 4319的QoS控制字段中。终端B4202将要由它自己发送的数据量确定为通过将发送多个数据帧的聚集帧所需的时间、SIFS时间以及发送BlockAck帧所需的时间相加而获得的值的上限。如果BlockAck帧4317中写有的NAV值与TXOP分配限度时间之和比从完成发送BlockAck帧4317到TXOP限的时间长度要长，那么将TXOP分配限度时间缩短并调节成使得通过将发送来自终端B 4202的HTP突发帧4353所需的时间、SIFS时间以及发送BlockAck帧4331所需的时间相加而获得的值变得短于到TXOP限的剩余时间。作为另一种选择，仅当通过将BlockAck帧4317中写有的NAV值与TXOP分配限度时间相加而获得的值比从完成发送BlockAck帧4317到TXOP限的时间长度要长时，终端A 4201才可以发送HTP突发帧4352。
当终端B4202要监测NAV值以防止它超过TXOP限时，例如，执行以下操作。终端A 4201和终端B 4202均减小HTP突发帧的聚集帧的数据量，使得通过将发送来自自身终端的HTP突发帧所需的时间、SIFS时间以及发送针对该HTP突发帧中包括的各数据帧的BlockAck帧所需的时间相加而获得的值变得短于到TXOP限的剩余时间。
（第三实施例）
图14是根据第三实施例的时序图。注意，终端A 5201根据与图3所示的第一实施例中的终端A 201的操作相关联的流程图进行操作，终端B 5202根据与图4所示的第一实施例中的终端B 202的操作相关联的流程图进行操作。
本实施例将例示如下配置：待写在来自终端A 5201的RTS帧5301中的NAV值是在由终端B 5202接收HTP突发帧5352之后完成发送待返回的BlockAck帧324所需的时间长度的值。
（3-1-1.从终端A发送RTS帧）
步骤1和2保持不变。
与第一实施例不同，在步骤3中确定的NAV时间5361的长度等于5×SIFS时间、发送CTS帧303所需的时间、发送来自终端A 5201的聚集帧5304所需的时间、发送来自终端B 5202的HTP突发帧5351所需的时间、发送来自终端A 5201的HTP突发帧5352所需的时间以及发送来自终端B 5202的BlockAck帧5324所需的时间之和。将该值作为NAV值写在RTS帧5301中。该NAV值表示从完成发送RTS帧5301到完成发送来自终端B 5202的第二BlockAck帧5324的时间长度。
图3中的步骤4到6保持不变。
（3-1-2.终端B对RTS帧的接收和对CTS帧的发送）
步骤101和102保持不变。
（3-1-3.终端A对CTS帧的接收和对聚集帧的发送）
步骤7到11保持不变。
（3-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
步骤103到109保持不变。
（3-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
步骤12和13保持不变。
在步骤14中，帧生成/传输处理单元104将通过将RIFS时间、2×SIFS时间、发送聚集帧5318所需的时间、发送HTP突发帧5353所需的时间以及发送BlockAck帧5331所需的时间相加而获得的值作为NAV值写在BlockAck帧5317中。该NAV值表示从完成发送BlockAck帧5317到完成下一次发送来自终端A 5201的BlockAck帧5331的时间长度。
步骤15到18保持不变。
当对BlockAck帧5317的接收完成时，终端C 5203和终端D 5204均禁止自己通过采用用于终端A 5201与终端B 5202之间的双向通信的频带来执行通信仅由BlockAck帧5317中写有的NAV值所表示的时间。
随后，从由RTS帧5301中的NAV值所限定的频带预留的结束时间到由BlockAck帧5317中写有的NAV值所限定的频带预留的结束时间的时间长度是NAV额外时间5362。
（3-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
步骤110和111保持不变。
在步骤112中，帧生成/传输处理单元104将通过将RIFS时间、发送聚集帧5325所需的时间、SIFS时间以及下一次发送来自终端A5331的BlockAck帧5324所需的时间相加而获得的值作为NAV值写在BlockAck帧5324中。该NAV值表示从完成发送BlockAck帧5324到完成下一次发送来自终端A 5201的BlockAck帧5331的时间长度，并表示到由BlockAck帧317中写有的NAV值所限定的频带预留的结束时间为止的剩余时间。
步骤113到116保持不变。
（3-1-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
步骤19和20保持不变。
在步骤21中，帧生成/传输处理单元104将0写成NAV值。步骤22保持不变。
如上所述，终端A 5201和终端B 5202都通知延迟了NAV，直到通过RTS-CTS交换来启动的NAV结束。这使得可以可靠地将NAV的延长甚至通知给只可以接收来自终端A 5201的发送波的终端或只可以接收来自终端B 5202的发送波的终端。
（第四实施例）
图15是根据第四实施例的时序图。
注意，终端A 6201根据与图3所示的第一实施例中的终端A 201的操作相关联的流程图进行操作，终端B 6202根据与图4所示的第一实施例中的终端B 202的操作相关联的流程图进行操作。
在本实施例中，如图16所示，假设在该双向通信中，假设除了终端A 6201和终端B 6202以外终端A 6201和终端B 6202所属的无线通信系统还包括传输数据不寻址到的终端C 6203、终端D 6204以及终端E 6205。
假设当终端A 6201和终端B 6202开始进行双向通信时，终端C6203、终端D 6204以及终端E 6205可以接收到来自终端A 6201的发送波。即，对于终端A 6201来说没有隐藏终端，即，没有不能接收来自终端A 6201的发送波的终端。
（4-1-1.从终端A发送RTS帧）
步骤1和2保持不变。
在步骤3中确定的NAV时间6361的长度与第一实施例的不同。将通过将4×SIFS时间、发送CTS帧303所需的时间、发送由终端6201所发送的聚集帧6304和BlockAck帧317所需的时间、以及发送HTP突发帧6351所需的时间相加而获得的值作为NAV值写在RTS帧6301中。该NAV值表示从完成发送RTS帧6301到完成下一次发送来自终端A6201的BlockAck帧6317的时间长度。
步骤4到6保持不变。
（4-1-2.终端B对RTS帧的接收和对CTS帧的发送）
图4中的步骤101和102保持不变。
（4-1-3.终端A对CTS帧的接收和对聚集帧的发送）
图3中的步骤7到11保持不变。
（4-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
图4中的步骤103到109保持不变。
（4-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
图3中的步骤12和13保持不变。
在步骤14中，帧生成/传输处理单元104将通过将RIFS时间、2×SIFS时间、发送聚集帧6318所需的时间、数据5-A 6319中写有的TXOP分配时间以及发送BlockAck帧6331所需的时间相加而获得的值作为NAV值写在BlockAck帧6317中。该NAV值表示从完成发送BlockAck帧6317到完成发送来自终端A 6201的BlockAck帧6331的时间长度。
图3中的步骤15到18保持不变。
当对BlockAck帧6317的接收完成时，终端C 6203、终端D 6204以及终端E 6205均禁止自己通过采用用于终端A 6201与终端B 6202之间的双向通信的频带来执行通信仅由BlockAck帧6317中写有的NAV值所表示的时间。
假设从由RTS帧4301中的NAV值所限定的频带预留的结束时间到由BlockAck帧6317中写有的NAV值所限定的频带预留的结束时间的时间长度是NAV额外时间6362。
（4-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
图4中的步骤110到116保持不变。
（4-1-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
图3中的步骤19到22保持不变。
如上所述，基站A 6201发送用于延长NAV的BlockAck帧6317，直到通过RTS-CTS交换所启动的NAV结束时。
预先限定的NAV时间持续，直到所有终端C 6203、终端D 6204以及终端E 6205都可以接收来自基站A 6201的发送波，并且基站A6201完成对BlockAck帧317的发送并向所有终端通知NAV的延长。因此，即使在包括基站A 6201的系统中，也可以在没有任何中断的情况下延长NAV时间。
注意，当要延长NAV时，基站A 6201进行调节以防止NAV额外时间的结束时间超过TXOP限。
在本实施例中，将基站A 6201称为基站。然而，在没有隐藏终端的假设下基站A 6201可以是终端。
（第五实施例）
图17是根据第五实施例的时序图。图18是与终端A 7201的操作相关联的流程图。图19是与终端B 7202的操作相关联的流程图。
假设终端A 7201位于与图5中的终端A 201的位置相同的位置，终端B 7202位于与图5中的终端B 202的位置相同的位置。
在本实施例中，将第一实施例的配置改变成使得：当终端B 7202未花费由终端A 7201所分配的全部TXOP分配时间时，将双向通信的启动加快未花费的时间。
（5-1-1.从终端A发送RTS帧）
图18中的步骤7001到7006与图3中的步骤1到6相同。
（5-1-2.终端B对RTS帧的接收和对CTS帧的发送）
图19中的步骤7101和7102与图4中的步骤101和102相同。
（5-1-3.终端A对CTS帧的接收和对聚集帧的发送）
图18中的步骤7007到7011与图3中的步骤7到11相同。
（5-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
图19中的步骤7103和7104与图4中的步骤103和104相同。
在步骤7105中，帧生成/传输处理单元104根据传输数据来生成数据1-B 7312、数据2-B 7313以及数据3-B 7314。
应当注意的是，TXOP分配时间等于RIFS时间、SIFS时间、发送BlockAck帧所需的时间以及发送4个数据帧所需的时间之和，但是终端B 7202只生成3个数据帧，即，数据1-B 7312、数据2-B 7313以及数据3-B 7314。例如，这是如下情况：终端B 7202没有足够大的量的寻址到终端A 7201的传输数据来在传输队列106中生成4个数据帧。
帧生成/传输处理单元104通过将数据1-B 7312、数据2-B 7313以及数据3-B 7314并合来生成聚集帧7311。
帧生成/传输处理单元104将通过将RIFS时间、发送包括3个数据帧的聚集帧7311所需的时间（即，发送3个数据帧所需的时间）、SIFS时间以及下一次发送来自终端A 7201的BlockAck帧7317所需的时间相加而获得的值作为NAV值写在BlockAck帧7310中。该NAV值表示从完成发送BlockAck帧7310到完成发送来自终端A 7201的BlockAck帧7317的时间长度。
图19中的步骤7106到7109与图4中的步骤106到109相同。
在此情况下，即使终端C 7204接收到BlockAck帧7310，无论BlockAck帧7310中写有的NAV值如何，该终端也不采用相应的传输频带执行通信，直到通过RTS-CTS帧交换所限定的NAV时间7361结束或接收到（稍后要描述的）Cf-结束帧7332。
（5-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
图18中的步骤7012到7018与图3中的步骤12到18相同。
在此情况下，如果从终端B7202发送的BlockAck帧7310中写有的NAV值短于到与TXOP分配时间相等的NAV时间7361的结束时间为止的剩余时间，那么终端A 7201知道数据1-A 305中写有的TXOP分配时间剩有相应的量未花费。
（5-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
图19中的步骤7101到7110与图4中的步骤101到110相同。
在步骤7111中，发送/接收状态管理单元108通过根据BlockAck帧7317中的位图确定是否存在待再发送的任何数据帧来准备待再发送的数据帧，然后执行从传输队列106提取新传输数据的处理。在此情况下，由于在传输队列106中没有寻址到终端A 7201的传输数据，因此发送/接收状态管理单元108将用于通知确认的位图传送给帧生成/传输处理单元104，然后通知没有寻址到终端A 7201的传输数据。
在步骤7112中，帧生成/传输处理单元104通过利用位图，针对发自终端A 7201的数据5-A 7319数据6-A 7320、数据7-A 7321以及数据8-A 7322生成BlockAck帧7324。帧生成/传输处理单元104已被通知没有寻址到终端A 7201的传输数据，因此生成用于通知终端A7201没有寻址到终端A 7201的传输数据的QoS空帧7326。帧生成/传输处理单元104将通过将RIFS时间、发送QoS空帧7326所需的时间、SIFS时间以及下一次发送来自终端A 7201的Ack帧7331所需的时间相加而获得的值作为NAV值写在BlockAck帧7324中。该NAV值表示从完成发送BlockAck帧7324到完成发送来自终端A 7201的Ack帧7331的时间长度。
帧生成/传输处理单元104将通过从BlockAck帧7324中写有的NAV值减去RIFS时间和发送QoS空帧7326所需的时间而获得的值作为NAV值写在QoS空帧7326中。该NAV值表示从完成发送QoS空帧7326到完成下一次发送来自终端A 7201的Ack帧7331的时间长度。
除了将传输聚集帧替换成QoS空帧以外，图19中的步骤7113到7116与图4中的步骤113到116相同。
（5-1-7.终端A对HTP突发帧的接收和对BlockAck帧的发送）
已接收到其间设置有RIFS时间的两个PHY帧（即HTP突发帧7353）的终端A7201的接收处理单元105在正常地接收到QoS空帧7326时向发送/接收状态管理单元108传送对BlockAck帧7331的发送请求（图18中的步骤7019）。
发送/接收状态管理单元108向帧生成/传输处理单元104传送对Ack帧7331的发送请求（图18中的步骤7020）。
帧生成/传输处理单元104根据所接收到的发送请求，针对发自终端B 7202的QoS空帧7326而生成Ack帧7331。帧生成/传输处理单元104生成用于NAV时间的强制终止的Cf-结束帧7332（图18中的步骤7021）。
帧生成/传输处理单元104在由接收处理单元105完成接收发自终端B7202的HTP突发帧7353之后SIFS时间时开始发送生成的HTP突发帧7354。
将对HTP突发帧7354的发送进行详细描述。首先，开始发送Ack帧7331（图18中的步骤7022）。假设对Ack帧7331的传输率是第一传输率。
帧生成/传输处理单元104在完成发送Ack帧7331之后RIFS时间时按与对Ack帧7331的传输率相同的第一传输率发送Cf-结束帧7332（图18中的步骤7023）。
终端C 7203接收Cf-结束帧7332，以知道释放了针对终端A 7201的频带预留因而可以使用该频带。
当还要执行该双向通信或者执行与另一终端的通信时，在经过了AIFS+回退时间之后再次执行从“1-4-1”起的序列的上述处理。
如上所述，在本实施例中，当终端B 7202不能花费由终端A 7201所分配的全部TXOP分配时间时，将双向通信的启动加快未花费的时间。此外，可以通知终端B 7202没有寻址到终端A 7201的传输数据。
这使得可以在不使终端B 7202的未花费时间变成不执行发送/接收的浪费时间的情况下快速终止双向通信。
根据本实施例，在步骤116中，发送QoS空帧7326。然而，如果可以通过任何帧来通知终端A 7201“终端B 7202的传输队列106没有寻址到终端A 7201的传输数据”，那么可以将QoS空帧7326替换成另一类型的帧。例如，可以达成如下协定：当BlockAck帧7324中写有的NAV值为0时，终端A 7201认为终端B 7202没有任何寻址到终端A 7201的传输数据。
此外，为了保证仅符合IEEE 802.11a/b/g/e规范的终端对Cf-结束帧7332的接收，可以按SIFS时间的间隔发送Ack帧7331和Cf-结束帧7332，而非按RIFS时间的间隔作为HTP突发帧发送Ack帧7331和Cf-结束帧7332。
作为另一种选择，可以将上述配置修改成：在不发送Ack帧7331的情况下，在由接收处理单元105完成了对来自终端B 7202的HTP突发帧7353的接收之后SIFS时间时，发送Cf-结束帧7332。在此情况下，假设终端B 7202在接收到Cf-结束帧7332时认为已发送HTP突发帧并且双向通信终止了。在此情况下，不必发送针对QoS空帧7326的Ack帧7331，因而只发送Cf-结束帧7332而不发送HTP突发帧7354。
根据本实施例，在完成发送来自终端A 7201的Ack帧7331之后RIFS时间期间将传输率从第一传输率改变成第二传输率。然而，可以按第一传输率发送Cf-结束帧7332。
（第六实施例）
图20是根据第六实施例的时序图。图21是与终端A 8201的操作相关联的流程图。
假设终端A 8202根据第五实施例中的终端A 7202的操作流程图进行操作。
还假设终端A 8201位于与图5中的终端A 201的位置相同的位置，终端B 8202位于与图5中的终端B 202的位置相同的位置。
在本实施例中，将第二实施例的配置改变成使得：当终端B 8202未花费由终端A 8201所分配的全部TXOP分配时间时，将双向通信的启动加快未花费的时间。
（6-1-1.从终端A发送RTS帧）
图21中的步骤8001和8002与图18中的步骤7001和7002相同。
在步骤8003中确定的NAV时间8361的长度与第二实施例中的相同。
图21中的步骤8004到8006与图18中的步骤7004到7006相同。
（6-1-2.终端B对RTS帧的接收和对CTS帧的发送）
图19中的步骤7101和7102保持不变。
（6-1-3.终端A对CTS帧的接收和对聚集帧的发送）
图21中的步骤8007到8011与图18中的步骤7008到7011相同。
（6-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
图19中的步骤7103和7104保持不变。
在步骤7105中，帧生成/传输处理单元104根据传输数据来生成数据1-B 8312、数据2-B 8313以及数据3-B 8314。
应当注意的是，TXOP分配时间等于RIFS时间、SIFS时间、发送BlockAck帧所需的时间以及发送4个数据帧所需的时间之和，但是终端B 8202只生成3个数据帧，即，数据1-B 8312、数据2-B 8313以及数据3-B 8314。例如，这是如下情况：终端B 8202没有足够大的量的寻址到终端A 8201的传输数据来在传输队列106中生成4个数据帧。
帧生成/传输处理单元104通过将数据1-B 8312、数据2-B 8313以及数据3-B 8314并合来生成聚集帧8311。
帧生成/传输处理单元104将通过将RIFS时间、发送聚集帧8311所需的时间（即，发送3个数据帧所需的时间）、SIFS时间以及下一次发送来自终端A 8201的BlockAck帧8317所需的时间相加而获得的值作为NAV值写在BlockAck帧8310中。该NAV值表示从完成发送BlockAck帧8310到完成发送来自终端A 8201的BlockAck帧8317的时间长度。
帧生成/传输处理单元104将通过从BlockAck帧8310中写有的NAV值减去RIFS时间和发送聚集帧8311所需的时间而获得的值作为NAV值写在数据1-B 8312、数据2-B 8313、数据3-B 8314以及数据4-B 8315中的每一个中。该NAV值表示从完成发送聚集帧8311到完成发送来自终端A 8201的BlockAck帧8317的时间长度。
图19中的步骤7106到7109保持不变。
当接收到BlockAck帧8310时，终端C 8203禁止自己在完成接收BlockAck帧8310之后通过采用用于终端A 8201与终端B 8202之间的双向通信的频带来执行通信由BlockAck帧8310中写有的NAV值所表示的时间。即，针对终端C 8203为终端A 8201延长频带预留。
（6-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
图21中的步骤8012到8018与图18中的步骤7012到7018相同。
如果从终端B 8202发送的BlockAck帧8310中写有的NAV值短于到数据1-A 8305中写有的TXOP分配时间的结束为止的剩余时间，那么终端A 8201知道BlockAck帧8305中写有的TXOP分配时间剩有相应的量未花费。
（6-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
图19中的步骤7110和7111保持不变。
在步骤7112中，帧生成/传输处理单元104通过利用位图，针对发自终端A 8201的数据5-A 8319数据6-A 8320、数据7-A 8321以及数据8-A 8322生成BlockAck帧8324。帧生成/传输处理单元104生成QoS空帧8326。
帧生成/传输处理单元104将通过将RIFS时间、发送QoS空帧8326所需的时间、SIFS时间以及下一次发送来自终端A 8201的Ack帧8331所需的时间相加而获得的值作为NAV值写在Ack帧8324中。该NAV值表示从完成发送BlockAck帧8324到完成发送来自终端A8201的Ack帧8331的时间长度。
帧生成/传输处理单元104将通过从BlockAck帧8324中写有的NAV值减去RIFS时间和发送QoS空帧8326所需的时间而获得的值作为NAV值写在QoS空帧8326中。该NAV值表示从完成发送QoS空帧8326到完成发送来自终端A 8201的Ack帧8331的时间长度。
图19中的步骤7113到7115保持不变。
此外，由于除了将待发送的帧替换成QoS空帧8326以外，步骤7116保持不变，因此将略去对步骤7116的描述。
（6-1-7.终端A对HTP突发帧的接收和对Ack帧的发送）
由于图21中的步骤8019和8020与图18中的步骤7019和7020相同，因此略去对其的描述。
帧生成/传输处理单元104通过利用接收到的位图，针对发自终端B8202的QoS空帧8326而生成Ack帧8331（图20中的步骤8021）。
帧生成/传输处理单元104在由接收处理单元105完成接收来自终端B 8202的HTP突发帧8353之后SIFS时间时发送所生成的Ack帧8331（图20中的步骤22）。
根据本实施例，不必发送Cf-结束帧8332，因为当对Ack帧8331的发送完成时NAV额外时间8364到期了。
当还要执行该双向通信时，在经过了AIFS+回退时间之后再次执行从“1-1-1”起的序列的上述处理。
如上所述，根据本实施例，即使在第二实施例中，当终端B 8202未花费由终端A 8201所分配的全部TXOP分配时间时，也可以将双向通信的启动加快未花费的时间。
结果，可以将双向通信的结束加快终端B 8202尚未花费的时间。
（第七实施例）
图22是根据第七实施例的时序图。
假设基站A 9201根据与图18所示的第五实施例中的终端A 7201的操作流程图进行操作，终端B 9202根据与图19所示的第五实施例中的终端B 7202的操作流程图进行操作。还假设基站A 9201位于与图5中的终端A 201的位置相同的位置，终端B 9202位于与图5中的终端B 202的位置相同的位置。
在本实施例中，将第四实施例的配置改变成使得：当终端B 9202未花费由基站A 9201所分配的全部TXOP分配时间时，将双向通信的启动加快未花费的时间。
（7-1-1.从终端A发送RTS帧）
图18中的步骤7001和7002保持不变。
在步骤3中确定的NAV时间9361的长度与第四实施例中的相同。
步骤7004到7006保持不变。
（7-1-2.终端B对RTS帧的接收和对CTS帧的发送）
图19中的步骤7101和7102保持不变。
（7-1-3.终端A对CTS帧的接收和对聚集帧的发送）
图18中的步骤7007到7011保持不变。
（7-1-4.终端B对聚集帧的接收和对HTP突发帧的发送）
图19中的步骤7103到7109保持不变。
（7-1-5.终端A对HTP突发帧的接收和对HTP突发帧的发送）
图18中的步骤7012和7013保持不变。
在步骤7014中，帧生成/传输处理单元104将通过将RIFS时间、2×SIFS时间、发送聚集帧9318所需的时间、数据5-A319中写有的TXOP分配时间以及发送BlockAck帧9331所需的时间相加而获得的值作为NAV值写在BlockAck帧9317中，从而延长频带预留。
图18中的步骤7015到7018保持不变。
（7-1-6.终端B对HTP突发帧的接收和对HTP突发帧的发送）
图19中的步骤7110到7115保持不变。
与第五或第六实施例一样，由于除了将待发送的帧替换成QoS空帧9326以外，步骤7116保持不变，因此也将略去对步骤7116的描述。
（7-1-7.终端A对HTP突发帧的接收和对Ack帧的发送）
图18中的步骤7019到7024保持不变。
注意，在本实施例中，由于当对Ack帧9331的完成时由BlockAck帧9317所限定的NAV额外时间7364持续，因此必须发送Cf-结束帧9332。
如上所述，根据本实施例，即使在第四实施例中，当终端B 9202未花费由终端A 9201所分配的全部TXOP分配时间时，也可以将双向通信的启动加快未花费的时间。
结果，可以将双向通信的结束加快终端B 9202尚未花费的时间。
（第八实施例）
参照根据图17所示的第五实施例的时序图进行以下描述。然而，假设将BlockAck帧7317替换成CTS自身帧7317。
当终端A 7201不能正常接收发自终端B 7202的HTP突发帧7351时，设定以下4个状态中的一个。本实施例将例示从第五实施例中的那些状态中的每一个进行恢复的方式。
（1）当载波侦听单元109自完成了对与QoS Cf-轮询+数据帧7305相并合的聚集帧7304的发送起甚至在经过了SIFS+1时隙时间之后也在载波侦听处理中未检测到与接收功率相关联的“忙”时：
在自完成了对聚集帧7304的发送起直到经过了SIFS+1时隙时间时与接收功率相关联地对是否检测到“忙”进行了监测之后，再发送与QoS Cf-轮询+数据帧7305相并合的聚集帧7304。作为另一种选择，可以发送BlockAckRequest帧。这些操作与IEEE 802.11e中定义的那些操作相同。
（2）当在正常接收到BlockAck帧7310之后RIFS时间时载波侦听单元109在载波侦听处理中未检测到与接收功率相关联的“忙”时：
在终端A7201完成发送第一聚集帧7304之后，通过管理帧交换等预先知道每个终端都将发送其间设置有RIFS时间的两个PHY帧。
由于该原因，即使在完成接收BlockAck帧7310（即第一PHY帧）之后RIFS时间时终端A 7201的载波侦听单元109在载波侦听处理中是“空闲”的，终端B 7202也应当已发送某个帧（在此情况下是聚集帧7311）作为第二PHY帧。
在此情况下，根据一种恢复方法，如在现有技术中那样，由终端A 7201在接收作为第一PHY帧的BlockAck帧7310之后PIFS时间（SIFS+1时隙）时发送待再发送的帧。
然而，在此情况下，从终端A 7201再发送的帧与从终端B 7202发送的某个帧相冲突。
这可以通过禁止终端A 7201执行发送仅分配给终端B 7202的TXOP分配时间的技术来避免。根据本实施例，在此情况下，根据由终端B 7202在终端A 7201接收到BlockAck帧7310之后在BlockAck帧7310中写入的NAV值，可以知道从终端B 7202发送的聚集帧的长度、SIFS时间以及发送BlockAck帧所需的时间。由于该原因，在经过了由BlockAck帧7310中写有的NAV值所表示的时间之后发送CTS自身帧7317。在该发送之后RIFS时间时发送聚集帧7318。即，将CTS自身帧7317作为HTP突发帧7352的一部分来发送。
（3）当载波侦听单元109在正常接收BlockAck帧310之后RIFS时间时在载波侦听处理中检测到与接收功率相关联的“忙”时：
如果终端A 7201的载波侦听单元109在完成接收BlockAck帧7314（即第一PHY帧）之后RIFS时间时在载波侦听处理中是“忙”的，那么认为当载波侦听单元109从“忙”转变成“闲”时，完成了对作为第二PHY帧从终端B 7202发送的某个帧（在此情况下是聚集帧7311）的发送。
在此情况下，因此，在终端A 7201的载波侦听单元109在完成接收BlockAck帧7310（即第一PHY帧）之后RIFS时间时变得“忙”之后，在载波侦听单元109变得“闲”之后PIFS时间时开始对CTS-自身帧7317的发送。在以上发送过程完成之后RIFS时间时发送数据帧或聚集帧。即，将CTS-自身帧7317作为HTP突发帧7352的一部分来发送。
（4）载波侦听单元109在对与QoS Cf-轮询+数据帧7305相并合的聚集帧7304的发送完成之后SIFS时间时在载波侦听处理中未检测到与接收功率相关联的“忙”，但是不能正常读取所接收到的帧：
在此情况下，自完成发送根据HTP突发帧7351的聚集帧7304起在经过了SIFS时间之后检测到“忙”仅与对BlockAck帧7310的发送相对应的时间。然后检测到“闲”仅RIFS时间，然后再次检测到“忙”。由于认为下一次检测到“闲”时的时间点对应于对HTP突发帧7351的发送完成时的时间点，因此在经过了PIFS时间之后开始发送CTS自身帧7317，然后在完成上述发送过程之后RIFS时间时发送聚集帧7318。即，将CTS-自身帧7317作为HTP突发帧7352的一部分来发送。
该恢复操作防止在RD方案中从终端A 7201发送的用于恢复操作的帧与从终端B 7202发送的HTP突发帧相冲突。
此外，如果终端B 7202未花费由终端A 7201所分配的全部TXOP分配时间，那么终端A 7201可以接收BlockAck帧310，可以将双向通信的启动加快未花费的时间。
设想将如本实施例中那样的恢复技术与第五、第六以及第七实施例组合起来。在此情况下，即使通过RTS-CTS帧交换所设定的NAV或BlockAck帧与由来自终端B 7202的BlockAck帧7314所设定的NAV同时到期，由于在NAV之前或紧接在NAV之后发送了CTS自身帧7317，因此不存在NAV已到期的可能性。这使得可以避免从终端A 7201和除终端B 7202以外的终端发送的帧相互冲突。
（第九实施例）
参照根据图14所示的第三实施例的时序图进行以下描述。注意，然而，将BlockAck帧5317替换成CTS自身帧5317。
第九实施例将针对第八实施例中描述的情况（2）例示第三实施例中的恢复操作。
注意，针对第八实施例中的情况（1）、（3）以及（4）的恢复操作保持不变。
（2）当在正常接收到BlockAck帧5310之后RIFS时间时载波侦听单元109在载波侦听处理中未检测到与接收功率相关联的“忙”时：
在从终端A 5201完成发送第一聚集帧5304之后，通过管理帧交换等预先知道每个终端都将发送其间设置有RIFS时间的两个PHY帧。
因此，即使在完成接收BlockAck帧5310（即第一PHY帧）之后RIFS时间时终端A 5201的载波侦听单元109在载波侦听处理中检测到与接收功率相关联的“空闲”，终端B 5202也应当已发送某个帧（在此情况下是聚集帧5311）作为第二PHY帧。
根据如现有技术中那样的恢复方法，由终端A 5201在接收作为第一PHY帧的BlockAck帧5310之后PIFS时间（SIFS+1时隙）时发送待再发送的帧。
然而，根据该操作，从终端A 5201再发送的帧与从终端B 5202发送的某个帧相冲突。
为了避免该冲突，在此情况下，在终端A 5201接收到BlockAck帧5310之后，终端A 5201在分配给终端B 5202的TXOP分配时间结束之后自完成发送CTS自身帧5317起在经过了RIFS时间之后发送数据帧或聚集帧。即，将CTS-自身帧5317作为多个数据帧的HTP突发帧5352的一部分来发送。
执行这种恢复会使得可以防止在RD方案中从终端A 5201发送的用于恢复操作的帧与从终端B 5202发送的HTP突发帧相冲突。
如果终端B 5202未花费由终端A 5201所分配的全部TXOP分配时间，那么终端A 5201可以检测到与接收功率相关联的“忙”，可以将双向通信的启动加快未花费的时间。
设想将如本实施例中那样的恢复技术与第五实施例组合起来。在此情况下，即使通过RTS-CTS帧交换所设定的NAV或BlockAck帧与由来自终端B 5202的BlockAck帧5314所设定的NAV同时到期，也不存在NAV在CTS-自身帧5317之前已到期的可能性。这使得可以避免从终端A 5201和除终端B 5202以外的终端发送的帧相互冲突。
（第十实施例）
以下将对本发明的每个实施例中的HTP突发帧的配置和在接收HTP突发帧时的接收操作进行详细描述。
图23A和23B均示出了PHY帧的配置。图23C和23D均示出了HTP突发帧的配置。
如图23A所示，在本发明的各实施例中的相应终端之间发送/接收帧，这些帧具有如下帧配置：在MAC帧5（如从MAC层发送到PHY层的数据帧或BlockAck帧）之前添加PHY头部3（其中有必需的信息，如传输率和发送帧长度，这些信息对于在数据发送/接收时对PHY层的控制来说是必需的），并且在PHY头部3之前附加有在PHY层处进行接收时用于时间同步所必需的前导1。
在本发明的每个实施例中，将具有图23A所示的配置的帧和具有图23B所示的配置的帧（聚集帧20）（其中在图23A所示的帧之后交替并合有多个PHY头部3和多个MAC帧5）称为PHY帧10。当要在MAC层处执行聚合时，在没有任何PHY头部3的情况下聚集多个MAC帧5以形成一聚集帧。
HTP突发帧具有如图23C所示那样的帧配置，并且作为多个聚集帧中的一个按HTP突发方案发送该HTP突发帧作为突发串，其中在参照图23A或23B描述的PHY帧10之间设置有RIFS间隔，对这些PHY帧10附加有前导1和PHY头部3。在本发明的各实施例中将该突发串发送称为HTP突发帧。作为另一种选择，可以采用在RIFS之后略去了前导的对PHY帧进行并合的方法，如图23D所示。
在HTP突发帧50中，在PHY帧之间设置有RIFS时间7。RIFS时间7是大大短于SIFS时间（在IEEE 802.11a中是16μs）（其为常规IEEE 802.11规范中的最小时间间隔）的间隔（2μs）。因此，为了减少PHY层处的接收处理，如在现有技术中那样，有必要在进行发送之前通知PHY层是按RIFS时间7还是按SIFS时间的间隔来发送数据。如果如图23D所示那样略去了前导1，具体来说，当PHY层未认识到PHY头部会在经过了2μs之后到达时，无法接收数据，因为不能建立时间同步。
根据本发明各实施例，在RD方案中，发起站与响应器终端在RD方案中进行双向数据发送/接收之前通过诸如关联的管理帧交换过程来达成协定：将从发起站终端发送的第一个聚集帧之后的所有聚集帧作为基于HTP突发方案的聚集帧进行通信，每个聚集帧都包括两个PHY帧10，使得将一个BlockAck帧附加到每个聚集帧的头部，并按RIFS时间7的间隔聚集一个PHY帧10。因此，当在RD方案中开始进行发送/接收时，MAC层可以知道它必须按RIFS时间7执行接收。这使得可以指示PHY层是否按RIFS时间7执行接收处理。
根据上述协定，协定使用三个或更多个PHY帧10，而不使用两个PHY帧10。此外，假设协定只使用最大数量个PHY帧10。在此情况下，对在接收到PHY帧10之后是否按RIFS执行发送的表示使得可以在没有来自MAC层的任何指示的情况下按RIFS时间7准备进行连续的接收处理。
此外，如果如在本发明各实施例中的BlockAck帧、Ack帧或Cf-结束帧的情况那样在MAC层处基于RD方案进行了通信之后知道不会按RIFS的间隔发送两个PHY帧，那么在接收了帧之后通知PHY层不必按RIFS时间7执行接收，因而可以将PHY层的接收模式恢复成普通模式。
根据按RIFS间隔执行突发发送的HTP突发方案，可以根据需要从MAC层对按RIFS间隔执行数据接收的特殊情形和普通接收方法进行控制。此外，对PHY头部的使用使得可以仅在PHY层执行控制，因而可以略去从MAC层进行的通知操作。
（第十一实施例）
在第一实施例中，基于RD方案的发起站终端与一个响应器终端执行双向数据发送/接收处理。与此相对照，本发明将例示如下方法：当在与作为总发送时段的TXOP分配时间相对应的时间内执行采用（在第一实施例中已描述的）RTS帧中的NAV和CTS帧中的NAV的频带预留，并执行基于RD方案与HTP突发方案的组合的发送/接收处理时，即使存在多个响应器终端，也执行基于RD方案与HTP突发方案的组合的发送/接收处理。
由于本实施例与第一实施例的不同之处仅在于存在多个响应器终端并且向不同目的地发送数据，因此以下仅主要对与第一实施例不同的部分进行描述。
图24是用于对如下情况下的发送/接收方法进行说明的时序图：当要执行基于RD方案与HTP突发方案的组合的发送/接收处理时，存在多个响应器终端。
在本实施例中，作为基于RD方案的发起站终端的终端A1501向作为第一响应器终端的终端B1502发送其中作为NAV值写有用于RD方案的TXOP时间的RTS帧1504。当接收到RTS帧1504时，终端B1502将通过从RTS帧1504中写有的NAV值减去SIFS时间和发送CTS帧1505所需的时间而获得的值写在CTS帧1505中，并将该帧返回给终端A1501。终端A1501接着发送通过将寻址到终端B1502的传输数据（即，数据1-A、数据2-A、数据3-A以及数据4-A）进行聚合而获得的聚集帧（该聚集帧的头部附加有QoS Cf-轮询+数据帧）。响应于该帧，终端B1502向终端A1501返回其头部附加有BlockAck帧1508的HTP突发帧1509。到此时间点为止的发送/接收操作与第一实施例中的相同。
当接收到HTP突发帧1509时，与第一实施例中不同，终端A1501在发送针对HTP突发帧1509的BlockAck帧时切换到与终端C1503之间的RD方案。终端A1501针对从终端B1502发送到终端A1501的HTP突发帧1509中的数据（即，数据1-B、数据2-B、数据3-B以及数据4-B），生成BlockAck帧1510作为BlockAck帧。通过将从终端A1501到终端C1503的传输数据（即，数据5-A、数据6-A、数据7-A以及数据8-A）聚合在BlockAck帧1510的RIFS之后，生成HTP突发帧1511，并将其发送给终端B1502和终端C1503。在本实施例中，将寻址到两个终端的帧（即，寻址到终端B1502的BlockAck帧1510和寻址到终端C1503的传输数据（即，数据5-A、数据6-A、数据7-A以及数据8-A））并合在HTP突发帧1511中。此外，寻址到终端C1503的传输数据（即，数据5-A）是QoS Cf-轮询+数据型的帧，并且将TXOP时间的一部分分配给终端C1503。
当接收到HTP突发帧1511时，终端B1502根据BlockAck帧1510检查从自身站发送的数据的确认状态。当接收到HTP突发帧1511时，终端C1503根据BlockAck帧1510之后RIFS时间的QoS Cf-轮询+数据帧1512，知道对自身站分配了TXOP时间。终端C1503接着针对HTP突发帧1511中的数据（即，数据5-A、数据6-A、数据7-A以及数据8-A））而生成BlockAck帧1513，在该BlockAck帧1513的RIFS之后通过将到终端A1501的传输数据（即，数据1-C、数据2-C、数据3-C以及数据4-C）聚合而生成HTP突发帧1514，并将该帧返回给终端A1501。当接收到HTP突发帧1514时，终端A1501针对到终端A1501的HTP突发帧1514中的传输数据（即，数据1-C、数据2-C、数据3-C以及数据4-C）而生成BlockAck帧1515，并在接收到HTP突发帧1514之后SIFS时间时返回该帧，从而结束终端B1502与终端C1503之间的采用RD方案的发送/接收处理。
在此时间点，在此情况下所采用的NAV设定方法和对HTP突发帧中的BlockAck帧的传输率与第一实施例中的相同。
在本实施例中的上述方法（即，接收聚集有QoS Cf-轮询+数据帧的聚集帧的方法，和发送通过在SIFS之后的BlockAck帧与通过聚合多个传输数据而获得的帧之间设定RIFS间隔而获得的HTP突发帧的方法）与其他实施例中的相同。因此，可以将其他实施例中的所有发送/接收方法都应用于根据本实施例的基于RD方案在多个终端之间进行的发送/接收处理。此外，可以按相同的方式执行恢复操作。
可以通过采用根据本实施例的发送/接收方法来执行基于RD方案的多个终端之间的双向通信，并且可以使BlockAck帧的发送成功概率高于多个终端之间的双向通信过程中的传输数据的发送成功概率。此外，通过与用于传输数据的PHY帧不同的PHY帧来发送BlockAck帧，使得可以通过利用该BlockAck帧来延长频带预留时段。即，在保持与其他实施例中所描述的效果相同的效果的同时，本实施例可以在多个终端之间高效地执行双向通信。
（第十二实施例）
除了在与多个终端执行双向通信时多轮询帧用于同时向多个终端分配发送时段以外，第十二实施例与第十一实施例相同，因此将只对与第十一实施例的不同部分进行描述。
图25是用于说明如下方法的时序图：通过借助于MMP（多接收器聚集多轮询）帧向多个终端分配发送时段，对来自自身站的传输数据和来自该多个终端的传输数据执行双向通信。
作为启动与本实施例中的多个终端之间的双向通信过程的终端的终端A1601发送通过如下处理而获得的HTP突发帧1606：将到终端B1602的传输数据（即，数据1-B、数据2-B、数据3-B以及数据4-B）聚合到一个PHY帧中（在该帧的头部在RIFS之后附加有MMP帧1604），并在RIFS之后将寻址到终端C1603的传输数据（即，数据5-A、数据6-A、数据7-A以及数据8-A）连接到该PHY帧。
将针对终端B1602的偏移时段1607和分配给终端B1602的TXOP时间1608写在MMP帧1604中，作为分配给终端B1602的发送时段。将针对终端C1603的偏移时段1609和分配给终端C1603的TXOP时间1610写在MMP帧1604中，作为分配给终端C1603的发送时段。将针对由MMP帧1604启动的双向通信时段1605中的频带预留的NAV值写在MMP帧1604中。
当接收到其头部并合有MMP帧1604的HTP突发帧1606时，终端B1602提取在MMP帧1604中写有的针对终端B1602的偏移时段1607，并通过利用终端B1602的发送/接收状态管理单元108来设定针对该偏移时段1607的定时器。终端B1602接着接收寻址到终端B1602的HTP突发帧1606中的传输数据（即，数据1-A、数据2-A、数据3-A以及数据4-A），并生成BlockAck帧1611。
当在终端B1602接收到HTP突发帧1606之后由发送/接收状态管理单元108设定的针对终端B1602的偏移时段1607的定时器到期时，分配给终端B1602的TXOP时间1608开始。此时，终端B1602生成BlockAck帧1611，并通过将到终端A1601的传输数据（即，数据1-B、数据2-B、数据3-B以及数据4-B）聚合在该BlockAck帧1611之后RIFS处来生成HTP突发帧1612。终端B1602接着将该HTP突发帧1612发送给终端A1601。终端B1602在发送HTP突发帧1612之后SIFS时间时接收来自终端A1601的BlockAck帧1613。然而，注意，对要聚合以形成HTP突发帧1612的数据的数量进行调节，以不使其超过分配给终端B1602的TXOP时间1608。如图25所示，由于HTP突发帧1612具有设置在BlockAck帧1611与到终端A1601的传输数据（即，数据1-B、数据2-B、数据3-B以及数据4-B）之间的RIFS时段，因此如在其他实施例中那样可以改变传输率并且可以通知NAV。
按与终端B1602相同的方式，当接收到HTP突发帧1606时，终端C1603提取在MMP帧1604中写有的针对终端C1603的偏移时段1609，并通过利用终端C1603的发送/接收状态管理单元108来设定针对该偏移时段1607的定时器。终端C1603接着接收寻址到终端C1603的HTP突发帧1606中的传输数据（即，数据5-A、数据6-A、数据7-A以及数据8-A），并生成BlockAck帧。当由终端C1603的发送/接收状态管理单元108设定的针对终端C1603的偏移时段1609的定时器到期时，分配给终端C1603的TXOP时间1610开始，并且终端C1603生成BlockAck帧1614。终端C1603通过将到终端A1601的传输数据（即，数据1-C、数据2-C、数据3-C以及数据4-C）聚合在该BlockAck帧1614之后RIFS时间处来生成HTP突发帧1615，然后将该HTP突发帧发送给终端A1601。终端C1603接着在发送HTP突发帧1615之后SIFS时间时接收来自终端A1601的BlockAck帧1616，并终止由BlockAck帧1614启动的双向通信时段1605。
然而，注意，分配给终端C1603的TXOP时间1610在分配给终端B1602的TXOP时间1608结束之后开始。
假设存储在终端B1602的传输队列中的数据的数量很小因而终端B1602不能花费掉分配给终端B1602的全部TXOP时间1608，分配了TXOP时间的终端A1601在接收到BlockAck帧之后RIFS时间时接收到一个PHY帧，从而如在其他实施例中那样表示在所分配的TXOP时间中的通信的完成，如图25所示。在此情况下，可以将未花费的TXOP时间用于发送从终端A 1601寻址到另一终端的数据。然而，注意，在分配给终端C 1603的TXOP时间1610的开始时间之前要使用未花费的TXOP时间。
通过采用根据本实施例的通信方法，可以使BlockAck帧的发送成功概率比在使用用于同时将发送时段分配给多个终端的多轮询帧的通信方法中的传输数据的发送成功概率要高。此外，通过与传输数据不同的PHY帧来发送BlockAck帧，使得可以通过利用该BlockAck帧来再次通知频带预留时段。再者，在BlockAck帧中写入由被分配了TXOP时间的终端来使用的时段，使得可以通知在所分配的TXOP时间内不使用的时段，从而高效地利用被分配了TXOP时间的终端不使用的时段。
本领域的技术人员可以容易地发现其他优点和修改。因此，本发明就其更广泛的方面而言，不受这里所示和所描述的具体细节和多个代表性实施例的限制。因此，在不脱离由所附权利要求及其等同物所限定的总的发明概念的精神或范围的前提下，可以进行各种修改。

Claims (18)

1.一种与另一个无线通信设备执行双向通信的无线通信设备，其中所述另一个无线通信设备预留频带并具有访问所述频带的权利的一部分时段被从所述另一个无线通信设备分配作为分配时段，所述无线通信设备包括：
接收装置，配置成从所述另一个无线通信设备接收多个MAC帧；
生成装置，配置成生成第一物理帧和第二物理帧；
其中，第一物理帧包括作为针对包括在接收到的多个MAC帧中的多个接收数据帧的确认的确认帧，以及第二物理帧包括寻址到所述另一个无线通信设备的多个传输数据帧；和
传输装置，配置成在所述分配时段期间按第一传输方案发送所述第一物理帧，然后按第二传输方案发送所述第二物理帧，
其中，第一传输方案能够被支持第一传输方案的第一无线通信设备和支持第一传输方案和第二传输方案两者的第二无线通信设备接收，以及其中，第二传输方案能够被第二无线通信设备接收。
2.根据权利要求1所述的无线通信设备，其中，从完成第一物理帧的传输到在所述传输装置启动第二物理帧的传输的时段是缩减帧间间隔。
3.根据权利要求1所述的无线通信设备，其中，在完成由所述另一个无线通信设备启动的RTS-CTS帧交换之后，启动与所述另一个无线通信设备的双向通信。
4.根据权利要求1所述的无线通信设备，其中，第一物理帧包含第一频带预留时段的值。
5.根据权利要求1所述的无线通信设备，其中，所述接收装置进一步接收接在所述多个接收数据帧之后的来自所述另一个无线通信设备的确认请求帧，以及
其中，所述确认请求帧按第一传输方案被发送，而所述多个传输数据帧按第二传输方案被发送。
6.根据权利要求1所述的无线通信设备，其中，所述生成装置进一步生成第三物理帧，该第三物理帧包括请求关于所述多个传输数据帧的确认帧的确认请求帧，以及
其中，所述传输装置在发送第二物理帧之后，按第一传输方案发送所述第三物理帧。
7.根据权利要求4所述的无线通信设备，其中，所述接收装置进一步根据从所述另一个无线通信设备接收的多个MAC帧来确定第二频带预留时段，以及其中，第二频带预留时段是基于第一频带预留时段而计算的。
8.根据权利要求4所述的无线通信设备，其中，第一频带预留时段是所述另一个无线通信设备所预留的时段的剩余时段。
9.根据权利要求1所述的无线通信设备，其中，包括在第二物理帧中的多个传输数据帧的量被调节以适合在所述分配时段内。
10.根据权利要求4所述的无线通信设备，其中，第一频带预留时段在持续时间字段中被指定，并被第一无线通信设备和第二无线通信设备用作网络分配向量(NAV)值，以及
其中，所述另一个无线通信设备预留频带的时段是发送机会(TXOP)时段。
11.根据权利要求1所述的无线通信设备，进一步包括天线，
其中，所述接收装置使用所述天线来接收所述多个MAC帧，以及
所述传输装置使用所述天线来发送第一物理帧和第二物理帧。
12.一种向另一个无线通信设备分配一部分时段作为分配时段并与所述另一个无线通信设备执行双向通信的无线通信设备，其中在所述一部分时段期间，所述无线通信设备预留频带并具有访问所述频带的权利，所述无线通信设备包括：
接收装置，配置成从所述另一个无线通信设备接收多个MAC帧；
生成装置，配置成生成第一物理帧和第二物理帧；
其中，第一物理帧包括作为针对包括在接收到的多个MAC帧中的多个接收数据帧的确认的确认帧，以及第二物理帧包括寻址到所述另一个无线通信设备的多个传输数据帧；和
传输装置，配置成在所述分配时段期间按第一传输方案发送所述第一物理帧，然后按第二传输方案发送所述第二物理帧，
其中，第一传输方案能够被支持第一传输方案的第一无线通信设备和支持第一传输方案和第二传输方案两者的第二无线通信设备接收，以及其中，第二传输方案能够被第二无线通信设备接收。
13.根据权利要求12所述的无线通信设备，其中，第一物理帧包含第一频带预留时段的值。
14.根据权利要求12所述的无线通信设备，其中，所述接收装置进一步接收接在所述多个接收数据帧之后的来自所述另一个无线通信设备的确认请求帧，以及
其中，所述确认请求帧按第一传输方案被发送，而所述多个传输数据帧按第二传输方案被发送。
15.根据权利要求12所述的无线通信设备，其中，所述生成装置进一步生成第三物理帧，该第三物理帧包括请求关于所述多个传输数据帧的确认帧的确认请求帧，以及
其中，所述传输装置在发送第二物理帧之后，按第一传输方案发送所述第三物理帧。
16.根据权利要求13所述的无线通信设备，其中，第一频带预留时段是所述无线通信设备所预留的时段的剩余时段。
17.根据权利要求13所述的无线通信设备，其中，第一频带预留时段在持续时间字段中被指定，并被第一无线通信设备和第二无线通信设备用作网络分配向量(NAV)值，以及
其中，所述无线通信设备预留频带的时段是发送机会(TXOP)时段。
18.根据权利要求12所述的无线通信设备，进一步包括天线，
其中，所述接收装置使用所述天线来接收所述多个MAC帧，以及
所述传输装置使用所述天线来发送第一物理帧和第二物理帧。
CN201210247057.2A 2005-06-17 2006-03-27 无线通信设备 Active CN102801507B (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2005-178584 2005-06-17
JP2005178584A JP4364165B2 (ja) 2005-06-17 2005-06-17 無線通信装置

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN200680017109XA Division CN101189831B (zh) 2005-06-17 2006-03-27 与发起站执行双向通信的无线通信设备和方法

Publications (2)

Publication Number Publication Date
CN102801507A CN102801507A (zh) 2012-11-28
CN102801507B true CN102801507B (zh) 2015-03-11

Family

ID=36682658

Family Applications (2)

Application Number Title Priority Date Filing Date
CN200680017109XA Active CN101189831B (zh) 2005-06-17 2006-03-27 与发起站执行双向通信的无线通信设备和方法
CN201210247057.2A Active CN102801507B (zh) 2005-06-17 2006-03-27 无线通信设备

Family Applications Before (1)

Application Number Title Priority Date Filing Date
CN200680017109XA Active CN101189831B (zh) 2005-06-17 2006-03-27 与发起站执行双向通信的无线通信设备和方法

Country Status (5)

Country Link
US (2) US7852791B2 (zh)
EP (2) EP1900154B1 (zh)
JP (1) JP4364165B2 (zh)
CN (2) CN101189831B (zh)
WO (1) WO2006134704A1 (zh)

Families Citing this family (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1145965A (ja) * 1997-07-28 1999-02-16 Kyocera Corp 伝熱性化合物およびこれを用いた半導体装置
US20050165946A1 (en) * 2003-12-22 2005-07-28 Intel Corporation Bi-directional wireless LAN channel access
JP4331088B2 (ja) 2004-11-01 2009-09-16 株式会社東芝 通信装置および通信方法
US8542589B2 (en) * 2006-06-05 2013-09-24 Qualcomm Incorporated Method and apparatus for providing beamforming feedback in wireless communication systems
JP4888396B2 (ja) * 2007-03-05 2012-02-29 ソニー株式会社 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
US8948046B2 (en) 2007-04-27 2015-02-03 Aerohive Networks, Inc. Routing method and system for a wireless network
KR101408544B1 (ko) 2007-05-07 2014-06-17 삼성전자주식회사 근거리무선통신의 데이터 송수신 방법
JP2008306419A (ja) * 2007-06-07 2008-12-18 Sony Corp 送信装置及び方法、並びにプログラム
US8270437B2 (en) 2007-06-18 2012-09-18 Intel Corporation Wireless network and method for communicating aggregated packets
US9686049B2 (en) * 2007-09-12 2017-06-20 Avago Technologies General Ip (Singapore) Pte. Ltd Method and system for Bluetooth (BT) delayed acknowledgement (ACK)
JP2009088915A (ja) * 2007-09-28 2009-04-23 Sony Corp 無線送信装置、無線送信方法、無線通信システム及びプログラム
US8837435B2 (en) 2007-10-31 2014-09-16 Samsung Electronics Co., Ltd. Method and system for medium access control in communication networks
US10771199B2 (en) 2008-04-02 2020-09-08 Qualcomm Incorporated Methods and apparatus for reverse link acknowledgement in a wireless local area network (WLAN)
US9450711B2 (en) * 2008-04-02 2016-09-20 Qualcomm Incorporated Method and apparatus for extended reverse direction grant in a wireless local area network (WLAN)
US9203560B2 (en) * 2008-04-04 2015-12-01 Qualcomm Incorporated Methods and apparatus for delayed block acknowledgement in a wireless local area network (WLAN)
US8218502B1 (en) 2008-05-14 2012-07-10 Aerohive Networks Predictive and nomadic roaming of wireless clients across different network subnets
JP2010050923A (ja) * 2008-08-25 2010-03-04 Sony Corp 通信装置、通信方法、プログラム、および通信システム
US9674892B1 (en) 2008-11-04 2017-06-06 Aerohive Networks, Inc. Exclusive preshared key authentication
US8811420B2 (en) * 2009-01-05 2014-08-19 Samsung Electronics Co., Ltd. System and method for contention-based channel access for peer-to-peer connection in wireless networks
US8483194B1 (en) * 2009-01-21 2013-07-09 Aerohive Networks, Inc. Airtime-based scheduling
JP5253229B2 (ja) * 2009-02-24 2013-07-31 株式会社東芝 無線通信装置
US8498280B2 (en) * 2009-03-27 2013-07-30 Qualcomm Incorporated Method and system for reducing header information in communication systems
JP5391816B2 (ja) 2009-05-08 2014-01-15 ソニー株式会社 通信装置及び通信方法、コンピューター・プログラム、並びに通信システム
US9900251B1 (en) 2009-07-10 2018-02-20 Aerohive Networks, Inc. Bandwidth sentinel
US11115857B2 (en) 2009-07-10 2021-09-07 Extreme Networks, Inc. Bandwidth sentinel
ES2825575T3 (es) * 2009-08-26 2021-05-17 Lg Electronics Inc Método y aparato para la transmisión de múltiples marcos para soportar MU-MIMO
KR101798163B1 (ko) 2009-12-09 2017-11-15 마벨 월드 트레이드 리미티드 집합체 데이터 단위들을 위한 무선 통신 시그널링
CN101800631B (zh) * 2010-01-27 2013-08-14 华为终端有限公司 一种逻辑链路控制中的帧处理方法和装置
US9173234B2 (en) 2010-03-31 2015-10-27 Qualcomm Incorporated Protection mechanisms for multi-user MIMO transmissions
US8989066B2 (en) * 2010-03-31 2015-03-24 Qualcomm, Incorporated Protection mechanisms for multi-user MIMO transmissions
BR112012031708A2 (pt) * 2010-07-13 2018-03-06 Thomson Licensing protocolo de jogo triplo - um protocolo de camada de controle de acesso a meio para transmissões em cooperação bidirecional de três nós codificados em rede
US8671187B1 (en) 2010-07-27 2014-03-11 Aerohive Networks, Inc. Client-independent network supervision application
US9002277B2 (en) 2010-09-07 2015-04-07 Aerohive Networks, Inc. Distributed channel selection for wireless networks
US9179476B2 (en) * 2011-10-11 2015-11-03 Qualcomm Incorporated Multi-user transmission during reverse direction grant
US10091065B1 (en) 2011-10-31 2018-10-02 Aerohive Networks, Inc. Zero configuration networking on a subnetted network
CN104769864B (zh) 2012-06-14 2018-05-04 艾诺威网络有限公司 多播到单播转换技术
US9743399B2 (en) * 2012-09-07 2017-08-22 Intel Corporation Methods and arrangements to signal short interframe spaces
GB2510140A (en) * 2013-01-24 2014-07-30 Sony Corp Virtual carrier for reduced capability wireless devices
US10389650B2 (en) 2013-03-15 2019-08-20 Aerohive Networks, Inc. Building and maintaining a network
US9413772B2 (en) 2013-03-15 2016-08-09 Aerohive Networks, Inc. Managing rogue devices through a network backhaul
US20150036673A1 (en) * 2013-07-30 2015-02-05 Qualcomm Incorporated Systems and methods for communicating multi-destination traffic in a wireless network
US9277567B2 (en) * 2013-08-29 2016-03-01 Qualcomm Incorporated Systems and methods for improved communication efficiency in high efficiency wireless networks
US9585171B2 (en) * 2013-09-13 2017-02-28 Futurewei Technologies, Inc. System and method for one-way traffic in wireless communications systems
CN105981469B (zh) 2014-02-11 2020-04-21 华为技术有限公司 数据传输处理方法及装置
WO2015137591A1 (ko) * 2014-03-10 2015-09-17 엘지전자 주식회사 무선랜에서 재전송 방법 및 장치
WO2016003994A1 (en) * 2014-06-30 2016-01-07 Dow Global Technologies Llc Treated porous material
US9408214B2 (en) 2014-07-24 2016-08-02 Qualcomm Incorporated Methods and systems for protection and bandwidth selection for downlink and uplink frequency division multiple access communications
US9775170B2 (en) * 2014-12-04 2017-09-26 Intel Corporation Apparatus, system and method of allocation using a frame
US10111258B2 (en) 2015-02-13 2018-10-23 Qualcomm Incorporated Methods and systems for receiver initiated protection of a wireless communication exchange
US10116360B2 (en) * 2015-04-23 2018-10-30 Newracom, Inc. Method and apparatus for uplink multi-user transmission in a high efficiency wireless LAN
GB201514517D0 (en) 2015-08-14 2015-09-30 Purelifi Ltd Wireless communication method and system
EP3340719B1 (en) * 2015-08-21 2020-03-04 Nippon Telegraph And Telephone Corporation Wireless communication system and wireless communication method
WO2017151932A1 (en) * 2016-03-02 2017-09-08 Marvell Semiconductor, Inc. Multiple traffic class data aggregation in a wireless local area network
CN107172714B (zh) * 2016-03-08 2022-07-15 中兴通讯股份有限公司 网络分配矢量nav的处理方法及装置
US10205578B2 (en) * 2016-09-05 2019-02-12 Lg Electronics Inc. Acknowledgement procedure in WLAN
US11962413B2 (en) 2019-03-12 2024-04-16 Sony Group Corporation Wireless communication device and method
CN115190534B (zh) * 2022-09-13 2022-12-06 北京科技大学 基于聚合帧的移动通信系统plc传输增强方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1599341A (zh) * 2003-09-18 2005-03-23 西安电子科技大学 无线局域网多速率传输方法
WO2005039127A1 (en) * 2003-10-15 2005-04-28 Qualcomm Incorporated High speed media access control
WO2005041467A2 (en) * 2003-10-24 2005-05-06 Sony Corporation Wireless communication system, wireless communication device and wireless communication method, and computer program

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1184751C (zh) * 1997-11-18 2005-01-12 国际商业机器公司 改进的无线光通信方法
US6266334B1 (en) * 1998-07-20 2001-07-24 Zayante, Inc. Method for optimizing acknowledge packet rate
US7054329B2 (en) * 2000-07-07 2006-05-30 Koninklijke Philips Electronics, N.V. Collision avoidance in IEEE 802.11 contention free period (CFP) with overlapping basic service sets (BSSs)
JP2004040373A (ja) 2002-07-02 2004-02-05 Canon Inc 無線端末装置およびその制御方法
US20040057507A1 (en) * 2002-09-24 2004-03-25 Ron Rotstein Link estimation in a communication system
EP1590922A1 (en) * 2003-01-09 2005-11-02 Thomson Licensing Method and apparatus for bandwidth provisioning in a wlan
TWI250741B (en) * 2003-02-26 2006-03-01 Realtek Semiconductor Corp Method for automatically and dynamically adjusting packet transmission speed of wireless communication network system
JP4215055B2 (ja) 2003-11-19 2009-01-28 日本電気株式会社 無線通信システム及び受信確認信号送信制御方法並びにそれに用いる無線局
US9210719B2 (en) 2003-11-19 2015-12-08 Koninklijke Philips N.V. Method for access to a medium by a multi-channel device
US20050165946A1 (en) * 2003-12-22 2005-07-28 Intel Corporation Bi-directional wireless LAN channel access
US7542453B2 (en) * 2004-01-08 2009-06-02 Sony Corporation Wireless communication system, wireless communication apparatus, wireless communication method, and computer program
JP4128961B2 (ja) * 2004-01-26 2008-07-30 株式会社東芝 無線通信装置、無線通信方法及び無線通信プログラム
JP4220435B2 (ja) * 2004-05-28 2009-02-04 株式会社東芝 無線通信システムおよび無線端末
JP4331088B2 (ja) * 2004-11-01 2009-09-16 株式会社東芝 通信装置および通信方法
US7768988B2 (en) * 2005-02-22 2010-08-03 Intel Corporation Method and apparatus to perform network medium reservation in a wireless network
JP4322836B2 (ja) * 2005-03-31 2009-09-02 株式会社東芝 無線通信システム
JP4575265B2 (ja) 2005-09-29 2010-11-04 株式会社東芝 無線通信装置
JP2009519690A (ja) * 2005-12-13 2009-05-14 コネクサント システムズ インク デュアルｃｔｓ保護システムおよび方法
US7869390B2 (en) * 2006-01-03 2011-01-11 Samsung Electronics Co., Ltd. Method and system for power save multi-poll (PSMP) communication in wireless systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1599341A (zh) * 2003-09-18 2005-03-23 西安电子科技大学 无线局域网多速率传输方法
WO2005039127A1 (en) * 2003-10-15 2005-04-28 Qualcomm Incorporated High speed media access control
WO2005041467A2 (en) * 2003-10-24 2005-05-06 Sony Corporation Wireless communication system, wireless communication device and wireless communication method, and computer program

Also Published As

Publication number Publication date
US7852791B2 (en) 2010-12-14
US8503339B2 (en) 2013-08-06
CN101189831A (zh) 2008-05-28
EP2587878B1 (en) 2020-04-22
EP1900154A1 (en) 2008-03-19
EP2587878A3 (en) 2016-11-30
CN101189831B (zh) 2012-07-25
CN102801507A (zh) 2012-11-28
WO2006134704B1 (en) 2007-02-15
EP1900154B1 (en) 2018-04-25
JP4364165B2 (ja) 2009-11-11
EP2587878A2 (en) 2013-05-01
WO2006134704A1 (en) 2006-12-21
JP2006352711A (ja) 2006-12-28
US20080002615A1 (en) 2008-01-03
US20110064065A1 (en) 2011-03-17

Similar Documents

Publication Publication Date Title
CN102801507B (zh) 无线通信设备
CN102497255B (zh) 无线终端
CN1787468B (zh) 无线局域网基站装置的服务质量控制方法
CN101610260B (zh) 用于无线局域网的通信方法
CN104247508B (zh) 通过机会式时间挪用在单个物理收发机上复用多个并发操作模式的方法及系统
US20190357257A1 (en) Wireless communication apparatus and method
CN1764157B (zh) 通信设备和方法
JP6495984B2 (ja) 無線通信装置および無線通信方法
CN100477617C (zh) 无线通信方法
CN1744602B (zh) 无线通信系统及无线终端
CN102843785B (zh) 无线局域网中逆向协议传输的方法及装置
US20070153830A1 (en) Methods and apparatus to provide fairness for wireless local area networks that use extended physical layer protection mechanisms
CN107925520A (zh) 用于协作接收中的响应帧的技术
EP1938495A1 (en) Wireless communication apparatus
JP4364210B2 (ja) 無線通信装置
US20070019607A1 (en) Radio communication system, radio communication apparatus and computer program
CN101835272A (zh) 在无线通信系统中以反方向授予进行调度
CN101300785A (zh) 确保无线局域网中的站之间对媒体的访问的公平性的方法和装置
WO2014139314A1 (zh) 无线局域网中的数据传输方法和系统
RU2378780C2 (ru) Способ для улучшения пропускной способности и эффективности потребления мощности в системах беспроводной связи
CN107925514A (zh) 使用触发信息的无线通信方法、和无线通信终端
WO2015133646A1 (ja) 通信制御装置、無線端末、メモリーカード、集積回路および無線通信方法
CN107660349A (zh) 高效随机调度信道接入
KR20180107649A (ko) 이중 연결 네트워크에서의 상향링크 전송지연 감소를 위한 방법 및 그 방법이 적용된 단말

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C14 Grant of patent or utility model
GR01 Patent grant