JP2017502564A - 拡張ブロック確認応答プロトコル - Google Patents

拡張ブロック確認応答プロトコル Download PDF

Info

Publication number
JP2017502564A
JP2017502564A JP2016533164A JP2016533164A JP2017502564A JP 2017502564 A JP2017502564 A JP 2017502564A JP 2016533164 A JP2016533164 A JP 2016533164A JP 2016533164 A JP2016533164 A JP 2016533164A JP 2017502564 A JP2017502564 A JP 2017502564A
Authority
JP
Japan
Prior art keywords
wireless device
transmission rate
frame
block acknowledgment
acknowledgment bitmap
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.)
Pending
Application number
JP2016533164A
Other languages
English (en)
Other versions
JP2017502564A5 (ja
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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2017502564A publication Critical patent/JP2017502564A/ja
Publication of JP2017502564A5 publication Critical patent/JP2017502564A5/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/1607Details of the supervisory signal
    • H04L1/1614Details of the supervisory signal using bitmaps
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0001Systems modifying transmission characteristics according to link quality, e.g. power backoff
    • H04L1/0015Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
    • H04L1/0019Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy in which mode-switching is based on a statistical approach
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements 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/18Automatic repetition systems, e.g. Van Duuren systems
    • H04L1/1825Adaptation of specific ARQ protocol parameters according to transmission conditions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00Arrangements affording multiple use of the transmission path
    • H04L5/003Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053Allocation of signaling, i.e. of overhead other than pilot signals
    • H04L5/0055Physical resource allocation for ACK/NACK
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management
    • H04W72/04Wireless resource allocation
    • H04W72/044Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446Resources in time domain, e.g. slots or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • H04W84/02Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/10Small scale networks; Flat hierarchical networks
    • H04W84/12WLAN [Wireless Local Area Networks]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Quality & Reliability (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

第1のワイヤレスデバイスから第2のワイヤレスデバイスに送られるべきブロック確認応答(BA)フレームのためのブロック確認応答ビットマップのサイズを選択するための方法は、第2のワイヤレスデバイスから受信されたいくつかのデータフレームの送信レートを決定することと、決定された送信レートに少なくとも部分的に基づいてブロック確認応答ビットマップのサイズを選択することと、選択されたサイズのブロック確認応答ビットマップが埋め込まれたBAフレームを第2のワイヤレスデバイスに送信することとを含む。【選択図】図4A

Description

本実施形態は、一般にワイヤレスネットワークに関し、より詳細には、ワイヤレスネットワークにおけるブロック確認応答に関する。
[0002]ワイヤレスローカルエリアネットワーク(WLAN)は、いくつかのクライアントデバイスまたは局(STA)が使用する共有ワイヤレス通信媒体を与える1つまたは複数のアクセスポイント(AP)によって形成され得る。基本サービスセット(BSS)に対応し得る各APは、APのワイヤレス範囲内のSTAがWLANとの通信リンクを確立および/または維持することを可能にするために、ビーコンフレームを周期的にブロードキャストする。STAがAPに関連付けられると、APとSTAとはデータフレームを交換し得る。STAがAPからデータフレームを受信したとき、STAは、データフレームの受信を確認応答するために確認応答(ACK)フレームをAPに返信する。
[0003]ブロック確認応答プロシージャは、STAが単一のACKフレームを使用して複数のデータフレームの受信を確認応答することを可能にし得る。より詳細には、STAは、複数のデータフレームおよび/またはいくつかのアグリゲートされたデータフレームの受信を確認応答するために1つのブロック確認応答(BA)フレームを使用し、それによって、APに送信される確認応答フレームの数を低減(およびしたがって共有ワイヤレス媒体の容量を節約)し得る。より詳細には、ブロック確認応答プロシージャが断片化(fragmentation)を使用しないとき、複数のアグリゲートされたデータフレームを確認応答するために圧縮ブロック確認応答(CBA:compressed block acknowledgement)フレームが使用され得る。CBAフレームは、最高64個の個々のデータフレームの受信を確認応答するために使用され得る(たとえば、8*8=64ビットを含んでいる)8オクテットのビットマップを含む。CBAフレームのビットマップを64ビットに制限することによって、CBAフレームの送信持続時間は、ワイヤレス媒体上のトラフィックを低減するために(たとえば、非圧縮BAフレームと比較して)最小限に抑えられ得る。
[0004]WLANに関連するワイヤレス媒体の容量に悪影響を及ぼすことなしに、単一のBAフレームを用いて確認応答され得るデータフレームの数を増加させることが望ましいであろう。
[0005]本実施形態は、例として示されており、添付の図面の図によって限定されるものではなく、ここで、図面の全体にわたって、同様の参照番号は対応する部分を指す。
本実施形態の少なくともいくつかが実装され得るWLANシステムのブロック図。 いくつかの実施形態によるワイヤレス局(STA)のブロック図。 基本(たとえば、比較的低い)送信レートを使用するワイヤレスデバイス間のフレームの例示的な交換を示すシーケンス図。 いくつかの実施形態による、高速(たとえば、比較的高い)送信レートを使用するワイヤレスデバイス間のフレームの例示的な交換を示すシーケンス図。 いくつかの実施形態による、ブロック確認応答ビットマップのサイズを選択するための例示的な動作を示す例示的なフローチャート。 いくつかの実施形態による、他のワイヤレスデバイスから受信されたフレームの送信レートを決定するための例示的な動作を示す例示的なフローチャート。 いくつかの実施形態による、拡張ブロック確認応答(EBA:extended block acknowledgement)フレームの例示的なサイズと、様々な送信レートについてのそれらの対応する送信持続時間を示す図。 様々なサイズのブロック確認応答ビットマップを含むブロック確認応答フレームのための例示的な送信レートおよび送信持続時間を示す図。 いくつかの実施形態による、応答EBAフレームおよびデュアルEIFSトランケーション(truncation)を用いる例示的なフレーム交換を示すシーケンス図。 いくつかの実施形態による、応答EBAフレームおよびシングルEIFSトランケーションを用いる例示的なフレーム交換を示すシーケンス図。 いくつかの実施形態による、応答EBAフレーム、シングルEIFSトランケーション、およびEBAフレームの後のEIFS持続時間を用いる例示的なフレーム交換を示すシーケンス図。 他の実施形態による、応答EBAフレーム、シングルEIFSトランケーション、およびEBAフレームの後のEIFS持続時間を用いる例示的なフレーム交換を示すシーケンス図。 応答EBAフレーム、RTS送信による第1のEIFSトランケーション、およびCTS送信による第2のEIFSトランケーションを用いる例示的なフレーム交換を示すシーケンス図。 いくつかの実施形態による、ワイヤレスチャネルへのアクセスを延期するための例示的な動作を示す例示的なフローチャート。
[0020]本開示の例示的な実施形態について、単に簡単のために、Wi−Fi(登録商標)対応デバイス間のデータ交換のコンテキストにおいて以下で説明する。実施形態は、他の様々なワイヤレス規格またはプロトコルの信号を使用するデータ交換に等しく適用可能であることを理解されたい。本明細書で使用する「WLAN」および「Wi−Fi」という用語は、IEEE802.11規格ファミリー、BLUETOOTH(登録商標)(Bluetooth(登録商標))、HiperLAN(主に欧州で使用される、IEEE802.11規格に類似のワイヤレス規格のセット)、および比較的短い電波伝搬距離を有する他の技術によって管理される通信を含むことができる。さらに、本明細書ではワイヤレスデバイス間でデータフレームを交換することに関して説明するが、本実施形態は、ワイヤレスデバイス間の任意のデータユニット、パケット、および/またはフレームの交換に適用され得る。したがって、「データフレーム」という用語は、たとえば、プロトコルデータユニット(PDU)、MACプロトコルデータユニット(MPDU)、および物理レイヤ・コンバージェンスプロシージャプロトコルデータユニット(PPDU)など、任意のフレーム、パケット、またはデータユニットを含み得る。「A−MPDU」という用語はアグリゲートされたMPDUを指すことがある。さらに、本明細書で使用する「圧縮ブロック確認応答(CBA:compressed block acknowledgement)フレーム」は、8バイトまたはオクテットのブロック確認応答ビットマップを含むBAフレームを指すことがあり、「拡張ブロック確認応答(EBA:extended block acknowledgement)フレーム」という用語は、8バイトまたはオクテットよりも大きい(たとえば、32バイト、64バイト、128バイトなどの)ブロック確認応答ビットマップを含むBAフレームを指すことがある。
[0021]以下の説明では、本開示の完全な理解を与えるために、特定の構成要素、回路、およびプロセスの例など、多数の具体的な詳細を記載する。本明細書で使用する「結合された」という用語は、直接接続されていること、または1つまたは複数の介在する構成要素もしくは回路を介して接続されていることを意味する。また、以下の説明では、説明のために、本実施形態の完全な理解を与えるために具体的な名称を記載する。ただし、これらの具体的な詳細は、実施形態を実行するために必要でないことがあることが当業者には明らかであろう。他の事例では、本開示を不明瞭にしないように、よく知られている回路およびデバイスをブロック図の形式で示す。本実施形態は、本明細書で説明する具体的な例に限定されるものと解釈されるべきではなく、むしろ添付の特許請求の範囲によって規定されたすべての実施形態をそれらの範囲内に含む。
[0022]上述のように、現在のWi−Fi規格は、ワイヤレスデバイス(たとえば、STAおよび/またはAP)が、単一のブロック確認応答(BA)フレームを使用して複数のデータフレームまたはアグリゲートされたデータフレームを確認応答することを可能にする。たとえば、圧縮ブロック確認応答(CBA)フレームは、一般に、最高8*8=64個のデータフレームの受信を確認応答し得る8オクテットのブロック確認応答ビットマップを含んでいる。したがって、CBAフレームのブロック確認応答ビットマップ中の各ビットは、64個のフレームのうちの対応する1個が受信されたかどうかを示し得る(たとえば、ここで、ブロック確認応答ビットマップ中の各ビットは、対応するデータフレームのステータス(たとえば、成功/失敗)を表す)。
[0023]ワイヤレスデバイスのペアが互いのデータ送信を確認応答するためにBAフレームを使用するより前に、ワイヤレスデバイスは、最初に、能力情報(capability information)(たとえば、バッファサイズおよびブロック確認応答ポリシー)がその間に互いにネゴシエートされ得るブロック確認応答セットアップフェーズに入る。セットアップフェーズが完了すると、ワイヤレスデバイスは、次いで、個々のACKフレームを待つことなしに互いに複数のフレームを送り得、代わりに、受信ワイヤレスデバイスは、単一のBAフレームを使用して複数のデータフレームの受信を確認応答し得る。ブロック確認応答アグリーメントは、他のワイヤレスデバイスにブロック確認応答削除(DELBA:Delete Block Acknowledgment)フレームを送ることによってティアダウン(たとえば、終了)され得る。
[0024]上述のように、各BAフレームがより多数のデータフレームを確認応答し得るように、より大きいブロック確認応答ビットマップをBAフレーム中に埋め込むことが望ましいことがある。たとえば、ブロック確認応答ビットマップのサイズを8バイトから32バイトに増加させることは、単一のBAフレームが最高32*8=256個のデータフレームの受信を確認応答することを可能にし得る。ブロック確認応答ビットマップ中のビット数を増加させることは、BAフレームの全体的サイズを増加させ、したがって、BAフレームの送信持続時間(たとえば、あるワイヤレスデバイスから別のワイヤレスデバイスにBAフレームを送信することに関連する信号伝搬時間)をも増加させ得る。BAフレームの送信持続時間を増加させることは、IEEE802.11規格ファミリーの1つまたは複数の適用可能な規定に準拠しないので望ましくないことがある。
[0025]したがって、いくつかの実施形態によれば、ワイヤレスデバイスは、ワイヤレスデバイス間の送信レートまたはリンクスピードに少なくとも部分的に基づいて、BAフレームのブロック確認応答ビットマップのサイズを増加させ得る。たとえば、ワイヤレスデバイス間の送信レートが、8バイトを有するブロック確認応答ビットマップを基本送信レートで送信することに関連するのと同様の時間量において、より大きいブロック確認応答ビットマップ(たとえば、8バイトよりも多くのバイトを有するブロック確認応答ビットマップ)を送信するのに十分高い場合、ワイヤレスデバイスは、増加したブロック確認応答ビットマップサイズを有する拡張ブロック確認応答(EBA)フレームを採用し得る。このようにして、ワイヤレスデバイスは、BAフレーム送信持続時間を増加させることなしに、より大きいブロック確認応答ビットマップをBAフレーム中に埋め込み得る。そうではなく、データフレームの送信レートが十分高くない(たとえば、しきい値以下の)場合、ワイヤレスデバイスは、8バイトのブロック確認応答ビットマップを有するCBAフレームを使用し続け得る。
[0026]したがって、本実施形態によれば、ワイヤレスデバイスは、最高n*8個のデータフレームの確認応答を可能にするnオクテットのブロック確認応答ビットマップを有するEBAフレームを利用し得、ただし、nは、ワイヤレスデバイス間の送信レートまたはリンクスピードに少なくとも部分的に基づき得る整数である。少なくともいくつかの実施形態では、EBAフレームは、ワイヤレスデバイスが最高32*8=256個のデータフレームを確認応答することを可能にする32オクテットのブロック確認応答ビットマップを含み得る。本実施形態のこれらおよび他の態様について以下でより詳細に説明する。
[0027]図1は、いくつかの実施形態が実装され得る例示的なワイヤレスネットワークシステム100のブロック図である。システム100は、3つのワイヤレス局STA1〜STA3(単に説明の目的で3つ示されている)と、ワイヤレスアクセスポイント(AP)110と、ワイヤレスローカルエリアネットワーク(WLAN)120とを含むように示されている。WLAN120は、IEEE802.11規格ファミリーに従って(または他の好適なワイヤレスプロトコルに従って)動作し得る複数のAPによって形成され得る。したがって、簡単のために、ただ1つのAP110が図1に示されているが、WLAN120は、AP110など、任意の数のアクセスポイントによって形成され得ることを理解されたい。追加としてまたは代替として、STA1〜STA3のうちの2つまたはそれ以上は、(たとえば、AP110を使用せずに)たとえば、ピアツーピアまたはアドホックネットワークを使用して互いと通信し得る。
[0028]AP110は、たとえば、アクセスポイントの製造業者によって、その中にプログラムされる一意のMACアドレスを割り当てられる。同様に、STA1〜STA3の各々も一意のMACアドレスを割り当てられる。一般に「バーンドイン(burned-in)アドレス」または組織固有識別子(OUI:organizationally unique identifier)と呼ばれることがある各MACアドレスは、一実施形態では6バイトのデータを含む。MACアドレスの第1の3バイトは、どの組織がデバイスを製造したかを識別し得、電気電子技術者協会(IEEE)によってそのような組織に割り当てられ得る。MACアドレスの第2の3バイトは、個々のデバイスを一意に識別するために使用され得る。
[0029]局STA1〜STA3は、たとえば、ネットワーク対応センサー、メモリタグ(RFIDタグ)、スマートメーター、セルフォン、携帯情報端末(PDA)、タブレットデバイス、ラップトップコンピュータなどを含む、任意の好適なWi−Fi対応ワイヤレスデバイスであり得る。少なくともいくつかの実施形態では、局STA1〜STA3は、トランシーバと、1つまたは複数の処理リソースと、1つまたは複数のメモリリソースと、電源(たとえば、バッテリー)とを含み得る。メモリリソースは、図4A、図4B、および図6に関して以下で説明する動作を実行するための命令を記憶する非一時的コンピュータ可読媒体(たとえば、EPROM、EEPROM(登録商標)、フラッシュメモリ、ハードドライブなど、1つまたは複数の不揮発性メモリ要素)を含み得る。
[0030]AP110は、1つまたは複数のワイヤレスデバイスが、Wi−Fi、WiMax(登録商標)、Bluetooth、または他の好適なワイヤレス通信規格を使用してAP110を介してネットワーク(たとえば、LAN、WAN、MAN、および/またはインターネット)に接続することを可能にする、任意の好適なデバイスであり得る。少なくとも1つの実施形態では、AP110は、ネットワークインターフェースと、1つまたは複数の処理リソースと、1つまたは複数のメモリソースとを含み得る。メモリリソースは、図4A、図4B、図6、および図8に関して以下で説明する動作を実行するための命令を記憶する非一時的コンピュータ可読媒体(たとえば、EPROM、EEPROM、フラッシュメモリ、ハードドライブなど、1つまたは複数の不揮発性メモリ要素)を含み得る。
[0031]図2に、図1の局STA1〜STA3のうちの少なくとも1つの一実施形態であるSTA200を示す。STA200は、アンテナ210と、トランシーバ220と、プロセッサ230と、メモリ240とを含む。トランシーバ220は、アンテナ210を介してAP110および/または他のSTA(図1も参照)に信号を送信し、それから信号を受信するために使用され得る。さらに、トランシーバ220は、よく知られているアクティブおよび/またはパッシブスキャニング技法を使用して近くのアクセスポイント(たとえば、STA200の範囲内のアクセスポイント)および/または他のSTAを検出し、識別するために、周囲環境を走査するために使用され得る。簡単のために図2にはただ1つのアンテナが示されているが、実際の実施形態では、STA200は、たとえば、多入力多出力(MIMO)機能を与えるために任意の数のアンテナを含み得る。
[0032]メモリ240は、データフレーム送信レート(たとえば、PHYレート)と、データフレームを1つまたは複数の他のワイヤレスデバイスに送信するために使用される変調およびコーディング方式(MCS:modulation and coding scheme)との間のいくつかのマッピングを記憶する送信レートルックアップテーブル242を含み得る。たとえば、送信レートルックアップテーブル242は、各々が、対応するデバイスのためのMCSと送信レートとを含む、複数の記憶ロケーションを含み得る。これは、STA200が、データフレームのヘッダからMCS情報を抽出し、次いで、抽出されたMCS情報を、対応する(1つまたは複数の)データフレームの送信レートを調べる(ルックアップする)探索鍵として使用することによって、(1つまたは複数の)受信されたデータフレームの送信レートを決定することを可能にし得る。いくつかの実施形態では、送信レートルックアップテーブル242はプリポピュレート(たとえば、所定のMCS送信レートマッピングをロード)され得る。他の実施形態では、STA200は、MCS送信レートマッピングを送信レートルックアップテーブル242に動的に記憶し得る。
[0033]メモリ240はまた、以下のソフトウェアモジュールを記憶し得る非一時的コンピュータ可読媒体(たとえば、EPROM、EEPROM、フラッシュメモリ、ハードドライブなど、1つまたは複数の不揮発性メモリ要素)を含み得る。
・たとえば、図4Aの動作401、402、および408について、および/または図6の動作601、602、および610について説明するように、フレーム(たとえば、データフレーム、ACKフレーム、BAフレーム、要求フレーム、応答フレーム、ビーコンフレーム、管理フレーム、アソシエーション(関連付け)フレーム、制御フレーム、アクションフレーム、管理フレームなど)の作成および/または交換を可能にするためのフレーム交換ソフトウェアモジュール244、
・たとえば、図4Aの動作404、図4Bの動作411〜412について、および/または図6の動作604について説明するように、(たとえば、送信レートルックアップテーブル242からそのような情報を取り出すことによって、または受信されたデータフレーム中に埋め込まれたMCS情報から送信レートを外挿することによって)1つまたは複数の受信されたデータフレームの送信レートを決定するための送信レート決定ソフトウェアモジュール246、
・たとえば、図4Aの動作406について、および/または図6の動作606および608について説明するように、BAフレーム内に埋め込まれるべきブロック確認応答ビットマップのサイズを選択するためのビットマップ選択ソフトウェアモジュール248、および
・たとえば、図8の動作802、804、806、808、および810について説明するように、ワイヤレスチャネルへのアクセスを選択的に延期するためのチャネルアクセス延期ソフトウェアモジュール249。
各ソフトウェアモジュールは、プロセッサ230によって実行されたとき、対応する機能をSTA200に実行させ得る命令を含む。
[0034]トランシーバ220とメモリ240とに結合されたプロセッサ230は、STA200に(たとえば、メモリ240内に)記憶された1つまたは複数のソフトウェアプログラムのスクリプトまたは命令を実行することが可能な任意の好適なプロセッサであり得る。たとえば、プロセッサ230は、様々なタイプのフレームの作成および/または1つまたは複数の他のワイヤレスデバイスとのそれらのフレームの交換を可能にするためのフレーム交換ソフトウェアモジュール244を実行し得る。プロセッサ230はまた、他のワイヤレスデバイスから受信された1つまたは複数のフレームの送信レートを決定するための送信レート決定ソフトウェアモジュール246を実行し得る。プロセッサ230はまた、1つまたは複数の他のワイヤレスデバイスに送られるブロック確認応答フレーム(たとえば、CBAフレームまたはEBAフレームのいずれか)内に埋め込まれるべきブロック確認応答ビットマップのサイズを選択するためのビットマップ選択ソフトウェアモジュール248を実行し得る。
[0035]図3Aに、第1のワイヤレスデバイス(DEV1)と第2のワイヤレスデバイス(DEV2)との間の第1のフレーム交換300を示す。本明細書での説明の目的で、DEV1は任意の好適なワイヤレスデバイス(たとえば、図1のAP110またはSTAのうちの1つ)であり得、DEV2は任意の好適なワイヤレスデバイス(たとえば、図1のSTAのうちの別のもの)であり得る。DEV1は、いくつかの基本PHY送信レートのうちの1つを使用して複数のデータフレーム301をDEV2に送信する。たとえば、802.11規格ファミリーは、現在、準拠ワイヤレスデバイスが6Mbps、12Mbps、および24Mbpsの基本送信レートをサポートすることを規定している。図3Aに示された例示的なフレーム交換300では、DEV1は、24Mbpsの基本送信レートでデータフレーム301を送信する。DEV2がデータフレーム301を受信したとき、DEV2は、データフレーム301の受信を確認応答するために、基本送信レートのうちの1つで(たとえば、24Mbpsで)CBAフレーム302をDEV1に送る。
[0036]以下で表1に示すように、CBAフレーム302は、一般に、フレーム制御(fc)のための2バイト、仮想キャリア検知持続時間(dur)のための2バイト、受信機アドレス(ra)のための6バイト、送信機アドレス(ta)のための6バイト、ブロック確認応答制御(bac)のための2バイト、ブロック確認応答開始シーケンス制御(bassc)のための2バイト、ブロック確認応答ビットマップ(bab)のための8バイト、およびフレーム検査シーケンス(fcs)のための4バイトの、合計32バイトまたはオクテットの情報を含む。上述のように、8バイトのブロック確認応答ビットマップは、最高64個のデータフレーム301の受信を確認応答するために使用され得る8*8=64ビットを含む。
Figure 2017502564
[0037]現在のWi−Fiプロトコルに従って、DEV2は、データフレーム301のそれと同じ(またはより低い)送信レートを使用してCBAフレーム302をDEV1に送信し得る。したがって、図3Aの例示的な交換300では、DEV2は、24Mbpsの基本送信レートでCBAフレーム302をDEV1に送信する。CBAフレーム302は、32バイトの情報を含んでおり、24Mbpsの基本(たとえば、比較的低い)送信レートにおいて約32μsの送信持続時間を有する。24Mbpsの基本送信レートにおいて、CBAフレーム302の8バイトのブロック確認応答ビットマップは、各々が4μsの持続時間を有する3つのデータシンボルに適合し得、PHYプロトコルデータユニット(PPDU)送信持続時間は、20μsのPHYヘッダを含めて合計32μsになることに留意されたい。したがって、いくつかの実施形態では、32μsの持続時間は、以下でより詳細に説明するように、本明細書ではEBA基準持続時間と呼ばれることがある。(たとえば、PHYデバイスの様々なタイプおよび/構成に対応する)他のPHYレートの場合、EBA基準持続時間は、32μs以外の持続時間であり得る。
[0038]本実施形態によれば、DEV2は、受信されたデータフレームの送信レートがしきい値よりも大きいとき、(たとえば、8バイトなどの比較的小さいブロック確認応答ビットマップを有するCBAフレームではなく)比較的大きいブロック確認応答ビットマップを有するEBAフレームを送ることによってDEV1からのデータフレームの受信を確認応答するように構成され得る。いくつかの実施形態では、しきい値は、EBAフレームの送信持続時間が、基本送信レートで送信されるときのCBAフレームの送信持続時間と同じである(たとえば、EBAフレームの送信持続時間がEBA基準持続時間に等しい(またはそれよりも小さい)ときの)最小送信レートとして決定され得る。そのような実施形態の場合、最小送信レート(およびしたがってしきい値)は、EBAフレームの合計サイズに少なくとも部分的に基づき、したがって、EBAフレーム中のブロック確認応答ビットマップのサイズにも少なくとも部分的に基づく。したがって、少なくともいくつかの実施形態では、EBAフレーム内に埋め込まれるブロック確認応答ビットマップのサイズは、DEV1から受信されたデータフレームの送信レートに少なくとも部分的に基づいて選択され得る。少なくとも別の実施形態では、DEV2は、DEV1から受信されたデータフレームの送信レートに少なくとも部分的に基づいて、異なる所定のBAフレーム間で(たとえば、EBAフレームまたはCBAフレームのいずれかを)選択し得る。
[0039]たとえば、EBAフレームが32バイトのブロック確認応答ビットマップを含み、したがって合計56バイトの情報を含む場合、EBAフレームは、EBAフレームの送信レートが約48Mbps〜約54Mbpsの範囲内にあるとき、約32μsでDEV1に送信され得る。したがって、次に図3Bを参照すると、DEV1から受信されたデータフレーム311が48Mbps(またはそれ以上)の比較的高い送信レートで送信されたとき、DEV2は、48Mbps(またはそれ以上)の比較的高い送信レートで32バイトのブロック確認応答ビットマップを含むEBAフレーム312をDEV1に送り得る。図3BのEBAフレーム312のための送信持続時間は、図3AのCBAフレーム302のための送信持続時間と同様であり、48Mbpsの比較的高い送信レートにおいて、EBAフレーム312の32バイトのブロック確認応答ビットマップは、各々が4μsの持続時間を有する3つのデータシンボルにぴったり合い、PHYプロトコルデータユニット(PPDU)送信持続時間は、20μsのPHYヘッダを含めて合計32μsになることに留意されたい。
[0040]32バイトのブロック確認応答ビットマップは、DEV1から受信された最高32*8=256個のデータフレーム311を確認応答するために使用され得る。したがって、DEV2が、8バイトのブロック確認応答ビットマップを含むCBAフレーム302の代わりに、32バイトのブロック確認応答ビットマップを含むEBAフレーム312を送信することが可能であるとき、DEV2は、図3AのCBAフレーム302の4倍の数(たとえば、64*4=256個)のデータフレームを確認応答するために図3BのEBAフレーム312を使用し得る。
[0041]ワイヤレスデバイスDEV2は、任意の好適な技法を使用して、受信されたデータフレーム311の送信レートを決定し得る。少なくともいくつかの実施形態では、DEV2は、1つまたは複数のデータフレームを含んでいるPPDUまたはA−MPDUのPHYヘッダ中に埋め込まれたMCS情報を抽出することによって、受信されたデータフレーム311の送信レートを決定し得る。データフレームの送信レートは、抽出されたMCS情報から外挿(または場合によっては導出)され得る。代替的に、DEV2は、図2の送信レートルックアップテーブル242を含み、送信レートルックアップテーブル242から対応する送信レートを取り出すために、抽出されたMCS情報を探索鍵として使用し得る。
[0042]いくつかの実施形態では、EBAフレーム312の送信レートは、受信されたデータフレーム311の送信レートよりも大きい(たとえば、基本送信レート/MCSセット以外である)ことがある。他の実施形態では、EBAフレーム312の送信レートは、受信されたデータフレーム311の送信レートよりも低いことがあり、その場合、DEV2は、EBAフレーム312を送信すべきなのかCBAフレーム302を送信すべきなのかを決定するとき、EBAフレーム312の予測される送信レートを使用し得る。しかしながら、EBAフレーム312の送信レートは、EBAフレームの送信持続時間が(1つのデータシンボルをもつ最短パケット持続時間である)24μsよりも小さくなることを防ぐために、何らかの上限値(たとえば、65Mbps)で上限を定め得ることに留意されたい。
[0043]ACKフレームの送信持続時間に少なくとも部分的に基づいて、受信されたデータフレームを、CBAフレームを使用して確認応答すべきなのかEBAフレームを使用して確認応答すべきなのかを決定することによって、(データフレームのPHY部分のみを符号化し得る)サードパーティSTAは、EBAフレームとCBAフレームとの等しい送信持続時間に起因する、起こり得る隠れた(hidden)応答フレーム送信のために延期すべき適切な時間を決定することが可能であり得る。
[0044]図4Aは、いくつかの実施形態による、ブロック確認応答ビットマップのサイズを選択するための例示的な動作400を示す例示的なフローチャートである。少なくとも1つの実施形態では、動作400は、第1のワイヤレスデバイス(DEV1)から第2のワイヤレスデバイス(DEV2)に送られた多数のフレームを、CBAフレームを使用して確認応答すべきなのかEBAフレームを使用して確認応答すべきなのかを決定するために使用され得る。DEV2は、DEV1からいくつかのデータフレームを受信し(402)、データフレームの送信レートを決定する(404)。次いで、DEV2は、決定された送信レートに少なくとも部分的に基づいてブロック確認応答ビットマップのサイズを選択する(406)。
[0045]たとえば、DEV2は、送信レートがしきい値よりも小さいかまたはそれに等しいとき、(たとえば、CBAフレームに一致する)ブロック確認応答ビットマップの比較的小さいサイズを選択し(406A)、送信レートがしきい値よりも大きいとき、(たとえば、EBAフレームに関連する)ブロック確認応答ビットマップの比較的大きいサイズを選択する(406B)。いくつかの実施形態では、比較的小さいサイズは整数Sとして示されることがあり、比較的大きいサイズは、Sの値の少なくとも2倍である整数Lとして示されることがある。
[0046]DEV2は、選択されたサイズのブロック確認応答ビットマップをBAフレーム中に埋め込む(408)。次いで、DEV2は、選択されたサイズのブロック確認応答ビットマップを含むBAフレームをDEV1に送信する(408)。ブロック確認応答ビットマップは、DEV2が、単一のBAフレームを使用して多数のフレーム(またはアグリゲートされたフレーム)を確認応答することを可能にし、ここにおいて、ブロック確認応答ビットマップの各ビットは、DEV1によって送信された複数のデータフレームのうちの対応する1つの受信を確認応答するためのものである。
[0047]図4Bは、いくつかの実施形態による、他のワイヤレスデバイスから受信されたフレームの送信レートを決定するための例示的な動作410を示す例示的なフローチャートである。最初に、DEV2は、受信されたデータフレームのうちの1つのヘッダから変調およびコーディング方式(MCS)を抽出する(411)。次いで、DEV2は、抽出されたMCSに少なくとも部分的に基づいて、受信されたデータフレームの送信レートを決定する(412)。少なくとも1つの実施形態では、DEV2は、MCSから探索鍵を生成し(412A)、MCS値と送信レートとの間のいくつかのマッピングを記憶するルックアップテーブルに探索鍵を与え(412B)、探索鍵に少なくとも部分的に基づいて、ルックアップテーブルから決定された送信レートを取り出す(412C)ことによって送信レート送信レートを決定し得る。
[0048]再び図3Aを参照すると、他の実施形態では、DEV2は、比較的大きいブロック確認応答ビットマップが、データフレームがDEV1からDEV2に送られた送信レートよりも小さいかまたはそれに等しい送信レートにおいて選択された数N個のデータシンボル内に適合(fit)することができる場合、(たとえば、比較的小さいブロック確認応答ビットマップを含んでいるCBAフレームではなく)比較的大きいブロック確認応答ビットマップを含んでいるEBAフレームを送ることによって、DEV1からのデータフレームの受信を確認応答するように構成され得、ここにおいて、Nは、1よりも大きいかまたはそれに等しい整数である。より詳細には、そのような他の実施形態のうちの少なくとも1つでは、DEV2は、DEV1に送信されるべきEBAフレームの選択された数N個のデータシンボル内に適合することができる最大ブロック確認応答ビットマップを選択するように構成され得る。EBAフレームの送信レートは、DEV1とDEV2との間のリンクが非対称性質を呈するときにデータフレームの送信レートよりも大きいことがあることに留意されたい。
[0049]いくつかの実施形態では、DEV2は、(たとえば、受信されたデータフレームのうちの1つまたは複数内に与えられたMCS情報を復号することによって)データフレームがDEV1からDEV2に送信された送信レートを決定し、次いで、DEV1に応答フレームを送信するための最高可能応答MCSを選択するために、決定された送信レートを使用し得る。最高可能応答MCSにおいて、DEV2は、選択された数N個のデータシンボル中で送信され得る最大応答MPDUサイズを決定し得る。最大応答MPDUサイズに少なくとも部分的に基づいて、DEV2は、選択された数N個のデータシンボル中で送信され得る最大ブロック確認応答ビットマップを決定し得る。決定された最大ブロック確認応答ビットマップに少なくとも部分的に基づいて、DEV2は、決定された最大ブロック確認応答ビットマップをもつ応答BAフレームがちょうど選択された数N個のデータシンボルを含んでいる応答MCSを決定し得る。より一般的には、デバイスは、選択されたMCSにおいて、最高で選択された数N個のシンボル中で送信され得る最大可能ブロック確認応答ビットマップを選択し、次いで、BAフレームがちょうど選択された数N個のデータシンボルを含んでいるようなMCSにおいて、選択されたブロック確認応答ビットマップをもつBAフレームを送信し得る。
[0050]BAフレームの選択された数のデータシンボル内に適合(fit)し得るブロック確認応答ビットマップの最大サイズを選択するための例示的な動作について図5の例示的なフローチャート500に関して以下で説明する。第2のデバイス(DEV2)が、第1のデバイス(DEV1)からいくつかのデータフレームを受信し(502)、データフレームの送信レートを決定する(504)。次いで、DEV2は、ブロック確認応答ビットマップが第1のワイヤレスデバイスにその内で送信され得るデータシンボルの数Nを選択する(506)。次に、DEV2は、選択された数N個のデータシンボル内に適合することができるブロック確認応答ビットマップの最大サイズを決定する(508)。
[0051]いくつかの実施形態では、DEV2は、DEV1に応答フレームを送信するための最高可能応答MCSを選択するために、決定された送信レートを使用し得る。最高可能応答MCSにおいて、DEV2は、選択された数N個のデータシンボル中でDEV1に送信され得る最大応答MPDUサイズを決定し得る。最大応答MPDUサイズに少なくとも部分的に基づいて、DEV2は、選択された数N個のデータシンボル中でDEV1に送信され得る最大ブロック確認応答ビットマップサイズを決定し得る。決定された最大ブロック確認応答ビットマップに少なくとも部分的に基づいて、DEV2は、決定された最大ブロック確認応答ビットマップをもつBAフレームがちょうど選択された数N個のデータシンボルを含んでいる応答MCSを決定し得る。
[0052]次いで、DEV2は、決定された最大サイズのブロック確認応答ビットマップを含むBAフレームを送信する(510)。
[0053]最大可能ブロック確認応答ビットマップを含んでいるBAフレームを第1のワイヤレスデバイスに送信することによって、第2のワイヤレスデバイスは、単一のブロック確認応答フレームを使用して、最大可能数の受信されたデータフレームを確認応答し得、これは、データフレームの受信を確認応答するために必要とされるACKフレームの数を低減し得る。
[0054]上記で説明した動作は、以下のような応答ルールとして定義され得る。
1.EBAをサポートするリンク上で応答としてBAフレームを送信するSTAは、そのリンク上でサポートされる最長可能EBAフレームをPPDUに合わせるものとし、当該PPDUは、EBA基準持続時間に等しい送信持続時間を有し、また、応答を要求し、PPDUと同じチャネル帯域幅を有するMPDUを含んでいるPPDUのデータレートよりも小さいかまたはそれに等しいデータレートを有するPHYモードを使用する。EBA基準持続時間は、A−MPDU中でEBAフレームを送信することによって、EOFパディングを追加することによって、および/またはEBAフレームの複数のインスタンスをA−MPDUに含めることによって決定され得る。このようにして、応答ルールは、あらゆる応答EBAフレームが動的EIFS持続時間と同じ送信持続時間を有するようにし得る。
2.応答EBAフレームを受信したSTAは、受信されたEBAフレームに応答してACKまたは他のMPDUを送信するものとする。このようにして、EBAフレームの送信によって開始されるEIFS持続時間は、ACKフレームまたは他のMPDUを受信したデバイスにおいてトランケートされる(is truncated)。
[0055]いくつかの実施形態では、受信されたPPDUのMAC部分を復号する問題があるとき、受信デバイスがDCFフレーム間スペース(DIFS)持続時間の代わりに拡張フレーム間スペース(EIFS:extended interframe space)持続時間を使用することを防ぐために、(以下でEIFSルールとして示される)新しいルールが使用され得る。たとえば、現在のIEEE802.11プロトコルによれば、(たとえば、フレーム中のエラーのために)受信されたフレームの1つまたは複数の部分を復号することができない受信デバイスは、それのバックオフを、DIFS持続時間ではなくEIFS持続時間だけ延期する。これは、あり得るACKフレームが受信デバイスからの干渉なしに送信されることを可能にする。一般に、EIFS持続時間は、(最低基本送信レートにおける)ACKフレームの送信持続時間+SIFS持続時間+DIFS持続時間に等しい。
[0056]したがって、少なくともいくつかの実施形態では、新しいEIFSルールは、選択された数N個のデータシンボルをもつPPDUが受信デバイスによって受信された場合、受信デバイスは、BAフレームの1つまたは複数の部分が受信デバイスによって復号され得ない場合でも、EIFS持続時間に従ってBAフレームの送信を延期しないことがあることを定め得る。このようにして、EIFS持続時間ではなくDIFS持続時間を使用することによってアイドル送信期間が低減され得る。より一般的には、基本MCS/レートまたはPHY必須MCS/レートで送信されたCBAフレームの持続時間に等しい持続時間を有するPPDUが受信された場合(たとえば、PPDUの送信持続時間がEBA基準持続時間に等しい(またはそれよりも小さい)場合)、EIFS持続時間はDIFS持続時間まで低減され得る。したがって、応答が要求されないフレーム(たとえば、ブロックACKフレーム)がそれらの持続時間のみを使用するとき、応答が要求されないこれらのフレームは周囲のデバイスにおいてEIFSを開始させないことになり、これは、そのフレームの後に予想される応答がない(たとえば、EIFS保護が必要とされない)ので望ましい。たとえば、24Mbps OFDMにおけるCBAフレームの持続時間は32μsであり、これは、上述のようにEBA基準持続時間と呼ばれることがある。
[0057]したがって、送信持続時間32μsのPPDUが受信された場合、EIFS持続時間(万一必要とされる場合)がDIFS持続時間に低減され得、CBAフレームよりも大きいBAフレームは、BAフレームの送信持続時間がちょうど32μsになるようなMCS/レートで送信される。ショートフレームが送信されるべきであり、しかも受信デバイスから応答フレームが予想される場合、送信デバイスは、ショートフレームをパディングし得、その結果得られるパディングされたPPDUが選択された数N個のデータシンボルを含んでいないように(たとえば、パディングされたPPDUがN個よりも多いデータシンボルを含んでいるように)し得る。ショートフレームは、たとえば、ゼロ長を示すMPDUデリミタおよび/またはフレーム終了(EOF)デリミタを含む、任意の好適な技法を使用してパディングされ得る。
[0058]他の実施形態では、EBAフレームのサイズと同じサイズのMPDUを含んでいるPPDUのみが、DIFS持続時間ではなくEIFS持続時間を使用することを(新しいEIFSルールによって)防がれ得る。いくつかの例示的なEBAフレームサイズ(たとえば、MPDUサイズ)を以下で表2に示す。
Figure 2017502564
[0059]さらに、図6に、EBAフレームの例示的なサイズと、様々な送信レートについてのそれらの対応する送信持続時間とを示す表600を示す。
[0060]いくつかの実施形態では、EBAフレームは、CBAフレームのフォーマットを使用して、および、CBAフレームに通常関連付けられるものよりも大きいビットマップをフレームが含むことを示すためにBAフレームのバリアント(変形)符号化(variant encoding)の予約済み値を割り当てて、形成され得る。たとえば、以下の表3に、32バイトのブロック確認応答ビットマップを含むEBAフレームのための例示的なフォーマットを示す。
Figure 2017502564
[0061]ブロックACKフレームバリアントのための例示的な符号化を以下で表4に示す。
Figure 2017502564
[0062]例示的な表4に示されているように、符号化値「111」は、EBAフレームフォーマットを示すために使用され得、符号化値「100」は、拡張CBAフレームフォーマットを示すために使用され得る。拡張CBAフレームフォーマットは、フロー制御情報が追加されることを除いてCBAフレームフォーマットと同じである。値「100」は、本明細書で説明するEBAフレームフォーマットと混同されるべきでない。
[0063]ブロック確認応答ビットマップの長さは、以下で表5に示すように、ブロックACK制御(bac)フィールドの1つまたは複数の予約済みビットに符号化され得る。
Figure 2017502564
[0064]ブロック確認応答ビットマップの長さはまた、ブロック確認応答制御(bac)フィールドのビットマップサイズフィールド中のビットを使用して符号化され得る。ビットマップサイズフィールドの例示的な値およびブロック確認応答ビットマップの対応するサイズを以下で表6に示す。
Figure 2017502564
[0065]表5に示された例示的なマッピングに従って、ブロック確認応答ビットマップサイズSはS=32*2bとして表され得、ここにおいて、bはビットマップサイズフィールド値を示す。たとえば、32バイト、64バイト、128バイト、および256バイトのブロック確認応答ビットマップサイズは、それぞれ0、1、2、および3に等しいbによって示され得る。
[0066]対応するEBAフレームおよび送信持続時間を図6に示す。(たとえば、S=32*2bのサイズによって定義された)サイズ32バイト、128バイト、512バイト、および2048バイトのブロック確認応答ビットマップがそのようなEBAフレームの(たとえば、32μsの送信持続時間によって示される)3つのデータシンボルに適合し得るPHYレートは、図6に示されているように、それぞれ48Mbps、63Mbps、103Mbps、および188Mbpsにほぼ等しい。
[0067]様々なブロック確認応答ビットマップサイズについて、EBAフレームのブロック確認応答ビットマップが3つのデータシンボル内に適合(fit)し得る送信レート(たとえば、PHYレート)は互いに比較的近いので、様々なブロック確認応答ビットマップ間のサイズの差を増加させることが可能であり得る。たとえば、(上記で表5に示したように)ブロック確認応答ビットマップサイズをS=32*2bとして定義する代わりに、ブロック確認応答ビットマップサイズはS=32*4bとして表され得る。したがって、これは、以下で表7に示すように、それぞれ0、1、2、および3に等しいbの値について32バイト、128バイト、512バイト、および2048バイトのブロック確認応答ビットマップサイズを示し得る。
Figure 2017502564
[0068](たとえば、S=32*4bのサイズによって定義された)サイズ32バイト、128バイト、512バイト、および2048バイトのブロック確認応答ビットマップがEBAフレームの3つのデータシンボルに適合(fit)し得るPHYレートは、それぞれ48Mbps、103Mbps、359Mbps、および1383Mbpsにほぼ等しい。対照的に、(たとえば、32*2bのサイズによって定義された)サイズ32バイト、64バイト、128バイト、および256バイトのブロック確認応答ビットマップがそのようなEBAフレームの3つのデータシンボルに適合し得るPHYレートは、それぞれ48Mbps、63Mbps、103Mbps、および188Mbpsにほぼ等しい。
[0069]少なくともいくつかの実施形態では、以下で表8に示すように、BAフレームバリアント符号化に関連する符号化値「101」は、フロー制御(fc)拡張をもつEBAフォーマットを代わりに示し得る。
Figure 2017502564
[0070]ブロック確認応答ビットマップサイズは、フロー制御(fc)をもつEBAフレームフォーマットの場合、および/またはフロー制御をもたないEBAフレームフォーマットの場合、ブロックアクセス制御(bac)フィールド中に符号化され得ることに留意されたい。
[0071]他の実施形態では、拡張ブロック確認応答フレームは、表9に示すように、圧縮ブロックAckフレームまたは拡張圧縮ブロックAckフレームのブロックACK制御(bac)フィールドにビットマップサイズフィールドを追加することによって圧縮ブロックAckフレームバリアント内で定義される。
Figure 2017502564
[0072]圧縮ブロックAckフレームまたは拡張圧縮ブロックAckフレームのブロック確認応答制御(bac)フィールドの新たに定義されたビットマップサイズフィールドを使用して符号化されたブロック確認応答ビットマップの例示的な長さを表10に示す。
Figure 2017502564
[0073]いくつかの実施形態では、ビットマップサイズフィールドの値0は、必ずしも8オクテットのブロック確認応答ビットマップのために予約済みであるとは限らない。この値は、既存の圧縮ブロックAckフレームまたは拡張圧縮ブロックAckフレームにマッピングされ得る。
[0074]上述のように、本明細書で開示するEIFSルールは、受信されたデータフレームのMAC部分を復号する問題があるとき、受信デバイスがDCFフレーム間スペース(DIFS)持続時間の代わりに拡張フレーム間スペース(EIFS)持続時間を使用することを防ぐために使用され得る。少なくともいくつかの実施形態では、ワイヤレスデバイスは、チャネルを介して受信されたデータフレームの送信持続時間を決定し得る。受信されたデータフレームの送信持続時間が指定された持続時間に等しい場合(たとえば、受信されたデータフレームの送信持続時間がEBAフレーム基準持続時間に等しい場合)、ワイヤレスデバイスは、チャネルにアクセスすることを延期するためにEIFS持続時間を使用することを防がれ得る。少なくとも1つの他の実施形態では、ワイヤレスデバイスは、受信されたデータフレームの送信持続時間が何らかの指定された持続時間よりも小さい場合、チャネルにアクセスすることを延期するためにEIFS持続時間を使用することを防がれ得る。
[0075]別の実施形態では、ワイヤレスデバイスは、データフレームを送信するために使用されるデータシンボルの数を決定し得る。データシンボルの数が指定された数に等しい場合、ワイヤレスデバイスは、チャネルにアクセスすることを延期するためにEIFS持続時間を使用することを防がれ得る。別の実施形態では、A−MPDUを送信すべきであるワイヤレスデバイスは、指定されたMCSにおいてA−MPDUを送信するために必要とされるデータシンボルの数を決定し得る。ワイヤレスデバイスは、データシンボルの数が指定された数に等しい場合、A−MPDUに1つまたは複数のゼロ長MPDUデリミタを追加することによって(たとえば、指定されたMCSにおいて拡張A−MPDUを送信するために必要とされるデータシンボルの数が指定された数を超えるように)拡張A−MPDUを形成し得る。
[0076]別の実施形態では、A−MPDUを送信すべきであるワイヤレスデバイスは、指定されたMCSにおいてA−MPDUを送信するために必要とされるデータシンボルの数を決定し得る。ワイヤレスデバイスは、次いで、データシンボルの数が指定された数に等しいかまたはそれよりも小さい場合、A−MPDUに1つまたは複数のゼロ長MPDUデリミタを追加することによって(たとえば、指定されたMCSにおいて拡張A−MPDUを送信するために必要とされるデータシンボルの数が指定された数を超えるように)拡張A−MPDUを形成し得る。
[0077]上述のように、いくつかの実施形態は、(たとえば、32μsなどのEBA基準持続時間に等しい)指定された送信持続時間を有する応答EBAフレームを受信したデバイスが、応答フレームのMAC部分を復号する問題があるとき、媒体アクセスを通常EIFS持続時間だけ延期することを防ぐEIFSルールを定義し得る。いくつかの実施形態では、EBAフレームであるように見えるものの後のEIFS時間はDIFS時間に等しいと定義され得る。これは、EBAフレームの後に応答フレームが送信されない場合を捕捉する。
[0078]他の実施形態では、受信デバイスは、SIFS持続時間の後にACKフレームを送信することによって、EBAフレームに応答した媒体アクセス延期のためのEIFS持続時間をトランケートし得る。たとえば、図7Aに、いくつかの実施形態による、応答EBAフレームおよびデュアルEIFSトランケーション(truncation)を用いる例示的なフレーム交換を示すシーケンス図710を示す。最初に、DEV1は、65Mbpsの送信レートでA−MPDUをDEV2に送信する。DEV2は、A−MPDUを受信し、SIFS持続時間の後に、48Mbpsで応答EBAフレームをDEV1に送信する。EBAフレームは、この例ではEBA基準持続時間に等しい32μsの送信持続時間を有し、したがって、EIFSルールが適用可能であり得る。しかしながら、EBAフレーム中にエラーがあるとき、EIFS持続時間を開始するか、またはEIFS持続時間をDIFS持続時間に短縮するのではなく、DEV2は、SIFS持続時間の間のみ待ち、次いで、(たとえば、6Mbpsの最低基本送信レートで)ACKフレームを送信し得る。
[0079]同時に、SIFS持続時間の後に、DEV1は、(たとえば、6Mbpsの最低基本送信レートで)ACKフレームを送信し得る。DEV1によって送信されるACKフレームとDEV2によって送信されるACKフレームとは同じコンテンツ(たとえば、PHYヘッダ中の同じスクランブラシードおよび同じ受信機アドレス)を含み得る。受信機アドレスは、設定された規約に応じてDEV1またはDEV2のMACアドレスに等しいことがある。少なくとも1つの実施形態では、両方のACKフレーム中のMACヘッダの持続時間フィールドは値0に設定され得る。ACKフレームの代わりに、DEV1および/またはDEV2は、アドレスフィールド、持続時間フィールドおよびスクランブラシードのための同じ値をもつCF−Endフレームを送信し得、その場合、保留中のネットワーク割振りベクトル(NAV:Network Allocation Vector)がトランケートされ(truncated)得る。
[0080]最低基本レートでのACKフレームの送信は、DEV1およびDEV2に近接した(たとえば、DEV1およびDEV2のワイヤレス範囲内の)他のデバイスに、(たとえば、ACKフレームは検査されたフレームチェックシーケンス(FCS)を含むので)ACKフレームを受信した後にEIFS持続時間を開始させないようにし得る。このようにして、SIFS持続時間の後のDEV1および/またはDEV2からのACKフレームの送信は、そのような他の近接したデバイスのEIFS持続時間を本質的にトランケートし、それによって、ワイヤレス媒体のアイドル時間と潜在的不当チャネルアクセスとをさらに最小限に抑え得る。
[0081]DEV2が、DEV1にEBAフレームを送信することによってDEV1からのA−MPDUの受信を確認応答する場合、DEV1とDEV2とが互いに比較的近い可能性がある。さらに、DEV1とDEV2とが互いに比較的近い(たとえば、互いからのしきい値距離よりも小さい距離にある)場合、DEV1およびDEV2に近接した他のデバイスがDEV1から送信されたフレームを受信し、それに応答することが可能であり得る。その結果、他の実施形態では、DEV1のみが、EBAフレームに応答して開始されたSIFS持続時間の後にACKフレームを送信し得る。たとえば、図7Bに、いくつかの実施形態による、応答EBAフレームおよびシングルEIFSトランケーションを用いるフレーム交換を示すシーケンス図720を示す。(図7Aのシーケンス図710と比較して)図7Bのシーケンス図720の1つの利点は、DEV1が、応答EBAフレームを送信することの後のSIFS持続時間のみの後に媒体へのアクセスを獲得し得るので、65Mbpsで送信されたA−MPDUフレームのためにシグナリングが必要とされないことである。ACKフレームの代わりに、DEV1は、NAVを同じくトランケートするためにCF−Endフレームを送信し得る。
[0082]図7Cに、いくつかの実施形態による、応答EBAフレーム、シングルEIFSトランケーション、およびEBAフレームの後のEIFS持続時間を用いるフレーム交換730を示すシーケンス図を示す。図7Cに示されたフレーム交換は、図7Bのフレーム交換と同様であるが、図7Aに示されたフレーム交換と同様の様式で対称保護を与える。より詳細には、図7Cのフレーム交換では、DEV1が、応答EBAフレーム(OFDM、HT、および/またはVHT PHYデバイスのための32μsの送信持続時間を有するPPDU)または応答フレームであるように見えるフレームを受信したとき、DEV1は、(先行するSIFSを含む)DEV1によって送信されるACKフレームの送信持続時間(TACK)+DIFS期間と同じ時間量の間持続し得るEIFS持続時間を開始する。そのような実施形態の場合、EBAフレームの持続時間フィールドは、少なくとも、SIFS持続時間+TACKに等しい時間期間のNAV持続時間を示す。
[0083]たとえば、DEV1が24Mbpsの最高基本送信レートで終了ACKフレームを送信するとき、上記で説明したEIFSルールは、デバイスが、24Mbpsよりも大きいかまたはそれに等しいデータレートで32μsの送信持続時間を有するフレームを受信したとき、EIFS持続時間は、SIFS+TACK@24Mbps+DIFSに等しい動的EIFS持続時間になると定める動的EIFSルールと置き換えられ得る。この例では、動的EIFS持続時間=16+28+34=78μsである。持続時間フィールドの値はSIFS+TACK@24Mbps=16+28=44μsとして表され得る。
[0084]6Mbpsの最低基本送信レートで送信される終了ACKフレームの場合、動的EIFSルールは、デバイスが、24Mbpsよりも大きいかまたはそれに等しいデータレートで32μsの送信持続時間を有するフレームを受信したとき、動的EIFS持続時間はSIFS+TACK@6Mbps+DIFSに等しいと定め得る。この例では、動的EIFS持続時間=16+44+34=94μsである。持続時間フィールドの値はSIFS+TACK@6Mbps=16+44=60μsとして表され得る。この例のための例示的なフレーム交換を図7Dに示す。
[0085]図7Dは、他の実施形態による、EBA応答フレーム、シングルEIFSトランケーション、およびEBAフレームの後のEIFS持続時間を用いるフレーム交換を示すシーケンス図740を示している。EBAフレームの持続時間フィールドの適切な値は、ブロックACK要求を含んでいるA−MPDUの持続時間フィールド設定にACKフレームを含めることによって与えられるかまたは割り当てられ得る。いくつかの実施形態では、図7Cおよび/または図7Dに示されたACKフレームはまたCF−Endであり得、その場合、EIFS持続時間はわずかにより長い(24Mbps CF−Endフレームの場合、EIFS=78μsであり、6Mbps CF−Endフレームの場合、EIFS=102μsである)。
[0086]持続時間値を含まないフレーム(たとえば、プロトコルバージョン1(PV1)フレーム)の場合、EIFS持続時間は、フレームのPHYヘッダがACK指示を含んでいない限り、FCSが正しく受信されたときに同じく開始されるべきであり、フレームのPHYヘッダがACK指示を含んでいる場合、EIFS持続時間(または他のアクセス延期期間)はPHYヘッダ中のACK指示に少なくとも部分的に基づき得る。PHYヘッダ中のACK指示をもたないPV1フレームの一例は、5GHz帯域においてOFDM、HT、またはVHT変調を使用して送信されるPV1フレームである。
[0087]代替実施形態では、応答EBAフレームの後に開始されるEIFS持続時間をトランケートするために、応答EBAフレームの受信側はRTS/CTSフレーム交換を開始し得、これは、(余分のRTSフレームという犠牲を払うが)本明細書で開示する動的EIFSルールを変更することなしに、EIFS持続時間を対称的にトランケートさせる。たとえば、図7Eに、さらに他の実施形態による、応答EBAフレーム、シングルEIFSトランケーション、およびEBAフレームの後のEIFS持続時間を用いるフレーム交換を示すシーケンス図750を示す。図7Eに示されているように、応答EBAフレームの送信の後に、DEV1は、SIFS持続時間を待ち、次いで、24Mbpsで(44μsの送信持続時間を有する)RTSフレームをDEV2に送信し得る。DEV2は、RTSフレームを受信し、SIFS持続時間の後に、24MbpsでCTSフレームをDEV1に送信する。RTSフレームのための動的EIFSルールがすでに定義されているので、EIFSトランケーションが実行され得る。
[0088]本明細書で説明するEIFSルールは以下のように定義され得る。PHYの最高必須非HTレートのデータレートはEBA基準レートと呼ばれる。EBA基準レートでCBAフレームを送信するために必要とされる持続時間はEBA基準持続時間と呼ばれる。たとえば、HT PHYのための最高必須非HTレートは24Mbpsであり、したがって、HTのためのEBA基準レートは24Mbpsである。24Mbpsにおいて、(32オクテットを含んでいる)CBAフレームの持続時間は32μsであり、したがって、VHTのためのEBA基準持続時間は32μsである。
[0089]さらに、デバイスにEIFS持続時間を開始させるPPDUが、EBA基準持続時間に等しい送信持続時間を有し、EBA基準レートよりも大きいデータレートを有するとき、EIFS持続時間はSIFS+TACK,est+DIFSに等しく、ただし、TACK,estは、EBA基準レートに少なくとも部分的に基づくACKフレームの推定送信持続時間である。たとえば、HT PHYの場合、EIFS持続時間は16+28+34=78μsに等しい。これは、EBA基準持続時間に等しい持続時間のPPDUが、応答ACKを送信させ得るEBAフレームである可能性が高いことを反映する。
[0090]図8に、いくつかの実施形態による、ワイヤレスチャネルへのアクセスを延期するための例示的な動作800を示す例示的なフローチャートを示す。最初に、ワイヤレスデバイスは、ワイヤレスチャネルを介して他のデバイスからアグリゲートされたデータフレームを受信し、アグリゲートされたデータフレームは1つまたは複数の復号エラーを含んでいる(802)。次いで、ワイヤレスデバイスは、アグリゲートされたデータフレームの送信持続時間を決定する(804)。ワイヤレスデバイスは、次いで、送信持続時間に少なくとも部分的に基づいて、EIFS持続時間またはDIFS持続時間のいずれかとして選択された時間期間の間チャネルへのアクセスを延期する(806)。
[0091]より詳細には、少なくともいくつかの実施形態では、ワイヤレスデバイスは、送信持続時間が指定された持続時間よりも小さいかまたはそれに等しいとき、時間期間をEIFS持続時間として選択し(806A)、送信持続時間が指定された持続時間よりも大きいとき、時間期間をDIFS持続時間として選択する(806B)。
[0092]次に、ワイヤレスデバイスは、時間期間の後に他のデバイスにブロック確認応答フレームを送信する(808)。その後、少なくともいくつかの実施形態では、ワイヤレスデバイスは、ブロック確認応答フレームを送信した後に開始されたショートフレーム間スペース(SIFS:short interframe space)持続時間の後に、他のデバイスに単一の確認応答フレームを送信する(810)。
[0093]上記の明細書では、実施形態について、それの特定の例示的な実施形態を参照しながら説明した。しかしながら、添付の特許請求の範囲に記載された本開示のより広い範囲から逸脱することなく、様々な改変および変更がそれに行われ得ることは明らかであろう。したがって、本明細書および図面は、限定的な意味ではなく例示的な意味で考慮されるべきである。

Claims (30)

  1. 第1のワイヤレスデバイスから第2のワイヤレスデバイスに送られるべきブロック確認応答(BA)フレームのためのブロック確認応答ビットマップのサイズを選択するための方法であって、
    前記第2のワイヤレスデバイスから受信されたいくつかのデータフレームの送信レートを決定することと、
    前記決定された送信レートに少なくとも部分的に基づいて、前記ブロック確認応答ビットマップの前記サイズを選択することと、
    前記第2のワイヤレスデバイスに送信されるべき前記BAフレーム中に前記ブロック確認応答ビットマップを埋め込むことと、
    を備える、方法。
  2. 前記ブロック確認応答ビットマップの前記サイズは、前記ブロック確認応答ビットマップが前記第2のワイヤレスデバイスに送信されるべきデータシンボルの数に少なくとも部分的に基づいてさらに選択される、請求項1に記載の方法。
  3. 前記選択することは、
    前記決定された送信レートがしきい値よりも小さいかまたはそれに等しい場合、前記ブロック確認応答ビットマップのために比較的小さいサイズSを選択することと、ここにおいて、Sは1よりも大きい整数であり、
    前記決定された送信レートが前記しきい値よりも大きい場合、前記ブロック確認応答ビットマップのために比較的大きいサイズLを選択することと、ここにおいて、Lは、Sの値の2倍に等しいかまたはそれよりも大きい整数である、
    を備える、請求項1に記載の方法。
  4. Sは8バイトに等しく、Lは2N*Sバイトに等しく、Nは1よりも大きい整数である、請求項3に記載の方法。
  5. 前記しきい値は、前記比較的小さいサイズの前記ブロック確認応答ビットマップが基本送信レートで前記第2のワイヤレスデバイスに送信され得るのと同じまたはより小さい送信持続時間内に、前記比較的大きいサイズの前記ブロック確認応答ビットマップが前記第2のワイヤレスデバイスに送信され得る最小送信レートを示す、請求項3に記載の方法。
  6. 前記最小送信レートは48Mbpsを備え、前記基本送信レートは12Mbpsまたは24Mbpsを備える、請求項5に記載の方法。
  7. 前記決定することは、
    前記受信されたデータフレームのうちの1つのヘッダから変調およびコーディング方式(MCS)を抽出することと、
    前記抽出されたMCSに少なくとも部分的に基づいて、前記決定された送信レートを導出することと、
    を備える、請求項1に記載の方法。
  8. 前記導出することは、
    前記MCSから探索鍵を生成することと、
    MCS値と送信レートとの間のいくつかのマッピングを記憶するルックアップテーブルから前記決定された送信レートを取り出すために前記探索鍵を使用することと、
    を備える、請求項7に記載の方法。
  9. 前記データフレームを受信することに関連する復号問題に応答して、前記第1のワイヤレスデバイスが拡張フレーム間スペース(EIFS)持続時間を採用することを防ぐこと、
    をさらに備える、請求項1に記載の方法。
  10. ワイヤレスデバイスであって、
    プロセッサと、
    前記プロセッサによって実行されたとき、前記ワイヤレスデバイスに、
    他のワイヤレスデバイスから受信されたいくつかのデータフレームの送信レートを決定することと、
    前記決定された送信レートに少なくとも部分的に基づいて、ブロック確認応答ビットマップのサイズを選択することと、
    前記他のワイヤレスデバイスに送信されるべきブロック確認応答(BA)フレーム中に前記ブロック確認応答ビットマップを埋め込むことと、
    を行わせる命令を記憶するメモリと、
    を備える、ワイヤレスデバイス。
  11. 前記ブロック確認応答ビットマップの前記サイズは、前記ブロック確認応答ビットマップが前記他のワイヤレスデバイスに送信されるべきデータシンボルの数に少なくとも部分的に基づいてさらに選択される、請求項10に記載のワイヤレスデバイス。
  12. 前記ブロック確認応答ビットマップの前記サイズを選択するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記決定された送信レートがしきい値よりも小さいかまたはそれに等しい場合、前記ブロック確認応答ビットマップのために比較的小さいサイズSを選択することと、ここにおいて、Sは1よりも大きい整数であり、
    前記決定された送信レートが前記しきい値よりも大きい場合、前記ブロック確認応答ビットマップのために比較的大きいサイズLを選択することと、ここにおいて、Lは、Sの値の2倍に等しいかまたはそれよりも大きい整数である、
    を行わせる、請求項10に記載のワイヤレスデバイス。
  13. Sは8バイトに等しく、Lは2N*Sバイトに等しく、Nは1よりも大きい整数である、請求項12に記載のワイヤレスデバイス。
  14. 前記しきい値は、前記比較的小さいサイズの前記ブロック確認応答ビットマップが基本送信レートで前記他のワイヤレスデバイスに送信され得るのと同じまたはより小さい送信持続時間内に、前記比較的大きいサイズの前記ブロック確認応答ビットマップが前記他のワイヤレスデバイスに送信され得る最小送信レートを示す、請求項12に記載のワイヤレスデバイス。
  15. 前記最小送信レートは48Mbpsを備え、前記基本送信レートは12Mbpsおよび24Mbpsからなるグループからの1つを備える、請求項14に記載のワイヤレスデバイス。
  16. 前記送信レートを決定するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記受信されたデータフレームのうちの1つのヘッダから変調およびコーディング方式(MCS)を抽出することと、
    前記抽出されたMCSに少なくとも部分的に基づいて、前記決定された送信レートを導出することと、
    を行わせる、請求項10に記載のワイヤレスデバイス。
  17. 前記決定された送信レートを導出するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記MCSから探索鍵を生成することと、
    MCS値と送信レートとの間のいくつかのマッピングを記憶するルックアップテーブルに前記探索鍵を与えることと、
    前記探索鍵に少なくとも部分的に基づいて、前記ルックアップテーブルから前記決定された送信レートを取り出すことと、
    を行わせる、請求項16に記載のワイヤレスデバイス。
  18. 前記命令の実行は、前記ワイヤレスデバイスに、
    前記データフレームを受信することに関連する復号問題に応答して、拡張フレーム間スペース(EIFS)持続時間を使用することを防ぐこと、
    をさらに行わせる、請求項10に記載のワイヤレスデバイス。
  19. ワイヤレスデバイスのプロセッサによって実行されたとき、前記ワイヤレスデバイスに、
    他のワイヤレスデバイスから受信されたいくつかのデータフレームの送信レートを決定することと、
    前記決定された送信レートに少なくとも部分的に基づいて、ブロック確認応答ビットマップのサイズを選択することと、
    前記他のワイヤレスデバイスに送信されるべきブロック確認応答(BA)フレーム中に前記ブロック確認応答ビットマップを埋め込むことと、
    を備える動作を実行させるプログラム命令を含む非一時的コンピュータ可読媒体。
  20. 前記ブロック確認応答ビットマップの前記サイズは、前記ブロック確認応答ビットマップが前記他のワイヤレスデバイスに送信されるべきデータシンボルの数に少なくとも部分的に基づいてさらに選択される、請求項19に記載の非一時的コンピュータ可読媒体。
  21. 前記ブロック確認応答ビットマップの前記サイズを選択するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記決定された送信レートがしきい値よりも小さいかまたはそれに等しい場合、前記ブロック確認応答ビットマップのために比較的小さいサイズSを選択することと、ここにおいて、Sは1よりも大きい整数であり、
    前記決定された送信レートが前記しきい値よりも大きい場合、前記ブロック確認応答ビットマップのために比較的大きいサイズLを選択することと、ここにおいて、Lは、Sの値の2倍に等しいかまたはそれよりも大きい整数である、
    を行わせる、請求項19に記載の非一時的コンピュータ可読媒体。
  22. Sは8バイトに等しく、Lは2N*Sバイトに等しく、Nは1よりも大きい整数である、請求項21に記載の非一時的コンピュータ可読媒体。
  23. 前記しきい値は、前記比較的小さいサイズの前記ブロック確認応答ビットマップが基本送信レートで前記他のワイヤレスデバイスに送信され得るのと同じまたはより小さい送信持続時間内に、前記比較的大きいサイズの前記ブロック確認応答ビットマップが前記他のワイヤレスデバイスに送信され得る最小送信レートを示す、請求項21に記載の非一時的コンピュータ可読媒体。
  24. 前記最小送信レートは48Mbpsを備え、前記基本送信レートは12Mbpsまたは24Mbpsを備える、請求項23に記載の非一時的コンピュータ可読媒体。
  25. 前記送信レートを決定するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記受信されたデータフレームのうちの1つのヘッダから変調およびコーディング方式(MCS)を抽出することと、
    前記抽出されたMCSに少なくとも部分的に基づいて、前記決定された送信レートを導出することと、
    を行わせる、請求項19に記載の非一時的コンピュータ可読媒体。
  26. 前記決定された送信レートを導出するための前記命令の実行は、前記ワイヤレスデバイスに、
    前記MCSから探索鍵を生成することと、
    MCS値と送信レートとの間のいくつかのマッピングを記憶するルックアップテーブルから前記決定された送信レートを取り出すために前記探索鍵を使用することと、
    を行わせる、請求項25に記載の非一時的コンピュータ可読媒体。
  27. 前記命令の実行は、前記ワイヤレスデバイスに、前記データフレームを受信することに関連する復号問題に応答して、拡張フレーム間スペース(EIFS)持続時間を使用することを防ぐことをさらに行わせる、請求項19に記載の非一時的コンピュータ可読媒体。
  28. ワイヤレスデバイスであって、
    他のワイヤレスデバイスから受信されたいくつかのデータフレームの送信レートを決定するための手段と、
    前記決定された送信レートに少なくとも部分的に基づいてブロック確認応答ビットマップのサイズを選択するための手段と、
    前記他のワイヤレスデバイスに送信されるべきブロック確認応答(BA)フレーム中に前記ブロック確認応答ビットマップを埋め込むための手段と、
    を備える、ワイヤレスデバイス。
  29. 前記ブロック確認応答ビットマップの前記サイズは、前記ブロック確認応答ビットマップが前記他のワイヤレスデバイスに送信されるべきであるデータシンボルの数に少なくとも部分的に基づいてさらに選択される、請求項28に記載のワイヤレスデバイス。
  30. 選択するための前記手段は、
    前記決定された送信レートがしきい値よりも小さいかまたはそれに等しい場合、前記ブロック確認応答ビットマップのために比較的小さいサイズSを選択することと、ここにおいて、Sは1よりも大きい整数であり、
    前記決定された送信レートが前記しきい値よりも大きい場合、前記ブロック確認応答ビットマップのために比較的大きいサイズLを選択することと、ここにおいて、Lは、Sの値の2倍に等しいかまたはそれよりも大きい整数である、
    を行う、請求項28に記載のワイヤレスデバイス。
JP2016533164A 2013-11-22 2014-11-21 拡張ブロック確認応答プロトコル Pending JP2017502564A (ja)

Applications Claiming Priority (11)

Application Number Priority Date Filing Date Title
US201361907852P 2013-11-22 2013-11-22
US61/907,852 2013-11-22
US201361913669P 2013-12-09 2013-12-09
US61/913,669 2013-12-09
US201361916039P 2013-12-13 2013-12-13
US61/916,039 2013-12-13
US201461930223P 2014-01-22 2014-01-22
US61/930,223 2014-01-22
US14/549,170 US20150146699A1 (en) 2013-11-22 2014-11-20 Extended block acknowledgement protocol
US14/549,170 2014-11-20
PCT/US2014/066790 WO2015077547A1 (en) 2013-11-22 2014-11-21 Extended block acknowledgment protocol

Publications (2)

Publication Number Publication Date
JP2017502564A true JP2017502564A (ja) 2017-01-19
JP2017502564A5 JP2017502564A5 (ja) 2017-12-07

Family

ID=52023672

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2016533164A Pending JP2017502564A (ja) 2013-11-22 2014-11-21 拡張ブロック確認応答プロトコル

Country Status (7)

Country Link
US (1) US20150146699A1 (ja)
EP (1) EP3072253A1 (ja)
JP (1) JP2017502564A (ja)
KR (1) KR20160086908A (ja)
CN (1) CN105745857A (ja)
CA (1) CA2927134A1 (ja)
WO (1) WO2015077547A1 (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015198158A2 (en) 2014-06-27 2015-12-30 Techflux, Ltd. Operating in power save mode
WO2016014969A1 (en) 2014-07-24 2016-01-28 Marvell Semiconductor, Inc. Group acknowledgement for multiple user communication in a wireless local area network
US10218483B2 (en) * 2015-09-25 2019-02-26 Qualcomm Incorporated Systems and methods for signaling and generating variable length block acknowledgment fields in a wireless network
US10278224B2 (en) 2015-10-20 2019-04-30 Marvell World Trade Ltd. Acknowledgment data unit for multiple uplink data units
US11082888B2 (en) 2015-10-20 2021-08-03 Nxp Usa, Inc. Single acknowledgment policy for aggregate MPDU
US10469210B2 (en) 2015-11-24 2019-11-05 Marvell World Trade Ltd. Acknowledgment data unit for data unit fragment
EP3920448A1 (en) 2015-11-30 2021-12-08 Sony Group Corporation Information processing apparatus, communication system, information processing method, and program
US10707986B2 (en) 2016-01-08 2020-07-07 Qualcomm Incorporated Systems and methods for variable length block acknowledgment
US10313923B2 (en) 2016-02-19 2019-06-04 Marvell World Trade Ltd. Acknowledgement of transmissions in a wireless local area network
CN109314606A (zh) * 2016-02-19 2019-02-05 马维尔国际贸易有限公司 无线局域网中的发送的确认
US10873878B2 (en) * 2016-02-19 2020-12-22 Nxp Usa, Inc. Acknowledgement of transmissions in a wireless local area network
WO2022006757A1 (zh) * 2020-07-07 2022-01-13 北京小米移动软件有限公司 信息传输方法、装置、通信设备和存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060034274A1 (en) * 2004-07-30 2006-02-16 Nokia Corporation System and method for variable length acknowledgements in a shared resource network
JP2010503250A (ja) * 2006-08-30 2010-01-28 ノキア コーポレイション モバイル通信システムにおける高速ack/nackの方法及び装置
US20130176939A1 (en) * 2012-01-11 2013-07-11 Solomon B. Trainin Device, system and method of communicating aggregate data units

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6367045B1 (en) * 1999-07-01 2002-04-02 Telefonaktiebolaget Lm Ericsson (Publ) Bandwidth efficient acknowledgment/negative acknowledgment in a communication system using automatic repeat request (ARQ)
EP1429488B1 (en) * 2002-12-09 2016-03-09 Broadcom Corporation Incremental redundancy support in an EDGE cellular wireless terminal
JP4128961B2 (ja) * 2004-01-26 2008-07-30 株式会社東芝 無線通信装置、無線通信方法及び無線通信プログラム
CN101006673A (zh) * 2004-07-30 2007-07-25 诺基亚公司 在共享资源网络中用于可变长度聚合确认的***和方法
US7813324B1 (en) * 2005-09-28 2010-10-12 Rockwell Collins, Inc. Scalable mobile adaptive reliable ToS based automatic retransmit request
EP1924009B1 (en) * 2006-11-20 2009-05-20 NTT DoCoMo Inc. Relay apparatus for relaying a data packet to be transmitted from a first partner transceiver to a second partner transceiver
GB2493504B (en) * 2011-07-25 2017-11-29 Qualcomm Technologies Int Ltd Data flow control
US9608789B2 (en) * 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
US20150092697A1 (en) * 2012-05-11 2015-04-02 Agency For Science, Technology And Research Methods for determining information about a communication parameter and communication devices
US9628243B2 (en) * 2012-09-12 2017-04-18 Agency For Science, Technology And Research Communication method with indications in the PHY header

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060034274A1 (en) * 2004-07-30 2006-02-16 Nokia Corporation System and method for variable length acknowledgements in a shared resource network
JP2008508812A (ja) * 2004-07-30 2008-03-21 ノキア コーポレーション 共用資源ネットワークにおける可変長確認応答用のシステムおよび方法
JP2010503250A (ja) * 2006-08-30 2010-01-28 ノキア コーポレイション モバイル通信システムにおける高速ack/nackの方法及び装置
US20130176939A1 (en) * 2012-01-11 2013-07-11 Solomon B. Trainin Device, system and method of communicating aggregate data units

Also Published As

Publication number Publication date
KR20160086908A (ko) 2016-07-20
CN105745857A (zh) 2016-07-06
US20150146699A1 (en) 2015-05-28
CA2927134A1 (en) 2015-05-28
EP3072253A1 (en) 2016-09-28
WO2015077547A1 (en) 2015-05-28

Similar Documents

Publication Publication Date Title
JP6416256B2 (ja) チャネルアクセス延期メカニズム
JP2017502564A (ja) 拡張ブロック確認応答プロトコル
JP6342395B2 (ja) フレーム制御設計のための装置および方法
KR101735031B1 (ko) 전체 링크 품질에 기초하여 엔티티를 선택하기 위한 방법
CN110089148B (zh) 聚合mpdu、用于发送对其的响应帧的方法及使用其的无线通信终端
US20080159205A1 (en) Wireless communication apparatus
JP2020005266A (ja) 無線通信装置及び無線通信方法
US11082923B2 (en) Method for direct communication between stations in wireless local area network and related device
KR20210122137A (ko) 다중 링크를 지원하는 통신 시스템에서 파라미터의 업데이트를 위한 방법 및 장치
US20140056223A1 (en) Fragmentation for long packets in a low-speed wireless network
KR20210124917A (ko) 다중 링크를 지원하는 통신 시스템에서 데이터의 송수신 위한 방법 및 장치
KR102567626B1 (ko) 집합 mpdu를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말
JP7358442B2 (ja) フラグメンテーションを利用する無線通信方法及びそれを使用する無線通信端末
KR20220082093A (ko) Txop를 사용하는 무선 통신 방법 및 이를 사용하는 무선 통신 단말

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20171026

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171026

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180817

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20180904

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20190326