JP2006129393A - 通信装置および通信方法 - Google Patents

通信装置および通信方法 Download PDF

Info

Publication number
JP2006129393A
JP2006129393A JP2004318487A JP2004318487A JP2006129393A JP 2006129393 A JP2006129393 A JP 2006129393A JP 2004318487 A JP2004318487 A JP 2004318487A JP 2004318487 A JP2004318487 A JP 2004318487A JP 2006129393 A JP2006129393 A JP 2006129393A
Authority
JP
Japan
Prior art keywords
frame
block ack
physical
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.)
Granted
Application number
JP2004318487A
Other languages
English (en)
Other versions
JP4331088B2 (ja
Inventor
Taijiyo Nishibayashi
泰如 西林
Masahiro Takagi
雅裕 高木
Tomoko Adachi
朋子 足立
Tomoya Tandai
智哉 旦代
Toru Nakajima
徹 中島
Yoriko Utsunomiya
依子 宇都宮
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
Priority to JP2004318487A priority Critical patent/JP4331088B2/ja
Priority to US11/201,258 priority patent/US20060092871A1/en
Priority to CN2009101345817A priority patent/CN101610260B/zh
Priority to CNA2005101186704A priority patent/CN1770774A/zh
Publication of JP2006129393A publication Critical patent/JP2006129393A/ja
Application granted granted Critical
Publication of JP4331088B2 publication Critical patent/JP4331088B2/ja
Priority to US12/646,580 priority patent/US8274992B2/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/18—Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • 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
    • 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/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • 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/1867—Arrangements specially adapted for the transmitter end
    • H04L1/188—Time-out mechanisms
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0866—Non-scheduled access, e.g. ALOHA using a dedicated channel for access

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Abstract

【課題】フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバーヘッドを解消して通信の実質的なスループットを向上できる通信装置および通信方法を提供すること
【解決手段】 データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築する手段と、前記物理フレームを前記宛先端末に送信する手段とを具備する通信装置である。前記ピギーバック送信は、送達確認フレームと少なくとも一つのＭＡＣフレームとがアグリゲートされた物理フレームを前記宛先端末から送信元に送信することである。
【選択図】図１

Description

本発明は、物理層のキャリアセンス情報とＭＡＣ層のキャリアセンス情報に基づいて媒体アクセス制御を行なう通信装置および通信方法に関する。
同一の媒体を共有して通信を行なう複数の通信装置がどのように媒体を利用して通信データを送信するかを決めるのが、媒体アクセス制御(ＭＡＣ: Media Access Control)である。媒体アクセス制御は、同時に２つ以上の通信装置が同一の媒体を利用して通信データの送信を行なった結果、受信側の通信装置が通信データを分離できなくなる事象（衝突）がなるべく少なくなり、一方、送信要求を持つ通信装置が存在するにもかかわらず媒体がいずれの通信装置によっても利用されない事象がなるべく少なくなるように、通信装置から媒体へのアクセスを制御するための技術である。
しかし、特に無線通信においては、通信装置がデータを送信しながら同時に送信データをモニタすることは困難であることから、衝突検出を前提としない媒体アクセス制御（ＭＡＣ）が必要である。無線ＬＡＮの代表的な技術標準であるIEEE802.11はＣＳＭＡ／ＣＡ(Carrier Sense Multiple Access with Collision Avoidance)を採用している。IEEE802.11のＣＳＭＡ／ＣＡでは、ＭＡＣフレームのヘッダーに、該フレームに続く１つ以上のフレーム交換からなる一連のシーケンスが終了するまでの期間(Duration)が設定される。この期間において、該シーケンスに関係がなく送信権を持たない通信装置は、媒体の仮想的な占有状態を判断することにより、送信を待機する。したがって、衝突の発生が回避される。一方、該シーケンスで送信権を持つ通信装置は、実際に物理媒体が占有されている期間を除き、媒体は使用されていないものと認識する。IEEE802.11では、このようなＭＡＣ層の仮想キャリアセンスと、物理層の物理キャリアセンスとの組み合わせによって媒体の状態を判定し、媒体アクセスを制御する旨が規定されている。
ＣＳＭＡ／ＣＡを採用しているIEEE802.11は、これまで主として物理層プロトコルを変更することによって通信速度の高速化を図ってきた。２．４ＧＨｚ帯についてはIEEE802.11（１９９７年、２Ｍｂｐｓ）からIEEE802.11b（１９９９年、１１Ｍｂｐｓ）へ、そしてIEEE802.11g（２００３年、５４Ｍｂｐｓ）へと変遷している。５ＧＨｚ帯については、今のところIEEE802.11a（１９９９年、５４Ｍｂｐｓ）のみが標準として存在する。そして、２．４ＧＨｚ帯および５ＧＨｚ帯の両方で更なる高速化を目指す標準規格を策定するためにIEEE802.11 TGn(Task Group n)が既に設立されている。
さらに、サービス品質(ＱｏＳ：Quality of Service)向上のためのアクセス制御も幾つか知られている。例えば、指定された帯域幅や遅延時間などのパラメータを保証するＱｏＳとして、従来のポーリング手順を拡張したＨＣＣＡ（HCF Controlled Access；ＨＣＦコントロールド・アクセス）がある。ＨＣＣＡでは、帯域幅や遅延時間などのパラメータを保証できるように、ポーリング手順において所要の品質を考慮したスケジューリングを行う。特許文献２は、IEEE802.11e規格のＱｏＳについて言及しており、無線ネットワークにおける通信装置間の通信に優先順位を付与する方法を開示する。
米国特許第５３２９５３１号明細書 特開２００２−３１４５４６公報
通信速度の高速化の実現において既存の規格と同一の周波数帯を用いるのであれば、新たに提供される通信装置は、既存の規格に従う通信装置との共存が可能であって、後方互換性も維持されることが好ましい。したがって、ＭＡＣ層のプロトコルは基本的には既存の規格と整合するＣＳＭＡ／ＣＡに従うのが良いと考えられる。この場合、ＣＳＭＡ／ＣＡに係わる時間的なパラメータ、例えばフレーム間の時間間隔(IFS: Interframe Space)やバックオフ期間を既存の規格と揃える必要がある。
ここで、物理層に関して通信速度の高速化を図れたとしても、通信の実質的なスループットを向上できないという問題点がある。すなわち、物理層の高速化が実現された場合、ＰＨＹフレームのフォーマットはもはや効率的ではなくなり、このことに起因するオーバーヘッドがスループットの向上を阻害すると考えられる。ＰＨＹフレームにおいて、ＣＳＭＡ／ＣＡに係わる時間的なパラメータはＭＡＣフレームに固定的に付随している。また、ＰＨＹフレームヘッダーは各ＭＡＣフレーム毎にそれぞれ必要である。
オーバーヘッドを削減してスループットを向上させる方法の一つとして、最近のdraft IEEE802.11e draft 5.0 (IEEE802.11のQoS強化) で導入されたBlock ACKがある。これを用いれば、バックオフ無しで複数のMACフレームを連続的に送信できるため、バックオフの量は削減できるが、物理層のヘッダーは削減されない。また、初期のdraft IEEE802.11eで導入されたアグリゲーションによれば、バックオフ量と物理層ヘッダーのいずれも削減可能だが、従来の物理層の制約によりMACフレームが含まれる物理層のフレームの長さを約4k byte以上にはできないため、効率の向上には大きな制約がある。仮に物理層のフレームを長くできたとしても、エラー耐性が低下するという問題が生じる。
本発明はかかる問題を解決すべくなされたものであり、既存の装置との共存が可能であって、しかもフレームフォーマットの効率化により複数のフレームを送信することに伴うオーバーヘッドを解消して通信の実質的なスループットを向上できる通信装置および通信方法を提供することを目的とする。
本発明の一観点に係る通信装置は、データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築する手段と、前記物理フレームを前記宛先端末に送信する手段とを具備する通信装置である。前記ピギーバック送信は、送達確認フレームと少なくとも一つのＭＡＣフレームとがアグリゲートされた物理フレームを前記宛先端末から送信元に送信することである。
本発明によれば、フレームフォーマットの効率化により複数のフレームを送信することに伴うオーバーヘッドを解消して通信の実質的なスループットを向上できる通信装置および通信方法を提供できる。
図１は本発明の第一の実施形態に係る通信装置の構成を示すブロック図である。この通信装置１は無線リンクを介して他の通信装置と通信する装置であり、物理層、ＭＡＣ層、およびリンク層のそれぞれに相当する処理ユニット２、３、４を有する。これら処理ユニットは実装に応じてアナログ又はデジタルの電子回路として、あるいはＬＳＩに組み込まれたＣＰＵにより実行されるファームウェア等として実現される。物理層の処理ユニット（以下、「処理ユニット」の表記を省略）２にはアンテナ５が接続されている。ＭＡＣ層３はＭＡＣフレームのアグリゲーション（集約）処理部６を有する。このアグリゲーション処理部６は、キャリアセンス制御部７と、再送制御部８とを備え、後に詳しく説明するブロックACK（複数のＭＡＣフレームに対する送達確認）フレームの送受信及びブロックACKフレームに基づく再送制御等を行う。
物理層２は、二種類の物理層プロトコルに対応可能に構成される。それぞれのプロトコル処理のために、物理層２は第一種の物理層プロトコル処理部９および第二種の物理層プロトコル処理部１０を有する。なお、実装では第一種の物理層プロトコル処理部９と第二種の物理層プロトコル処理部１０との間で回路の共用などがしばしば行なわれるため、これらは必ずしも独立して存在するわけではない。
本発明の実施形態では、第一種の物理層プロトコルはIEEE802.11aに規定されるプロトコルとし、第二種の物理層プロトコルは送信側と受信側とでそれぞれ複数のアンテナを用いる、いわゆるＭＩＭＯ(Multiple Input Multiple Output)によるプロトコルと仮定する。周波数帯域を同一に保ってもアンテナの数にほぼ比例した伝送容量の増加が見込めることから、ＭＩＭＯはIEEE802.11の更なる高スループット化を目指すために利用可能な技術の一つである。リンク層４に関しては、IEEE802で規定される通常のリンク層機能を有するものとする。伝送レートを向上するために採用する技術はMIMOに限定されない。例えば、周波数占有帯域を増やすような方法、およびそれとMIMOの組み合わせでも構わない。
IEEE802.11e Draft 8.0によれば、MAC(媒体アクセス制御；Media Access Control)層の伝送効率を改善するための技術として、ブロックACK(Block ACK)が提案されている。ブロックACKでは、端末が、あるチャネル使用期間(TXOP: Transmission Opportunity)の間、QoS(Quality of Service)データをSIFS(Short Inter Frame Space)とよばれる最小フレーム間隔で送信し、その後、受信端末に対し、過去の受信履歴状況を要求するためにブロックACK要求(Block ACK Request)を任意のタイミングで送信する。受信側では、ブロックACK要求の定める始点シーケンス番号を元に、過去の受信ステータス状況をビットマップ形式に変換し、ブロックACK(Block ACK)として応答する。
本発明の実施形態の詳細を説明する前に、ブロックACK及びブロックACKの受信側端末におけるバッファ管理の既存技術について説明する。IEEE802.11e Draft 10.0によれば、MAC(Media Access Control)層の伝送効率を改善するための技術として、ブロックACK(Block ACK)が知られている。ブロックACKでは、端末があるチャネル使用期間(TXOP: Transmission Opportunity)の間、QoS(Quality of Service)データをSIFS(Short Inter Frame Space)とよばれる最小フレーム間隔で送信し、その後、受信端末に対し、過去の受信履歴状況を要求するためにブロックACK要求(Block ACK Request)を任意のタイミングで送信する。受信側では、ブロックACK要求の定める始点シーケンス番号に従い、過去の受信ステータス状況をビットマップ形式に変換し、ブロックACK(Block ACK)として応答する。
図２及び図３は、IEEE802.11e Draft 10.0で規定されているブロックACK要求フレーム及びブロックACKフレームのフォーマットをそれぞれ示したものである。図２及び図３に示されるフレームはそれぞれMACフレームであり、IEEE802.11で規定されているMACヘッダーを有する。該MACヘッダーは、Frame Control(フレーム制御)フィールド、Duration(期間)フィールド、Receiver Address(宛先アドレス)、Transmitter Address(送信元アドレス)から構成されている。
BAR Control(Block ACK Request Control)２０は、4ビットのTID(Traffic Identifier: 優先度識別子)フィールドを有する。QoSデータは優先度(TID)毎に存在し、それぞれに独自のシーケンス番号、及びフラグメント番号が割り当てられることから、図３のブロックACKにおける受信ステータスについても、これを優先度毎に用意する必要がある。ブロックACK要求のBAR Control２０のTIDフィールドは、このような優先度を指定するために用いられる。
図２のブロックACK要求のBlock ACK Starting Sequence Control２１は、4ビットのフラグメント番号フィールド、及び12ビットのStarting Sequence Number(始点シーケンス番号)フィールドから構成される。Starting Sequence Numberは、受信端末が過去の受信履歴を遡り、Starting Sequence Numberに対応するシーケンス番号からの相対的な受信ステータスに基づいてブロックACKを作成するために用いられる。
図３のブロックACKのBA Control３０は、図２のBAR Control２０と同様に、4ビットのTIDフィールドを含む。Block ACK Starting Sequence Control（ブロックACK始点シーケンス番号）３１は、該ブロックACK中のBlock ACK Bitmap３２の示す受信ステータスの始点シーケンス番号を示す。IEEE802.11e Draft 10.0によれば、Block ACK Bitmapのサイズは1024ビットの固定長であり、これにより最大64MSDU(MAC Size Data Unit)のデータに対する受信履歴を通知することが可能である。1MSDUは、最大で16個のフラグメント(分割)化されたMPDU(MAC Protocol Data Unit)を含む。尚、図２及び図３のそれぞれのMACフレームには、誤り検査のためのFCS(Frame Check Sequence)が付加される。
図４及び図５はHCCA(Hybrid coordination function Controlled Channel Access)におけるブロックACKのシーケンス例を示している。図に示されるHC(Hybrid Coordinator)は、IEEE802.11eにおけるQoSアクセスポイント(QoS-AP)であり、スケジューリングの主体となって、QoS端末(QSTA: QoS Station)へのチャネル使用期間(TXOP)の付与、ダウンリンク(HCからQSTAへの下り方向)伝送を行う。QSTAへのTXOPの付与は、HCからのQoS CF-Pollフレーム(QoS Contention Free-Poll: HCがQSTAに送信を許可するために送信するQoS対応ポーリングフレーム)に基づいて行われる。
図４において、まずHCがQSTA1に対し、QoS CF-Pollフレーム４０を送信することでチャネル使用期間(TXOP1)を与える。QSTAはTXOPの間、任意のフレームを送信することが可能である。図４の例では、QSTA2にQoSデータフレーム４１をSIFS間隔でバースト的に送信し、その最後にブロックACK要求フレーム４２を送信した後、QSTA2からのブロックACKフレーム４３を受信している。QSTA1のTXOP期間が終了すると、次にHCがTXOP期間2を獲得し、TXOP期間2において、QSTA1に対しQoSデータ４４をやはりバースト的に送信している。TXOP期間2の最後には、QSTA1のTXOP期間1と同様に、ブロックACK要求４５をHCが送信し、HC はQSTA1からのブロックACK４６を受信している。ブロックACK要求４２，４５は、Block ACK Starting Sequence Controlで指定される相対的な受信ステータスを宛先に要求する。図４は、即時型ブロックACK(Immediate Block ACK)の例であり、この場合、ブロックACK要求４２，４５を受信した端末はSIFS期間後に必ずブロックACK４３，４６を応答しなくてはならない。
一方、図５は、遅延型ブロックACK(Delayed Block ACK)の例を示している。ブロックACK要求５０を受信した端末は、まずIEEE802.11のACK(IEEE802.11e Draft 10.0ではノーマルACKと呼ばれている)５１を返し、任意の期間後にブロックACK５２を送信する。ブロックACK５２を最後に受け取ったデータ送信端末は、ノーマルACK５３を返信することで遅延型ブロックACKの一連のシーケンスが完了する。尚、ブロックACK対象のQoSデータは、従来のMACヘッダーに対しIEEE802.11e用に拡張されたQoS Control field中の、Ack Policyフィールドを用いて受信側に通知される。Ack Policyフィールドでは、IEEE802.11の通常のACKであるノーマルACK(Normal ACK)、IEEE802.11eのブロックACK(Block ACK)、更にACKを必要としないノーマルACK(No ACK)方式などを指定することが可能である。
本発明の実施形態は、単一のPPDU(PHY Protocol Data Unit)について、PSDU(PHY Service Data Unit)内に複数のMPDU(MAC Protocol Data Unitをアグリゲートして送信する通信装置に関する。なお、PPDUはPHYフレーム及びPSDUを内部に含んだ物理フレームに相当する。また、MPDUはMACヘッダー及びMSDU(MAC Service Data Unit)を内部に含んだMACフレームに相当する。
無線LANでハイスループットを達成するには、フレーム間隔やバックオフ期間といったMAC層のオーバーヘッド、及び物理層のオーバーヘッドを削減する必要がある。図６及び図７に示すように、複数のMPDUを1つのPSDU(Physical layer convergence protocol Size Data Unit)にアグリゲートして送信することで、これらのオーバーヘッドを削減することが可能である。図６の例では、複数のMPDUをアグリゲートしたPSDU６０の先頭部分に、MACヘッダーからFCSまでを含むMPDUの長さをオクテット単位で示すヘッダー情報６１が存在する。以後、このヘッダー情報６１を「MACスーパーフレームヘッダー」と呼ぶ。MACスーパーフレームヘッダー６１には、該ヘッダー６１自体の誤りを検出するためのCRC(Cyclic Redundancy Check)６２を付加する。MPDUが存在しない部分のMPDU長フィールドには0を記載する。また、MACスーパーフレームヘッダー６１が誤っていれば、全てのMPDUの受信に失敗したとみなす。
図７は、PSDU７０内にアグリゲートされた各MPDUの前方に、後続するMPDUの長さを示す情報が存在する。更に、MPDU長情報の誤りを検出するためのCRCが付加され、これらMPDU長情報及びCRCを併せて、「MPDUセパレーション」と呼ぶ。図７の構成の物理フレームを受信した端末は、まず先頭のMPDUセパレーション７１のCRCを検査する。先頭のMPDUセパレーション７１を正常に受信していれば、後続するMPDUを切り出してFCSの計算を行なう。FCSの結果が正常であれば、該MPDUを正常に受信したと判断する。FCSの結果が異常であれば、該MPDUの受信に失敗したとみなし、MPDUセパレーション７１のMPDU長が示す分だけスキップし、次のMPDUセパレーション７２のCRCを検査する。このように、MPDUセパレーションが誤っていた場合、連続的にオクテット単位でスキップしてCRC検査を行い、その結果が正常であれば、そのMPDUセパレーションに後続するMPDUに対するFCSを計算し、正常に受信できたかどうかの判断をする。
本発明の実施形態において、複数のMPDUがアグリゲートされた物理フレームに対する部分応答には、IEEE802.11eのブロックACKフレームを拡張したものを利用することとする。図８に、拡張したブロックACKのフレーム構成を示す。IEEE802.11e Draft 10.0によれば、ブロックACKフレームは、フラグメント化を考慮して、1024ビットの固定長のビットマップを持つ。フラグメントは一般にオーバーヘッドが大きいことから、ハイスループットを達成するには、MSDUをフラグメント化しないことが望ましい。図８の拡張したブロックACKフレームは、フラグメント化を行なわない前提で、64MSDUに対応するBlock ACK Bitmap８０を用意する。Block ACK Bitmap８０は、従来のブロックACKフレームに比べ、16分の1のサイズに圧縮することが可能である。以後、圧縮されたBlock ACK Bitmap８０を有するブロックACKのことを、「圧縮ブロックACK」と呼ぶことにする。尚、圧縮ブロックACKのBlock ACK Bitmap８０は、1つの物理フレームにアグリゲートされたMPDUの数に応じて可変長としても良い。
図９に、複数MPDUをアグリゲートして送信する例を示す。本発明の実施形態において、複数のMPDUがアグリゲートされた物理フレームを受信した端末（STA及びHC）は、該物理フレーム内にブロックACK要求が含まれていなくても、最小フレーム間隔であるSIFS後に圧縮ブロックACKを送信元に返信する。例えば、まずHCは、QoS CF-Pollフレーム９０をQSTA1に送信することにより、QSTA1に対してTXOP期間1を与える。TXOP期間1において、QSTA1は、シーケンス番号「1」〜「3」のMPDUがアグリゲートされた物理フレーム９１をQSTA2に対して送信し、QSTA2は物理フレーム９３内のMPDUの受信状況をSIFS後に圧縮ブロックACK９２としてQSTA1応答している。続くTXOP期間2においては、HCが物理フレーム９３をQSTA1に対して送信し、QSTA1は物理フレーム９３内のMPDUの受信状況を圧縮ブロックACK９４としてSIFS後にHCに応答している。また、TXOP期間3においては、HCはQoS CF-Pollフレーム９７をQSTA2に送信し、QSTA2に対してTXOP期間3を与えている。QSTA2は、物理フレーム９５をHCに対して送信し、HCは物理フレーム９５内のMPDUの受信状況をSIFS後に圧縮ブロックACK９６としてQSTA2に対し応答している。ここで、本発明の実施形態においては、ブロックACK要求を物理フレーム内に含まなくとも圧縮ブロックACKの返信を可能としているが、従来のIEEE802.11e Draft 10.0のように、ブロックACK要求フレームを物理フレームの最後にアグリゲートして送信し、受信側ではブロックACK要求フレームの示す情報に従って、圧縮ブロックACKを返信することとしてもよい。
複数MPDUをアグリゲートして送信し、以上のような圧縮ブロックACKによるセレクティブ・リピート型の再送制御を行なうことで、MAC効率を高めることができる。
（第一の実施形態）
そして本発明の第一の実施形態は、複数のMPDUをアグリゲートした後、宛先からの部分応答フレームに逆方向のMPDUをピギーバックする（便乗させる）ことで、MAC効率を高める。また、IEEE802.11e Draft 10.0で規定されている、即時型ブロックACK、及び遅延型ブロックACKに対する適用方法を併せて説明する。
具体的には、第一実施形態の通信装置は、即時型ブロックACK伝送において、ブロックACKフレームに少なくとも一つのデータフレームをピギーバックする。このため、データ送信開始側で、宛先に対し複数データをピギーバックすることを許可する送信許可フレームをデータフレーム、ブロックACK要求フレーム、又はブロックACKフレームのいずれかにアグリゲートして送信する。このような第一実施形態の通信装置は、送信側端末として動作する際に、宛先から返信された物理フレームの内部を検索し、ブロックACKフレームが含まれていなければ、タイムアウトが発生したとみなす。一方、受信側では、ブロックACKに関するタイムアウトが発生した場合、次のピギーバック可能期間に、前回送信した全てのデータフレームを再送対象として送信する方法と、代わりにブロックACK要求をピギーバックする方法とのどちらかを選択する。
宛先からの部分応答フレームに逆方向(宛先から送信元へ)の複数MPDUをピギーバックすることで、MAC効率を高めることが可能であるが、本来、IEEE802.11e Draft 10.0の規定によると、TXOPを獲得したデータ送信端末に対し、宛先端末はデータフレームに対する応答フレームを返信するなどしかできない。そこで、宛先端末に対し、ピギーバック送信を可能にするために、送信許可を与えるフレームを図１０のような構成の場合で考える。
データ送信元を始点端末と考えることで、この図１０のフレーム１００を「IAC(Initiator Aggregation Control)フレーム」と呼ぶことにする。図１０に示すように、IACフレーム１００は、Frame Control(フレーム制御)フィールド、Duration(期間)フィールド、Receiver Address(宛先アドレス)、およびTransmitter Address(送信元アドレス)からなるIEEE802.11で規定されているものと同一のMACヘッダーを有する。
MACヘッダーに続くIAC Maskフィールド１０１は、当該IACフレーム１００の用途(RTS、MIMOフィードバック、ピギーバック送信許可)をビットマップ形式で指定する。Next PPDU (PLCP Protocol Data Unit) Sizeフィールド１０２は、送信元が該TXOP期間内で次に送信する物理フレームの長さをオクテット単位で示す。Next PPDU Default MCSフィールド１０３は、Next PPDU Size１０２で指定された物理フレームを送信する際の物理伝送レートを表す。Reverse Direction Limitフィールド１０４、Reverse Direction Grantフィールド１０５、及びResponse Period Offsetフィールド１０６は、宛先に対してピギーバックに必要な送信許可時間を付与する目的で設けられる。宛先に対してピギーバックのための送信時間を付与する場合は、送信元端末が現在保持しているTXOP期間の中から任意の時間を切り取る。送信元が与えられたTXOP期間自体を延長することは許されない。RDTID(Reverse Direction Traffic Identifier)フィールド１０７は、ピギーバック対象のTIDを指定する。MCS Feedbackフィールド１０８は、伝播路環境に応じた伝送レート設定(リンクアダプテーション)のために使用する。IACフレーム１００の末尾には、IEEE802.11の規定に従って4オクテットのFCSが付加される。
図１１は、IACフレームを用いる場合の、複数MPDUのアグリゲーションと宛先に対するピギーバックの許可の様子を示す図である。この図１１に示す例は、HCCAの場合のフレームシーケンスであるが、本発明はコンテンションベースのQoSアクセス制御方式であるEDCA(Enhanced Distributed Channel Access)にも適用可能である。図１１において、TXOP期間1を得たHCは、QSTA1に対するIACフレーム１１０とシーケンス番号「1」〜「4」の複数データフレーム１１１とがアグリゲートされた物理フレーム１１２を送信する。QSTA1は、物理フレーム１１２を受信すると、SIFS期間後に圧縮ブロックACK１１３を返信することになるが、IACフレーム１１０によりピギーバック送信が許可されているため、QSTA1は、自身のHCに対するアップリンク方向のデータ１１４がアグリゲートされた物理フレーム１１５を送信する。QSTA1がHCへの圧縮ブロックACKにピギーバック可能なMPDUの数は、HCより付与されたReverse Direction LimitあるいはReverse Direction Grantの時間の範囲内で決定する。Reverse Direction LimitあるいはReverse Direction Grantは、HCのTXOP期間1の範囲内で調整する。QSTA1が圧縮ブロックACK１１３とアップリンク方向のシーケンス番号「1」〜「4」のデータ１１４とがアグリゲートゲートされた物理フレーム１１５を送信すると、SIFS後にHCはQSTA1のデータ１１４に対する圧縮ブロックACK１１６を返信してTXOP期間1を終了する。TXOP期間2では、HCからQSTA2に対し、IACフレーム１１７とシーケンス番号「1001」〜「1004」のデータフレーム１１８とがアグリゲートされた物理フレーム１１９を送信している。QSTA2では、HCへのアップリンク方向のデータ、すなわちピギーバックするためのデータが存在しなければ、Reverse Direction Grant(あるいはReverse Direction Limit)が与えられていれも、HCのデータに対する圧縮ブロックACKのみを返信する。尚、図１１において、2つのTXOP期間の間はPIFS(PCF Inter Frame Space)だけ隔てられている。
このような第一の実施形態によれば、IACフレームにより宛先端末に対し意図的にピギーバック送信を許可できる。そして、ピギーバック送信の許可を得た宛先端末がデータフレーム等をピギーバック送信することにより、ＭＡＣ効率を向上できる。
以下、図１２〜図２３を参照し、物理フレームに誤りが生じた場合のシーケンス例を幾つか説明する。
図１２及び図１３は、HCがIACフレーム１２１とシーケンス番号「1」〜「4」の複数データフレーム１２２がアグリゲートされた物理フレーム１２３をQSTA1に送信した後、SIFS後にキャリアセンスでビジー１２４を検出したが、FCS計算の結果、全てのMPDUが誤っていた場合のシーケンス例である。
尚、IEEE802.11の規定によると、ある一定の値よりも大きい電力を検知した場合、無線チャネルは使用中(ビジー)であるとみなす。また、IEEE802.11e Draft 10.0の規定によると、HCCAによるチャネルアクセス時において、HCがQoS CF-Pollフレームを送信してからSIFS後にビジーを検知したが、FCS計算の結果、受信フレームが誤っていた場合には、チャネルが未使用(アイドル)状態になってからPIFS後に、TXOP期間を再度獲得できるようQoS CF-Pollフレームを再送する。一方、HCがデータフレームの送信後にビジーを検出し、FCS検査が誤っていた場合に、該HCはSIFS後にデータフレームを再送する。ポールフレーム送信の場合ではTXOP期間を正しく獲得できたか否かが不明であるが、データフレーム送信の場合では、送信元は既にTXOP期間を獲得しているために、SIFS後に任意のフレームの送信が可能である。
図１２及び図１３の場合では、QSTA1からHC方向への圧縮ブロックACK（およびピギーバックされたデータ）が存在し、HCにおいてそれら全てのMPDUがFCS計算で誤ったならば、該HCにおいて圧縮ブロックACKを受信するまでの時間をカウントするタイマーがタイムアウトすることになる。HCは、このタイムアウトにより圧縮ブロックACKを受信できなかったことを検知し、無線チャネルがアイドルになってからSIFS後に（明示的な）ブロックACK要求を送信する。HCがこのブロックACK要求を送信できるのは、該HCはピギーバックの開始側であって、TXOPを獲得しているものと解釈できるからである。該ブロックACK要求のBlock ACK Starting Sequence Controlには、送信した先頭MPDUのシーケンス番号「1」が指定される。図１２の例では、HCがブロックACK要求１２５を送信する際に、IACフレームは同一物理フレームにアグリゲートされていない。このためQSTA1は前回受信したHCからのデータに対する送達確認を圧縮ブロックACK１２６によって返信するのみにとどまる。なぜなら、IACフレームが存在しないために、QSTA1からのピギーバック送信は許可されていないからである。
第一の実施形態に係る通信装置は、送信端末として動作する際に、宛先端末に対し、部分応答フレームに複数MPDUをアグリゲートして返信することを許可するためのフレーム、すなわちIACフレームを送信するか否かを、該送信端末に与えられたチャネル使用期間（すなわちTXOP）の残期間に応じて決定する。
図１２に示すように、HCがQSTA1からの圧縮ブロックACK１２６を受信した後、HCのTXOP期間1が終了し、PIFS時間後に次のTXOP期間2が開始する。TXOP期間2において、HCはQSTA2に対し、IACフレーム１２７とシーケンス番号「1001」〜「1004」のデータフレーム１２８とがアグリゲートされた物理フレーム１２９を送信している。
これに対し図１３に示す例は、HCが保持するTXOP期間1に余裕がある場合であり、HCはIACフレーム１３０とブロックACK要求１３１とがアグリゲートされた物理フレーム１３２を送信することによりQSTA1に対してピギーバック送信を許可する。この物理フレーム１３２を受信したQSTA1は、IACフレーム１３０によりピギーバック送信が許可され、HCに対するアップリンク方向のデータフレーム１３４を圧縮ブロックACK(HCが最初に送信したシーケンス番号「1」〜「4」のMPDUに対応)１３３にピギーバックして送信することができる。HCは、QSTA1からのデータフレーム１３４に対する圧縮ブロックACK１３６をSIFS後に送信した後、TXOP期間1を終了している。
したがって、TXOPを獲得している側のスケジューリング状況に応じて、宛先端末に対し、ピギーバックの許可、不許可を選択的に制御することができる。
図１４は、QSTAからHCに対するアップリンク方向の送信時に、アグリゲートされた複数MPDUが部分的に誤った場合の例を示している。まずHCは、IACフレーム１４０とシーケンス番号「1」〜「4」のデータフレーム１４１とを1つの物理フレーム１４２にアグリゲートしてQSTA1に送信する。そのSIFS後に、QSTA1はHCからのデータフレーム１４１に対する圧縮ブロックACK１４３にHCへのアップリンク方向の複数データをピギーバックして送信する。図１４の例では、QSTA1からの圧縮ブロックACKとシーケンス番号「4」のMPDU１４４がFCS計算の結果、誤っていた場合を表している。
第一の実施形態では、複数MPDUをアグリゲートして送信した後、SIFS後にチャネルがビジーを検出しても、ビジーの要因となった物理フレーム内に正常な圧縮ブロックACKが存在しない場合、送信したMPDUはリカバリーの対象とみなす。このため、IEEE802.11e Draft 10.0の規定に従い、ブロックACK要求を送信し、宛先からのブロックACKの再送を促す必要がある。
図１４の例によると、HCがQSTA1に送信したシーケンス番号「1」〜「4」のMPDU１４１に対する圧縮ブロックACKをHCが受信できていない。そこでHCは、TXOP期間1の範囲の中であれば、QSTA1からのアップリンク方向のデータ(シーケンス番号「1」〜「4」)に対する圧縮ブロックACK１４６にブロックACK要求１４７をアグリゲート(ピギーバック)し、これによりブロックACKの再送をQSTA1に対して要求し、更にQSTA1に対して送信を許可するためのIACフレーム１４５を同一物理フレーム１４８にアグリゲートして送信する。そのSIFS後に、QSTA1は、前回送信した圧縮ブロックACKの内容をそのまま（鸚鵡返し的に）送信し、IACフレーム内のReverse Direction Grant(あるいはReverse Direction Limit)情報に基づいてアップリンク方向のデータをピギーバックする。図１４では、シーケンス番号「4」のMPDU１５０がHCからの圧縮ブロックACK１４６によって送信に失敗したことが検出されており、このMPDU１５０を再送用として、HCへの圧縮ブロックACK１４９にピギーバックする。その後、HCはQSTA1から再送されたシーケンス番号「4」のMPDU１５０に対する圧縮ブロックACK１５１を送信し、TXOP期間1を終了する。
ここで、HCが獲得したTXOP期間1が短く、QSTA1からのフレーム送信を促す時間的余裕が無ければ、ブロックACK要求をアグリゲートせず、圧縮ブロックACKのみを送信してTXOP期間を終了することも可能である。
また、宛先端末から返信される物理フレームの特定フレーム位置のエラー検出に基づいて、送達確認フレームの有無を判定してもよい、例えば、圧縮ブロックACKに複数データをピギーバックして応答する場合であって、かつ圧縮ブロックACKを必ず物理フレーム内の先頭部分にアグリゲートするなどの前提を送受信端末間で相互に認識している場合、先頭MPDUに対するFCS計算結果が誤りであれば、他の複数MPDUを検索せずに、部分応答フレームに対するタイムアウトの発生、すなわち圧縮ブロックACKの受信に失敗したとみなすことができる。
図１４の例のように、圧縮ブロックACKの他に、IACフレームがHCからの物理フレームの先頭にアグリゲートされている場合、先頭MPDUだけでなく、2番目のMPDUに対するFCSまで計算して、圧縮ブロックACKを正常に受信できたかどうかの判断を行なう。ここで、IACフレームが必ず物理フレーム内の先頭に、圧縮ブロックACKがそれ以降で一番前に（すなわち同物理フレーム内においてIACフレームの次に）アグリゲートされているとすれば、該物理フレームを受信した端末は、2番目のMPDUに対するFCS計算の結果が誤りであれば、圧縮ブロックACKの受信に失敗したとみなす。すなわち、圧縮ブロックACKをアグリゲートする位置を予め送受信端末間で認識していれば、該部分に対するFCS計算の結果を、圧縮ブロックACKの受信成功、失敗の判断材料とすることができる。
図１５及び図１６は、HCからQSTAに対するダウンリンク方向の物理フレーム内のMPDUに誤りが発生した場合の再送例を示している。HCがIACフレームとシーケンス番号「1」〜「4」の複数MPDUをアグリゲートして送信し、シーケンス番号「1」と「4」のMPDU１５２，１５３が誤っていたとする。物理フレーム受信からSIFS後に、QSTA1はHCのシーケンス番号「1」と「4」のMPDUが誤っていたことを示す圧縮ブロックACK１５４に、QSTA1からHCに対するアップリンク方向のデータ(シーケンス番号「1」〜「4」)１５５をピギーバックして送信する。HCはQSTA1からの物理フレーム受信からSIFS後に、アップリンク方向のデータに対する圧縮ブロックACK１５６を送信してTXOP期間1を終了する。そして、PIFSの間キャリアセンスを行なって無線チャネルがアイドルであれば、次のTXOP期間2を獲得し、IACフレーム１５７と再送の対象となったシーケンス番号「1」と「4」のデータフレーム１５８とをアグリゲートして送信する。QSTA1はSIFS後に、HCが再送したシーケンス番号「1」及び「4」を正常に受信したことを示す圧縮ブロックACK１５９を送信し、TXOP期間2が終了している。HCからQSTA2にデータを送信するための次のTXOP期間3は、PIFSのキャリアセンスを行なった後、獲得されている。ここで、図１６に示すように、HCに与えられたTXOP期間1に余裕があれば、QSTA1からHCへのアップリンク方向の複数データフレーム１５５に対する圧縮ブロックACK１５６と共に、HCからQSTA1へのダウンリンク方向の再送用データフレーム１６０及びIACフレーム１６１をアグリゲートして送信することも可能である。この場合、図１５の例に比べてMAC効率が更に高くなっている。
図１７及び図１８は、ダウンリンク及びアップリンク双方の物理フレーム内のMPDUに誤りが発生した場合の再送例を示している。図１７において、HCはQSTA1に対するダウンリンク方向に、IACフレームとシーケンス番号「1」〜「4」のデータフレームをアグリゲートして送信する。そして、シーケンス番号「1」と「4」が誤っていたとする。QSTA1は、HCからの物理フレームを受信してからSIFS後に、HCからのデータフレームに対する圧縮ブロックACK１７０にHCへのアップリンク方向のシーケンス番号「1」〜「4」のデータフレーム１７１をピギーバックして送信する。図１７はHCへのアップリンクの複数MPDUの中で、シーケンス番号「2」と「3」の部分がFCS計算の結果、誤っていたことを表している。
図１７のTXOP期間1は短く、誤ったMPDUを再送する余裕がないため、HCはQSTA1からのアップリンク方向のデータに対する圧縮ブロックACK１７２を送信してTXOPを終了している。図１７において、PIFS後にHCが再度TXOP期間を獲得(TXOP期間2)すると、IACフレーム１７３と再送対象のシーケンス番号「1」「4」のMPDU１７４をアグリゲートしてQSTA1に送信する。QSTA1は、HCからのダウンリンクのデータに対する送達確認を圧縮ブロックACK１７５として送信し、IAC１７３で付与された送信許可時間の範囲内で、再送用のMPDUをピギーバックする。図１７において、QSTA1は、再送用のシーケンス番号「2」「3」のMPDUに加え、新しいシーケンス番号「5」のMPDUをHCへの圧縮ブロックACK１７５にピギーバックしている。その後、HCがQSTA1からのデータに対する圧縮ブロックACK１７６を送信し、TXOP期間2を終了する。
図１８の例では、HCが保持するTXOP期間1が比較的長く、QSTA1からのアップリンクデータを受信してからSIFS後に、IACフレーム１８０と圧縮ブロックACK１８１、及び再送の必要なシーケンス番号「1」「4」のデータフレーム１８２をアグリゲートして送信している。QSTA1は、「1」「4」に対する圧縮ブロックACK１８３に、再送の必要なシーケンス番号「2」「3」と新しいシーケンス番号「5」のMPDU１８４をピギーバックして送信している。最後に、HCがQSTA1に対して圧縮ブロックACK１８５を返信し、TXOP期間1を終えている。ここで、無線チャネル上の誤り率が高く、ダウンリンク、アップリンク双方の間で再送が度重なると、データ送信の公平性が損なわれる可能性がある。再送の品質を高めるため、連続的に送信可能なMPDU数の上限を総ウィンドウサイズとして定めたり、再送も含めた連続送信回数の上限を定めたり、HCのスケジューラ部の管理によって、IACのReverse Direction Grant(あるいはReverse Direction Limit)の値を調整したりする方法が考えられる。
図１９及び図２０は、QSTAからHCへのアップリンク方向のデータが全て誤った場合の再送例を示している。図１９において、HCはIACフレーム１９０と、シーケンス番号「1」「2」のデータフレーム１９１をアグリゲートして送信する。SIFS後、QSTA1はMPDUを正常に受信したことを通知するための圧縮ブロックACK１９２に、アップリンク方向のシーケンス番号「1」「2」のデータフレーム１９３をピギーバックして送信する。この時、QSTA1からHCへのアップリンク方向のデータがFCS計算の結果全て誤っていた場合(図１９ではシーケンス番号「1」「2」)、HCはQSTA1のデータの存在を知らないため、圧縮ブロックACKを作成せず、TXOP期間1が終了する。IEEE802.11e Draft 10.0の規定に従うならば、QSTA1は、HCに向けてデータフレームを送信した後、応答フレームを受信するためのタイマーをセットする。物理フレーム送信後、SIFS+1スロット時間内にビジーを検出すれば、タイマーをリセットし、受信したMACフレームに対するFCS計算を行なう。このスロット時間は、物理的な処理誤差を許容するために用いられ、物理伝送規格によって値も異なる。逆に、物理フレーム送信からSIFS+1スロット時間経過してもビジーを検出しなければ、送信したデータフレームをリカバリーの対象とみなす。無論、ビジーを検出してもMACフレームに対するFCS計算の結果が異常であれば、送信したデータフレームをリカバリーの対象とみなす。図１９において、TXOP期間1を保有しているHCは、QSTA1からの圧縮ブロックACK１９２を受信し、PIFS経過してから次のTXOP期間2を獲得する。TXOP期間2では、HCはIACフレーム１９４とシーケンス番号「1001」「1002」のデータフレーム１９５をアグリゲートして送信する。TXOP期間2が開始した時点で、QSTA1はアップリンクに送信したシーケンス番号「1」「2」のMPDUをリカバリー対象とみなす。図１９のTXOP期間2で、QSTA2からHCへのアップリンク方向のシーケンス番号「1」「2」のデータフレーム１９６の送信後に、SIFS+1スロット時間経過してもビジーの要因となる応答フレームの送信が行なわれていないため、これらのデータフレーム１９６をリカバリーの対象とする。HCがTXOP期間2を終了し、PIFS後に次のTXOP期間3を獲得する。TXOP期間3において、HCはQSTA1に対して、IACフレーム１９７と新しいシーケンス番号「3」「4」のデータフレーム１９８をアグリゲートして送信する。IACフレーム１９７により、QSTA1はシーケンス番号「3」「4」に対する圧縮ブロックACK１９９に、ブロックACK要求２００をピギーバック可能となっている。IEEE802.11e Draft 10.0の規定によれば、即時型ブロックACK伝送を行う際、Ack PolicyがBlock ACKのQoSデータをSIFS間隔で送信した後、ブロックACK要求フレームを送信し、一定時間経過しても宛先からのブロックACKフレームを受信できなければ、ブロックACK要求フレームを再送する。図１９の例では、QSTA1がHCへのアップリンク方向に送信したデータに対する圧縮ブロックACKを受信していないため、ブロックACK要求フレーム２００をピギーバックして、HCからの圧縮ブロックACKフレームの送信を促す。SIFS後、HCはQSTA1に対するIACフレーム２０１と、ブロックACK要求２００に対する圧縮ブロックACK２０２をアグリゲートして送信する。この圧縮ブロックACK２０２のBlock ACK Bitmapは、QSTA1からのデータでブロックACK要求フレーム２００のBlock ACK Starting Sequence Control以降のMPDUを1つも正常に受信していないため、ビットマップは全て0の状態となっている。HCがIACフレームと圧縮ブロックACKを併せて送信することで、QSTA1は、送信に失敗した2つのMPDUの存在を確認すると共に、それらをHCに向けて再送する。
図２０に示すように、QSTA1がHCに送信したデータフレームにリカバリーの必要が生じた際、次の送信可能期間で、ブロックACK要求を送信する代わりに、直接データフレームのみを再送することも可能である。IEEE802.11e Draft 10.0の規定によれば、QoSデータには遅延許容時間が存在するため、図１９に示すようにブロックACK要求を送信し、宛先からの圧縮ブロックACKを受信してからデータフレームを再送している余裕がないことがスケジューリング的に分かっている場合、図２０に示すようにデータフレーム２０３を直接再送する。このような実施形態によれば、リカバリーが生じた際、ブロックACK要求を送信するか、全てのデータフレームを直接再送するかを選択的に用いることで、QoS要求を満たすだけでなく、MAC効率を高めることが可能である。
また、図１９に示すように、HCからQSTAにピギーバック許可が与えられた場合にリカバリー処理を行う方法だけでなく、EDCA期間におけるTXOP獲得時の最初、あるいはHCからのQoS CF-PollによるTXOP獲得時の最初に、リカバリー処理を行う方法を用いても実現可能である。尚、本発明の第一の実施形態では、TXOPを保有する主体がHCとなっているが、もちろん、QSTA1が完全にTXOPを獲得して、該期間内に任意のMACフレームを自由に送信する場合にも、ピギーバック手法の適用が可能であることは言うまでもない。
また、図１９のTXOP期間3では、HCがQSTA1に対し、圧縮ブロックACK２０２にIACフレーム２０１をアグリゲートしている。HCがTXOPを保有している場合、ピギーバックを行うためのスケジューリングの主体もHCにある。従って、遅延許容時間の観点から、QSTA1に直ちにデータフレームの再送を行わせたい場合、図１９の例のようにIACフレーム２０１を圧縮ブロックACK２０２にアグリゲートする。図１９の例では、QSTA1に対する圧縮ブロックACKフレーム２０２のBlock ACK Bitmapが全て0であるため、HC側ではQSTA1が再送処理を行う必要があることを認識する。ここで、QSTAに対する圧縮ブロックACKフレームのBlock ACK Bitmapにおいて、受信成功と受信失敗を示すビットが交互に並んでいる場合や、ブロックACK要求Block ACK Starting Sequence Controlと圧縮ブロックACKのBlock ACK Starting Sequence Controlの値が異なる場合(データ送信側では圧縮ブロックACKのBlock ACK Starting Sequence Controlよりも前のシーケンス番号のMPDUは全て送信に失敗したとみなす)も、HCはQSTA1が再送の必要があると認識する。その場合、HCのスケジューラ部の判断に応じて、QSTAにピギーバックを許可するためのIACフレームを送信する。あるいは、IACフレームで指定されたReverse Direction Grant(あるいはReverse Direction Limit)は、必ずしもQSTA側で全て消化する必要はないため、予めIACフレームを送信して、ピギーバックにおける再送用のマージンを与えることも可能である。
図２１及び図２２は、HCからのダウンリンクにアグリゲートして送信した全てのMPDUが誤っていた場合の再送例を示している。図２１では、HCがIACフレーム２１０とシーケンス番号「1」〜「4」のデータフレーム２１１をアグリゲートしてQSTA1に送信している。そして、無線チャネル上の衝突や、高いビット誤り率などを要因として、IACフレームを含む全てのMPDUが誤ったとする。その場合、QSTA1はHCが送信した物理フレーム内のMPDUを全く理解できず、自分宛のMPDUが含まれているかどうかの判断もできない。そのため、HCがIACフレームを送信しても、QSTA1はアップリンク方向のデータを送信しない。IEEE802.11e Draft 10.0の規定によれば、HCCAによるチャネルアクセスを行なっている際、HCがあるTXOP期間の一番初めのフレーム(データ、あるいはQoS CF-Poll)を送信しても、宛先からの反応がない場合、PIFSのキャリアセンスを行なった後、再度フレームを送信することが定められている。従って、図２１の例では、PIFS後にTXOP期間2を獲得し、QSTAに対してNAVを張らせる目的も含めたブロックACK要求２１２を送信する。更に、図２１の例では、ブロックACK要求２１２にIACフレーム２１３をアグリゲートしている。これにより、QSTA1は、TXOP期間1において受信に失敗したシーケンス番号「1」〜「4」のMPDUに対する圧縮ブロックACKフレーム２１４に、HCへのアップリンク方向の複数データ２１５をピギーバックする。図２１では、HCがQSTA1に対する圧縮ブロックACK２１６を送信してTXOP期間2を終了している。尚、図２１において、QSTA1がTXOP期間2でHCに対して送信する圧縮ブロックACK２１４のBlock ACK Bitmapは、全てのMPDUを受信失敗したことを表すために、全て0で埋められている。あるいは、図２２の例のように、HCからのダウンリンクのデータ送信が全て誤っていた場合、PIFS後にブロックACK要求２２０のみを送信する。このブロックACK要求フレーム２２０には、IACフレームがアグリゲートされていないため、QSTA1は圧縮ブロックACK２２１を送信するのみにとどまる。TXOP期間2が終了後、HCが獲得するTXOP期間3において、シーケンス番号「1」〜「4」のデータフレーム２２２が再送されることになる。すなわち、図２１の例の場合に比べ、ダウンリンクのデータの再送タイミングを早めることができる。従って、HCのスケジューリング処理部は、遅延許容時間などを考慮し、IACフレームをQSTAに送信するか否かを判断することで、MAC効率を高めることが可能である。
本発明の第一の実施形態においては、ブロックACK要求を含まず複数のデータを1つの物理フレームにアグリゲートして送信し、該物理フレームを受信した端末は、SIFS後にMPDUの受信ステータスを圧縮ブロックACKとして応答する。ここで、図２３に示すように、複数データをアグリゲートした物理フレームの最後にブロックACK要求を含む場合にも、本発明は適用可能である。基本的な動作は、ブロックACK要求を含まない場合と同一であるが、図２３を用いて再送例を示す。
図２３において、TXOP期間1を獲得したHCは、IACフレーム２３０とシーケンス番号「1」〜「4」の複数データ２３１、及びBlock ACK Starting Sequence Controlが「1」のブロックACK要求フレーム２３２をアグリゲートして送信する。この時点で、シーケンス番号「1」「4」のデータ２３１、ブロックACK要求フレーム２３２がQSTA1で正常に受信できなかったとする。QSTA1は、HCからのブロックACK要求を受信していないため、圧縮ブロックACKを送信することはできないが、過去1回分の物理フレームの受信ステータスとして、Block ACK Starting Sequence Controlを「2」、Block ACK Bitmapを110…のように受信情報を記憶しておく。TXOP期間1において、QSTA1は、シーケンス番号「1」〜「3」のデータフレーム２３３とBlock ACK Starting Sequence Controlが「1」のブロックACK要求２３４をアグリゲートして送信する。ここで、このブロックACK要求フレーム２３４がHCにおいて正常に受信されないと、HCは圧縮ブロックACKを応答しない。データフレーム送信側は、SIFS+1スロット時間内にビジーを検出するが、受信した物理フレームの中に自分宛の圧縮ブロックACKフレームが存在しない場合、送信したフレームをリカバリーの対象とみなす。HCは、IACフレーム２３５と、QSTA1に圧縮ブロックACKの再送を促すためのブロックACK要求フレーム２３６をアグリゲートして送信する。QSTA1は、シーケンス番号「1」「4」のMPDUが誤ったことを示す圧縮ブロックACK２３７に、HCに対するブロックACK要求フレーム２３８をピギーバックして送信する。そして、HCは、IACフレーム２３９、QSTA1からのブロックACK要求に対する圧縮ブロックACK２４０と、再送用のシーケンス番号「1」「4」のMPDU２４１、及びブロックACK要求フレーム２４２をアグリゲートして送信する。TXOP期間1の最後に、QSTA1が圧縮ブロックACK２４３を送達確認として送信する。IACフレームでピギーバックが許可されており、かつHC宛に送信するデータが送信用キュー内に存在すれば、併せて送信する。前述したように、QSTA1に対してピギーバックを許可するか否かは、HCのスケジューリング処理部の判断に従って決定する。
本発明の第一の実施形態によれば、複数のMPDUをアグリゲートして送信し、宛先からの部分応答フレームに逆方向のデータをピギーバックして送信することで、MAC効率を向上させることができる。本実施形態では、コンテンションフリーのQoSアクセス制御方式であるHCCAを中心に説明を進めたが、コンテンションベースのEDCAにおいても適用可能であることは言うまでもない。EDCAの場合では、TXOPを獲得した端末がスケジューリングの主体として、IACフレームを用いて宛先端末にピギーバックのフレーム送信量を調節する。また、HCCAにおいても、HCからQoS CF-Pollフレームを受信してTXOPを獲得したQSTAは、該TXOP期間の範囲内であれば、IACフレームを用いて宛先端末にピギーバック送信を許可する。これらのスケジューリングは、QoSデータの遅延許容時間等に依存する。
（第二の実施形態）
本発明の第二の実施形態は、遅延型ブロックACK伝送に関し、ブロックACKの送信を後回しにすることを了解するためのACKフレームを、第一の実施形態で説明したIACフレームによって代替するというものである。具体的には、本発明の第二の実施形態に係る通信装置は、複数のデータフレームを送信した後、宛先端末から他の宛先に対するIACフレームを、遅延型ブロックACKに対するノーマルACKの代替として使用し、宛先端末は一定時間後に、該ブロックACKフレームを複数データとアグリゲートして送信する。
IEEE802.11e Draft 10.0によれば、ブロックACK要求フレームを受信してからSIFS後にブロックACKフレームを返信することが困難な場合、図５に示したような遅延型ブロックACKを行なうことができる。遅延型ブロックACKでは、ブロックACK要求に対するACK応答をまず行い、任意の時間経過した後にブロックACKフレームを送信し、それに対するACK応答を行なう。遅延型ブロックACKでは、ブロックACK要求やブロックACKを送信した後、一定時間経過してもACKを受信できない場合、それらのフレームの送信に失敗したとみなす。本発明の第二の実施形態は、遅延型ブロックACKを用いた場合のピギーバック送信に関するものである。
図２４に、IEEE802.11eの従来の遅延型ブロックACKのポリシーを用いて、本発明の第一の実施形態で示したピギーバックを行なった場合のフレーム交換の様子を示す。図２４において、TXOP期間1を獲得したHCは、IACフレーム２４４とシーケンス番号「1」「2」のデータフレーム２４５をアグリゲートして送信する。QSTA1は、HCからのデータ２４５に対する圧縮ブロックACK２４６に対し、IACフレーム２４４によって付加された期間内でアップリンク方向のデータ２４７をピギーバックして送信する。ここで、HCからの応答に遅延型ブロックACKのポリシーを適用するならば、IEEE802.11のACKフレーム２４８を送信することで、遅延型ブロックACKを受け付けた旨を通知する。HCがACKフレームを送信しない場合や、ACKフレームが誤りによってQSTA1で正常に受信できない場合、QSTA1はデータフレーム(あるいはブロックACK要求フレーム)をリカバリーの対象とみなす。図２４のTXOP期間2においても、TXOP期間1の場合と同様に、HCからQSTA2への圧縮ブロックACKに遅延型ポリシーを適用した場合で、QSTA2に対するACK２４９を送信した後、TXOPを終了している。TXOP期間3で、QSTA1に対してダウンリンク方向のシーケンス番号「3」のデータフレーム２５０と、TXOP期間1で送信を延長したBlock ACK Starting Sequence Control「1」の圧縮ブロックACK２５１をアグリゲートして送信し、QSTA1がACKフレーム２５２を送信することで、遅延型ブロックACKの1シーケンスを完了している。図２４のTXOP期間3では、ACKフレーム２５２に、HCからのダウンリンクのデータに対するBlock ACK Starting Sequence Control「3」の圧縮ブロックACK２５３をピギーバックしている。以上のように、遅延型ブロックACKを用いてピギーバックを行なう際、IEEE802.11のACKフレームを介することで、MAC効率が低下してしまうことが避けられない。そこで本発明の第二の実施形態は、かかる問題を解決する仕組みを実現する。尚、以下では、遅延型ブロックACKポリシーを、HCからQSTA方向の圧縮ブロックACK送信に適用した場合について主に説明していくが、アップリンク、ダウンリンク双方の場合にも、本発明が適用可能であることは言うまでもない。
図２５及び図２６に、遅延型ブロックACKへの適用についての本発明の基本的な実施形態を示す。図２５のHCにおいて、QSTA1からのアップリンク方向のデータに対する圧縮ブロックACKの送信を先延ばしにしたい場合、通常ならばIEEE802.11のACKフレームを送信するが、代わりに他の宛先に対するIACフレームをSIFS後に送信することで代用する。IACフレームは、図１０に示したIAC Maskフィールドの各ビットに1を立てることで、様々な用途に利用できる。ここで、遅延型ブロックACKの送信を了解したことを示すために、IAC Maskフィールドの中に1ビットサイズの識別フラグを用意する。
HCからQSTA2に対してシーケンス番号「1001」「1002」のデータフレーム２５５を送信する時点で、同時にアグリゲートするIACフレーム２５４の宛先MACアドレスは、QSTA2となっている。本発明の第二の実施形態では、HCはQSTA2への送信時に、IACフレームのIAC Maskフィールド内に拡張した、遅延型ブロックACKを受け付けた旨のフラグに1の値を設定する(無論、負論理にも適応可能である)。QSTA1はHCが応答する圧縮ブロックACKには、遅延型ブロックACKポリシーが適用されていることを予め認識している。そこで、HCへアップリンク方向のデータを送信してからSIFS+1スロット時間以内に無線チャネルのビジーを検出した場合、該物理フレーム内にアグリゲートされたIACフレームを正常に受信しており、かつIACフレームのIAC Maskフィールド内の遅延型ブロックACKを受け付けた旨のフラグが1(負論理の場合は0)になっていれば、宛先側で遅延型ブロックACKの送信を受け付けたと認識する。
ここで、図２５のHCは、QSTA1からの物理フレームを受信してから、SIFS後にQSTA2にデータを送信している。IEEE802.11e Draft 10.0の規定によれば、ブロックACK要求あるいはデータを送信してからSIFS+1スロット時間内に無線チャネルのビジーを検出しなければ、送信したフレームをリカバリーの対象とみなす。従って、HCがQSTA1に対して遅延型ブロックACKを受け付けた旨を通知するフレームも、SIFS後に送信する必要がある。QSTA1は、HCへのフレーム送信からSIFS後にビジーを検出することで、タイマーをリセットする。そして、ビジーの要因となった物理フレーム内のIACフレームの宛先が自分宛以外であったとしても、IAC Mask内のフラグが1になっていれば、遅延型ブロックACKポリシーによって、圧縮ブロックACKが返信されてくることを確認する。もしIAC Maskのフラグが0のまま(負論理の場合は1のまま)であれば、遅延型ブロックACKシーケンスの確立に失敗したと判断する。
図２５では、HCがQSTA2からのアップリンク方向のフレーム受信を終了してからSIFS後にQSTA1に対するシーケンス番号「3」のデータ２５６と、QSTA1に対するIACフレーム２５７、及びBlock ACK Starting Sequence Control「1」の圧縮ブロックACK２５８をアグリゲートして送信する。この圧縮ブロックACKフレーム２５８は、QSTA1が最初に送信したシーケンス番号「1」「2」のMPDUに対する送達確認フレームである。尚、IACフレーム２５７の宛先はQSTA1であるが、IAC Mask内のフラグを立てることにより、QSTA2からのアップリンク方向のデータに対する遅延型ブロックACK送信を受け付けた旨を通知する。また、IEEE802.11e Draft 10.0の規定によれば、ブロックACKフレームに対するACK応答も必要であるが、本発明の第二の実施形態において、ACKフレームとHCからのダウンリンク方向のデータに対する圧縮ブロックACKをアグリゲートするような場合、圧縮ブロックACKを送信することで、IEEE802.11のACKフレームを送信したことと兼用する。すなわち、HCは、シーケンス番号「3」のデータと、遅延型ポリシーの圧縮ブロックACKを送信した後、宛先(図２５の例ではQSTA1)が即時型ポリシーで圧縮ブロックACKを返してくれば、IEEE802.11e Draft 10.0で規定されている、ブロックACKに対するACKフレーム受信とみなす。
図２５のように、他の宛先に向けて送信するデータが存在すれば、IACフレームを併せてアグリゲートし、該フレームを用いて、遅延型ブロックACKを受け付けた旨を通知する。ここで、図２６の例のように、ダウンリンクのデータが存在しなくなった時は、IEEE802.11のACKフレームを送信してTXOP期間を終了する。図２６の例では、QSTA2からのフレーム２６０を受信した後、SIFS後に送信すべきデータが存在しないため、通常のACKフレーム２６１をQSTA2宛に送信して、遅延型ブロックACKを受け付けた旨を通知する。TXOP期間1が終了して、TXOP期間2が開始した時点で、QSTA1に対する遅延型ポリシーの圧縮ブロックACK２６２とダウンリンクのデータ２６３をアグリゲートして送信する。図２５に示したように、QSTA1からの圧縮ブロックACKは、通常のACKの役割(ブロックACKに対するACK)も兼ね備えている。本発明の第二の実施形態では、決められたTXOP期間の間で、かつSIFS間隔で送信するデータが存在する場合に、他の宛先に対するIACフレームを用いて、遅延型ブロックACKに対するACK応答とみなす。よって、図２５及び図２６のように、IACフレームを遅延型ブロックACKにおけるACKの意味で用いることによって、従来のIEEE802.11e Draft 10.0の遅延型ブロックACKのポリシーを適用した場合に比べ、MAC効率を向上することが可能である。
図２７〜図３０において、誤りによる再送を行う場合のフレーム交換の様子を示す。基本的な動作としては、本発明の第一の実施形態の場合と同じである。まず、図２７に示すように、HCがIACフレーム２７０と、シーケンス番号「1」「2」のダウンリンクのデータ２７１をQSTA1に対して送信する。ここで、QSTA1がSIFS後に送信する応答フレームが誤った場合、HCはビジー２７２のみを検出する。すると、HCはSIFS後にブロックACK要求フレーム２７４とIACフレーム２７３をアグリゲートしてQSTA1に送信する。QSTA1からHCへの圧縮ブロックACKに、即時型ブロックACKポリシーが適用されているとした場合、QSTA1はHCからのブロックACK要求２７４の受信からSIFS後に圧縮ブロックACK２７５を送信する。図２７の例では、Block ACK Starting Sequence Control「1」の圧縮ブロックACK２７５と、HCへのアップリンク方向のデータ２７６をピギーバックして送信する。HCからQSTA方向の圧縮ブロックACKには遅延型ポリシーが適用されていると仮定して、図２５の場合と同様に、QSTA2宛へのIACフレーム２７７を用いて、遅延型ブロックACK適用を受け付けた旨を通知する。その後、QSTA2からHCへのアップリンク方向のフレーム送信が終了した時点でHCの持つTXOP期間1が残り少なくなっており、スケジューリングの観点からHCはQSTA1への遅延型ポリシーの圧縮ブロックACKを送信したとする。QSTA1は、HCから受信した物理フレーム内に遅延型の圧縮ブロックACKが存在していることから、IEEE802.11のACKフレームを返信して遅延型ブロックACKシーケンスを完了する。この時、本発明の第二の実施形態では、図２５の例のように、HCが遅延型の圧縮ブロックACKにダウンリンクのデータを送信しており、かつQSTA1からHCへの圧縮ブロックACKに即時型ポリシーが適用されているならば、前述のように、圧縮ブロックACKだけを送信することで、IEEE802.11の通常のACKの役割を兼用することが可能である。図２７の例では、TXOP期間1の最後にHCが送信する物理フレームには、データがアグリゲートされていないため、QSTA1は通常のACK２７８を送信して遅延型ブロックACKのシーケンスを完了する。
図２８に、QSTAからHCへのアップリンク方向のMPDUが部分的に誤った場合の例を示す。図２８の例では、QSTA1からHCへの圧縮ブロックACK２８０と、アップリンク方向のシーケンス番号「2」のデータ２８１が誤っている。HCは、QSTA1から圧縮ブロックACKを受信できないため、送信したフレームをリカバリーの対象とみなし、ブロックACK要求２８２を送信する。ここで、HCが送信するブロックACK要求２８２には、IACフレーム２８３がアグリゲートされている。このIACフレーム２８３の宛先はQSTA1であり、IAC Maskフィールド内のフラグには1(負論理の場合は0)が立っている。IACフレーム２８３を受信したQSTA1は、自身が送信したシーケンス番号「1」「2」のデータに対する圧縮ブロックACKに、遅延型ポリシーが正しく適用されたことを確認する。そして、QSTA1は、Block ACK Starting Sequence Control「1」の圧縮ブロックACK２８３を再送する。SIFS後に、HCはQSTA2に対し、IACフレーム２８４、シーケンス番号「1001」「1002」のデータ２８５をアグリゲートして送信する。この時、IACフレーム２８４のIAC Maskフィールドのフラグの値は、初期値である0(負論理の場合は1)のままにしておく。QSTA1からのデータに対する遅延型ブロックACKポリシーの受付通知は、既に完了しているためである。QSTA2からHCにデータが送信された後、HCはQSTA1へのダウンリンクのデータ(シーケンス番号「3」)２８６と、遅延型ポリシーのBlock ACK Starting Sequence Control「1」の圧縮ブロックACK２８７を送信する。QSTA1は、HCのシーケンス番号「3」に対する圧縮ブロックACK２８８を、IEEE802.11eのブロックACKに対するACKフレームとして兼用させる。更に、IACフレームによりピギーバックが許可されている場合、送信に失敗したシーケンス番号「2」のデータフレーム２８９をピギーバックして再送する。
図２９に、ダウンリンク方向の物理フレームにアグリゲートしたMPDUが部分的に誤った場合の再送例を示す。図２９の例では、QSTAからHCへの圧縮ブロックACK送信に即時型ポリシーを適用しているため、QSTA1がHCからのシーケンス番号「1」のMPDUが誤ったことを圧縮ブロックACK２９０で応答し、HCはシーケンス番号「1」のMPDU２９１を再送する。TXOP期間2において、HCがQSTA2にシーケンス番号「1001」「1002」のデータフレーム２９２とIACフレーム２９３をアグリゲートして送信する。QSTA2は即時型ポリシーのHCへの圧縮ブロックACK２９４と、アップリンク方向のデータ２９５をピギーバックして送信する。HCは、QSTA2のフレーム受信からSIFS後にQSTA1へデータ２９６を送信する際、併せてアグリゲートしたIACフレーム２９７のIAC Maskフィールド内のフラグに1をセットして送信する。QSTA2は、QSTA1宛のIACフレーム２９７のフラグが1になっている場合、自身の送信したアプリンク方向のデータに対するHCからの部分応答に、遅延型のポリシーが適用されたことを確認する。
図３０は、QSTAからHCへのアップリンク方向の全てのデータが誤り、HCが圧縮ブックACKを返信できなかった場合を示している。図３０において、QSTA1はHCからのIACフレームによりピギーバック送信を許可されているため、アップリンク方向のデータ(シーケンス番号「1」「2」)３００を圧縮ブロックACK３０１にピギーバックする。この時、QSTA1の送信したデータフレームがFCS計算の結果、全て誤っていた場合、HCは圧縮ブロックACKを返信しない。そしてTXOP期間1の範囲内で、HCはSIFS後にQSTA2へのダウンリンクの送信を行なう。ここで、QSTA2に対するIACフレーム３０２のIAC Maskフィールド内のフラグは、初期値0(負論理の場合は1)のままである。QSTA1は、HCの送信した物理フレームを監視しており、IACフレーム３０２内のフラグを検査するが、値が0のままであるため、遅延型ポリシーの圧縮ブロックACKの適用に失敗したと判断し、送信したデータフレーム３００をリカバリーの対象とみなす。その後、HCがQSTA1へのシーケンス番号「3」のデータ３０３と、IACフレーム３０４をアグリゲートして送信すると、QSTA1はHCからのデータ３０３に対する圧縮ブロックACK(Block ACK Starting Sequence Control「3」)３０５に、ブロックACK要求３０６をピギーバックする。あるいは、本発明の第一の実施形態のように、シーケンス番号「1」「2」を再送対象として直接アグリゲートしても良い。ブロックACK要求３０６をピギーバックするか再送対象のフレームを直接アグリゲートするかは、QSTA1のスケジューリング処理部が選択する。QSTA1のフレームを受信してからSIFS後に、HCが他のQSTAにデータを送信する場合、IACフレームのIAC Maskフィールド内にフラグに1を立てる。(負論理の場合は0)これにより、QSTA1は、自身の送信したブロックACK要求(あるいはデータ)に対する、遅延型ポリシーの圧縮ブロックACK返信がHC側で適用されたと認識する。
以上説明したように、本発明の第二の実施形態によれば、遅延型ブロックACKに対してピギーバック手法を効率良く適用し、MAC効率を高めることができる。尚、第二の実施形態では、HCからQSTAへの圧縮ブロックACK(すなわちQSTAからアップリンクのデータ)に遅延型ポリシーを、QSTAからHCへの圧縮ブロックACK(すなわちQSTAへのダウンリンクのデータ)に即時型ポリシーを用いた場合の例を示した。本発明は、アップリンク、ダウンリンク双方向の圧縮ブロックACKに遅延型ポリシーを用いることも可能であることは言うまでもない。
また、第一の実施形態で示したように、EDCAによるTXOPを獲得した際にも、アクセス権のある端末が主導となって、IACフレームによる遅延型ブロックACKを実施する方法にも適用可能である。更に、ブロックACK要求を物理フレームの最後尾にアグリゲートする場合にも第一の実施形態と同じように適用することが可能である。この場合、ブロックACK要求フレームがFCS計算の結果誤っていれば、データ受信側は圧縮ブロックACKを送信しない。その後、データ送信端末は、ブロックACK要求フレームを再送するなどして、受信側からの圧縮ブロックACKの再送を要求する。
（第三の実施形態）
本発明の第三の実施形態は、複数の宛先に対して複数MPDUをアグリゲートして送信する場合における即時型ブロックACKの適用および遅延型ブロックACKの適用に関するものである。同一の宛先へのMACフレームのみをアグリゲートして送信する場合、宛先が切り替わる毎に、キャリアセンスやバックオフのオーバーヘッドが生じる。これに対し、複数の異なる宛先へのMACフレームを1つの物理フレームにアグリゲートすることで、これらのオーバーヘッドを削減し、MAC効率を高めることが可能となる。
図３１に複数宛先に関する情報を含むMACフレームの一例を示す。このようなMACフレーム３１０を物理フレームの先頭にアグリゲートすることで、物理フレーム受信端末は自分宛のMPDUが存在するか否かを即座に判断することができる。図３１に示すようなMACフレーム３１０を、以後「MRAD(Multiple Receiver Aggregation Descriptor)フレーム」と呼ぶ。図３１に示すように、MRADフレーム３１０は、Frame Control、Duration、Receiver Address、Transmitter AddressなどのIEEE802.11の従来のMACヘッダー３１１を有する。MRADフレーム３１０には、物理フレーム内にアグリゲートされた宛先数をNumber of receiversフィールド３１２で示し、宛先MACアドレス情報を示すReceiver Address Infoフィールド３１３と、宛先毎に占有する情報サイズをオクテット単位で指定するLengthフィールド３１４が存在する。図３１の例では、Receiver Address Info 3までの情報を表しているが、この数に限定されず、任意の可変長とすることが可能である。つまり、宛先の数は任意である。
図３２に、即時型ブロックACKのポリシーを適用した場合のフレーム交換例を示す。TXOPを獲得したHCは、MRADフレーム３２０、QSTA1に対するIAC３２１とデータフレーム(シーケンス番号「1」「2」)３２２、QSTA2に対するIAC３２３とデータフレーム(シーケンス番号「1001」「1002」)３２４を1つの物理フレーム３２５にアグリゲートして送信する。MRADフレーム３２０の情報を用いることで、QSTA1とQSTA2以外の端末は、省電力モードに移行するなど自由に処理を行うことができる。また、QSTA1、QSTA2宛のIACフレーム３２１、３２３には、HCの物理フレーム送信終了からのオフセット時間を記載することで、QSTA1、QSTA2が応答するタイミングを指定する。このオフセット時間は、図１０に示した例におけるResponse Period Offsetフィールドを使用する。QSTA1は自分宛のIACフレームを正常に受信した場合、図３２に示すように、ピギーバック送信可能時間の範囲内で、HCへの圧縮ブロックACK３２６にアップリンクのデータ３２７をアグリゲートして送信する。同様に、QSTA2もQSTA1のフレーム送信に引き続き、HCへの圧縮ブロックACK３２８とアップリンクのデータ３２９をアグリゲートして送信する。この時、図３２の例は、QSTA2の送信したデータフレーム３２９が誤っていることを示している。即時型ブロックACKポリシーを適用した場合、QSTA2のフレーム送信が終了してからSIFS後に、HCはMRADフレーム３３０、QSTA1に対するIAC３３１と圧縮ブロックACKフレーム３３２をアグリゲートして送信する。QSTA2のデータは全て誤っているため、HCからQSTA2に対する圧縮ブロックACKフレームはアグリゲートされない。ここで、HCがQSTA2に逆方向(アップリンク)のフレーム送信を許可しない場合、MRADフレーム３３０のReceiver Address InfoフィールドにQSTA2のMACアドレスは含まれないことになる。Number of receiversフィールドは1であり、QSTA1のMACアドレスおよび長さ情報のみが記載される。もし、QSTA2の送信を許可する場合、QSTA2宛のIACフレームをアグリゲートし、Number of receiversは2とし、QSTA2のMACアドレスも追加される。
本発明の第三の実施形態において、TXOP期間1内に再びHCが物理フレームを送信した場合、QSTA1とQSTA2はHCからの物理フレーム内にアグリゲートされたMRADフレーム内のReceiver Address Infoフィールドを検査し、自分のMACアドレスが存在しない場合、送信したフレームをリカバリーの対象とみなす。すなわち、図３２の例では、QSTA2が送信したシーケンス番号「1」「2」に対する即時型圧縮ブロックACKの受信に失敗したと判断し、適切なリカバリー動作を行なう。
図３３及び図３４に、遅延型ブロックACKポリシーへの適用例を示す。図３３において、HCは、MRADフレーム３３０、QSTA1へのIAC３３１とデータフレーム(シーケンス番号「1」)３３２、QSTA2へのIAC３３３とデータフレーム(シーケンス番号「1001」)３３４を1つの物理フレーム３３５にアグリゲートして送信する。QSTA1、QSTA2は、それぞれのIACフレーム情報に基づいて、アップリンクに送信するタイミングを認識し、HCからのデータに対する圧縮ブロックACK３３６，３３７にアップリンクのデータ３３８,３３９をピギーバックして送信する。
遅延型ポリシーを適用する場合、QSTAの送信が終了してから即座に圧縮ブロックACKを送信する必要はない。その代わりに、第二の実施形態で示したように、逆方向の送信を許可(TXOPを持たない端末の送信を許可)するフレームを、IEEE802.11e Draft 10.0遅延型ブロックACK伝送のブロックACK要求フレームに対するACKフレームとみなすことができる。ここで、HCはQSTA1、QSTA2、QSTA3へのIACフレーム３４０と、QSTA3へのダウンリンク方向のデータ(シーケンス番号「2001」)３４１をアグリゲートして送信する。QSTA1、QSTA2へのIACフレームのReverse Direction Grant、Response Period Offsetはいずれも0にする。すなわち、QSTA1、QSTA2のアップリンク方向の送信は許可しない。ただし、遅延型ブロックACKを受け付けた旨のフラグはオンに設定する。この物理フレームを受信したQSTA1、QSTA2は自身の送信したデータに対して遅延型ブロックACKポリシーが適用されたことを確認する。その後、QSTA3は、HCのデータ(シーケンス番号「2001」)に対する圧縮ブロックACK３４２と、アップリンク方向のデータ３４３をアグリゲートして送信する。図３３においてHCは、QSTA1、QSTA2、QSTA3に対するIACフレーム３４４と、QSTA1、QSTA2への圧縮ブロックACK３４５を送信する。この圧縮ブロックACK３４５は、QSTA1、QSTA2からのアップリンク方向のデータに対する遅延型ポリシーのブロックACKである。ここで、QSTA1、QSTA2へのIACフレーム３４４のReverse Direction Grant、Response Period Offsetには、それぞれのQSTAが最低限IEEE802.11のACKフレームを送信できるような値をセットする。また、QSTA3のIAC Maskのフラグを立てることで遅延型ブロックACKを受け付けた旨を通知する。尚、図３４に示すように、HCが保持するTXOP期間の残りが少なくなった場合は、それぞれの宛先毎に用意され、アグリゲートされたIEEE802.11のACKフレーム３４６を送信する。つまり、複数宛先のACKアグリゲーションとなる。
図３５及び図３６を参照し、複数の宛先に対するデータをアグリゲートした場合の受信側のバッファ管理について説明する。図３５のように、MRADフレーム３５０、QSTA1へのIAC３５１、シーケンス番号「1」「2」のデータフレーム３５２，３５３、QSTA2へのIAC３５４、シーケンス番号「1001」「1002」のデータフレーム３５５，３５６をアグリゲートして送信する場合を考える。ここで、複数のフレームをアグリゲートする際のフォーマットは、図６に示したようなフォーマットであっても良い。
図３６に示すように、QSTA1へのシーケンス番号「1」のMPDU３５２がFCS計算の結果、誤っていたとする。IACフレーム３５１で指定されたオフセット値を用いて、QSTA1はBlock ACK Starting Sequence Control「2」の圧縮ブロックACK３６０、QSTA2はBlock ACK Starting Sequence Control「1001」の圧縮ブロックACK３６１を送信する。ブロックACK要求を含まないアグリゲーションデータに対して、圧縮ブロックACKのBlock ACK Starting Sequence Controlの値は、正常に受信できた一番初めのMPDUのシーケンス番号を用いる。図３６において、QSTA1の受信バッファ３６２にはシーケンス番号「0」「4095」のMPDU、QSTA2の受信バッファ３６３にはシーケンス番号「999」と「1000」のMPDUが既に格納されていたとする。本発明の第三の実施形態において、IACフレームに対するFCS計算が正常で、かつそれに続くデータフレームのFCS計算結果が正常な場合、該データフレームのシーケンス番号を、受信バッファ管理のための正規のシーケンス番号情報とみなす。図３６の例で、QSTA1はHCに圧縮ブロックACKの送信を行なうが、受信バッファ３６２内のMACフレームはそのままにしておく。一方、QSTA2は全てのフレームを正常に受信しているため、シーケンス番号「1001」を正式なBlock ACK Starting Sequence Controlの値として、受信バッファ管理を行なう。IEEE802.11e Draft 10.0の規定によれば、Block ACK Starting Sequence Controlの値よりも前のシーケンス番号を持つMACフレームは、全て受信バッファから開放し、上位層に渡す必要がある。そのため図３６のQSTA2は、シーケンス番号「999」〜「1002」のMACフレームを受信バッファ３６３から開放して上位層に渡す。
図３７に示すように、IACフレームを含まない構成にすることもできる。図３７の例では、QSTA2へのシーケンス番号2のデータがFCS計算の結果誤ったことを示している。この場合、QSTA2のシーケンス番号「1001」のデータフレームに対するFCS計算結果が正常であっても、QSTA1のMPDUがどの部分までアグリゲートされているか判断することができないため、圧縮ブロックACKを返信しても、受信バッファからMACフレームを開放することはできない。つまり、本発明の第三の実施形態において、異なる宛先アドレスを持つ連続した二つのMPDUに対するFCS計算の結果が正常であれば、二つ目のMPDU(すなわち新しい宛先のMPDU)のシーケンス番号を、次の宛先の正式なBlock ACK Starting Sequence Controlと判断して、受信バッファ管理を行なう。
ところで、IEEE802.11e Draft 10.0の規定によれば、MACフレームはトラフィックの優先度毎に分類され、ブロックACK要求やブロックACKフレームも優先度毎に必要となる。図２のブロックACK要求フレームのBAR(Block Ack Request)Controlフィールド、図３のブロックACKフレームのBA(Block Ack)Controlフィールドには、4ビットのTID(Traffic Identifier)識別子が存在し、0-15の番号が記載される。尚、TIDに0-7の数値が割り当てられた際は、該MACフレームがPrioritized QoS(優先度QoS)すなわちEDCAによる送信が行なわれることを意味しており、8-15の数値が割り当てられた際は、該MACフレームがParameterized QoS(パラメータ化QoS)すなわちHCCAによる送信が行なわれることを表している。TIDは、図８の圧縮ブロックACKや、図１０のIACフレームのRDTID(Reverse Direction Traffic Identifier)にも用いられる。IACフレームのRDTIDフィールドでは、TXOPを獲得している送信端末が、宛先に対してピギーバック送信を許可する際に、ピギーバックするMACフレームの優先度を指定する目的で使用する。IEEE802.11e Draft 10.0の規定によれば、MACフレームのシーケンス番号はTID毎に独立して割り当てる必要がある。従って、QoSデータの受信側では、受信バッファを優先度毎に管理することが望ましい。前述したように、IEEE802.11eのブロックACKによる伝送では、ブロックACK要求フレームの示す始点シーケンス番号(Block ACK Starting Sequence Control)よりも前のシーケンス番号を持つMACフレームは、受信バッファから全て開放する。ここで、ブロックACK要求フレームは、TID毎に用意されるため、受信バッファ管理も優先度(TID)毎に行なう必要がある。これまで、図３５、図３７において、単一の優先度(TIDが1種類)の場合に関して、複数の宛先へのMACフレームがアグリゲートされた物理フレームに関する場合の受信バッファ管理の説明を行なった。本実施形態では、複数宛先のみならず、更に複数優先度のMACフレームを単一物理フレームにアグリゲートする場合にも適用可能である。例えば、図３５において、MRADに続いてQSTA1へのIACフレーム、シーケンス番号1、2のデータフレーム、QSTA2へのIACフレーム、シーケンス番号1001、1002のデータフレームの順番でアグリゲートした場合を述べたが、MRADに続きQSTA1への高優先度(TIDの値については任意)のIACフレーム、シーケンス番号1、2のデータフレーム、QSTA1への中優先度のIACフレーム、シーケンス番号1、2のデータフレーム、及びQSTA2への高優先度(TIDの値については任意)のIACフレーム、シーケンス番号1001、1002のデータフレーム、QSTA1への中優先度のIACフレーム、シーケンス番号1001、1002のデータフレームの順にアグリゲートしたとする。この場合、各宛先、優先度の先頭にIACフレームがアグリゲートされている前提の元で、IACフレームに対するFCS計算の結果が正常で、かつ続くMPDUに対するFCS計算が正常であれば、該MPDUのシーケンス番号を正規の始点シーケンス番号とみなして、受信端末内の優先度毎のバッファに対して、始点シーケンス番号よりも前のシーケンス番号を持つMACフレームは全てバッファから開放し上位層に渡す。もしくは、図３７のように、IACフレームを必ずしも含む必要がない場合、二つの連続したMPDUに対するFCS計算結果が正常で、かつ二つのMPDUの宛先アドレス、あるいは優先度が異なる場合、二番目のMPDUのシーケンス番号は、該MPDUの宛先端末内で優先度毎に用意される受信バッファ管理に用いられる。すなわち、正規の始点シーケンス番号よりも前のシーケンス番号を持つMACフレームは、全て受信バッファから開放して上位層に渡すことになる。
本実施形態では、アクセスポイントからQSTAへのダウンリンクの送信時に、複数宛先のMACフレームをアグリゲートして送信する例を示したが、QoS CF-PollフレームによりTXOPを与えられていれば、QSTAが送信の主体となっても良い。QSTAが送信の主体となる場合、複数宛先の候補としては、アクセスポイントの他に、DLP(Direct Lint Protocol)としてQSTA間で直接通信可能な端末などが挙げられる。更に、コンテンションフリーのQoSアクセス制御方式であるHCCAだけでなく、コンテンションベースのEDCAにおいても適用可能であることは言うまでもない。EDCAの場合では、TXOPを獲得した端末が複数宛先に対するデータ送信の起点となる。また、IACフレームによる宛先へのピギーバック送信許可も、TXOPを獲得した端末のスケジューリング処理部によって実現される。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
本発明の実施形態に係る通信装置の構成を示すブロック図 IEEE802.11e Draft 10.0で規定されているブロックACK要求フレームのフォーマットを示す図 IEEE802.11e Draft 10.0で規定されているブロックACKフレームのフォーマットを示す図 即時型ブロックACKのシーケンス例を示す図 遅延型ブロックACKのシーケンス例を示す図 複数MPDUのアグリゲーションの一例を示す図 複数MPDUのアグリゲーションの別の例を示す図 圧縮ブロックACKのフォーマットを示す図 圧縮ブロックACKのシーケンス例を示す図 IACフレームのフォーマットを示す図 IACフレームによるピギーバック送信の一例を示す図 送信エラーの発生により明示的なブロックACK要求を送信する場合を示す図 明示的なブロックACK要求にIACを付加する場合を示す図 アップリンク方向の送信フレームに部分的な誤りが生じた場合を示す図 ダウンリンク方向の送信フレームに部分的な誤りが生じた場合を示す図 ダウンリンク方向の送信フレームに部分的な誤りが生じた場合の別の例を示す図 アップリンク方向及びダウンリンク方向の双方向において、それぞれ、送信フレームに部分的な誤りが生じた場合を示す図 アップリンク方向及びダウンリンク方向の双方向において、それぞれ、送信フレームに部分的な誤りが生じた場合の別の例を示す図 アップリンク方向への圧縮ブロックACK送信についてタイムアウトが発生した場合を示す図 アップリンク方向への圧縮ブロックACK送信についてタイムアウトが発生した場合の別の例を示す図 HCからのダウンリンク方向にアグリゲート送信した全てのMPDUが誤っていた場合を示す図 HCからのダウンリンク方向にアグリゲート送信した全てのMPDUが誤っていた場合の別の例を示す図 複数データをアグリゲートした物理フレームの最後にブロックACK要求を含む場合を示す図 遅延型ブロックACKのポリシーを用いてピギーバックを行なう場合のフレーム交換の様子を示す図 遅延型ブロックACKに適用されたピギーバックを示す図 遅延型ブロックACKに適用されたピギーバックの別の例を示す図 遅延型ブロックACKにおいてビジーのみが検出された場合を示す図 アップリンク方向への送信データに部分的な誤りが生じた場合を示す図 ダウンリンク方向への送信データに部分的な誤りが生じた場合を示す図 アップリンク方向についてタイムアウトが生じた場合を示す図 MRADフレームのフォーマットを示す図 複数宛先への即時型ブロックACKのフレーム交換例を示す図 複数宛先への即時型ブロックACKのフレーム交換の別の例を示す図 複数宛先への即時型ブロックACKのフレーム交換の別の例を示す図 複数宛先へのアグリゲーションと受信バッファ管理を説明するための図 複数宛先へのアグリゲーションと受信バッファ管理を説明するための図 複数宛先へのアグリゲーションと受信バッファ管理を説明するための図
符号の説明
１…通信装置；
２…物理層(PHY)；
３…ＭＡＣ（媒体アクセス制御）層；
４…リンク層；
５…アンテナ；
６…アグリゲーション処理部；
７…キャリアセンス制御部；
８…再送制御部；
９…第一種の物理層プロトコル処理部；
１０…第二種の物理層プロトコル処理部

Claims (25)

  1. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築する手段と、
    前記物理フレームを前記宛先端末に送信する手段とを具備する通信装置。
  2. 前記ピギーバック送信は、送達確認フレームと少なくとも一つのＭＡＣフレームとがアグリゲートされた物理フレームを前記宛先端末から送信元に送信することである請求項１に記載の通信装置。
  3. 前記送信許可フレームを前記物理フレームにアグリゲートするか否かをチャネル使用許可期間の残期間に応じて決定する手段をさらに具備する請求項１に記載の通信装置。
  4. 前記物理フレームの送信後から最小フレーム時間後に、前記宛先端末から返信される物理フレームに送達確認フレームが含まれるか否かを判定する手段と、
    前記送達確認フレームが含まれない場合に、該送達確認フレームの再送を要求する手段とを具備する請求項１に記載の通信装置。
  5. 前記宛先端末から返信される物理フレームの特定フレーム位置のエラー検出に基づいて、前記送達確認フレームの有無を判定する請求項４に記載の通信装置。
  6. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた第一の物理フレームを受信する手段と、
    前記送信許可フレームに応じて、送達確認フレームと複数のデータフレームとがアグリゲートされた第二の物理フレームを送信する手段と、
    前記データフレームに対する送達確認が受信されないことによるタイムアウトを検出する手段と、
    前記タイムアウトが検出されたならば、前記第一の物理フレームに対する送達確認フレームと前記第二の物理フレームのデータフレームについての送達確認要求フレームとがアグリゲートされた第三の物理フレーム、又は前記第一の物理フレームに対する送達確認フレームと再送に係る第二の物理フレームのデータフレームとがアグリゲートされた第四の物理フレームのいずれかを送信する手段とを具備する通信装置。
  7. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、遅延型ブロックACKに係るノーマルACKフレームの代わりに用いられ、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築する手段と、
    前記物理フレームを宛先端末に送信する手段とを具備する通信装置。
  8. 前記物理フレームを送信することにより、前記宛先端末以外の端末に対して前記遅延型ブロックACKに係るノーマルACKを通知する請求項７に記載の通信装置。
  9. 前記遅延型ブロックACKに係るノーマルACKの通知から一定時間後に送達確認フレームを送信する手段を具備する請求項８に記載の通信装置。
  10. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、遅延型ブロックACKに係るノーマルACKフレームの代わりに用いられ、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを受信する手段と、
    前記送信許可フレームに基づいて、前記遅延型ブロックACKに係るノーマルACKの通知を検知する手段とを具備する通信装置。
  11. 前記遅延型ブロックACKに係るノーマルACKの通知から一定時間後に送達確認フレームを受信する手段を具備する請求項１０に記載の通信装置。
  12. ピギーバック送信を許可するための送信許可フレームとデータフレームとが複数の宛先端末についてアグリゲートされた物理フレームを構築する手段と、
    前記物理フレームを前記複数の宛先端末に対して送信する手段とを具備し、
    該宛先端末からの逆方向のデータを受信した後、部分応答の送信を遅延型にする旨の確認通知を、該宛先端末に対する送信許可フレームによって代替する通信装置。
  13. ピギーバック送信を許可するための送信許可フレームとデータフレームとが複数宛先毎についてアグリゲートされた物理フレームを受信する手段と、
    前記物理フレームの送信元端末に対し、部分応答フレームにデータフレームをピギーバックして送信する手段と、
    前記複数の宛先端末への物理フレームを送信した端末がその時点で所有している連続的な送信可能期間内に、再度、複数の宛先端末について複数のMACフレームをアグリゲートして送信する手段とを具備し、
    前記物理フレーム内に含まれる複数宛先制御情報が含む宛先情報を検査し、もし該物理フレームの受信端末のアドレスが含まれていなければ、ピギーバックして送信したデータフレームに対する部分応答への遅延型ポリシーの適用が失敗したと判断する通信装置。
  14. 前記複数宛先制御情報内に自身のアドレスが存在する場合、更に自分宛にピギーバック送信を許可する制御情報フレームが正しく受信できており、かつ遅延型部分応答使用を確認する旨の通知フラグが有効であれば、部分応答に対する遅延型ポリシーの適用に成功したと判断する請求項１３に記載の通信装置。
  15. 複数の宛先端末への複数の優先度のMACフレームがアグリゲートされた物理フレームを受信する手段と、
    受信された物理フレームのMACフレームを格納する優先度毎の受信バッファと、
    宛先毎、優先度毎それぞれの先頭部分に制御情報フレームがアグリゲートされている前提において、該制御フレームに対する誤り計算結果が正常であり、かつ、該制御フレームに続くデータフレームも正常に受信していれば、該データフレームのシーケンス番号情報を用いて、前記受信バッファを管理する手段とを具備する通信装置。
  16. 前記受信バッファ管理を、制御フレームに続くデータフレームのシーケンス番号を始点番号とみなし、該始点番号よりも前のシーケンス番号を持つ受信バッファ内のMACフレームは、全てバッファから開放し、上位層に渡すことにより実現する請求項１５に記載の通信装置。
  17. 宛先毎、優先度毎の制御情報フレームをアグリゲートしない場合において、二つの連続したMACフレームに対する誤り計算結果が正常であり、かつ二つのMACフレームの宛先アドレス、あるいは優先度識別子が異なる場合に、二番目のMACフレームのシーケンス番号を、該MACフレームの示す宛先端末における優先度毎の受信バッファ管理に用いる請求項１５に記載の通信装置。
  18. 前記受信バッファ管理を、二つの正常に受信した宛先、あるいは優先度の異なるMACフレームの二番目のMACフレームのシーケンス番号を始点番号とみなし、該始点番号よりも前のシーケンス番号を持つ受信バッファ内のMACフレームは、全てバッファから開放し、上位層に渡すことによって実現する請求項１７に記載の通信装置。
  19. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築するステップと、
    前記物理フレームを前記宛先端末に送信するステップとを含む通信方法。
  20. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた第一の物理フレームを受信するステップと、
    前記送信許可フレームに応じて、送達確認フレームと複数のデータフレームとがアグリゲートされた第二の物理フレームを送信するステップと、
    前記データフレームに対する送達確認が受信されないことによるタイムアウトを検出するステップと、
    前記タイムアウトが検出されたならば、前記第一の物理フレームに対する送達確認フレームと前記第二の物理フレームのデータフレームについての送達確認要求フレームとがアグリゲートされた第三の物理フレーム、又は前記第一の物理フレームに対する送達確認フレームと再送に係る第二の物理フレームのデータフレームとがアグリゲートされた第四の物理フレームのいずれかを送信するステップとを含む通信方法。
  21. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、遅延型ブロックACKに係るノーマルACKフレームの代わりに用いられ、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを構築するステップと、
    前記物理フレームを宛先端末に送信するステップとを含む通信方法。
  22. データフレーム、送達確認フレーム、及び送達確認要求フレームのいずれかと、遅延型ブロックACKに係るノーマルACKフレームの代わりに用いられ、宛先端末に対してピギーバック送信を許可する送信許可フレームとがアグリゲートされた物理フレームを受信するステップと、
    前記送信許可フレームに基づいて、前記遅延型ブロックACKに係るノーマルACKの通知を検知するステップとを含む通信方法。
  23. ピギーバック送信を許可するための送信許可フレームとデータフレームとが複数の宛先端末についてアグリゲートされた物理フレームを構築するステップと、
    前記物理フレームを前記複数の宛先端末に対して送信するステップとを含み、
    該宛先端末からの逆方向のデータを受信した後、部分応答の送信を遅延型にする旨の確認通知を、該宛先端末に対する送信許可フレームによって代替する通信方法。
  24. ピギーバック送信を許可するための送信許可フレームとデータフレームとが複数宛先毎についてアグリゲートされた物理フレームを受信するステップと、
    前記物理フレームの送信元端末に対し、部分応答フレームにデータフレームをピギーバックして送信するステップと、
    前記複数の宛先端末への物理フレームを送信した端末がその時点で所有している連続的な送信可能期間内に、再度、複数の宛先端末について複数のMACフレームをアグリゲートして送信するステップとを含み、
    前記物理フレーム内に含まれる複数宛先制御情報が含む宛先情報を検査し、もし該物理フレームの受信端末のアドレスが含まれていなければ、ピギーバックして送信したデータフレームに対する部分応答への遅延型ポリシーの適用が失敗したと判断する通信方法。
  25. 複数の宛先端末への複数の優先度のMACフレームがアグリゲートされた物理フレームを受信するステップと、
    受信された物理フレームのMACフレームを優先度毎の受信バッファに格納するステップと、
    宛先毎、優先度毎それぞれの先頭部分に制御情報フレームがアグリゲートされている前提において、該制御フレームに対する誤り計算結果が正常であり、かつ、該制御フレームに続くデータフレームも正常に受信していれば、該データフレームのシーケンス番号情報を用いて、前記受信バッファを管理するステップとを含む通信方法。
JP2004318487A 2004-11-01 2004-11-01 通信装置および通信方法 Active JP4331088B2 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2004318487A JP4331088B2 (ja) 2004-11-01 2004-11-01 通信装置および通信方法
US11/201,258 US20060092871A1 (en) 2004-11-01 2005-08-11 Communication method for wireless LANS
CN2009101345817A CN101610260B (zh) 2004-11-01 2005-11-01 用于无线局域网的通信方法
CNA2005101186704A CN1770774A (zh) 2004-11-01 2005-11-01 用于无线局域网的通信方法
US12/646,580 US8274992B2 (en) 2004-11-01 2009-12-23 Communication method for wireless lans

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004318487A JP4331088B2 (ja) 2004-11-01 2004-11-01 通信装置および通信方法

Publications (2)

Publication Number Publication Date
JP2006129393A true JP2006129393A (ja) 2006-05-18
JP4331088B2 JP4331088B2 (ja) 2009-09-16

Family

ID=36261733

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004318487A Active JP4331088B2 (ja) 2004-11-01 2004-11-01 通信装置および通信方法

Country Status (3)

Country Link
US (2) US20060092871A1 (ja)
JP (1) JP4331088B2 (ja)
CN (2) CN1770774A (ja)

Cited By (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008160551A (ja) * 2006-12-25 2008-07-10 Toshiba Corp 無線通信装置
JP2008227700A (ja) * 2007-03-09 2008-09-25 Oki Electric Ind Co Ltd 無線通信システム、無線通信装置及び送信権調停方法
JP2008270951A (ja) * 2007-04-17 2008-11-06 Mitsubishi Electric Corp データ通信装置
JP2008306592A (ja) * 2007-06-08 2008-12-18 Univ Nagoya 車載通信システム、車載通信装置及び車載通信方法
JP2009088915A (ja) * 2007-09-28 2009-04-23 Sony Corp 無線送信装置、無線送信方法、無線通信システム及びプログラム
JP2009540688A (ja) * 2006-06-05 2009-11-19 クゥアルコム・インコーポレイテッド 無線通信システム内でビームフォーミングフィードバックを提供する方法および装置
JP2010515320A (ja) * 2006-12-27 2010-05-06 テレフオンアクチーボラゲット エル エム エリクソン（パブル） パケットベースのセルラーシステムにおける送信時間および受信時間の適合方法
JP2010226722A (ja) * 2009-03-23 2010-10-07 Research In Motion Ltd ピギーバック方式ａｃｋ／ｎａｃｋビットマップと共にアップリンクデータブロックを割り当て、伝送するシステムおよび方法
JP2011518500A (ja) * 2008-04-04 2011-06-23 クゥアルコム・インコーポレイテッド 無線ローカルエリアネットワーク（ｗｌａｎ）における遅延ブロック肯定応答のための方法及び装置
JP2012015996A (ja) * 2010-05-18 2012-01-19 Intel Corp ダウンリンクマルチユーザ多入力多出力ネットワークにおいて応答をスケジューリングする方法および装置
JP2012517780A (ja) * 2009-02-12 2012-08-02 クゥアルコム・インコーポレイテッド 無線通信システムにおける多元接続互換性のためのデータ送信の受信成功を通知する方法および装置
JP2014050034A (ja) * 2012-09-03 2014-03-17 Nippon Hoso Kyokai <Nhk> 無線通信装置及びプログラム
JP2014195280A (ja) * 2009-01-29 2014-10-09 Qualcomm Incorporated 無線ローカルエリアネットワーク（ｗｌａｎ）の拡張された逆方向許可のための方法および装置
WO2017094331A1 (ja) * 2015-11-30 2017-06-08 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US20170331587A1 (en) 2014-12-01 2017-11-16 Lg Electronics Inc. Method and device for recovering error without retransmission of data frame in wireless lan
JPWO2017043189A1 (ja) * 2015-09-11 2018-06-28 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US10771199B2 (en) 2008-04-02 2020-09-08 Qualcomm Incorporated Methods and apparatus for reverse link acknowledgement in a wireless local area network (WLAN)
WO2021006064A1 (ja) * 2019-07-10 2021-01-14 ソニー株式会社 無線通信装置および方法
WO2022145058A1 (ja) * 2020-12-28 2022-07-07 日本電信電話株式会社 送信局及び受信局
WO2022144961A1 (ja) * 2020-12-28 2022-07-07 日本電信電話株式会社 送信局及び受信局
WO2022163265A1 (ja) * 2021-01-27 2022-08-04 ソニーグループ株式会社 通信装置、及び通信方法

Families Citing this family (105)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8630168B2 (en) * 2003-06-23 2014-01-14 Intel Corporation Adaptive use of a transmit opportunity
US7065144B2 (en) * 2003-08-27 2006-06-20 Qualcomm Incorporated Frequency-independent spatial processing for wideband MISO and MIMO systems
US8472473B2 (en) * 2003-10-15 2013-06-25 Qualcomm Incorporated Wireless LAN protocol stack
US8284752B2 (en) * 2003-10-15 2012-10-09 Qualcomm Incorporated Method, apparatus, and system for medium access control
US8462817B2 (en) 2003-10-15 2013-06-11 Qualcomm Incorporated Method, apparatus, and system for multiplexing protocol data units
US8842657B2 (en) * 2003-10-15 2014-09-23 Qualcomm Incorporated High speed media access control with legacy system interoperability
US9226308B2 (en) 2003-10-15 2015-12-29 Qualcomm Incorporated Method, apparatus, and system for medium access control
US8233462B2 (en) * 2003-10-15 2012-07-31 Qualcomm Incorporated High speed media access control and direct link protocol
US8483105B2 (en) 2003-10-15 2013-07-09 Qualcomm Incorporated High speed media access control
US20050165946A1 (en) * 2003-12-22 2005-07-28 Intel Corporation Bi-directional wireless LAN channel access
US8903440B2 (en) * 2004-01-29 2014-12-02 Qualcomm Incorporated Distributed hierarchical scheduling in an ad hoc network
JP4086304B2 (ja) * 2004-04-23 2008-05-14 株式会社東芝 通信装置、通信システム、および通信制御プログラム
US7826438B1 (en) * 2004-04-26 2010-11-02 Marvell International Ltd. Circuits, architectures, systems, methods, algorithms and software for reducing contention and/or handling channel access in a network
US7564814B2 (en) * 2004-05-07 2009-07-21 Qualcomm, Incorporated Transmission mode and rate selection for a wireless communication system
JP4012172B2 (ja) * 2004-05-28 2007-11-21 株式会社東芝 無線通信装置及び無線通信方法
US8401018B2 (en) * 2004-06-02 2013-03-19 Qualcomm Incorporated Method and apparatus for scheduling in a wireless network
JP4440037B2 (ja) * 2004-08-11 2010-03-24 株式会社東芝 通信装置及び通信方法
JP4889646B2 (ja) 2004-10-12 2012-03-07 アウェア， インコーポレイテッド 電気通信環境における資源の共有
JP4130648B2 (ja) * 2004-10-19 2008-08-06 株式会社東芝 通信装置および通信方法
JP4834072B2 (ja) * 2005-03-07 2011-12-07 クゥアルコム・インコーポレイテッド ワイヤレスパケットネットワークのためのブロック肯定応答プロトコル
US8830846B2 (en) * 2005-04-04 2014-09-09 Interdigital Technology Corporation Method and system for improving responsiveness in exchanging frames in a wireless local area network
JP4364165B2 (ja) * 2005-06-17 2009-11-11 株式会社東芝 無線通信装置
US8600336B2 (en) 2005-09-12 2013-12-03 Qualcomm Incorporated Scheduling with reverse direction grant in wireless communication systems
US8619658B2 (en) 2005-09-21 2013-12-31 Interdigital Technology Corporation Method and apparatus for transmission management in a wireless communication system
KR100615139B1 (ko) * 2005-10-18 2006-08-22 삼성전자주식회사 무선통신 시스템에서 전송 시간 구간의 할당 방법과 장치및 그 시스템
DE102005049931B4 (de) * 2005-10-19 2009-04-09 Atmel Germany Gmbh Sende-/Empfangsvorrichtung
US20070115821A1 (en) * 2005-10-26 2007-05-24 Samsung Electro-Mechanics Co., Ltd. Method for transmitting wireless data using piggyback
JP2009515401A (ja) * 2005-11-04 2009-04-09 ノキア コーポレイション マルチキャスト及び／又は同報肯定応答機構
US7904777B2 (en) * 2006-01-24 2011-03-08 Samsung Electronics Co., Ltd. Method and system for generating block acknowledgements in wireless communications
JP4542997B2 (ja) * 2006-02-08 2010-09-15 株式会社東芝 無線通信装置及び無線通信方法
US8125941B2 (en) * 2006-03-28 2012-02-28 Intel Corporation Wireless communication device and method for communicating voice over a wireless network using bidirectional multiple receiver aggregation
US7769044B2 (en) * 2006-03-29 2010-08-03 Cisco Technology, Inc. Voice over internet protocol favoring aggregating technology in a WLAN
EP2178254B1 (en) * 2006-04-12 2017-02-08 TQ Delta, LLC Packet retransmission and memory sharing
WO2007131347A1 (en) 2006-05-11 2007-11-22 Nortel Networks Limited Media access control protocol for multi-hop network systems and method therefore
CN101449541B (zh) * 2006-05-30 2013-05-29 艾利森电话股份有限公司 用于减少在通信网络中发送的消息量的方法和装置
JP5131194B2 (ja) * 2006-09-05 2013-01-30 日本電気株式会社 パケット回復方法、通信システム、情報処理装置およびプログラム
GB0619769D0 (en) * 2006-10-06 2006-11-15 Siemens Ag Variable length coding
US20080130538A1 (en) * 2006-12-05 2008-06-05 Qualcomm Incorporated Enhanced management frame aggregation in a wireless network system
US8879448B2 (en) * 2006-12-22 2014-11-04 Samsung Electronics Co., Ltd. Apparatus for controlling power of WiMedia media access control device and method using the same
JP4284353B2 (ja) * 2006-12-26 2009-06-24 株式会社東芝 無線通信装置
JP4888396B2 (ja) * 2007-03-05 2012-02-29 ソニー株式会社 無線通信システム、無線通信装置及び無線通信方法、並びにコンピュータ・プログラム
GB2463584B (en) * 2007-04-27 2012-02-01 Kode Biotech Ltd Carbohydrate-lipid constructs and their use in preventing or treating viral infection
US8223790B1 (en) * 2007-04-30 2012-07-17 Avaya Inc. Method and apparatus performing no back-off forwarding
US7826429B2 (en) * 2007-06-19 2010-11-02 Intel Corporation Transmit and receive transition accelerator
CN101374265B (zh) * 2007-08-21 2012-01-11 华为技术有限公司 Tfi的分配方法、反馈信息的区分方法及装置
CN102299778B (zh) * 2007-08-21 2014-02-19 华为技术有限公司 反馈方法、反馈信息的区分方法及装置
JP2009278354A (ja) * 2008-05-14 2009-11-26 Sony Corp 通信装置、通信方法、プログラム、および通信システム
US8730878B2 (en) * 2008-08-20 2014-05-20 Qualcomm Incorporated Power and resource efficient APPDU based approach with scheduled block ACKS for WLAN
US8706878B1 (en) 2008-08-21 2014-04-22 United Services Automobile Association Preferential loading in data centers
CN101841512A (zh) * 2009-03-20 2010-09-22 天际微芯(北京)科技有限公司 Eoc网络中标识上下行通信的方法
JP5316208B2 (ja) 2009-05-08 2013-10-16 ソニー株式会社 通信装置及び通信方法、コンピューター・プログラム、並びに通信システム
KR101534865B1 (ko) 2009-06-23 2015-07-27 엘지전자 주식회사 링크 적응 절차 수행 방법
JP5378525B2 (ja) 2009-09-04 2013-12-25 株式会社東芝 通信システム及び無線機
EP2299768A1 (en) * 2009-09-18 2011-03-23 Electronics and Telecommunications Research Institute Data transmission apparatus and method in wireless communication system
JP2011109252A (ja) * 2009-11-13 2011-06-02 Canon Inc 通信装置、通信装置の制御方法およびプログラム
CN102726093B (zh) * 2010-02-02 2016-08-03 马维尔国际贸易有限公司 通信设备中的节电特征
KR101764888B1 (ko) * 2010-02-16 2017-08-16 한국전자통신연구원 광대역 근거리 무선 통신 장치 및 방법
KR101758909B1 (ko) * 2010-02-18 2017-07-18 엘지전자 주식회사 무선 랜에서 수신 확인 전송 방법 및 장치
US8867459B2 (en) * 2010-03-08 2014-10-21 Broadcom Corporation Mobile subscriber information transmission over multiple uplink frames
US9236975B2 (en) * 2010-03-08 2016-01-12 Broadcom Corporation Mobile subscriber information transmission over multiple uplink frames
US10033485B2 (en) * 2010-08-25 2018-07-24 Qualcomm Incorporated Managing acknowledgement messages from multiple destinations for multi user MIMO transmissions
US8855088B2 (en) 2010-12-22 2014-10-07 Intel Corporation Reverse protocol for low latency wireless applications
KR101237454B1 (ko) * 2011-02-24 2013-02-26 서울대학교산학협력단 무선 네트워크에서 ａｃｋ의 전송기회를 이용한 데이터 전송 방법
US9438384B2 (en) * 2011-03-08 2016-09-06 Qualcomm Incorporated Providing multiple retransmission policies for a single data stream by mapping differentiated services code point (DSCP) bit fields to media access control protocol data unit (MPDU) bit fields
US20130034061A1 (en) * 2011-08-02 2013-02-07 Broadcom Corporation Reverse direction protocol implementation
JP5713844B2 (ja) * 2011-08-25 2015-05-07 株式会社東芝 無線通信装置及び干渉回避方法
US20130230059A1 (en) 2011-09-02 2013-09-05 Qualcomm Incorporated Fragmentation for long packets in a low-speed wireless network
US9179476B2 (en) * 2011-10-11 2015-11-03 Qualcomm Incorporated Multi-user transmission during reverse direction grant
US9516524B2 (en) * 2011-10-25 2016-12-06 Mediatek, Inc. Transmitter assisted quality of service measurement
US9445438B2 (en) * 2011-10-28 2016-09-13 Qualcomm Incorporated Systems and methods for fast initial network link setup
US8873494B2 (en) 2011-10-28 2014-10-28 Qualcomm Incorporated Systems and methods for fast initial network link setup
US9191977B2 (en) 2011-10-28 2015-11-17 Qualcomm Incorporated Systems and methods for fast initial network link setup
US9402243B2 (en) 2011-10-28 2016-07-26 Qualcomm Incorporated Systems and methods for fast initial network link setup
US9271317B2 (en) * 2011-10-28 2016-02-23 Qualcomm Incorporated Systems and methods for fast initial network link setup
US9814085B2 (en) 2011-10-28 2017-11-07 Qualcomm, Incorporated Systems and methods for fast initial network link setup
US9338732B2 (en) 2011-10-28 2016-05-10 Qualcomm Incorporated Systems and methods for fast initial network link setup
KR101603450B1 (ko) * 2011-12-09 2016-03-14 엘지전자 주식회사 무선랜 시스템에서 프레임 송신 및 수신 방법과 이를 지원하는 장치
US9363707B2 (en) 2011-12-29 2016-06-07 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
CN103188146B (zh) * 2011-12-31 2017-04-26 华为技术有限公司 一种连续数据包的发送、接收方法和装置
US8948089B2 (en) * 2012-01-11 2015-02-03 Intel Corporation Device, system and method of communicating aggregate data units
US20130223338A1 (en) 2012-02-29 2013-08-29 Qualcomm Incorporated Apparatus and methods for block acknowledgment compression
US9253290B2 (en) 2012-02-29 2016-02-02 Qualcomm Incorporated Apparatus and methods for block acknowledgment compression
US8832515B2 (en) 2012-02-29 2014-09-09 Qualcomm Incorporated Block acknowledgement mechanism including sequence number acknowledgement and retry bit
US8971247B2 (en) * 2012-05-25 2015-03-03 Qualcomm Incorporated Methods, devices, and systems for efficient retransmission communications
US10178582B2 (en) * 2012-08-06 2019-01-08 Qualcomm Incorporated Apparatus and methods for frame control design
US20140146736A1 (en) * 2012-11-28 2014-05-29 Electronics And Telecommunications Research Institute Method of grouping stations in multi-transmission
US9781627B2 (en) 2013-04-08 2017-10-03 Qualcomm Incorporated Systems and methods for generating and decoding short control frames in wireless communications
US9492741B2 (en) 2013-05-22 2016-11-15 Microsoft Technology Licensing, Llc Wireless gaming protocol
US20150036673A1 (en) * 2013-07-30 2015-02-05 Qualcomm Incorporated Systems and methods for communicating multi-destination traffic in a wireless network
US9907070B2 (en) * 2013-11-22 2018-02-27 Qualcomm Incorporated Channel access deferral mechanism
KR101761529B1 (ko) * 2014-01-02 2017-07-25 엘지전자 주식회사 무선랜에서 상향링크 프레임을 전송하는 방법 및 장치
EP3127281A4 (en) * 2014-03-29 2017-12-13 Intel IP Corporation Methods and arrangements for power efficient reverse direction communications
KR101708977B1 (ko) * 2014-08-28 2017-02-21 영남대학교 산학협력단 무선랜의 패킷 처리장치 및 그 방법
US10045367B2 (en) 2014-10-03 2018-08-07 Qualcomm Incorporated Uplink data fragmentation for multi-user networks
US9775170B2 (en) * 2014-12-04 2017-09-26 Intel Corporation Apparatus, system and method of allocation using a frame
EP3289713A1 (en) 2015-04-29 2018-03-07 Interdigital Patent Holdings, Inc. Triggered transmission opportunity and multiple user ack procedures in wlan systems
US20170201298A1 (en) * 2016-01-11 2017-07-13 Intel Corporation Multiuser multiple-input and multiple-output setup frame
JP6699205B2 (ja) * 2016-02-02 2020-05-27 ソニー株式会社 基地局装置、通信端末、通信システム、プログラム、フレーム送信方法およびデータ構造
US9900871B1 (en) * 2017-01-05 2018-02-20 Lg Electronics Inc. Method for transmitting uplink frame in wireless LAN system and wireless device using the same
EP4243550A1 (en) 2017-01-09 2023-09-13 Wilus Institute of Standards and Technology Inc. Wireless communication method using txop and wireless communication terminal using same
US11510197B2 (en) * 2019-02-07 2022-11-22 Plantronics, Inc. Systems and methods for managing wireless packet communications by assigning separate resources for sequential transmission attempts
US11750329B2 (en) * 2020-01-04 2023-09-05 Nxp Usa, Inc. Apparatus and method for block acknowledgement management in multi-link communication systems
WO2021140651A1 (ja) * 2020-01-10 2021-07-15 日本電信電話株式会社 端末、基地局、通信方法及び通信プログラム
CN114070475A (zh) * 2020-07-31 2022-02-18 华为技术有限公司 比特块的发送方法及装置
CN114765897A (zh) * 2021-01-13 2022-07-19 华为技术有限公司 一种通信方法及装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9304636D0 (en) * 1993-03-06 1993-04-21 Ncr Int Inc A method of accessing a communication system
US6327254B1 (en) 1997-10-14 2001-12-04 Lucent Technologies Inc. Method for bandwidth sharing in a multiple access system for communications networks
US7031287B1 (en) * 2000-07-14 2006-04-18 At&T Corp. Centralized contention and reservation request for QoS-driven wireless LANs
US7352770B1 (en) * 2000-08-04 2008-04-01 Intellon Corporation Media access control protocol with priority and contention-free intervals
US20020159418A1 (en) 2000-11-02 2002-10-31 Sharp Laboratories Of America, Inc. Quality of service using wireless lan
WO2003005644A1 (fr) 2001-07-06 2003-01-16 Sharp Kabushiki Kaisha Procede et programme de gestion de telecommunications, support d'enregistrement contenant le programme de gestion de telecommunications, systeme et appareil de telecommunications et appareil de gestion centrale
US20030135640A1 (en) * 2002-01-14 2003-07-17 Texas Instruments Incorporated Method and system for group transmission and acknowledgment
US8483105B2 (en) * 2003-10-15 2013-07-09 Qualcomm Incorporated High speed media access control
JP4005974B2 (ja) * 2004-01-09 2007-11-14 株式会社東芝 通信装置、通信方法、および通信システム
JP4047836B2 (ja) 2004-04-02 2008-02-13 株式会社東芝 通信装置、通信システム、通信方法、および通信制御プログラム
US7463642B2 (en) * 2004-04-07 2008-12-09 Cisco Technology, Inc. Multiple receiver aggregation
JP4086304B2 (ja) 2004-04-23 2008-05-14 株式会社東芝 通信装置、通信システム、および通信制御プログラム
JP4012172B2 (ja) 2004-05-28 2007-11-21 株式会社東芝 無線通信装置及び無線通信方法
US8401018B2 (en) * 2004-06-02 2013-03-19 Qualcomm Incorporated Method and apparatus for scheduling in a wireless network
JP4440037B2 (ja) 2004-08-11 2010-03-24 株式会社東芝 通信装置及び通信方法
US7474676B2 (en) * 2004-09-10 2009-01-06 Mitsubishi Electric Research Laboratories, Inc. Frame aggregation in wireless communications networks
JP4130648B2 (ja) 2004-10-19 2008-08-06 株式会社東芝 通信装置および通信方法
JP4364165B2 (ja) 2005-06-17 2009-11-11 株式会社東芝 無線通信装置
JP4284353B2 (ja) 2006-12-26 2009-06-24 株式会社東芝 無線通信装置

Cited By (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009540688A (ja) * 2006-06-05 2009-11-19 クゥアルコム・インコーポレイテッド 無線通信システム内でビームフォーミングフィードバックを提供する方法および装置
US8542589B2 (en) 2006-06-05 2013-09-24 Qualcomm Incorporated Method and apparatus for providing beamforming feedback in wireless communication systems
JP2008160551A (ja) * 2006-12-25 2008-07-10 Toshiba Corp 無線通信装置
JP2010515320A (ja) * 2006-12-27 2010-05-06 テレフオンアクチーボラゲット エル エム エリクソン（パブル） パケットベースのセルラーシステムにおける送信時間および受信時間の適合方法
JP2008227700A (ja) * 2007-03-09 2008-09-25 Oki Electric Ind Co Ltd 無線通信システム、無線通信装置及び送信権調停方法
JP2008270951A (ja) * 2007-04-17 2008-11-06 Mitsubishi Electric Corp データ通信装置
US8448035B2 (en) 2007-06-08 2013-05-21 National University Corporation Nagoya University Communication system adapting for car, communication apparatus adapting for car, and communication method adapting for car
JP2008306592A (ja) * 2007-06-08 2008-12-18 Univ Nagoya 車載通信システム、車載通信装置及び車載通信方法
JP2009088915A (ja) * 2007-09-28 2009-04-23 Sony Corp 無線送信装置、無線送信方法、無線通信システム及びプログラム
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)
JP2011518500A (ja) * 2008-04-04 2011-06-23 クゥアルコム・インコーポレイテッド 無線ローカルエリアネットワーク（ｗｌａｎ）における遅延ブロック肯定応答のための方法及び装置
JP2014195280A (ja) * 2009-01-29 2014-10-09 Qualcomm Incorporated 無線ローカルエリアネットワーク（ｗｌａｎ）の拡張された逆方向許可のための方法および装置
JP2012517780A (ja) * 2009-02-12 2012-08-02 クゥアルコム・インコーポレイテッド 無線通信システムにおける多元接続互換性のためのデータ送信の受信成功を通知する方法および装置
US8804611B2 (en) 2009-02-12 2014-08-12 Qualcomm Incorporated Method and apparatus for acknowledging successful reception of a data transmission for multi-access compatibility in a wireless communication system
JP2010226722A (ja) * 2009-03-23 2010-10-07 Research In Motion Ltd ピギーバック方式ａｃｋ／ｎａｃｋビットマップと共にアップリンクデータブロックを割り当て、伝送するシステムおよび方法
JP2012257307A (ja) * 2009-03-23 2012-12-27 Research In Motion Ltd ピギーバック方式ａｃｋ／ｎａｃｋビットマップと共にアップリンクデータブロックを割り当て、伝送するシステムおよび方法
US8855063B2 (en) 2010-05-18 2014-10-07 Intel Corporation Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network
JP2012015996A (ja) * 2010-05-18 2012-01-19 Intel Corp ダウンリンクマルチユーザ多入力多出力ネットワークにおいて応答をスケジューリングする方法および装置
US9661648B2 (en) 2010-05-18 2017-05-23 Intel Corporation Method and apparatus for response scheduling in a downlink multiple-user multiple input multiple output network
JP2014050034A (ja) * 2012-09-03 2014-03-17 Nippon Hoso Kyokai <Nhk> 無線通信装置及びプログラム
US10530524B2 (en) 2014-12-01 2020-01-07 Lg Electronics Inc. Method and device for recovering error without retransmission of data frame in wireless LAN
US20170331587A1 (en) 2014-12-01 2017-11-16 Lg Electronics Inc. Method and device for recovering error without retransmission of data frame in wireless lan
JP2018504015A (ja) * 2014-12-01 2018-02-08 エルジー エレクトロニクス インコーポレイティド 無線ｌａｎにおけるデータフレームの再送信なしにエラーを回復する方法及び装置
JPWO2017043189A1 (ja) * 2015-09-11 2018-06-28 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
JPWO2017094331A1 (ja) * 2015-11-30 2018-09-13 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
WO2017094331A1 (ja) * 2015-11-30 2017-06-08 ソニー株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
JP7031308B2 (ja) 2015-11-30 2022-03-08 ソニーグループ株式会社 情報処理装置、通信システム、情報処理方法およびプログラム
US11659439B2 (en) 2015-11-30 2023-05-23 Sony Corporation Information processing apparatus, communication system, information processing method, and program
US11805442B2 (en) 2015-11-30 2023-10-31 Sony Corporation Information processing apparatus, communication system, information processing method, and program
WO2021006064A1 (ja) * 2019-07-10 2021-01-14 ソニー株式会社 無線通信装置および方法
US11882483B2 (en) 2019-07-10 2024-01-23 Sony Group Corporation Wireless communication device and method for multi band operations (MBO)
WO2022145058A1 (ja) * 2020-12-28 2022-07-07 日本電信電話株式会社 送信局及び受信局
WO2022144964A1 (ja) * 2020-12-28 2022-07-07 日本電信電話株式会社 送信局及び受信局
WO2022144961A1 (ja) * 2020-12-28 2022-07-07 日本電信電話株式会社 送信局及び受信局
WO2022163265A1 (ja) * 2021-01-27 2022-08-04 ソニーグループ株式会社 通信装置、及び通信方法

Also Published As

Publication number Publication date
CN101610260B (zh) 2013-05-29
JP4331088B2 (ja) 2009-09-16
US20060092871A1 (en) 2006-05-04
US20100189056A1 (en) 2010-07-29
US8274992B2 (en) 2012-09-25
CN1770774A (zh) 2006-05-10
CN101610260A (zh) 2009-12-23

Similar Documents

Publication Publication Date Title
JP4331088B2 (ja) 通信装置および通信方法
JP4440037B2 (ja) 通信装置及び通信方法
JP4086304B2 (ja) 通信装置、通信システム、および通信制御プログラム
JP4130648B2 (ja) 通信装置および通信方法
JP4047836B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
KR101451247B1 (ko) 무선 근거리 통신망에서 멀티캐스트 데이터의 수신 확인 및 재전송을 위한 방법 및 장치
KR101482087B1 (ko) 무선 근거리 통신망에서 멀티캐스트 수신 확인의 요청 및 수신 확인의 전송을 위한 장치
JP4528541B2 (ja) 通信装置、通信方法、および通信システム
JP4374001B2 (ja) 通信装置、通信方法、および通信システム
JP4444237B2 (ja) 無線通信装置
JP4314294B2 (ja) 通信装置、通信システム、通信方法、および通信制御プログラム
JP4543049B2 (ja) 通信装置および通信装置の通信方法
WO2012130092A1 (zh) 一种用于帧确认的方法和装置

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20080128

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080407

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080916

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20081117

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090526

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090617

R151 Written notification of patent or utility model registration

Ref document number: 4331088

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120626

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120626

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130626

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250