ホーム > 特許ランキング > ソニーグループ株式会社
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2023-11-09
(54)【発明の名称】通信デバイスおよび方法
(51)【国際特許分類】
H04W 72/512 20230101AFI20231101BHJP
H04W 84/12 20090101ALI20231101BHJP
H04W 72/21 20230101ALI20231101BHJP
H04W 72/23 20230101ALI20231101BHJP
【ＦＩ】
H04W72/512
H04W84/12
H04W72/21
H04W72/23
【審査請求】未請求
【予備審査請求】未請求
(21)【出願番号】P 2023524523
(86)(22)【出願日】2021-10-29
(85)【翻訳文提出日】2023-06-09
(86)【国際出願番号】 EP2021080078
(87)【国際公開番号】W WO2022090441
(87)【国際公開日】2022-05-05
(31)【優先権主張番号】20204987.0
(32)【優先日】2020-10-30
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
(71)【出願人】
【識別番号】000002185
【氏名又は名称】ソニーグループ株式会社
(74)【代理人】
【識別番号】110003339
【氏名又は名称】弁理士法人南青山国際特許事務所
(72)【発明者】
【氏名】チオキナ－カー ダナ
(72)【発明者】
【氏名】ハンデ トーマス
(72)【発明者】
【氏名】ベレンスエラ ダニエル
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA14
5K067DD11
5K067EE02
5K067EE10
(57)【要約】
本開示は、PPDUをプリエンプション処理する、すなわち、非レイテンシセンシティブ・トラフィックを運ぶPPDUを切り取り、レイテンシに制約のあるSTAを提供するという概念に関する。一実施形態によれば、第2の通信デバイスと通信するように構成される第1の通信デバイスが提供される。第1の通信デバイスは、上記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、上記データユニットの推定送信時間前に上記データユニットの上記進行中の送信を終了させ、かつ、上記進行中のデータユニットの交換のために上記第1の通信デバイスと上記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に上記第3の通信デバイスとの間で、上記プリエンプティブデータユニットを受信かつ/または送信するように構成された回路を具備し、上記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、上記第3の通信デバイスとの間で受信かつ/または送信されることを示す。
【選択図】図１３
【選択図】図１３
【特許請求の範囲】
【請求項1】
第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させ、かつ、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信デバイス。
【請求項2】
前記回路は、確認応答または要求上の確認応答がないように、データユニットの確認応答ポリシーを第2の通信デバイスとの前記データユニットの進行中の交換時に設定する
ように、構成されている
請求項１に記載の第1の通信デバイス。
【請求項3】
前記回路は、前記第2の通信デバイスとの前記データユニットの進行中の交換の一部として、前記送信機会の意図された前記継続時間を示す第1の継続時間インジケータを送信し、かつ、
前記第3の通信データとの間のデータユニットの受信または送信の一部として、前記データユニットの進行中の送信のトランケーションの後に、前記プリエンプティブデータユニットの送信が完了した後に、意図された前記送信機会の残り継続時間を示す第2の継続時間インジケータを送信するように
構成されている
請求項１に記載の第1の通信デバイス。
【請求項4】
前記回路は、前記プリエンプティブデータユニットの送信または受信、および、送信または受信されたプリエンプティブデータユニットに対する任意の所要の応答の、もしくは、
前記プリエンプティブデータユニットの送信、および、前記送信または受信されたフレームに対する任意の所要の応答をトリガまたはスケジューリングする前記フレームの、
予期された継続時間と、前記進行中のデータユニットの前記トランケーションを行った後に、前記意図された送信機会の残された継続時間が等しいかまたはより大きい場合にのみ、前記データユニットの進行中の送信を終了させる
請求項１に記載の第1の通信デバイス。
【請求項5】
前記回路は、第1のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、第2のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、
前記第2の通信デバイスの意図された送信機会が1つ以上のさらなるPHYデータユニット用の送信時間を含んでいる場合、
前記第1のプリエンプティブデータユニットを前記第3の通信デバイスに送信し、前記第3の通信デバイスから前記第2のプリエンプティブデータを受信する
ように構成されており、
前記第2のプリエンプティブデータユニットの継続時間が、前記1つ以上のPHYデータユニットの送信時間の継続時間より短く、トランケーションがない場合、
前記第1のプリエンプティブデータユニットの終端が前記第2の通信デバイスに送信されるデータユニットの意図された継続時間の終端に対応するように、パディングデータ量が前記第1のプリエンプティブデータユニットに追加される
請求項１に記載の第1の通信デバイス。
【請求項6】
前記プリエンプティブデータユニットの送信が、前記意図されたデータユニットの最初に意図された継続時間を超えないか、もしくは、短いフレーム間スペースまたは短いフレーム間スペース、スロット時間およびフレーム間許容レベルの関数を超えない請求項１に記載の第１の通信デバイス。
【請求項7】
前記回路は、前記第2の通信デバイスの送信機会中に、前記第3の通信デバイスから低レイテンシセンシティブ・トラフィックを送受信する要求を示す通知を受信した結果として、前記第2のデバイスとの間で前記進行中のデータ交換のトランケーションを実行する
ように構成されており、
前記通知は、前記第1の通信デバイスと前記第2の通信デバイスとの間で前記進行中のデータ交換が実行されるリンクとは異なるリンクで受信される
請求項１に記載の第1の通信デバイス。
【請求項8】
前記回路は、第1のプリエンプティブデータユニットとして、前記第1の通信デバイスと前記第2の通信デバイスとの間のデータ交換のために得られた送信機会の間に、さらなるプリエンプティブデータユニットを送信することを前記第3の通信デバイスに要求かつ/または可能にするトリガフレーム、または、前記第3の通信デバイスとのプリエンプティブデータ交換をスケジューリングするフレームを送信し、かつ/または、
データユニットの送受信と同時に前記第3の通信デバイスにプリエンプティブデータユニットを前記第2の通信デバイスに送信し、かつ/または、
前記第2の通信デバイスからのデータユニットと同時に前記第3の通信デバイスからプリエンプティブデータユニットを受信し、かつ/または、
進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で確立された、低レイテンシトラフィック・ストリーム識別子に対応するトラフィックのみを含むプリエンプティブデータユニットを、前記第3の通信デバイスに送信する
ように構成されている
請求項１に記載の第1の通信デバイス。
【請求項9】
前記回路は、前記進行中のデータ交換が行われる前記第2の通信デバイスとの送信機会を確立する一部として、1つ以上の潜在的なプリエンプションを示す制御フレームの1つ以上を送信し、かつ/または、
前記進行中の送信機会の前に前記第3の通信デバイスとネゴシエートされた予め定義された時間間隔でのデータユニットの進行中の送信のトランケーションを行う
ように構成されており、
ユーザフィールドは、プリエンプティブデータユニットの意図された受信機として前記第3の通信デバイスを示し、
ユーザフィールドは、前記第3の通信デバイスが潜在的なプリエンプティブデータ交換において意図された参加者としてそれ自体を識別する一連の通信デバイスを示す
請求項１に記載の第1の通信デバイス。
【請求項10】
第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信し、
前記第3の通信デバイスとの新たな送信機会を確立する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信デバイス。
【請求項11】
終端指示の継続時間、および、前記第3の通信デバイスとの送信機会の確立の継続時間を差し引いて切り取れなかった場合に、前記プリエンプティブデータユニットの継続時間が、現在の送信機会継続時間よりも長いときに、残りのネット継続時間を表す前記差は、前記残りのネット継続時間の前に前記プリエンプティブデータユニットの第1の部分を送信し、前記残りのネット継続時間の後に前記プリエンプティブデータユニットの第2の部分を送信する
請求項１０に記載の第1の通信デバイス。
【請求項12】
前記回路は、現在の送信機会の終端と位置合わせされた前記プリエンプティブデータユニットの前記第1の部分を、切り取られていない場合、送信し、かつ/または、前記第2の通信デバイスのためのデータユニットと、前記第3の通信デバイスのためのデータユニットとを備えるマルチユーザPPDUにおいて、前記プリエンプティブデータユニットの前記第1の部分および/または第2の部分を送信する
ように構成されている
請求項１０に記載の第1の通信デバイス。
【請求項13】
前記回路は、前記第3の通信デバイスと交換されるトラフィックのアクセスカテゴリが、低レイテンシセンシティブ・アクセスカテゴリを示す場合、および/または、進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で低レイテンシセンシティブ・セッションが確立された場合に、
現在の送信機会を前記第3の通信デバイスと終了または共用するように構成されている
請求項１または１０に記載の第1の通信デバイス。
【請求項14】
第1の通信デバイスと通信するように構成された第3の通信デバイスであって、第2の通信デバイスにアドレス指定されたデータユニットを受信し、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定し、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定し、かつ、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信する
ように構成された回路を具備する
第3の通信デバイス。
【請求項15】
前記回路は、前記切り取られたデータユニットの意図された継続時間とデータユニットインジケータの和から、前記切り取られたデータユニットの推定受信継続時間、前記プリエンプティブデータユニットの受信継続時間およびフレーム間空間を差し引き、
前記差し引きと等しい継続時間指示を含むプリエンプティブデータユニットを送信する
ように構成されており、
前記データユニットインジケータは、ゼロより大きい整数であり、前記切り取られたデータユニットが、現在の前記送信機会内に送信される最後のデータユニットではないことを示し、かつ、前記進行中の送信継続時間の予想継続時間を示す
請求項１４に記載の第3の通信デバイス。
【請求項16】
前記回路は、前記進行中のデータ交換の意図的な早期終了、
前記第3の通信デバイスからのプリエンプティブデータユニット送信を要求するトリガフレームの受信、
応答を要求するプリエンプティブデータユニットの受信、および
潜在的なトランケーション指示で定義される時間間隔
のうちの1つ以上の決定に応じて、前記第1の通信デバイスから第2の通信デバイスへの、前記進行中の送信機会の終端前および/または前記データユニットの意図された継続時間の終端前に、ネットワーク割当てベクトルNAVをリセットする
ように構成されている
請求項１４に記載の第3の通信デバイス。
【請求項17】
第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させるステップと、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信方法。
【請求項18】
第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信するステップと、
前記第3の通信デバイスとの新たな送信機会を確立するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信方法。
【請求項19】
第1の通信デバイスと通信するための第3の通信方法であって、第2の通信デバイスにアドレス指定されたデータユニットを受信するステップと、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定するステップと、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定するステップと、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信するステップと
を含む
第3の通信方法。
【請求項20】
プロセッサによって実行されると、請求項１７～１９のいずれか1つに記載の方法を実行させる、コンピュータプログラム製品内に記憶される非一時的なコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、それらが通信するための第1の通信デバイスおよび第2の通信デバイスに関する。本開示は、さらに、対応する通信方法に関するものである。
【背景技術】
【0002】
IEEE 802.11-2016で定義されているWLANは、パケットベースのデータ転送を実装する。1つ以上の入力データパケットまたはMSDU(MAC層サービスデータユニット)が存在し、無線チャネルが空いている場合、これらのMSDUは、PPDU(物理層プロトコルデータユニット)として1つ以上のピアWLAN通信デバイスに送信される前に、1つ以上のMPDU(MAC層プロトコルデータユニット)へのMAC層およびPHY層によって処理される。
【0003】
無線チャネルで測定されるこのようなPPDUの長さには一定の制限が適用される。これらの制限により、最大長または送信時間は、考慮される規格に応じて2ms～10ms(時折20ms)の範囲に制限される。送信時間はPPDU送信の開始時に決定され、固定される。チャネルアクセス、プリアンブル送信、および/または制御フレーム送信を獲得するためのオーバヘッドが無視できるので、長い送信時間は、通信の高効率にとって有利である。
【0004】
低遅延通信のコンテキストでは、アクセスポイント(AP)または局(STA)は、非レイテンシセンシティブ・データパケットとレイテンシセンシティブ・データパケットの両方を送信することができる。しばしば、レイテンシセンシティブ・パケットの到着はランダムで、未知で、予測不可能である。従って、1つ以上のレイテンシセンシティブMSDUが到着した時、1つ以上の非レイテンシセンシティブMSDUの送信がちょうど開始されたことが起こる可能性がある。
現在のWLANの振る舞いによれば、レイテンシセンシティブMSDUを伝達する新しいPPDU送信が開始される前に、進行中のPPDU送信が終了することを要求される。従って、レイテンシセンシティブMSDUは、それらの伝送のために許容できない長さを待つ必要がある可能性がある。
現在のWLANの振る舞いによれば、レイテンシセンシティブMSDUを伝達する新しいPPDU送信が開始される前に、進行中のPPDU送信が終了することを要求される。従って、レイテンシセンシティブMSDUは、それらの伝送のために許容できない長さを待つ必要がある可能性がある。
【0005】
本明細書で提供される「背景技術」の説明は、本開示の背景を大まかに提示するためのものである。現に指名された発明者の著作物は、本背景技術の項に記載されている範囲において、また、出願時に先行技術とされていなかった明細書の態様において、本開示に対して先行技術として明示的にも黙示的にも認められない。
【発明の概要】
【0006】
本発明は、改善された方法で、特に、低レイテンシセンシティブ・トラフィック交換を可能にするために、進行中のデータ伝送が切り取られる状況において、チャネルアクセスおよびチャネルアクセシングに関連するパラメータを決定することに関して、正しい振る舞いで対応する通信デバイスおよび方法を提供することが目的である。
さらに別の目的として、通信方法を実現するための対応するコンピュータプログラム、および通信方法を実現するための非一時的なコンピュータ読み取り可能な記録媒体が提供される。
さらに別の目的として、通信方法を実現するための対応するコンピュータプログラム、および通信方法を実現するための非一時的なコンピュータ読み取り可能な記録媒体が提供される。
【0007】
本発明の一態様によれば、第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスが提供され、この第1の通信デバイスは、
上記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
上記データユニットの推定送信時間前に上記データユニットの上記進行中の送信を終了させ、かつ、
上記進行中のデータユニットの交換のために上記第1の通信デバイスと上記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に上記第3の通信デバイスとの間で、上記プリエンプティブデータユニットを受信かつ/または送信する
ように構成された回路を具備し、
上記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、上記第3の通信デバイスとの間で受信かつ/または送信されることを示す。
上記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
上記データユニットの推定送信時間前に上記データユニットの上記進行中の送信を終了させ、かつ、
上記進行中のデータユニットの交換のために上記第1の通信デバイスと上記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に上記第3の通信デバイスとの間で、上記プリエンプティブデータユニットを受信かつ/または送信する
ように構成された回路を具備し、
上記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、上記第3の通信デバイスとの間で受信かつ/または送信されることを示す。
【0008】
本発明の一態様によれば、第2の通信デバイスおよび第3の通信デバイスと通信するように構成された別の第1の通信デバイスが提供され、この第1の通信デバイスは、
上記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
現在の送信機会の終端前に上記現在の送信機会の終端を示す終了通知を送信し、
上記第3の通信デバイスとの新たな送信機会を確立する
ように構成された回路を具備し、
上記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、上記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
上記新たな送信機会の継続時間は、上記第3の通信デバイスとの間の、上記プリエンプティブデータの少なくとも送信および/または受信をカバーする。
上記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
現在の送信機会の終端前に上記現在の送信機会の終端を示す終了通知を送信し、
上記第3の通信デバイスとの新たな送信機会を確立する
ように構成された回路を具備し、
上記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、上記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
上記新たな送信機会の継続時間は、上記第3の通信デバイスとの間の、上記プリエンプティブデータの少なくとも送信および/または受信をカバーする。
【0009】
さらなる別の態様によれば、第1の通信デバイスと通信するように構成された第3の通信デバイスが提供され、この第3の通信デバイスは、
第2の通信デバイスにアドレス指定されたデータユニットを受信し、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定し、
上記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定し、かつ、
切り取られたデータユニットの残りの継続時間内および/または上記送信機会の残りの継続時間内にプリエンプティブデータユニットを上記第1の通信デバイスとの間で受信かつ/または送信する
ように構成された回路を具備する。
第2の通信デバイスにアドレス指定されたデータユニットを受信し、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定し、
上記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定し、かつ、
切り取られたデータユニットの残りの継続時間内および/または上記送信機会の残りの継続時間内にプリエンプティブデータユニットを上記第1の通信デバイスとの間で受信かつ/または送信する
ように構成された回路を具備する。
【0010】
第1の通信デバイスおよび第2の通信デバイスに対応するさらなる別の態様によれば、
コンピュータプログラムをコンピュータ上で実行するときに、コンピュータに本明細書に開示する方法のステップを実行させるためのプログラム手段を具備するコンピュータプログラムと、
プロセッサによって実行されるときに、本明細書に開示する方法を実行させるコンピュータプログラム製品を記憶する非一時的なコンピュータ読み取り可能な記録媒体と、
が提供される。
コンピュータプログラムをコンピュータ上で実行するときに、コンピュータに本明細書に開示する方法のステップを実行させるためのプログラム手段を具備するコンピュータプログラムと、
プロセッサによって実行されるときに、本明細書に開示する方法を実行させるコンピュータプログラム製品を記憶する非一時的なコンピュータ読み取り可能な記録媒体と、
が提供される。
【0011】
本実施形態は、従属請求において定義される。開示された通信方法、開示されたコンピュータプログラム、および開示されたコンピュータ読み取り可能な記録媒体は、クレームされた通信デバイスと同様の、および/または、同一のさらなる実施形態を有し、本明細書に記載かつ/または開示された従属クレームで定義される。
【0012】
本開示の1つの態様は、PPDUをプリエンプション処理する、すなわち、レイテンシ制約のあるSTAを処理するために、非レイテンシセンシティブ・トラフィックを運ぶPPDUを切り取るという概念である。さらなる態様は、トランケーション（切り取り）の理由であるSTAでの正しい動作を可能にするための強調、すなわち、即時更新を必要とするSTAまたは即時更新を必要とするSTAを扱う。
【0013】
本開示のコンテキストにおいて、第1の通信デバイスは「アクセスポイント」または「AP」とも呼ばれ、第2の通信デバイスは「始動局」または「sSTA」とも呼ばれ、第3の通信デバイスは「プリエンプティブ局」または「pSTA」とも呼ばれる。
【0014】
前述の段落は一般的な導入により提供されており、以下の特許請求の範囲を限定することを意図するものではない。説明される本実施形態は、さらなる利点とともに、添付の図面と併せて以下の詳細な説明を参照することによって最もよく理解される。
【図面の簡単な説明】
【0015】
添付の図面に関連して考慮される場合、以下の詳細な説明を参照することによってより良く理解されるようになるので、本開示およびその付随する利点の多くのより完全な理解は、容易に得られる。
【図2】PPDU切り取りなしの、非レイテンシセンシティブかつレイテンシセンシティブ・データ送信を示す図である。
【図3】非レイテンシセンシティブかつレイテンシセンシティブ・データ送信とPPDU切り取りを示す図である。
【図4】WLANにおける送信のためのPHYとMAC間の相互作用を示す図である。
【図5】PHY層のブロックサイズを示す図である。
【図6】本開示を適用するための第1のシナリオを概略的に示す。
【図7】本開示を適用するための第2のシナリオを概略的に示す。
【図8】本開示を適用するための第3のシナリオを概略的に示す。
【図9】本開示による通信デバイスの模式図を示す。
【図10】本開示に係る第1の通信デバイスの通信方法の一実施形態のフローチャートを示す。
【図11】本開示に係る第1の通信デバイスの通信方法の別の実施形態のフローチャートを示す。
【図12】本開示に係る第3の通信デバイスの通信方法の一実施形態のフローチャートを示す。
【図13】送信境界に関する実施形態を示す図である。
【図14A】TXTIME(pPPDU2) < TXTIME(Ack)でsPPDU後にAck時間が含まれた元のTXOPの場合の振る舞いを示す図である。
【図14B】TXTIME(pPPDU2) >TXTIME(Ack)でsPPDU後にAck時間が含まれた元のTXOPの場合の振る舞いを示す図である。
【図15】TXOPトランケーションおよびリセットを用いた一実施形態の図である。
【図16A】従来の確認ポリシー設定を示す図である。
【図16B】一実施形態で提案される新しい確認ポリシー設定を示す図である。
【図17】非AP局が低レイテンシトラフィックセッションを開始するセッションの動作を示す図である。
【図18】本開示に係る第1の通信デバイスの通信方法の別の実施形態のより詳細なフローチャートを示す。
【図19】トランケーションの場合のインターフェース間の関係を示す図である。
【発明を実施するための形態】
【0016】
図面を参照すると、図1は、いくつかの図全体にわたって同一または対応する部分を示し、図1は、一般に知られているWLANにおけるデータユニットの関係および構成、特にMSDUまたはA-MSDU(集約MSDU)、MPDU、PSDU(物理層サービスデータユニット)およびPPDUを示す。
【0017】
本開示によれば、PPDU送信、すなわち、データユニットの送信は、既に送信されたデータを失うことなく、切り取られる(または中断される)ものとする。従って、これは、進行中のPPDU送信の受信機フレンドリなトランケーション（切り取り）と見なすことができる。
【0018】
図2および図3は、低遅延通信に対するPPDUトランケーションの利点を示す図を示している。
図2によると、PPDU切り取りは使用されず、図3によると、PPDU切り取りが使用される。両方の図が従来のWLAN振る舞いを示し、MSDU到着時間が両方の図において等しいことに留意されたい。
図2によると、PPDU切り取りは使用されず、図3によると、PPDU切り取りが使用される。両方の図が従来のWLAN振る舞いを示し、MSDU到着時間が両方の図において等しいことに留意されたい。
【0019】
図2によれば、非レイテンシセンシティブMSDUを保持するPPDU 10は、PPDU 11内に保持されたレイテンシセンシティブMSDUが送信される前に終了することが要求される。これは、レイテンシセンシティブMSDUが送信可能になるまでキューまたはメモリにバッファされる必要があるため、レイテンシセンシティブMSDUに対して不要なキュー遅延を引き起こす。
しかしながら、図3によれば、非レイテンシセンシティブ・データを保持するPPDU 20を2つのPPDU部21および22に切り取ることにより、レイテンシセンシティブ・データを保持するPPDU 23の高速伝送が可能になる。
従って、レイテンシセンシティブMSDUのキュー遅延は、図2と比較して小さくなる。図2のPPDU切り取りと比較して、図3の非レイテンシセンシティブ・データのキュー遅延の増加は、異なるトラフィックタイプのキュー遅延のトレードオフを提供できるが、減少は提供しない。非レイテンシセンシティブMSDUとレイテンシセンシティブMSDUは、異なるSTAを対象としてもよいに注意すべきである。
しかしながら、図3によれば、非レイテンシセンシティブ・データを保持するPPDU 20を2つのPPDU部21および22に切り取ることにより、レイテンシセンシティブ・データを保持するPPDU 23の高速伝送が可能になる。
従って、レイテンシセンシティブMSDUのキュー遅延は、図2と比較して小さくなる。図2のPPDU切り取りと比較して、図3の非レイテンシセンシティブ・データのキュー遅延の増加は、異なるトラフィックタイプのキュー遅延のトレードオフを提供できるが、減少は提供しない。非レイテンシセンシティブMSDUとレイテンシセンシティブMSDUは、異なるSTAを対象としてもよいに注意すべきである。
【0020】
WLAN内では、PHYおよびMAC層の信号処理は、一実施形態ではブロック単位で行われてもよい。いくつかの処理ステップでは、ブロック長が異なる。想定されるPPDUトランケーション動作に対して守られるブロック長は、LDPC符号語長、OFDMシンボル長、およびMPDUデータユニットである。
【0021】
MPDUデータユニットは、(i)ヘッダ情報、(ii) (暗号化)ユーザデータ、しばしばMSDU、および(iii)フレームチェックシーケンス(FCS)から構成される。FCSは、ユーザデータおよび/またはヘッダ情報内の伝送エラーを検出するために使用される。誤差が検出された場合、MPDUは破棄され、そのMDPUの送信機から再送信が要求されてもよい。
1つ以上のMPDUをA-MPDUに集約して、1つのPPDUで送信することができる(図1)。PSDU、すなわちMPDUまたはA-MPDUがMAC層で容易に利用可能になると、すなわち、少なくとも送信されるデータ量が既知であると、PHY層は送信のためにトリガされる。
1つ以上のMPDUをA-MPDUに集約して、1つのPPDUで送信することができる(図1)。PSDU、すなわちMPDUまたはA-MPDUがMAC層で容易に利用可能になると、すなわち、少なくとも送信されるデータ量が既知であると、PHY層は送信のためにトリガされる。
【0022】
図4は、送信のためのPHYとMACの相互作用、すなわち、PPDU送信の開始およびMACとPHY間のデータ転送を示している。MACはPHYをトリガして、PHY-TXSTART.request(要求)(TXVECTOR)関数(またはプリミティブ)によって送信を開始する。この要求には、PHY入力データユニット(PSDU)の長さ情報、変調符号化方式(MCS)、すなわちコードレートとコンスタレーションダイアグラムサイズ、空間ストリームの数、MIMOモード、帯域幅およびRUサイズなどのPHYの1つ以上の構成パラメータを保持するTXVECTORが含まれる。
【0023】
この情報に基づいて、PHYはLDPCおよびOFDM変調のためのブロックサイズとそれぞれの構造を決定する。このプロセスは様々なステップを保持しており、開示された解決策の一部ではないため、ここでは省略する。異なるブロックサイズは、PSDUの少なくとも終端(および好ましくは始端)ですべてのブロックの境界が一致するように決定される。これらのブロックサイズおよび関連するブロック構造は、それぞれのPPDUの符号化および変調プロセス全体の間、固定されたままである。
図5は、ブロック単位の操作と、PSDUの最初と最後のブロック境界の一致を視覚化したものである。
図5は、ブロック単位の操作と、PSDUの最初と最後のブロック境界の一致を視覚化したものである。
【0024】
図4では、PHY-TXSTART.要求とブロックサイズの計算に続いて、PHYは信号情報(SIG)と同様にチャネル見積もりシークエンス(STF、LTF)とトレーニングシンボルの送信を開始する。
この信号情報は、受信機がそのPPDUの受信用にPHYを設定するために使用される。SIGフィールドデータがコンパイルされると、PHYはPHY-TXSTART.confirm (TXSTATUS)プリミティブを発行して、データ交換の準備ができたことをMACに報告する。その後、MACはPHYDATA.request(DATA, USER_INDEX)プリミティブを使用してPHYにデータを送信する。これにより、DATAは、USER_INDEXによって識別されるユーザに対して送信される実際のデータを保持する。
多くの場合、DATAはサイズ1オクテットである。PHYは、PHY-DATA.confirmプリミティブを発行して正常なデータ転送を確認する。データ交換は、MACがPHYに送信を終了させることを示すPHY-TXEND.requestを発行するまで継続される。その後、無線メディアで送信されなくなった時点で、PHYはPHY-TXEND.conformによって送信が終了したことをMACに通知する。
この信号情報は、受信機がそのPPDUの受信用にPHYを設定するために使用される。SIGフィールドデータがコンパイルされると、PHYはPHY-TXSTART.confirm (TXSTATUS)プリミティブを発行して、データ交換の準備ができたことをMACに報告する。その後、MACはPHYDATA.request(DATA, USER_INDEX)プリミティブを使用してPHYにデータを送信する。これにより、DATAは、USER_INDEXによって識別されるユーザに対して送信される実際のデータを保持する。
多くの場合、DATAはサイズ1オクテットである。PHYは、PHY-DATA.confirmプリミティブを発行して正常なデータ転送を確認する。データ交換は、MACがPHYに送信を終了させることを示すPHY-TXEND.requestを発行するまで継続される。その後、無線メディアで送信されなくなった時点で、PHYはPHY-TXEND.conformによって送信が終了したことをMACに通知する。
【0025】
リアルタイムアプリケーション(RTA)のコンテキストでは、APは、レイテンシとジッタのポイントに厳しい制約がある基本サービスセット(BSS)内でSTAを処理する必要がある。一方、現在WLANで定義されているPPDUは、比較的長い伝送時間、例えば5msを持つことができる。従って、PPDUをプリエンプトする、即ち、非レイテンシセンシティブ・トラフィックを運ぶPPDUを切り取るという概念が、レイテンシに制約のあるSTAに役立つように出現した。
PPDU送信の切り取りは、PHYTXEND.requestプリミティブによっていつでもMACによって実行されてよい。しかしながら、この方法で切り取ることは、未完成の最後のOFDMシンボルを導き、従って、受信機によって復調できず、データ損失に帰着するPPDUの部分的に損傷に至る。さらに、PPDUの切り取りを引き起こしたもの、たとえばキャリア損失、干渉、および意図的な切り取りである可能性があることは、受信機にとっては明らかではない。受信機がPPDUの内容を切り取りまで正しくデコードできるようにするために、PPDUの早期終了の場合、特定のパディング技術を設計する必要がある。
PPDU送信の切り取りは、PHYTXEND.requestプリミティブによっていつでもMACによって実行されてよい。しかしながら、この方法で切り取ることは、未完成の最後のOFDMシンボルを導き、従って、受信機によって復調できず、データ損失に帰着するPPDUの部分的に損傷に至る。さらに、PPDUの切り取りを引き起こしたもの、たとえばキャリア損失、干渉、および意図的な切り取りである可能性があることは、受信機にとっては明らかではない。受信機がPPDUの内容を切り取りまで正しくデコードできるようにするために、PPDUの早期終了の場合、特定のパディング技術を設計する必要がある。
【0026】
本開示では、切り取りが意図されたSTAのためのチャネルアクセスのための新しいルールと同様に、チャネル・アクセス・パラメータの正確かつ公平な分配を可能にするためのさらなる強化が提案される。さらに、直接関与するSTAだけでなく、アクセス機会を見つけるためにメディアをリッスンする残りのSTAに対しても、ネットワーク割り当てベクトル(NAV)の正しい設定を保証するために、チャネルアクセスに関連する態様を議論した。
【0027】
以下に考えられるシナリオを図6～8に示す。
【0028】
プリエンプティブSTA (pSTA)へのDL送信のためにダウンリンク(DL) PPDUトランケーションを使用する第1のシナリオを図6に概略的に示す。
このシナリオでは、AP (本明細書では第1の通信デバイスとも呼ぶ)は、PPDU (本明細書では、一般に開始データユニットまたはsPPDUとも呼ぶ)を最初のSTA (本明細書では第2の通信デバイスまたは開始STAとも呼ぶ)に向けて送信する。sPPDU送信中のある時点において、APの上層は、異なるSTA (ここでは第3の第1の通信デバイスまたはpSTA)に高優先度データを送信する必要性を示す。
結果として、処理遅延(pDelay)の後、sPPDUは切り取られ、sSTAへの送信は停止され、所定の時間間隔フレーム間スペース(IFS)の後、APは新たなPPDU (ここではプリエンプティブデータユニットまたはpPPDUとも呼ばれる)をpSTAに送信する。図6では、継続時間Dが示されており、これは、sPPDUのsSTA 300への本来意図された送信時間を示す。したがって、切り取りが実行されない場合、DはsPPDUの期間になる。元々意図されたsPPDUの継続時間Dは、sPPDUのプリアンブル、すなわち、sSTA 300とpSTA 100を、例えばプリアンブルフィールドに存在する情報からデコードできるSTAによって推定できる。
このシナリオでは、AP (本明細書では第1の通信デバイスとも呼ぶ)は、PPDU (本明細書では、一般に開始データユニットまたはsPPDUとも呼ぶ)を最初のSTA (本明細書では第2の通信デバイスまたは開始STAとも呼ぶ)に向けて送信する。sPPDU送信中のある時点において、APの上層は、異なるSTA (ここでは第3の第1の通信デバイスまたはpSTA)に高優先度データを送信する必要性を示す。
結果として、処理遅延(pDelay)の後、sPPDUは切り取られ、sSTAへの送信は停止され、所定の時間間隔フレーム間スペース(IFS)の後、APは新たなPPDU (ここではプリエンプティブデータユニットまたはpPPDUとも呼ばれる)をpSTAに送信する。図6では、継続時間Dが示されており、これは、sPPDUのsSTA 300への本来意図された送信時間を示す。したがって、切り取りが実行されない場合、DはsPPDUの期間になる。元々意図されたsPPDUの継続時間Dは、sPPDUのプリアンブル、すなわち、sSTA 300とpSTA 100を、例えばプリアンブルフィールドに存在する情報からデコードできるSTAによって推定できる。
【0029】
pSTAからのアップリンク(UL)送信のためにDL PPDUトランケーションを使用する第2のシナリオが、図7に概略的に描かれている。
このシナリオは、第1のシナリオの拡張であり、主な違いは、APからのDL送信が切り取り後に発生するだけでなく、pSTAからの応答も発生することである。このシナリオは一般的な意味で描写され、例えば次の特定のケースをカバーする。
i) APによって送信された最初のpPPDU (pPPDUI)は、通常の/暗黙のACKポリシーおよび/またはBAck要求フレームで集約されたpSTAに向けての高い優先度データを含み、一方、pPPDU2は確認応答またはブロック確認応答を含む。
ii) APはpSTAから緊急の更新を必要とし、この更新を得るためにsSTAへの送信を中断する。この場合、正しいチャネルアクセスを可能とするために、一実施形態によれば、pSTAからのデータ送信を要求するAPからフレームを最初に送信し、次の通信のためのチャネル・アクセス・パラメータを設定することが提案される。これは、必要な更新を含むpSTAからのPPDUによってフレーム間スペース内で実行される。pPPDU1は、例えば、IEEE 802.11axで定義されたようなトリガフレーム(TF)であってもよく、pPPDU2の送信をトリガするものであってもよく、または、(例えば、開始指示および基本RU/BW割り当てを含む必要がある)類似の機能を備えたこの単純化されたバージョンであってもよい。
iii) APは、送信すべき緊急データを有するpSTAから別のリンクからの指示を受信した。続いて、APは、sPPDUをプリエンプトした後に送信を可能にするが、正しいチャネル・アクセス・パラメータを確実にするために、一実施形態によれば、pSTAからの送信をトリガするフレームを最初に送信し、送信のためのチャネル・アクセス・パラメータを通知することが提案される。したがって、pPPDU1とpPPDU2のコンテンツの一例は、それぞれトリガフレームとデータPPDUである。
このシナリオは、第1のシナリオの拡張であり、主な違いは、APからのDL送信が切り取り後に発生するだけでなく、pSTAからの応答も発生することである。このシナリオは一般的な意味で描写され、例えば次の特定のケースをカバーする。
i) APによって送信された最初のpPPDU (pPPDUI)は、通常の/暗黙のACKポリシーおよび/またはBAck要求フレームで集約されたpSTAに向けての高い優先度データを含み、一方、pPPDU2は確認応答またはブロック確認応答を含む。
ii) APはpSTAから緊急の更新を必要とし、この更新を得るためにsSTAへの送信を中断する。この場合、正しいチャネルアクセスを可能とするために、一実施形態によれば、pSTAからのデータ送信を要求するAPからフレームを最初に送信し、次の通信のためのチャネル・アクセス・パラメータを設定することが提案される。これは、必要な更新を含むpSTAからのPPDUによってフレーム間スペース内で実行される。pPPDU1は、例えば、IEEE 802.11axで定義されたようなトリガフレーム(TF)であってもよく、pPPDU2の送信をトリガするものであってもよく、または、(例えば、開始指示および基本RU/BW割り当てを含む必要がある)類似の機能を備えたこの単純化されたバージョンであってもよい。
iii) APは、送信すべき緊急データを有するpSTAから別のリンクからの指示を受信した。続いて、APは、sPPDUをプリエンプトした後に送信を可能にするが、正しいチャネル・アクセス・パラメータを確実にするために、一実施形態によれば、pSTAからの送信をトリガするフレームを最初に送信し、送信のためのチャネル・アクセス・パラメータを通知することが提案される。したがって、pPPDU1とpPPDU2のコンテンツの一例は、それぞれトリガフレームとデータPPDUである。
【0030】
STAがマルチリンク能力を持ち、送信が発生するリンクとは異なるリンク上でプリエンプション要求が実行される場合、iiiの場合に提示されるトリガフレームが、リンク上で正しいチャネルアクセスと一貫した期間情報を保証できる容易な実装として提案される。ただし、遅延が発生するため、レイテンシ要件が厳しい場合にも、遅延なしの動作が必要になることがある。
従って、第3のシナリオは、図8に概略的に示されるように、sPPDU切り取り後のpPPDUのための直接ULアクセスを使用して考慮されてもよい。
従って、第3のシナリオは、図8に概略的に示されるように、sPPDU切り取り後のpPPDUのための直接ULアクセスを使用して考慮されてもよい。
【0031】
この場合の一要件は、pSTAがリンクをリッスンすることで、少なくともsPPDUの開始以降にトランケーションが実行され、プリアンブル情報がデコードされる。DL送信およびトランケーションが実行されるリンクとは異なるリンク上でプリエンプションを要求するメカニズムは、本開示の範囲外である。しかし、完全性のために、図8のマルチリンク関係の一例も同様である。ここでは、トランケーションが発生した後のチャネルアクセスのみに焦点を当て、特定のリンクで送信機会(TXOP)の一貫性を確保し、ここで、データ交換の意図された継続期間を表すTXOPは、トランケーションが発生していない。
【0032】
図6～8に示すシナリオに対して正しい振る舞いを保証するためには、pSTAチャネルアクセス、APチャネルアクセス、およびsSTAのAck振る舞いが保証される必要がある。
【0033】
pSTAチャネルアクセスとは、プリエンプティブデータユニットやプリエンプティブデータユニットへの応答(例:確認応答)を送信するために、pSTAがチャネルにアクセスできるようにするメカニズムのことである。WLAN環境内では、共通のメカニズムは、メディア占有の情報を保持し、意図したまたは意図しない送信機から受信したフレームの継続期間情報に基づいて、定期的に更新されるネットワーク割り当てベクトル(NAV)に基づいている。
STAは、フレームを受信すると、メディアが占有されている継続期間を判定し、この期間内にチャネルへのアクセスを控えたり、チャネルアクセスの競合を控えたりする。このような振る舞いは、プリエンプションの場合に制限を引き起こす可能性がある。これは、sSTAへの送信が開始されると、プリエンプティブSTAが記録媒体ビジーを検出し、APとsSTA間のデータ交換の時間中は送信できないためである。
従って、現在の規則によれば、sSTAはプリエンプティブデータまたはプリエンプティブデータへの応答を、最初の意図された送信機会の終わりまで送信することができない。
STAは、フレームを受信すると、メディアが占有されている継続期間を判定し、この期間内にチャネルへのアクセスを控えたり、チャネルアクセスの競合を控えたりする。このような振る舞いは、プリエンプションの場合に制限を引き起こす可能性がある。これは、sSTAへの送信が開始されると、プリエンプティブSTAが記録媒体ビジーを検出し、APとsSTA間のデータ交換の時間中は送信できないためである。
従って、現在の規則によれば、sSTAはプリエンプティブデータまたはプリエンプティブデータへの応答を、最初の意図された送信機会の終わりまで送信することができない。
【0034】
さらに、IEEE 802.11axで定義された二重NAVメカニズムによれば、pSTAは、それが送信を要求するトリガフレームの受信者である場合、潜在的には、そのBSS内NAV (すなわち、それ自身のBSS内のSTAに対するNAV)をリセットすることができる。しかしながら、規格の現在の修正の下では、BSS内NAVのリセットは、この指示を運ぶPPDUの終わりの後で、かつ、トリガフレームへの応答としてのみ可能である。
PPDUの終了前に更新できるのは、interBSS(または基本NAV)のみである。したがって、現在のルールに基づいて、特に図7および8に示されているシナリオでは、pSTAはPPDU切り取り後にAPへの送信を開始できない。
PPDUの終了前に更新できるのは、interBSS(または基本NAV)のみである。したがって、現在のルールに基づいて、特に図7および8に示されているシナリオでは、pSTAはPPDU切り取り後にAPへの送信を開始できない。
【0035】
この提案のコンテキストでは、APチャネルアクセスはいくつかの態様を指す。
第1の態様は、APがpSTAへのプリエンプティブ送信を実行する必要がある場合に備えて、1つのsSTAで取得した送信機会を共有または切り取ることを指す。第2の態様は、STAが、切り取りされた送信を理解する否かにかかわらず、同様のNAV情報を持つように正しい継続時間情報を分配することを意味する。最後の態様は、pSTAチャネルアクセスを容易にするためにAPによって実行されるメカニズムを指す。
第1の点に関しては、プライマリアクセスカテゴリになる一つの特定アクセスカテゴリ(AC)のトラフィックに対する送信機会を得た。現在の規格では、TXOP共有に関して強い制限がある。第2の点に関しては、pPPDUを送信することは、アクセス問題、即ち、既存の規則に従って、既にそれらのネットワーク割り当てベクトルを更新したSTAのための衝突を作成することを避けるために、送信機会制限を守らなければならない。ただし、制限がある。
第1の態様は、APがpSTAへのプリエンプティブ送信を実行する必要がある場合に備えて、1つのsSTAで取得した送信機会を共有または切り取ることを指す。第2の態様は、STAが、切り取りされた送信を理解する否かにかかわらず、同様のNAV情報を持つように正しい継続時間情報を分配することを意味する。最後の態様は、pSTAチャネルアクセスを容易にするためにAPによって実行されるメカニズムを指す。
第1の点に関しては、プライマリアクセスカテゴリになる一つの特定アクセスカテゴリ(AC)のトラフィックに対する送信機会を得た。現在の規格では、TXOP共有に関して強い制限がある。第2の点に関しては、pPPDUを送信することは、アクセス問題、即ち、既存の規則に従って、既にそれらのネットワーク割り当てベクトルを更新したSTAのための衝突を作成することを避けるために、送信機会制限を守らなければならない。ただし、制限がある。
【0036】
TXOP共有は制限条件下でのみ許可されるものであり、プライマリACの継続時間であるメインの1つは、超えられない。特定の環境、例えばSUでは、他のACと残りのTXOP送信を共有する前に、最初にプライマリACの送信を完了しなければならず、特定のACはより高い優先度を持たなければならない。
【0037】
NAV情報は、そのような情報を検索できる限り、MACヘッダ内の継続期間情報すべてのフレームで更新される。さらに、継続時間のPHY指示は、HE STAのプリアンブル内でも利用可能であり、これは、MAC指示が検索できないときに使用することができる。STAは、以下の伝送機会の期間に関する情報と、この情報を含むPPDUの長さに関する情報に基づいて、媒体利用率と次の可能な送信時間をそれらの側から判定する。
従って、送信機会限界と同様にPPDU限界は、チャネルアクセスを正しく決定するSTAにとって重要である。結果として、異なるSTAへの送信を可能にするためにPPDUを切り取るプリエンプション方式は、2つの境界が最初のPPDUとTXOP継続時間が通知されたものと一致するように行われるべきである。
従って、送信機会限界と同様にPPDU限界は、チャネルアクセスを正しく決定するSTAにとって重要である。結果として、異なるSTAへの送信を可能にするためにPPDUを切り取るプリエンプション方式は、2つの境界が最初のPPDUとTXOP継続時間が通知されたものと一致するように行われるべきである。
【0038】
sSTAのAck振る舞いとは、sSTAがAPに確認通知を送信し、APによって送信されたすべてのMPDUが正しく受信されたかどうかを通知し、受信されなかった場合はどのMPDUが欠落しているかを通知するメカニズムのことである。Ackを要求または送信できるいくつかのメカニズムがある。現在の提案の特定のケースでは、sSTAからのAckフレームを運ぶPPDUとプリエンプティブデータ送信との間の衝突を避けるために、これに特別な注意を払うべきである。以下、図16を用いて、本発明の一実施形態による本課題を回避する方式を説明する。
【0039】
図9は、無線チャネル上の第2の通信デバイス200(本明細書では開始局、sSTAとも呼ぶ)および第3の通信デバイス300(本明細書ではプリエンプティブ局、pSTAとも呼ぶ)と通信するための本開示の態様に従った第1の通信デバイス100(例えば、アクセスポイント、AP)を示す図である。
したがって、第1の通信100は、第2の通信デバイスおよび第3の通信デバイス300とデータを交換(受信および/または送信)することができる。
したがって、第1の通信100は、第2の通信デバイスおよび第3の通信デバイス300とデータを交換(受信および/または送信)することができる。
【0040】
通信デバイス100、200、300の各々は、特定の動作を行うように構成された回路101、201、301を含む。回路は、それぞれのプロセッサまたはコンピュータによって、即ち、ハードウェアおよび/またはソフトウェアとして、または専用ユニットまたはコンポーネントによって実施することができる。例えば、それぞれプログラムされたプロセッサは、それぞれの回路101、201、301を表すことができる。
【0041】
図10は、本開示に係る第1の通信デバイス100(AP)の第1の通信方式110の一実施形態のフローチャートを示し、回路101によって実行されてもよい。
第1のステップ111では、APは、第2の通信デバイスとのデータユニットの継続交換中に、トランケーション通知を受信する。トランケーション通知は、切り取り条件が満たされ、プリエンプティブデータユニットが第3の通信デバイスから受信され、かつ/または、第3の通信デバイスに送信される場合、データユニットの進行中の送信が切り取られることを示す。トランケーション通知は、進行中の送信機会中に、優先度の高い低レイテンシトラフィック/トラフィックが、進行中の送信に含まれているものよりも高い優先度を持つことを示している可能性がある。
トランケーション通知を受信したら、まず、トランケーションを実行できるか(すなわち、もしそれが継続時間内に収まるならば、STAは、切り取りされた送信を処理することができる)を判定し、そして、PPDUを切り取りすることだけを決定する必要がある。
第1のステップ111では、APは、第2の通信デバイスとのデータユニットの継続交換中に、トランケーション通知を受信する。トランケーション通知は、切り取り条件が満たされ、プリエンプティブデータユニットが第3の通信デバイスから受信され、かつ/または、第3の通信デバイスに送信される場合、データユニットの進行中の送信が切り取られることを示す。トランケーション通知は、進行中の送信機会中に、優先度の高い低レイテンシトラフィック/トラフィックが、進行中の送信に含まれているものよりも高い優先度を持つことを示している可能性がある。
トランケーション通知を受信したら、まず、トランケーションを実行できるか(すなわち、もしそれが継続時間内に収まるならば、STAは、切り取りされた送信を処理することができる)を判定し、そして、PPDUを切り取りすることだけを決定する必要がある。
【0042】
第2のステップ112で、APは、データユニットの推定送信時間前に、データユニットの進行中の送信を終了する。一実施形態では、APは、TXOPの残りの継続時間および進行中のPPDU送信に基づいて、切り取りを実行することに意味があるかどうか(すなわち、有用であるか)を評価する。
【0043】
第3のステップ113で、APは、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に、第3の通信デバイス(すなわち、pSTA)からプリエンプティブデータユニットを受信し、かつ/または、第3の通信デバイスに送信する。APが生成する実施形態では、切り取り条件が満たされた場合、MACによってPHYに発行され、進行中のPPDUのトランケーションを実行することをPHYに示す、さらなるトランケーションプリミティブが生成される。
【0044】
別の実施形態は、低レイテンシセンシティブ・トラフィックストリーム特性およびプリエンプションパラメータについて知らせるために、低レイテンシセンシティブ・トラフィックストリーム(LLTS)セッションを確立することを扱う。この実施形態の一実装では、低センシティブ・トラフィックを有する非AP STAは、それが関連付けられているAPとの低レイテンシトラフィックセッションを確立することができる。
図17は、このようなセッションの動作を示す図である。
図17は、このようなセッションの動作を示す図である。
【0045】
このようなセッションを設定する場合、(ステーション管理エンティティ(SME)とMACを持つ) 非AP STAは、トラフィック特性(周期性、継続時間など)と要件(データレートやレイテンシ境界のポイントなど)を対応するものに通知する。さらに、(SMEとMACを持つ)APに、プリエンプションの準備ができたことを通知することもできる。この場合、サポートできるプリエンプション関連パラメータを追加で示してもよい（例えば、PPDUの受信中に、連続的にまたは定期的にのみリッスンできる場合、PPDU中にどのくらいの頻度でCCAを実行できるか）。
これらのパラメータをレイテンシトラフィックセッション要求内に含めることは、1つの可能な実装にすぎない。代替案は、関連付けられているSTAとAPの間で交換される能力要素のフィールド内で、プリエンプション能力およびパラメータを示すことである。
これらのパラメータをレイテンシトラフィックセッション要求内に含めることは、1つの可能な実装にすぎない。代替案は、関連付けられているSTAとAPの間で交換される能力要素のフィールド内で、プリエンプション能力およびパラメータを示すことである。
【0046】
APは、レイテンシトラフィックセッション要求に、受付/拒否または代替パラメータの提案で応答する。具体的には、プリエンプトに関して、APは、レイテンシの時点でトラフィック要件を満たすために、LLTS要求者以外のSTAに向けて、進行中のPPDUのトランケーションに頼ることができるかどうかを示してもよい。さらに、トランケーションが実行され得る場合には、トランケーションのパラメータを、例えば、使用されるべき正確な値が、潜在的に切り取り可能なPPDUのプリアンブルに示される、可能なトランケーション精度を、すなわち、（のちに）トランケーションが実行され得るOFDMシンボルの数、または、一連の可能な値を示す。
スケジュールは、要求側STAに対する応答内に存在することができ、これは、レイテンシセンシティブ・トラフィックストリームが送信され得る特定の間隔、および/または、APが更新を要求できる時間を信号送信する。さらに、潜在的なトランケーションがこれらのスケジュールに対応する指定された時間間隔内に可能であるか、あるいは、これらの範囲外で可能であるかを示すことができる。
時間間隔を指定し、指定された間隔内でのみ実行される可能性のある切り取りを確実にすることは、pSTAの省電力動作の改善に貢献できる。さもなければ、要求側pSTAは、他のSTAに属するPPDUを継続的にリッスンすることをコミットし、意図的なトランケーションが行われるかどうかを常に評価し、さらに、フォローアップ送信の識別子が自身に対応するかどうかを検証する必要がある。
スケジュールは、要求側STAに対する応答内に存在することができ、これは、レイテンシセンシティブ・トラフィックストリームが送信され得る特定の間隔、および/または、APが更新を要求できる時間を信号送信する。さらに、潜在的なトランケーションがこれらのスケジュールに対応する指定された時間間隔内に可能であるか、あるいは、これらの範囲外で可能であるかを示すことができる。
時間間隔を指定し、指定された間隔内でのみ実行される可能性のある切り取りを確実にすることは、pSTAの省電力動作の改善に貢献できる。さもなければ、要求側pSTAは、他のSTAに属するPPDUを継続的にリッスンすることをコミットし、意図的なトランケーションが行われるかどうかを常に評価し、さらに、フォローアップ送信の識別子が自身に対応するかどうかを検証する必要がある。
【0047】
特定のスケジュールおよび周期性は、低レイテンシセンシティブ・トラフィックストリーム(LLSTS またはLLTS)設定で定義される。あるいは、これらは、特定のSTA、例えば、個別またはブロードキャスト・ターゲット・ウェイクアップ時間のためのスケジューリング間隔のセットアップおよび/またはアナウンスの中で、APによってさらにアナウンスされ得る。pSTAがこれらの間隔を決定できるように、APは割り当てIDを割り当てられ、このIDには、pSTAとAPの識別子とともにLLTS 識別子がマッピングされる。
ブロードキャスト・ウェイクアップ時間間隔の場合、APは、セットアップまたは更新構成情報を含む制御フレーム内で、これらの間隔中の送信が切り取られる可能性があることを示してもよい。
ブロードキャスト・ウェイクアップ時間間隔の場合、APは、セットアップまたは更新構成情報を含む制御フレーム内で、これらの間隔中の送信が切り取られる可能性があることを示してもよい。
【0048】
APとpSTAの間で低レイテンシセンシティブ・トラフィックが確立された場合、このトラフィックのトラフィックストリーム識別子とAPおよびpSTAの識別子とは、トランケーション後に送信されるPPDUに含まれる。
【0049】
同様に、別の実装では、非AP STAへの低レイテンシセンシティブ・トラフィックの存在を上位レイヤから通知されるAPは、それぞれのSTAとの低レイテンシセンシティブ・セッションを確立してもよい。この場合、APがLLSTSReservation内に含めることができる場合、プリエンプションがサポートされているかどうか、かつ、どのパラメータを使用するか(例えば精度)を示す。続いて、pSTAは、例えば与えられたOFDM制度で周期的リスニングが可能であるならば、それがパラメータを受け入れるかどうかを確認する。
IEEE 802.11規格で定義されているTSセットアップメカニズムをいくつか変更して再利用することで、低レイテンシセンシティブ・トラフィック情報と低レイテンシセンシティブ・トラフィックをセットアップできる。
IEEE 802.11規格で定義されているTSセットアップメカニズムをいくつか変更して再利用することで、低レイテンシセンシティブ・トラフィック情報と低レイテンシセンシティブ・トラフィックをセットアップできる。
【0050】
別の実施形態は、pSTAが起動され、追従送信を処理することができることが知られている特定の時間間隔でのみトランケーションを可能にする。この実施形態では、周期性またはレイテンシ要件のようなトラフィックストリームパラメータは、pSTAおよびAPによって、例えば通常のTSによって交換することができる。
しかしながら、プリエンプションパラメータは、特定に定義されたサービス期間、即ち、APと特定のpSTAの間のより目標とされたデータ交換が実行される時間間隔内に交換され、起動される。このような時間間隔の例として、TWT SP (ターゲット・ウェイク・タイム・サービス期間)がある。
しかしながら、プリエンプションパラメータは、特定に定義されたサービス期間、即ち、APと特定のpSTAの間のより目標とされたデータ交換が実行される時間間隔内に交換され、起動される。このような時間間隔の例として、TWT SP (ターゲット・ウェイク・タイム・サービス期間)がある。
【0051】
pSTAとAPは、低レイテンシセンシティブ・トラフィック特性に対応する潜在的な送信を実行できる間隔を確立する。セットアップフェーズでは、APとpSTA間のデータ交換の特性をネゴシエートできる（たとえば、pSTAからの送信がAPからのトリガによって先行される必要がある場合に）。さらに、上述のプリエンプション関連パラメータ、例えば、精度は、レイテンシトラフィック特性、および、APとpSTAの両方の能力ならびにBSS内からの他のトラフィック要件に応じて選択することができる。
選択されたパラメータは、APとpSTAの間でさらにネゴシエートすることができる。確立されたTWT SPの間、pSTAはまた、ネゴシエートされた一連のリンクの上で、メディア上で交換されたPPDUをリッスンすることができるように起動することをコミットする。この方法で確立された時間間隔中に、pSTAがPPDUの早期終了を観測した場合、pSTAは、切り取りを決定した直後に、PHY-CCAをアイドル状態に設定することが許可され、その後、それぞれの時間間隔内で定義されたさらなるルールに従う(つまり、プリエンプティブデータユニットを含むAPからの追従PPDU を待つか、pSTAからの送信をトリガするフレームを待つか、直接送信を開始する)。
選択されたパラメータは、APとpSTAの間でさらにネゴシエートすることができる。確立されたTWT SPの間、pSTAはまた、ネゴシエートされた一連のリンクの上で、メディア上で交換されたPPDUをリッスンすることができるように起動することをコミットする。この方法で確立された時間間隔中に、pSTAがPPDUの早期終了を観測した場合、pSTAは、切り取りを決定した直後に、PHY-CCAをアイドル状態に設定することが許可され、その後、それぞれの時間間隔内で定義されたさらなるルールに従う(つまり、プリエンプティブデータユニットを含むAPからの追従PPDU を待つか、pSTAからの送信をトリガするフレームを待つか、直接送信を開始する)。
【0052】
図18は、本開示に係る第1の通信デバイス100(AP)の第1の通信方式130のより詳細なフローチャートを示し、回路101によって実行されてもよい。このフローチャートでは、切り取りを実行するかどうかの決定に関する詳細を特に示す。
【0053】
最初のステップ131では、LLTSの指示は、APの上位MAC層(例えば、SME (システム管理エンティティ))から来てもよい。低レイテンシセッションを確立する一方で、トラフィック特性の1つは、他のトラフィックカテゴリよりも優先され、このトラフィックカテゴリのレイテンシ制約を満たすために、進行中の送信が切り取られる可能性があることである。
トランケーションケーパビリティをもつ低レイテンシトラフィックの通知は、(例えば、pSTAによって送信された要求フレームによって図8に示されるような)別のリンクを介してpSTAから送信されてもよい。
トランケーションケーパビリティをもつ低レイテンシトラフィックの通知は、(例えば、pSTAによって送信された要求フレームによって図8に示されるような)別のリンクを介してpSTAから送信されてもよい。
【0054】
ステップ132で、例えば、プリエンプションを実行する能力を示しているか、かつ/または、低レイテンシ交通ストリームセッションの確立に関与しており、このセッションがプリエンプティブトラフィックを処理することができ、セッションがアクティブであるかどうかが確認される場合、そのpSTAは、プリエンプティブ送信を受信する資格があることが意図されているかどうかが検証される。
これらの条件が満たされない場合、sSTAへの送信は継続され、満たされない場合は、ステップ133に続く。
これらの条件が満たされない場合、sSTAへの送信は継続され、満たされない場合は、ステップ133に続く。
【0055】
ステップ133において、pSTAが起動状態であるか否かが検証される。この検証はオプションである。欠落している場合、処理はステップ134または135のいずれかに直接進み、トランケーションを実行するか否かを判定する。この場合、例えば規格で、一方または他方のステップの選択を予め定義してもよい。ステップ135は、このような場合に好ましく、トリガフレームに基づいて、pSTAが起動状態であり、フォローアッププリエンプティブデータを送信可能であるか否かを容易に判定することができる。
STAが特定の間隔内で起動されるかどうかの情報は、対象起動時間間隔STAが起動されることをコミットする以前に交換されたフレーム内のSTAからの指示によって確立することができる。一実施形態では、低レイテンシトラフィックストリームセッションの一部として、または、追従予定セッション内で、送信が発生しそうであり、pSTAが起動することをコミットする時間間隔が定義される。これは、APがSTAの起動状態を知ることができるもう1つのメカニズムである。
STAが特定の間隔内で起動されるかどうかの情報は、対象起動時間間隔STAが起動されることをコミットする以前に交換されたフレーム内のSTAからの指示によって確立することができる。一実施形態では、低レイテンシトラフィックストリームセッションの一部として、または、追従予定セッション内で、送信が発生しそうであり、pSTAが起動することをコミットする時間間隔が定義される。これは、APがSTAの起動状態を知ることができるもう1つのメカニズムである。
【0056】
ステップ134および135は、TXOPの残りの継続時間がプリエンプティブ送信を可能にするか、または、STAからのプリエンプティブ送信をトリガすることを可能にするのに十分であるかどうかを判定することにつながる動作を実行している。さらに、これらの手順によって、フレームを即時通知で送信するか(通知送信がTXOP時間内に収まる場合)、フレームを遅延Ackで送信するか(これは次のTXOPで発生する)を決定する。
残りの継続時間が、少なくとも1つのプリエンプティブデータユニットまたはプリエンプティブデータユニットもしくはCF ENDフレームのスケジュールを送信するのに十分である場合、PHYへの切り取り指示プリミティブが発行され(ステップ136および137)、sPPDUは切り取られる。そうでない場合、sSTAへのSTA送信が継続される(ステップ138)。
したがって、ステップ132から135は、基本的に、「切り取りが意味をなす場合」によって、上記の何が表現されるかを判定する。ここでのトランケーション指示は、トランケーションを実行するために、MACおよび/またはPHYにトランケーションプリミティブを発行することを意味する。
残りの継続時間が、少なくとも1つのプリエンプティブデータユニットまたはプリエンプティブデータユニットもしくはCF ENDフレームのスケジュールを送信するのに十分である場合、PHYへの切り取り指示プリミティブが発行され(ステップ136および137)、sPPDUは切り取られる。そうでない場合、sSTAへのSTA送信が継続される(ステップ138)。
したがって、ステップ132から135は、基本的に、「切り取りが意味をなす場合」によって、上記の何が表現されるかを判定する。ここでのトランケーション指示は、トランケーションを実行するために、MACおよび/またはPHYにトランケーションプリミティブを発行することを意味する。
【0057】
ステップ139および140では、sPPDUが切り取られる。その後、ステップ141において、pPPDUがステップ131に示すようなLLTSと共に送信される。ステップ142において、IFSの後、ステップ131の1つに対応するLLTS IDを有するLLTSおよび/またはpPPDUに対応するトラフィックを含むプリエンプティブデータユニットを送信する必要性を示すトリガが送信される。
【0058】
図19は、トランケーションの場合のインターフェース、特にAP MACインターフェースとAP SMEインターフェースの間の関係を示す図である。
トランケーション通知付きの低レイテンシトラフィックは、SMEから来て、TruncationNotification.Requestとして図19でマークされたプリミティブによってMACに渡される。MACは、例えば、ステップ132～135に基づいて、トランケーションを実行できるか否かを判定する。この判定に基づいて、トランケーションを受け入れ、トランケーションを実行するためのさらなる指示をPHYに提供するか、トランケーション要求を拒否し、sSTAへの進行中の送信を継続する。
判定した結果は、図19でTruncationNotification.confirmとしてマークされたプリミティブにおいて、MACからSMEに送信される。
トランケーション通知付きの低レイテンシトラフィックは、SMEから来て、TruncationNotification.Requestとして図19でマークされたプリミティブによってMACに渡される。MACは、例えば、ステップ132～135に基づいて、トランケーションを実行できるか否かを判定する。この判定に基づいて、トランケーションを受け入れ、トランケーションを実行するためのさらなる指示をPHYに提供するか、トランケーション要求を拒否し、sSTAへの進行中の送信を継続する。
判定した結果は、図19でTruncationNotification.confirmとしてマークされたプリミティブにおいて、MACからSMEに送信される。
【0059】
図11は、本開示に係る第1の通信デバイス100(AP)の第1の通信方式120の他の実施形態のフローチャートを示す図であり、回路101によって実行されてもよい。
第1のステップ121で、APは、第2の通信デバイスとの進行中のデータユニットの交換中に、トランケーション通知を伴うLLTSの指示のようなトランケーション通知を受信する。第2のステップ122では、図18に記載されているようなトランケーション条件の同様の検証を実行した後、すなわち、トランケーション通知付きLLTSの受信者がプリエンプティブ送信を受信する資格があり、送信機会の残りの期間が少なくとも終了通知フレームを送信するのに十分である場合、APは、現在の送信機会の終了前に現在の送信機会の終了を示す終了通知を送信する。
第3のステップ123で、APは第3の通信デバイスと新たな送信機会を確立する。ここで、前記新たな送信機会の継続時間は、少なくとも、プリエンプティブデータの第3の通信デバイスへの送信、および/または、第3の通信デバイスからのプリエンプティブデータの受信をカバーする。sPPDUの最初の意図された終わりの前に新しい送信機会が得られる場合、一実施形態では、pSTAの場合、新たに得られるTXOPの内容を、トランケーションを必要とするLLTSに対応するトラフィックのみを含むように制限することが提案される。
あるいは、sSTAのために切り取りされたトラフィックの要件に応じて、新しいTXOPは、pSTAのためのLLTSと、元々意図されたTXOPからのsSTAからの残りのトラフィックのみに制限されるように定義することができる。
第1のステップ121で、APは、第2の通信デバイスとの進行中のデータユニットの交換中に、トランケーション通知を伴うLLTSの指示のようなトランケーション通知を受信する。第2のステップ122では、図18に記載されているようなトランケーション条件の同様の検証を実行した後、すなわち、トランケーション通知付きLLTSの受信者がプリエンプティブ送信を受信する資格があり、送信機会の残りの期間が少なくとも終了通知フレームを送信するのに十分である場合、APは、現在の送信機会の終了前に現在の送信機会の終了を示す終了通知を送信する。
第3のステップ123で、APは第3の通信デバイスと新たな送信機会を確立する。ここで、前記新たな送信機会の継続時間は、少なくとも、プリエンプティブデータの第3の通信デバイスへの送信、および/または、第3の通信デバイスからのプリエンプティブデータの受信をカバーする。sPPDUの最初の意図された終わりの前に新しい送信機会が得られる場合、一実施形態では、pSTAの場合、新たに得られるTXOPの内容を、トランケーションを必要とするLLTSに対応するトラフィックのみを含むように制限することが提案される。
あるいは、sSTAのために切り取りされたトラフィックの要件に応じて、新しいTXOPは、pSTAのためのLLTSと、元々意図されたTXOPからのsSTAからの残りのトラフィックのみに制限されるように定義することができる。
【0060】
図12は、本開示に係る第3の通信デバイス300(pSTA)の第3の通信方式310の実施形態のフローチャートを示し、回路301によって実行されてもよい。
第1のステップ311で、pSTAは第2の通信デバイス200(sSTA)にアドレス指定されたデータユニットを受信する。第2のステップ312において、pSTAは、データユニットの進行中の伝送の予想される継続時間および/または進行中の伝送機会を示す継続時間指示を判定する。このステップの一部として、pSTAは、受信パケットのプリアンブル内の長さ情報から、進行中のPPDUの継続時間をチェックすることができ、これは、PPDUの早期終了が発生するかどうかを判定する際に、さらに使用することができる。
また、このステップの一部として、データ交換が行われる送信機会の継続時間指示は、MACヘッダまたはPHYプリアンブルの指示から判定れる。この情報は、pSTAがプリエンプティブデータユニットまたはプリエンプティブデータユニットへの応答を送信する必要があり、したがってTXOP境界を遵守するために送信パラメータを選択する必要がある場合に、さらに使用される。
第3のステップで、pSTAはデータユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定する。次に、第4のステップ314で、pSTAは、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に、プリエンプティブデータユニットを第1の通信デバイスから受信し、かつ/または、第1の通信デバイスに送信する。
第1のステップ311で、pSTAは第2の通信デバイス200(sSTA)にアドレス指定されたデータユニットを受信する。第2のステップ312において、pSTAは、データユニットの進行中の伝送の予想される継続時間および/または進行中の伝送機会を示す継続時間指示を判定する。このステップの一部として、pSTAは、受信パケットのプリアンブル内の長さ情報から、進行中のPPDUの継続時間をチェックすることができ、これは、PPDUの早期終了が発生するかどうかを判定する際に、さらに使用することができる。
また、このステップの一部として、データ交換が行われる送信機会の継続時間指示は、MACヘッダまたはPHYプリアンブルの指示から判定れる。この情報は、pSTAがプリエンプティブデータユニットまたはプリエンプティブデータユニットへの応答を送信する必要があり、したがってTXOP境界を遵守するために送信パラメータを選択する必要がある場合に、さらに使用される。
第3のステップで、pSTAはデータユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定する。次に、第4のステップ314で、pSTAは、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に、プリエンプティブデータユニットを第1の通信デバイスから受信し、かつ/または、第1の通信デバイスに送信する。
【0061】
一般に、PHYデータユニットの長さは、PPDUのPHYプリアンブル内で示される情報であり、受信側がPPDUの長さを計算し、PPDUの進行中の送信でメディアがビジーである時間を暗黙的に計算できるようにする。さらに、送信機会の継続時間は、進行中のPPDUより多くの交換を意味する可能性があり、PHYおよび/またはMACヘッダの中で示されてもよい。
本開示のコンテキストでは、切り取られたデータユニットの長さは、第1の通信デバイスによって第2の通信デバイスに効果的に送信されたデータユニットの長さを参照する。さらに、切り取られたデータユニットの意図された長さは、データユニットの意図された長さを第2の通信デバイスに参照させ、すなわち、切り取りを考慮せず、第1の通信デバイスから第2の通信デバイスに送られるPPDUのプリアンブル内の情報に対応する。
データユニットの継続時間は、所与の長さを持つデータユニットの処理時間を参照し、2つの間の依存性は規格の中で与えられ、従って、データユニットを参照する場合、長さと継続時間という用語は交換可能に使用される。さらに、TXOPの意図された期間は、トランケーションが考慮される前に、第1の通信デバイスと第2の通信デバイスの間の通信のために得られた送信機会の意図された期間を参照する。
本開示のコンテキストでは、切り取られたデータユニットの長さは、第1の通信デバイスによって第2の通信デバイスに効果的に送信されたデータユニットの長さを参照する。さらに、切り取られたデータユニットの意図された長さは、データユニットの意図された長さを第2の通信デバイスに参照させ、すなわち、切り取りを考慮せず、第1の通信デバイスから第2の通信デバイスに送られるPPDUのプリアンブル内の情報に対応する。
データユニットの継続時間は、所与の長さを持つデータユニットの処理時間を参照し、2つの間の依存性は規格の中で与えられ、従って、データユニットを参照する場合、長さと継続時間という用語は交換可能に使用される。さらに、TXOPの意図された期間は、トランケーションが考慮される前に、第1の通信デバイスと第2の通信デバイスの間の通信のために得られた送信機会の意図された期間を参照する。
【0062】
一態様によれば、本開示は、TXOP境界および継続時間情報に関するソリューションを提示する。現在、継続時間情報は、取得されたTXOP内で交換される保留中のPPDUの継続時間、すなわち、継続時間情報を運ぶPPDUに続くPPDUに基づいて設定される。ただし、トランケーションの場合は、ノートランケーション(oTXTIMEとして以下に示す)、および/または、トランケーションが実行された後の残りの時間(rTXTIMEとして以下に示す)を想定して、sSTA用に意図された元のパケットの意図した長さである追加のパラメータを考慮する必要がある。
これは、誤ったNAVを設定することを防ぐために、元のPPDUまたはTXOP情報を失った可能性があるSTAに必要かもしれない。さらに、多くのSTAが期待されるPPDUの終わりまで待機時間にあるかもしれないので、不公平さや混乱を避けるために、新しい継続時間設定とpPPDU長さが選ばれるべきである。同様に、複数フレーム交換のTXOPの場合、継続時間は、切り取られたPPDUの推定処理時間を考慮に入れて、共有されるTXOPの同じ終端を指すべきである。
これは、誤ったNAVを設定することを防ぐために、元のPPDUまたはTXOP情報を失った可能性があるSTAに必要かもしれない。さらに、多くのSTAが期待されるPPDUの終わりまで待機時間にあるかもしれないので、不公平さや混乱を避けるために、新しい継続時間設定とpPPDU長さが選ばれるべきである。同様に、複数フレーム交換のTXOPの場合、継続時間は、切り取られたPPDUの推定処理時間を考慮に入れて、共有されるTXOPの同じ終端を指すべきである。
【0063】
一実施形態では、切り取られたPPDUは、そのTXOP内の最後であると考えられる。図13は、そのような実施形態を示す図である。特に、図6と図7に示されている第1と第2のシナリオでは、pPPDUまたはpPPDU 1がTXOPホルダからのDL PPDUである場合、継続時間情報は容易に利用可能である。プリエンプション指示を受信すると、APは最も早い潜在PPDUトランケーション時間を判定する。
これに基づいて、PPDUの残りの期間であるrTXTIMEを計算し、pSTA用のPPDUの推定所要時間を決定する。
TXTIME(pPPDU) + IFS1 < rTXTIME (式１)の場合、
pSTAに対するpPPDUを送信できる。(式１)において、TXTIME(pPPDU)は、pPPDU送信の継続時間を表し、IFS1は、SIFSとして選択されるか、あるいは、より短い、例えば、RIFSとして選択されることができる。この場合、受信モードと送信モードの間で切り替える必要はない。pPPDUに含まれるMPDUのMACヘッダにおける継続時間指示は、この場合、
dp= rTXTIME － TXTIME(pPPDU) － IFS1と等しくなる。
これに基づいて、PPDUの残りの期間であるrTXTIMEを計算し、pSTA用のPPDUの推定所要時間を決定する。
TXTIME(pPPDU) + IFS1 < rTXTIME (式１)の場合、
pSTAに対するpPPDUを送信できる。(式１)において、TXTIME(pPPDU)は、pPPDU送信の継続時間を表し、IFS1は、SIFSとして選択されるか、あるいは、より短い、例えば、RIFSとして選択されることができる。この場合、受信モードと送信モードの間で切り替える必要はない。pPPDUに含まれるMPDUのMACヘッダにおける継続時間指示は、この場合、
dp= rTXTIME － TXTIME(pPPDU) － IFS1と等しくなる。
【0064】
TXOP境界がすべてのSTAによって理解されることを保証するための追加のオプションの手段は、pPPDUをPPDUの元の時間(この場合dp= 0)にパッドすることである。この場合、MACヘッダをデコードできなかったSTAは、正しいTXOP境界を待つのではなく、pPPDUの早期終了時にバックオフ手順を開始することを妨げられる。
【0065】
同様に、別の実施形態では、特に図7に示された第2のシナリオの場合、pPPDUが確認応答を必要とするフレームを含む場合、APは、即時Ackを同じ間隔内で送信できるかどうかを判定する。したがって、
TXTIME (pPPDU1) + IFS1 + SIFS + TXTIME(pPPDU2) < rTXTIME(式２)の場合、
ここで、pPPDU2はACKフレームを運ぶPPDUであり、pPPDU1内のMPDUのAckポリシーをNormal Ackに設定することができ、pSTAはpPPDU1の受信からSIFS内で応答する。(式２)では、TXTIME (pPPDU1)とTXTIME (pPPDU2) はそれぞれpPPDU1とPPDU2の送信時間を表し、上記と同様にSIFSまたはRIFSとして設定でき、SIFS は短いフレーム間空間期間であるIFS1はフレーム間空間期間である。
そうしないと、APはAckポリシーをdelayed Ackに設定し、pSTAは適切な要求の後、将来の送信機会内に確認応答を送信する。(式２)もまた、PPDU1がトリガフレームを運ぶことを意図している。この場合、APは、自体がトリガフレームを送信し、pSTAが応答フレームを送信するのに十分な時間が、残りのrTXTIME内にあるかどうかを判定する。前の実施例と同様に、TXOP境界よりも早く終了の場合のpPPDU2のパディングは、追加の保護を確実にする。
TXTIME (pPPDU1) + IFS1 + SIFS + TXTIME(pPPDU2) < rTXTIME(式２)の場合、
ここで、pPPDU2はACKフレームを運ぶPPDUであり、pPPDU1内のMPDUのAckポリシーをNormal Ackに設定することができ、pSTAはpPPDU1の受信からSIFS内で応答する。(式２)では、TXTIME (pPPDU1)とTXTIME (pPPDU2) はそれぞれpPPDU1とPPDU2の送信時間を表し、上記と同様にSIFSまたはRIFSとして設定でき、SIFS は短いフレーム間空間期間であるIFS1はフレーム間空間期間である。
そうしないと、APはAckポリシーをdelayed Ackに設定し、pSTAは適切な要求の後、将来の送信機会内に確認応答を送信する。(式２)もまた、PPDU1がトリガフレームを運ぶことを意図している。この場合、APは、自体がトリガフレームを送信し、pSTAが応答フレームを送信するのに十分な時間が、残りのrTXTIME内にあるかどうかを判定する。前の実施例と同様に、TXOP境界よりも早く終了の場合のpPPDU2のパディングは、追加の保護を確実にする。
【0066】
rTXTIMEは、PPDUの終端まで計算でき、または、PPDUの後の小さなマージンが許容されるように計算することもできることが知られている。この変動は、ある閾値によって制限され、それは、例えば、TXOP制限拡張と同様に、または単に、RX PHYのウェイクアップ時間の公称値をカバーするように選択され得る。
【0067】
さらに、pPPDU1がCF-ENDフレームを含んでいる場合、pSTAはpPPDU2を送信するために競合する必要があるかもしれないことが知られている。pSTAは、oTXTIMEの終端(およびオプションでマージン)を遵守できる場合、pPPDU2を送信してもよい。
【0068】
APとsSTAとの間のデータ交換に対応する送信機会内に、pSTAがプリエンプティブデータユニットを送信するか、プリエンプティブデータユニットに応答することを可能にするために、以下の解決策が考えられる。
1つの任意の解決策は、トランケーション後に最初のPPDU内でフレームのようなトリガを送信し、pSTAを識別し、それにNAVをリセットしてプリエンプティブデータユニットを送信することを要求することである。また、BSS内NAVルールは、sPPDUの後にプリエンプト・テーブル指示で直接アドレス指定されるpSTAが、BSS内NAVを無視することを可能にするように適応されてもよい。
さらに、それ自体に対応する低レイテンシトラフィックの何らかの指示が存在する場合、例えば、送信が切り取られる可能性のあるインターバルとして以前に示された時間間隔の間にPPDUが実行されるならば、この時間間隔がAPとpSTAの間で交渉(ネゴシエート)されたスケジュールに対応するならば、APとpSTAの間のLLTSセットアップに対応するトラフィック識別子の指示がpPPDU内に存在するならば、LLTSに対応する割り当て識別子が、sPPDUまたは制御フレーム内に存在するならば、アクティブ低レイテンシセンシティブ・トラフィックストリームセッションに含まれるpSTAは、PPDUの意図的な早期終了を判定するNAVをリセットすることができる。
いずれの場合も、STAはBSS間ルールに従う必要があるかもしれない。
1つの任意の解決策は、トランケーション後に最初のPPDU内でフレームのようなトリガを送信し、pSTAを識別し、それにNAVをリセットしてプリエンプティブデータユニットを送信することを要求することである。また、BSS内NAVルールは、sPPDUの後にプリエンプト・テーブル指示で直接アドレス指定されるpSTAが、BSS内NAVを無視することを可能にするように適応されてもよい。
さらに、それ自体に対応する低レイテンシトラフィックの何らかの指示が存在する場合、例えば、送信が切り取られる可能性のあるインターバルとして以前に示された時間間隔の間にPPDUが実行されるならば、この時間間隔がAPとpSTAの間で交渉(ネゴシエート)されたスケジュールに対応するならば、APとpSTAの間のLLTSセットアップに対応するトラフィック識別子の指示がpPPDU内に存在するならば、LLTSに対応する割り当て識別子が、sPPDUまたは制御フレーム内に存在するならば、アクティブ低レイテンシセンシティブ・トラフィックストリームセッションに含まれるpSTAは、PPDUの意図的な早期終了を判定するNAVをリセットすることができる。
いずれの場合も、STAはBSS間ルールに従う必要があるかもしれない。
【0069】
別の実施形態では、切り取られたPPDUは、そのTXOP内の最後ではなかったと考えられる。例えば、TXOPはsSTAからのAckに対する応答時間を含んでいた。切り取られたPPDUが、TXOPの最後ではないが、例えばAck / Block Ackなどによって元々従うべきであるとき、可能な操作が図14に示されている。意図されたpPPDU1の継続時間が式(1)を満たすことができるが、式(2)を満たすことができない場合、rTXTIMEからいくらかのマージンを引いて、Ackを含むpPPDU2が終了のSIFS内に送信されるまで、pPPDUはパディングされる。
pPPDU2の終端がTXOP制限内にあり、pPPDUの終端のSIFS後のpPPDU2の開始が他のSTAによってデコードされるようにマージンを選択して、PPDUの長さに関する正しい情報を取得できる。
pPPDU2の終端がTXOP制限内にあり、pPPDUの終端のSIFS後のpPPDU2の開始が他のSTAによってデコードされるようにマージンを選択して、PPDUの長さに関する正しい情報を取得できる。
【0070】
TXOPの残り時間に対するpPPDU2の長さに応じた、2つの例を図14に示す。
図14Aは、元のTXOPがsPPDU後にAck時間を含み、かつ、pPPDU2の送信時間が元の意図したAckの送信時間よりも小さい場合の振る舞い、すなわち、TXTIME(pPPDU2) < TXTIME(Ack)の場合の行動を示す図である。
図14Aに示された実施形態では、pPPDU1は、pPPDU1の送信を、sPPDUの当初意図された終端と整列させるようにパディングされる。このパディングの理由は、PPDU内省電力モードになっているレガシーSTAとSTAを含むすべてのSTAが、APからのPPDUによるメディア占有の終端への同一の参照を持つようにし、コリジョンを避けるためである。
図14Bは、元のTXOPがsPPDUの後にAck時間を含み、pPPDU2の送信時間が元の意図したTXTIME(pPPDU2) >TXTIME(Ack)の送信時間よりも大きい場合の振る舞いを示す図である。
この場合、コリジョンの危険性がある間、pPPDU2送信は、最初に意図されたsPPDUの終端の前に開始することが許される可能性がある。TXOPがsPPDU、1つのACK、および適用可能なSIFSのみを含むように定義されていることは、1つの例に過ぎないことに注意する。
ここで説明される記述と技術は、送信機会がsPPDUの継続時間より長い場合に一般的に適用可能である。より正確には、pPPDU2と適用可能なSIFSの継続時間が、送信機会境界とsPPDUの意図した継続時間の差より小さいとき、切り取りなしで、あるいは、同等に、sPPDUとSIFS内の継続時間指示の差がpPPDUの継続時間より長いとき、これをsPPDUの意図した当初の終端に合わせるために、pPPDU1のパディングを実行することが推奨される。
図14Aは、元のTXOPがsPPDU後にAck時間を含み、かつ、pPPDU2の送信時間が元の意図したAckの送信時間よりも小さい場合の振る舞い、すなわち、TXTIME(pPPDU2) < TXTIME(Ack)の場合の行動を示す図である。
図14Aに示された実施形態では、pPPDU1は、pPPDU1の送信を、sPPDUの当初意図された終端と整列させるようにパディングされる。このパディングの理由は、PPDU内省電力モードになっているレガシーSTAとSTAを含むすべてのSTAが、APからのPPDUによるメディア占有の終端への同一の参照を持つようにし、コリジョンを避けるためである。
図14Bは、元のTXOPがsPPDUの後にAck時間を含み、pPPDU2の送信時間が元の意図したTXTIME(pPPDU2) >TXTIME(Ack)の送信時間よりも大きい場合の振る舞いを示す図である。
この場合、コリジョンの危険性がある間、pPPDU2送信は、最初に意図されたsPPDUの終端の前に開始することが許される可能性がある。TXOPがsPPDU、1つのACK、および適用可能なSIFSのみを含むように定義されていることは、1つの例に過ぎないことに注意する。
ここで説明される記述と技術は、送信機会がsPPDUの継続時間より長い場合に一般的に適用可能である。より正確には、pPPDU2と適用可能なSIFSの継続時間が、送信機会境界とsPPDUの意図した継続時間の差より小さいとき、切り取りなしで、あるいは、同等に、sPPDUとSIFS内の継続時間指示の差がpPPDUの継続時間より長いとき、これをsPPDUの意図した当初の終端に合わせるために、pPPDU1のパディングを実行することが推奨される。
【0071】
式(2)が順守され、AckがoTXTIME内に送信される場合、APはCF_endフレームを送信してTXOPを終了してもよい。
【0072】
pSTAがチャネルにアクセスし、sSTAのTXOPでpPPDU2を送信できるようにするために、ここでは、TXOPが取得された制御フレームがpSTAのユーザ情報、例えば、割り当て識別子、そして可能であれば空のリソース割当フィールドまたはプリエンプションフラグの指示のいずれかを含むプリエンプト可能な情報、および、低遅延セッションセットアップからpSTAで既知の低レイテンシトラフィックストリーム識別子の低レイテンシトラフィック識別子を含む制御フレームを含む実施形態で提案されている。
このような制御フレームの実装例は、上述のようにpSTAに関するユーザ情報フィールドを含むように修正されたRTSトリガである。このようなフレームは、図14Aおよび図14Bに示すように、拡張RTSと呼ばれる。pSTAは、eRTSに応答することができ、これは、pSTAが起動され、プリエンプティブ送信を受信する可能性があるという事実に関する追加情報をAPに提供し、そして、STAからのプリエンプティブ送信が実行される可能性があることを各チャネル内のSTAに通知することができる。
このような制御フレームの実装例は、上述のようにpSTAに関するユーザ情報フィールドを含むように修正されたRTSトリガである。このようなフレームは、図14Aおよび図14Bに示すように、拡張RTSと呼ばれる。pSTAは、eRTSに応答することができ、これは、pSTAが起動され、プリエンプティブ送信を受信する可能性があるという事実に関する追加情報をAPに提供し、そして、STAからのプリエンプティブ送信が実行される可能性があることを各チャネル内のSTAに通知することができる。
【0073】
TPXTIME (pPPDU2) > TXTIME (Ack_sSTA)の場合、pPPDU1はsPPDUの前に終了できるが、pPPDU2送信は、
(TXTIME(pPPDU1) + IFS1 + TXTIME(pPPDU2) < (rTXTIME + TXTIME Ack_sSTA) である限り、非パッドpPDU1の後にSIFSを開始できる。
(TXTIME(pPPDU1) + IFS1 + TXTIME(pPPDU2) < (rTXTIME + TXTIME Ack_sSTA) である限り、非パッドpPDU1の後にSIFSを開始できる。
【0074】
プリエンプティブデータユニットは、進行中の送信を切り取るので、無線メディア上に不公平性や悪用を生じないようにルールを考慮すべきである。この目的のために、pPPDU1および/またはpPPDU2の中で運ばれるプリエンプティブ送信が、トランケーションを必要とするLLTSにのみ対応することが、ここでは実施形態として提案される。
さらに、pSTAからのpPPDUの送信を要求するトリガフレームは、pSTAからのpPPDU内に含まれるトラフィックがLLTSに対応する唯一のものであるという指示を運ぶように定義することもできる。さらなる実施形態では、pSTAトラフィックを制限するが、sSTAの残りのトラフィックの少なくとも一部をTXOP内で送信できるようにすることが提案される。例えば、TB PPDUモードでsSTAからのデータユニットと同時にpPPDU2を送信できるようにする。
プリエンプティブデータユニットに対応するデータ交換の終了後、TXOP内に残りの時間がある場合、sSTAとAP間のデータ交換を再開する必要がある。
さらに、pSTAからのpPPDUの送信を要求するトリガフレームは、pSTAからのpPPDU内に含まれるトラフィックがLLTSに対応する唯一のものであるという指示を運ぶように定義することもできる。さらなる実施形態では、pSTAトラフィックを制限するが、sSTAの残りのトラフィックの少なくとも一部をTXOP内で送信できるようにすることが提案される。例えば、TB PPDUモードでsSTAからのデータユニットと同時にpPPDU2を送信できるようにする。
プリエンプティブデータユニットに対応するデータ交換の終了後、TXOP内に残りの時間がある場合、sSTAとAP間のデータ交換を再開する必要がある。
【0075】
別の実施形態では、図8に示す第3のシナリオのスキームに基づいてAPに更新を送信する必要があるpSTAは、まず、sPPDUプリアンブルをデコードし、可能であれば、これに含まれるMPDUのMACヘッダをデコードして、ちょうど切り取られたPPDUとTXOPの最初の意図された継続時間を決定する。この情報に基づいて、sPPDUの早期終了が発生し、結果的に送信機会の残りの継続時間が発生したと判定される。
これに基づいて、pPPDUがoTXTIMEを超えることなく送信できるかどうかを推定する。また、基本的には式(1)に従い、対応するIFS1とする。この場合、IFS1は少なくともSIFSと同じ長さになってよい(小さくはない)。
これに基づいて、pPPDUがoTXTIMEを超えることなく送信できるかどうかを推定する。また、基本的には式(1)に従い、対応するIFS1とする。この場合、IFS1は少なくともSIFSと同じ長さになってよい(小さくはない)。
【0076】
pPPDUを送信する場合、継続時間指示は次のように設定される。
Duration indication (pPPDU) = d + oTXTIME - IFS1 - RXTlME(pPPDU) - RXTlME(sPPDU)
ここで、dはsPPDUのMACヘッダから判定される継続時間指示であり、sPPDUがTXOPの最後であった場合、または、厳密に正であった場合は0である。oTXTIMEは、sPPDUのPHYプリアンブルの長さフィールドの情報に基づいて決定される。RXTIME (sPPDU)は、ここでは、目的のsPPDUからsSTAへのAPの有効な送信時間を表し、pSTAの観点からは、sPPDUパケットを検出してから早期終了を検出するまでの経過時間を表す。
RXTIME (pPPDU)は、pSTAからAPに送信されるpPPDUの推定所要時間を表す。pSTAは、上記の式を満たすために、pPPDUの送信パラメータを選択してもよい。
Duration indication (pPPDU) = d + oTXTIME - IFS1 - RXTlME(pPPDU) - RXTlME(sPPDU)
ここで、dはsPPDUのMACヘッダから判定される継続時間指示であり、sPPDUがTXOPの最後であった場合、または、厳密に正であった場合は0である。oTXTIMEは、sPPDUのPHYプリアンブルの長さフィールドの情報に基づいて決定される。RXTIME (sPPDU)は、ここでは、目的のsPPDUからsSTAへのAPの有効な送信時間を表し、pSTAの観点からは、sPPDUパケットを検出してから早期終了を検出するまでの経過時間を表す。
RXTIME (pPPDU)は、pSTAからAPに送信されるpPPDUの推定所要時間を表す。pSTAは、上記の式を満たすために、pPPDUの送信パラメータを選択してもよい。
【0077】
pPPDU継続時間は、たとえ送信機会の境界が依然として順守される場合であっても、sPPDUの意図された終わりを超えないように選択されることが好ましい。すなわち、元のTXOP期間がoTXTIME、1つのSIFSおよび超過時間の合計よりも大きい。その理由は、レガシーSTAは正しい継続時間情報を復号化することができず、プリアンブル内のレガシー長情報に基づいてチャネルへのアクセスを控えるだけであるからである。
したがって、oTXTIME中はチャネルへのアクセスを控え、その後はチャネルをリッスンし、アイドル状態の場合は、バックオフカウンタが0のときに競合するか、送信する可能性がある。pPPDU送信が、sPPDUが送信されたものとは異なるパラメータで行われる場合、例えば、APとは異なる空間方向、異なる電力、または、pSTA側から送信が行われる場合、レガシーSTAは、アイドル状態になるチャネルを誤検出し、競合を開始するか、あるいは、それらのバックオフカウンタが0である場合でさえ、送信を開始する可能性がある。
この伝送は、pPPDU伝送と衝突し、従って、関与する両者にとって有害である。この課題を避けるために、pPPDUの伝送は、sPPDUの意図された境界を超えないことが提案される。あるいは、超過した場合は、1より小さい時間間隔にする必要がある。これにより、コリジョンが発生する可能性がある。この時間間隔は、SIFS、または、規格制限内のSIFS許容範囲内の別のSTAからの送信がチャネルにアクセスする可能性がある場合に、sPPDUの推定終了後の最短継続時間に対応するSIFSおよびスロット時間の関数とすることができる。
したがって、oTXTIME中はチャネルへのアクセスを控え、その後はチャネルをリッスンし、アイドル状態の場合は、バックオフカウンタが0のときに競合するか、送信する可能性がある。pPPDU送信が、sPPDUが送信されたものとは異なるパラメータで行われる場合、例えば、APとは異なる空間方向、異なる電力、または、pSTA側から送信が行われる場合、レガシーSTAは、アイドル状態になるチャネルを誤検出し、競合を開始するか、あるいは、それらのバックオフカウンタが0である場合でさえ、送信を開始する可能性がある。
この伝送は、pPPDU伝送と衝突し、従って、関与する両者にとって有害である。この課題を避けるために、pPPDUの伝送は、sPPDUの意図された境界を超えないことが提案される。あるいは、超過した場合は、1より小さい時間間隔にする必要がある。これにより、コリジョンが発生する可能性がある。この時間間隔は、SIFS、または、規格制限内のSIFS許容範囲内の別のSTAからの送信がチャネルにアクセスする可能性がある場合に、sPPDUの推定終了後の最短継続時間に対応するSIFSおよびスロット時間の関数とすることができる。
【0078】
第3のシナリオのpSTAがpPPDUを送信できるように、BSS内NAVを適合させることができる。プリエンプト可能フラグ付きで送信されたPPDUの後、pSTAはBSS内NAVを無視できるが、少なくともPHYプリアンブルを正しくデコードし、リンク上のTXOP継続時間に関する正しい情報を持っている場合、直接アドレス指定された場合はBSS間ルールに従う必要があってもよい。
さらに、もし自身に対応する低レイテンシトラフィックの何らかの指示が存在するならば、例えば、もしPPDU送信が、送信が切り取られる可能性があるインターバルとして以前に示されたインターバルの間に実行されるならば、もしそのインターバルがAPとpSTAとの間で交渉されたスケジュールに対応するならば、もしAPとpSTAとの間のLLTSセットアップに対応するトラフィック識別子の指示がpPPDU内に存在すれば、もしLLTSに対応する割り当て識別子がsPPDU内に存在するならば、あるいは、もし異なるリンク上で交渉が行われたならば、アクティブ低レイテンシセンシティブ・トラフィックストリームセッションに関与するpSTAは、PPDUの意図的な早期終了を決定するNAVをリセットすることができる。
さらに、もし自身に対応する低レイテンシトラフィックの何らかの指示が存在するならば、例えば、もしPPDU送信が、送信が切り取られる可能性があるインターバルとして以前に示されたインターバルの間に実行されるならば、もしそのインターバルがAPとpSTAとの間で交渉されたスケジュールに対応するならば、もしAPとpSTAとの間のLLTSセットアップに対応するトラフィック識別子の指示がpPPDU内に存在すれば、もしLLTSに対応する割り当て識別子がsPPDU内に存在するならば、あるいは、もし異なるリンク上で交渉が行われたならば、アクティブ低レイテンシセンシティブ・トラフィックストリームセッションに関与するpSTAは、PPDUの意図的な早期終了を決定するNAVをリセットすることができる。
【0079】
継続時間インジケータは、好ましくは、pPPDU1のヘッダ内で送信される。送信される継続時間指示は、決定がなされたものに基づいたものと正確に同じではない(概念的には似ているが、異なる形態を持つことができる。例えば、pPPDUが完全なpPPDU継続時間でoTXTIME内に収まるかどうかを決定するのに対し、送信されたフレーム内に現れる指示はpPPDUの終端に関してのものである)。
【0080】
さらに別の実施形態で使用され得るAPおよびTXOP共有態様からの以下のチャネルアクセスについて説明する。
TXOPは、TXOPのプライマリACと呼ばれる特定のアクセスカテゴリのトラフィックに対してAPによって取得されている。異なるACでpSTAのトラフィックとTXOPを共有できるようにするために、実施例では以下の解決策を想定することができる。
TXOPは、TXOPのプライマリACと呼ばれる特定のアクセスカテゴリのトラフィックに対してAPによって取得されている。異なるACでpSTAのトラフィックとTXOPを共有できるようにするために、実施例では以下の解決策を想定することができる。
【0081】
図15は、TXOPトランケーションおよびリセットを用いた実施形態の図である。
APはpPPDU1内でCF_endを送信し、これによって現在のTXOPが終了する。その後、APはpSTAの低レイテンシトラフィックのACをメディアと競合し、メディアが空いている場合は新しいTXOPを取得する。oTXTIMEの前に新たなTXOPが取得された場合、最初のpPPDU1がoTXTIME境界で整列されたpSTAに送信され、pPPDU2内で送信が継続される。
これは、元のPPDUの予想される送信中に待機モードになっていたSTAへの新たなTXOP継続時間情報を示す。oTXTIMEの後に新しいTXOPが取得された場合、PPDU分割は必要ない。新しいTXOPはpSTAのACのために得られるが、sSTAのための切り取られたトラフィックのための追加の共有機会を含んでもよい。
APはpPPDU1内でCF_endを送信し、これによって現在のTXOPが終了する。その後、APはpSTAの低レイテンシトラフィックのACをメディアと競合し、メディアが空いている場合は新しいTXOPを取得する。oTXTIMEの前に新たなTXOPが取得された場合、最初のpPPDU1がoTXTIME境界で整列されたpSTAに送信され、pPPDU2内で送信が継続される。
これは、元のPPDUの予想される送信中に待機モードになっていたSTAへの新たなTXOP継続時間情報を示す。oTXTIMEの後に新しいTXOPが取得された場合、PPDU分割は必要ない。新しいTXOPはpSTAのACのために得られるが、sSTAのための切り取られたトラフィックのための追加の共有機会を含んでもよい。
【0082】
【0083】
一般に、任意のMACデータユニットは、この特定のデータユニットへの確認応答のための振る舞いを定義するAckポリシーフィールドを保持する。このフィールドの設定には、次の3つの関連オプションがある。
i)「通常肯定応答または暗黙的ブロック肯定応答」:受信者は、データユニットまたは複数のデータユニットが受信された後に、確認応答またはブロック確認応答を送信する。つまり、このAckポリシーを持つ1つ以上のデータユニットを保持するPPDUが終了すると、PPDUが終了した後に確認またはBlock確認がSIFSに送信される。
ii) "No Ack": 受信者はデータユニットの受信時に動作を実行しない。
iii) "Block Ack": 受信者はデータユニットの受信時に動作を実行しない。ただし、受信者は受信状態を内部的に記録する場合を除く。受信者は、将来、ブロック確認応答で応答するブロック確認要求フレームを期待することができる。これは、ブロック確認応答フレームを保持するPPDUの終了後のSIFSである。
i)「通常肯定応答または暗黙的ブロック肯定応答」:受信者は、データユニットまたは複数のデータユニットが受信された後に、確認応答またはブロック確認応答を送信する。つまり、このAckポリシーを持つ1つ以上のデータユニットを保持するPPDUが終了すると、PPDUが終了した後に確認またはBlock確認がSIFSに送信される。
ii) "No Ack": 受信者はデータユニットの受信時に動作を実行しない。
iii) "Block Ack": 受信者はデータユニットの受信時に動作を実行しない。ただし、受信者は受信状態を内部的に記録する場合を除く。受信者は、将来、ブロック確認応答で応答するブロック確認要求フレームを期待することができる。これは、ブロック確認応答フレームを保持するPPDUの終了後のSIFSである。
【0084】
したがって、進行中のデータユニットの交換が切り取られ、少なくとも1つのデータユニットがそのAckポリシーとして「通常のAckまたは暗黙のBlock Ack」を定義する場合、確認応答は、切り取られたPPDUに応答して送信される。これにより、プリエンプティブデータユニットの別の通信デバイス(pSTA)への送信が明らかに停止または妨げられる。
確認応答は、pPPDUが送信される前に受信される必要があるか、あるいは、望ましくないpPPDUと確認応答のコリジョンに達するかの何れかである。この課題を図16Aに示す。
確認応答は、pPPDUが送信される前に受信される必要があるか、あるいは、望ましくないpPPDUと確認応答のコリジョンに達するかの何れかである。この課題を図16Aに示す。
【0085】
このため、切り取られることがあるデータユニットの交換内の任意のデータユニットのAckポリシーは、「Ackなし」または「Block Ack」のAckリシーを使用する。したがって、図16Bに示すように、sSTAからAPへの確認通知は、回避されるか、要求に応じて提供される。
【0086】
別の実施形態によれば、トランケーションが必要とされ得るTXOPを確立する場合(例えば、アクティブセッションを有するRTA STAがある場合)、これは、MU TXOPとして行われ、MU RTSはsSTAとpSTAの両方を示す。トランケーションの後、pPPDUと残りのsPPDUのフラグメントの同時伝送が送信されるが、上述のようにoTXTIME境界を遵守するために、適切なパディングが選択される。
この場合、pPPDU1は、図14Aおよび図14Bに示されている規則および対応する方程式に基づいた所要時間情報を有するMU PPDUである。
この場合、pPPDU1は、図14Aおよび図14Bに示されている規則および対応する方程式に基づいた所要時間情報を有するMU PPDUである。
【0087】
別の実施形態によれば、TXOP共有ルールは、pSTAのアクセスカテゴリが低レイテンシセンシティブ・トラフィックに対応する場合、初期TXOPトランケーションを可能にするように、または、低レイテンシトラフィックがMACインターフェースに来る場合、TXOP共有を可能にするように再設計される。
【0088】
別の実施形態では、TXOP内のsSTAのための送信継続が適用され得る。APは、2つのSTAに対して同時にAckを要求することがある。これは、pPPDUの終了後に、期待される応答を持つ遅延BA要求によって示される。この応答はTB PPDUの場合もある。pPPDUはAPから送信されるため、sSTAはpPPDUのTXTIMEをデコードし、TB PPDU送信に参加できるようにこれに同期させることができる。
この操作は、プリエンプトされた送信がTXOPの終端にある場合、かつ/または、切り取られたPPDUがTXOP内の最後にあった場合に特に有効である。
この操作は、プリエンプトされた送信がTXOPの終端にある場合、かつ/または、切り取られたPPDUがTXOP内の最後にあった場合に特に有効である。
【0089】
本開示は、以下の実施形態の1つ以上を利用することができる。
【0090】
トランケーション要求は、sSTAのTXOP中に別のリンクのpSTAから送信される。上述のより詳細に述べたように、最初のpPPDUは、pSTAがプリエンプトされたデータユニットを送信することを要求または許可するトリガフレームとすることができる。トランケーション後の送信は、TXOP境界とPPDU境界条件を考慮しながら、sSTAと同時にpSTAに対して行うことができる。
TXOPを有効にするために使用された初期RTSは、pSTA (またはpSTAが属するセット)もユーザフィールドでアドレス指定されるように送信される(プリエンプション指示の形成は伴うが、必ずしもRUを伴うものではない)。これは、初期破棄に関して最初の部分に現れるが、チャネルアクセスでも重要である。
TXOPを有効にするために使用された初期RTSは、pSTA (またはpSTAが属するセット)もユーザフィールドでアドレス指定されるように送信される(プリエンプション指示の形成は伴うが、必ずしもRUを伴うものではない)。これは、初期破棄に関して最初の部分に現れるが、チャネルアクセスでも重要である。
【0091】
トランケーションは、STAに通知される所定の時間間隔(最も重要なのはpSTAまたはpSTAが属するが、APに関連付けられたすべてのSTAに対して行うことができるセット)内で発生する可能性がある。この場合、低レイテンシトラフィックが優先され、低レイテンシ以外のSTAは早期終了が発生しやすくなる。
一実施形態では、元の送信は、プリエンプティブデータユニットが短いプリエンプティブユニットの場合に伝達された後に再開される。
一実施形態では、元の送信は、プリエンプティブデータユニットが短いプリエンプティブユニットの場合に伝達された後に再開される。
【0092】
本開示の利点は、進行中の送信およびPPDUトランケーションの使用可能性よりも高い優先度トラフィックを有するRTA局に対する改善されたレイテンシの1つ以上を含む。PPDUトランケーションは、レイテンシセンシティブ・トラヒックの利点を提供するが、PPDUトランケーションをサポートするためのチャネルアクセス機構は、現在、これらのタイプの方式を実装することを不可能にしている。この制限については、本開示で取り上げる。
【0093】
このように、本開示は、プリエンプティブ送信の場合のチャネルアクセスのためのメカニズムを提案する。この場合、あるSTAに意図された初期PPDUは、高いプライオリティトラフィックをもつ別のSTAのためのデータ送信を可能にするために、切り取られる。提示された実施形態は、特に、リアルタイムの低レイテンシ通信を必要とするアプリケーションに適している。メディアをリッスンするSTAのチャネルアクセスにおける公平性と同様に、チャネル占有、共有および送信境界の尊重に関する情報の正しい分布を保証する方法を提示した。
【0094】
したがって、前述の議論は、単に本開示内容の例示的な実施形態を開示し、説明しているに過ぎない。当業者には理解されるように、本開示内容は、その精神または本質的な特徴から逸脱することなく、他の特定の形態で実施することができる。従って、本開示は、他のクレームと同様に、例示的であることが意図されるが、本開示の範囲を限定するものではない。
本開示は、本明細書の教示の、任意の容易に識別可能な変形を含み、発明の主題が公衆に専用とされないように、前述の請求項の用語の範囲を部分的に定義する。
本開示は、本明細書の教示の、任意の容易に識別可能な変形を含み、発明の主題が公衆に専用とされないように、前述の請求項の用語の範囲を部分的に定義する。
【0095】
さらに請求項において「含む、備える、具備する」という語は他の構成要件またはステップを除外することなく不定冠詞「1つの～」は複数を除外しない。単一要素または他のユニットは、請求範囲に記載されたいくつかの項目の機能を満たすことができる。相互に異なる従属請求において一定の手段が推奨されるという単なる事実は、これらの手段の組合せが有利に使用できないことを示すものではない。
【0096】
本開示の実施形態が、少なくとも部分的に、ソフトウェア制御型のデータ処理装置によって実装されるものとして説明されている限り、光ディスク、磁気ディスク、半導体メモリなど、そのようなソフトウェアを搬送する非一時的な機械可読媒体も、本開示の一実施形態を表すと考えられることが理解される。さらに、このようなソフトウェアは、インターネットまたは他の有線もしくは無線電気通信システムを介して、他の形態で配布することもできる。
【0097】
開示されたデバイス、装置およびシステムの要素は、対応するハードウェアおよび/またはソフトウェア要素、例えば、適切な回路または電気回路によって実現することができる。回路とは、従来の回路素子、特定用途向け集積回路を含む集積回路、標準集積回路、特定用途向け標準製品、およびフィールド・プログラマブル・ゲート・アレイを含む電子部品の構造アセンブリである。さらに、回路は、中央処理ユニット、グラフィックス処理ユニット、およびソフトウェアコードに従ってプログラムまたは構成されるマイクロプロセッサを含む。
回路は、純粋なソフトウェアを含まないが、回路は、上述のハードウェア実行ソフトウェアを含む。回路または電気回路は、単一のデバイス、ユニット、複数のデバイスまたはユニット、あるいはチップセット、またはプロセッサによって実現することができる。
回路は、純粋なソフトウェアを含まないが、回路は、上述のハードウェア実行ソフトウェアを含む。回路または電気回路は、単一のデバイス、ユニット、複数のデバイスまたはユニット、あるいはチップセット、またはプロセッサによって実現することができる。
【0098】
本発明は、開示された主題のさらなる実施形態のリストに従う。
1. 第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させ、かつ、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信デバイス。
2. 前記回路は、
確認応答または要求上の確認応答がないように、データユニットの確認応答ポリシーを第2の通信デバイスとの前記データユニットの進行中の交換時に設定する
ように、構成されている
実施形態1に記載の第1の通信デバイス。
3. 前記回路は、
前記第2の通信デバイスとの前記データユニットの進行中の交換の一部として、前記送信機会の意図された前記継続時間を示す第1の継続時間インジケータを送信し、かつ、
前記第3の通信データとの間のデータユニットの受信または送信の一部として、前記データユニットの進行中の送信のトランケーションの後に、前記プリエンプティブデータユニットの送信が完了した後に、意図された前記送信機会の残り継続時間を示す第2の継続時間インジケータを送信するように
構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
4. 前記第2の継続時間インジケータは、前記切り取られたデータユニットの長さ、前記切り取られたデータユニットの意図された長さ、前記送信機会の意図された継続時間、および少なくとも1つのプリエンプティブデータユニットの長さ、のうちの1つ以上に基づいて決定されている
実施形態3に記載の第1の通信デバイス。
5. 前記回路は、
前記プリエンプティブデータユニットの送信または受信、および、送信または受信されたプリエンプティブデータユニットに対する任意の所要の応答の、もしくは、
前記プリエンプティブデータユニットの送信、および、前記送信または受信されたフレームに対する任意の所要の応答をトリガまたはスケジューリングする前記フレームの、
予期された継続時間と、前記進行中のデータユニットの前記トランケーションを行った後に、前記意図された送信機会の残された継続時間が等しいかまたはより大きい場合にのみ、前記データユニットの進行中の送信を終了させる
上記実施形態のいずれか1つに記載の第1の通信デバイス。
6. 前記回路は、
前記切り取られたデータユニットの残りの継続時間と前記プリエンプティブデータユニットの継続時間との差、または、前記第3の通信デバイスからの送信をトリガするトリガフレームの差、または、前記第3の通信デバイスによるプリエンプティブデータ交換のスケジューリングの差、または、コンテンションフリーエンドフレームと1フレーム間の空間間隔との差を示す第2の継続時間インジケータを生成するように構成されている
実施形態3に記載の第1の通信デバイス。
7. 前記回路は、
前記プリエンプティブデータユニットの前記継続時間と前記確認応答の前記継続時間、および/または、フレーム間空間の継続時間を、前記切り取られたデータユニットの残りの継続時間から差し引くか、または、
前記第3の通信デバイスに送信される第1のプリエンプティブデータユニットの継続時間と、前記第3の通信デバイスから受信される第2のプリエンプティブデータユニットの継続時間と、2つのフレーム間空間とを、前記切り取られたデータユニットの残りの継続時間から差し引き、
前記差し引きの結果を示す前記第2の継続時間インジケータを生成する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
8. 前記回路は、前記第2の継続時間インジケータによって示される計算された継続時間に安全マージンを追加するように構成され、
前記安全マージンは、短いフレーム間時間、スロット時間、または前記短いフレーム間時間の許容レベルに応じて、前記第3の通信デバイスのウェイクアップ時間または送信機会延長または設定値に対応する
上記実施形態のいずれか1つに記載の第1の通信デバイス。
9. 前記回路は、
第1のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、第2のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、
前記第2の通信デバイスの意図された送信機会が1つ以上のさらなるPHYデータユニット用の送信時間を含んでいる場合、
前記第1のプリエンプティブデータユニットを前記第3の通信デバイスに送信し、前記第3の通信デバイスから前記第2のプリエンプティブデータを受信する
ように構成されており、
前記第2のプリエンプティブデータユニットの継続時間が、前記1つ以上のPHYデータユニットの送信時間の継続時間より短く、トランケーションがない場合、
前記第1のプリエンプティブデータユニットの終端が前記第2の通信デバイスに送信されるデータユニットの意図された継続時間の終端に対応するように、パディングデータ量が前記第1のプリエンプティブデータユニットに追加される
上記実施形態のいずれか1つに記載の第1の通信デバイス。
10. 前記回路は、
第1のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信され、第2のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信され、かつ、前記第2の通信デバイスの意図された送信機会が1つ以上のさらなるPHYデータユニット用の送信時間を含んでいる場合、
前記第2のプリエンプティブデータの継続時間が前記1つ以上のさらなるPHYデータユニットの送信時間より長い場合に、前記進行中のデータユニットの推定継続時間にフレーム間の時間間隔を加える前に、前記プリエンプティブデータユニットの送信を開始する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
11. 前記回路は、
切り取られたデータユニットの意図された長さとデータユニットインジケータの和から、前記第3の通信デバイスに送信される第1のプリエンプティブデータユニットの継続時間、前記第3の通信デバイスから受信される第2のプリエンプティブデータユニットの継続時間、およびフレーム間スペースを減算し、
前記減算の結果に基づいて、前記第2の通信デバイスへの前記データユニット送信のトランケーションを実行するか否かを判定する
ように構成されており、
前記データユニットインジケータは、ゼロより大きい整数であり、切り取られたデータユニットが、現在の送信機会内に送信される最後のデータユニットではないことを示し、かつ、進行中の送信継続期間の予期された継続時間を示し、
トランケーション通知は、進行中のデータユニットのトランケーションが行われるべきであることを示している
実施形態5に記載の第1の通信デバイス。
12. 前記回路は、
前記切り取られたデータユニットが、現在の送信機会内に送信される最後のデータユニットであった場合、前記切り取られたデータユニットの前記意図された時間から前記プリエンプティブデータユニットの受信継続時間とフレーム間スペースとを差し引き、
前記差し引きした結果に基づいて、前記第2の通信デバイスに対する前記データユニット送信のトランケーションを行うかどうかを判定する
ように構成されており、
前記トランケーション通知は、前記進行中のデータユニットのトランケーションが行われるべきであることを示す
上記実施形態のいずれか1つに記載の第1の通信デバイス。
13. 前記回路は、
前記第2の通信デバイスの送信機会中に、前記第3の通信デバイスから低レイテンシセンシティブ・トラフィックを送受信する要求を示す通知を受信した結果として、前記第2のデバイスとの間で前記進行中のデータ交換のトランケーションを実行する
ように構成されており、
前記通知は、前記第1の通信デバイスと前記第2の通信デバイスとの間で前記進行中のデータ交換が実行されるリンクとは異なるリンクで受信される
上記実施形態のいずれか1つに記載の第1の通信デバイス。
14. 前記回路は、
第1のプリエンプティブデータユニットとして、前記第1の通信デバイスと前記第2の通信デバイスとの間のデータ交換のために得られた送信機会の間に、さらなるプリエンプティブデータユニットを送信することを前記第3の通信デバイスに要求かつ/または可能にするトリガフレーム、または、前記第3の通信デバイスとのプリエンプティブデータ交換をスケジューリングするフレームを送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
15. 前記回路は、
データユニットの送受信と同時に前記第3の通信デバイスにプリエンプティブデータユニットを前記第2の通信デバイスに送信し、かつ/または、
前記第2の通信デバイスからのデータユニットと同時に前記第3の通信デバイスからプリエンプティブデータユニットを受信し、かつ/または、
進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で確立された、低レイテンシトラフィック・ストリーム識別子に対応するトラフィックのみを含むプリエンプティブデータユニットを、前記第3の通信デバイスに送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
16. 前記回路は、
前記進行中のデータ交換が行われる前記第2の通信デバイスとの送信機会を確立する一部として、1つ以上の潜在的なプリエンプションを示す制御フレームの1つ以上を送信し、かつ/または、
前記進行中の送信機会の前に前記第3の通信デバイスとネゴシエートされた予め定義された時間間隔でのデータユニットの進行中の送信のトランケーションを行う
ように構成されており、
ユーザフィールドは、プリエンプティブデータユニットの意図された受信機として前記第3の通信デバイスを示し、
ユーザフィールドは、前記第3の通信デバイスが潜在的なプリエンプティブデータ交換において意図された参加者としてそれ自体を識別する一連の通信デバイスを示す
上記実施形態のいずれか1つに記載の第1の通信デバイス。
17. 前記回路は、
前記進行中の送信機会の前に、前記第3の通信デバイスとネゴシエートされた所定の時間間隔で、データユニットの前記進行中の送信のトランケーションを行う
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
18. 前記回路は、
前記プリエンプティブデータユニットの送受信と、送受信されたプリエンプティブデータユニットに対する必要な応答の後に、前記第2の通信デバイスとの元のデータユニットの交換を再開する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
19. 前記回路は、
前記プリエンプティブデータユニットに含まれるMPDUのMACヘッダ内で前記継続時間インジケータを送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
20. 前記回路は、
前記プリエンプティブデータユニットを送信する前に、前記プリエンプティブデータユニットにパディングデータを追加する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
21. 前記回路は、
前記プリエンプティブデータユニットにパディングデータの量を追加し、前記プリエンプティブデータユニットの終端が、切り取られていなかった場合に、切り取られたデータユニットの終端に対応するようにする
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
22. 第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信し、
前記第3の通信デバイスとの新たな送信機会を確立する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信デバイス。
23.終端指示の継続時間、および、前記第3の通信デバイスとの送信機会の確立の継続時間を差し引いて切り取れなかった場合に、前記プリエンプティブデータユニットの継続時間が、現在の送信機会継続時間よりも長いときに、
残りのネット継続時間を表す前記差は、前記残りのネット継続時間の前に前記プリエンプティブデータユニットの第1の部分を送信し、前記残りのネット継続時間の後に前記プリエンプティブデータユニットの第2の部分を送信する
実施形態22に記載の第1の通信デバイス。
24. 新たな前記送信機会の継続時間は、トランケーションなしに、前記終端指示の継続時間を差し引いて、かつ、前記第3の通信デバイスとの前記送信機会の確立の継続時間を差し引いた現在の送信機会継続時間を超えないように設定されている
実施形態22または23に記載の第1の通信デバイス。
25. 前記回路は、現在の送信機会の終端と位置合わせされた前記プリエンプティブデータユニットの前記第1の部分を、切り取られていない場合、送信するように構成されている
実施形態24に記載の第1の通信デバイス。
26. 前記回路は、
前記第2の通信デバイスのためのデータユニットと、前記第3の通信デバイスのためのデータユニットとを備えるマルチユーザPPDUにおいて、前記プリエンプティブデータユニットの前記第1の部分および/または第2の部分を送信する
ように構成されている
実施形態24または25に記載の第1の通信デバイス。
27. 前記新たな送信機会は、現在の送信機会用に意図された残りのトラフィックの少なくとも一部の交換のために、前記第2の通信デバイスと共有することができる
実施形態22～26のいずれか1つに記載の第1の通信デバイス。
28. 前記回路は、
前記第3の通信デバイスと交換されるトラフィックのアクセスカテゴリが、低レイテンシセンシティブ・アクセスカテゴリを示す場合、および/または、進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で低レイテンシセンシティブ・セッションが確立された場合に、
現在の送信機会を前記第3の通信デバイスと終了または共用するように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
29. 前記プリエンプティブデータユニットは、前記進行中のデータ送信の前に実行されるセットアップフェーズ内で確立されたパラメータを有する低レイテンシトラフィックを含む
上記実施形態のいずれか1つに記載の第1の通信デバイス。
30. 前記プリエンプティブデータユニットの送信は、意図されたデータユニットの最初に意図した継続時間を超えないか、もしくは、短いフレーム間空間、または、短いフレーム間空間、スロット時間、およびフレーム間許容レベルの関数を超えてはならない。
上記実施形態のいずれか1つに記載の第1の通信デバイス。
31. 第1の通信デバイスと通信するように構成された第3の通信デバイスであって、
第2の通信デバイスにアドレス指定されたデータユニットを受信し、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定し、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定し、かつ、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信する
ように構成された回路を具備する
第3の通信デバイス。
32. 前記回路は、
前記切り取られたデータユニットの意図された継続時間とデータユニットインジケータの和から、前記切り取られたデータユニットの推定受信継続時間、前記プリエンプティブデータユニットの受信継続時間およびフレーム間空間を差し引き、
前記差し引きと等しい継続時間指示を含むプリエンプティブデータユニットを送信する
ように構成されており、
前記データユニットインジケータは、ゼロより大きい整数であり、前記切り取られたデータユニットが、現在の前記送信機会内に送信される最後のデータユニットではないことを示し、かつ、前記進行中の送信継続時間の予想継続時間を示す
実施形態31に記載の第3の通信デバイス。
33. 前記回路は、
前記プリエンプティブデータユニットの送信が、前記切り取られたデータユニットの最初の意図された終端を超えないように、もしくは、短いフレーム間空間、または、短いフレーム間空間、スロット時間およびフレーム間許容レベルの関数を超えないように、もしくは、前記第1の通信デバイスから前記第2の通信デバイスへの前記データユニットの最初の意図された終端を超えないように、前記プリエンプティブデータを送信する
ように構成されている
実施形態31または32に記載の第3の通信デバイス。
34. 前記回路は、
前記進行中のデータ交換の意図的な早期終了、
前記第3の通信デバイスからのプリエンプティブデータユニット送信を要求するトリガフレームの受信、
応答を要求するプリエンプティブデータユニットの受信、および
潜在的なトランケーション指示で定義される時間間隔
のうちの1つ以上の決定に応じて、前記第1の通信デバイスから第2の通信デバイスへの、前記進行中の送信機会の終端前および/または前記データユニットの意図された継続時間の終端前に、ネットワーク割当てベクトルNAVをリセットする
ように構成されている
実施形態31～33のいずれか1つに記載の第3の通信デバイス。
35. 前記回路は、
低レイテンシトラフィック識別子の指示が前記プリエンプティブデータユニット内に存在するかどうか、または、前記プリエンプティブデータユニットの送信を要求するトリガフレームが受信されたどうかを判定する
ように構成されている
実施形態31～34のいずれか1つに記載の第3の通信デバイス。
36. 低レイテンシトラフィック識別子およびプリエンプションパラメータが、前記進行中のデータ交換の前の位相でネゴシエートされている
実施形態31～35のいずれか1つに記載の第3の通信デバイス。
37. 前記回路は、
前記第3の通信データとの間のデータユニットの受信または送信の一部として、前記データユニットの進行中の送信のトランケーションの後に、前記プリエンプティブデータユニットの送信が完了した後に、意図された前記送信機会の残り継続時間を示す第2の継続時間インジケータを送受信するように
構成されている
実施形態31～36のいずれか1つに記載の第3の通信デバイス。
38. 前記回路は、
第1のプリエンプティブデータユニットとして、前記第1の通信デバイスと前記第2の通信デバイスとの間のデータ交換のために得られた送信機会の間に、さらなるプリエンプティブデータユニットを送信することを前記第3の通信デバイスに要求かつ/または可能にするトリガフレーム、または、前記第3の通信デバイスとのプリエンプティブデータ交換をスケジューリングするフレームを受信する
ように構成されている
実施形態31~37のいずれか1つに記載の第3の通信デバイス。
39. 第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させるステップと、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信方法。
40. 第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信するステップと、
前記第3の通信デバイスとの新たな送信機会を確立するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信方法。
41. 第1の通信デバイスと通信するための第3の通信方法であって、
第2の通信デバイスにアドレス指定されたデータユニットを受信するステップと、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定するステップと、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定するステップと、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信するステップと
を含む
第3の通信方法。
42.プロセッサによって実行されると、実施形態39,40または41に記載の方法を実行させる、コンピュータプログラム製品内に記憶される
非一時的なコンピュータ読み取り可能な記録媒体。
43. コンピュータプログラムがコンピュータ上で実行されるときに、実施形態39、40または41に記載の方法のステップを前記コンピュータに実行させるためのプログラムコード手段を具備する
コンピュータプログラム。
1. 第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させ、かつ、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信デバイス。
2. 前記回路は、
確認応答または要求上の確認応答がないように、データユニットの確認応答ポリシーを第2の通信デバイスとの前記データユニットの進行中の交換時に設定する
ように、構成されている
実施形態1に記載の第1の通信デバイス。
3. 前記回路は、
前記第2の通信デバイスとの前記データユニットの進行中の交換の一部として、前記送信機会の意図された前記継続時間を示す第1の継続時間インジケータを送信し、かつ、
前記第3の通信データとの間のデータユニットの受信または送信の一部として、前記データユニットの進行中の送信のトランケーションの後に、前記プリエンプティブデータユニットの送信が完了した後に、意図された前記送信機会の残り継続時間を示す第2の継続時間インジケータを送信するように
構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
4. 前記第2の継続時間インジケータは、前記切り取られたデータユニットの長さ、前記切り取られたデータユニットの意図された長さ、前記送信機会の意図された継続時間、および少なくとも1つのプリエンプティブデータユニットの長さ、のうちの1つ以上に基づいて決定されている
実施形態3に記載の第1の通信デバイス。
5. 前記回路は、
前記プリエンプティブデータユニットの送信または受信、および、送信または受信されたプリエンプティブデータユニットに対する任意の所要の応答の、もしくは、
前記プリエンプティブデータユニットの送信、および、前記送信または受信されたフレームに対する任意の所要の応答をトリガまたはスケジューリングする前記フレームの、
予期された継続時間と、前記進行中のデータユニットの前記トランケーションを行った後に、前記意図された送信機会の残された継続時間が等しいかまたはより大きい場合にのみ、前記データユニットの進行中の送信を終了させる
上記実施形態のいずれか1つに記載の第1の通信デバイス。
6. 前記回路は、
前記切り取られたデータユニットの残りの継続時間と前記プリエンプティブデータユニットの継続時間との差、または、前記第3の通信デバイスからの送信をトリガするトリガフレームの差、または、前記第3の通信デバイスによるプリエンプティブデータ交換のスケジューリングの差、または、コンテンションフリーエンドフレームと1フレーム間の空間間隔との差を示す第2の継続時間インジケータを生成するように構成されている
実施形態3に記載の第1の通信デバイス。
7. 前記回路は、
前記プリエンプティブデータユニットの前記継続時間と前記確認応答の前記継続時間、および/または、フレーム間空間の継続時間を、前記切り取られたデータユニットの残りの継続時間から差し引くか、または、
前記第3の通信デバイスに送信される第1のプリエンプティブデータユニットの継続時間と、前記第3の通信デバイスから受信される第2のプリエンプティブデータユニットの継続時間と、2つのフレーム間空間とを、前記切り取られたデータユニットの残りの継続時間から差し引き、
前記差し引きの結果を示す前記第2の継続時間インジケータを生成する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
8. 前記回路は、前記第2の継続時間インジケータによって示される計算された継続時間に安全マージンを追加するように構成され、
前記安全マージンは、短いフレーム間時間、スロット時間、または前記短いフレーム間時間の許容レベルに応じて、前記第3の通信デバイスのウェイクアップ時間または送信機会延長または設定値に対応する
上記実施形態のいずれか1つに記載の第1の通信デバイス。
9. 前記回路は、
第1のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、第2のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信される必要があり、
前記第2の通信デバイスの意図された送信機会が1つ以上のさらなるPHYデータユニット用の送信時間を含んでいる場合、
前記第1のプリエンプティブデータユニットを前記第3の通信デバイスに送信し、前記第3の通信デバイスから前記第2のプリエンプティブデータを受信する
ように構成されており、
前記第2のプリエンプティブデータユニットの継続時間が、前記1つ以上のPHYデータユニットの送信時間の継続時間より短く、トランケーションがない場合、
前記第1のプリエンプティブデータユニットの終端が前記第2の通信デバイスに送信されるデータユニットの意図された継続時間の終端に対応するように、パディングデータ量が前記第1のプリエンプティブデータユニットに追加される
上記実施形態のいずれか1つに記載の第1の通信デバイス。
10. 前記回路は、
第1のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信され、第2のプリエンプティブデータユニットが前記第3の通信デバイスとの間で送受信され、かつ、前記第2の通信デバイスの意図された送信機会が1つ以上のさらなるPHYデータユニット用の送信時間を含んでいる場合、
前記第2のプリエンプティブデータの継続時間が前記1つ以上のさらなるPHYデータユニットの送信時間より長い場合に、前記進行中のデータユニットの推定継続時間にフレーム間の時間間隔を加える前に、前記プリエンプティブデータユニットの送信を開始する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
11. 前記回路は、
切り取られたデータユニットの意図された長さとデータユニットインジケータの和から、前記第3の通信デバイスに送信される第1のプリエンプティブデータユニットの継続時間、前記第3の通信デバイスから受信される第2のプリエンプティブデータユニットの継続時間、およびフレーム間スペースを減算し、
前記減算の結果に基づいて、前記第2の通信デバイスへの前記データユニット送信のトランケーションを実行するか否かを判定する
ように構成されており、
前記データユニットインジケータは、ゼロより大きい整数であり、切り取られたデータユニットが、現在の送信機会内に送信される最後のデータユニットではないことを示し、かつ、進行中の送信継続期間の予期された継続時間を示し、
トランケーション通知は、進行中のデータユニットのトランケーションが行われるべきであることを示している
実施形態5に記載の第1の通信デバイス。
12. 前記回路は、
前記切り取られたデータユニットが、現在の送信機会内に送信される最後のデータユニットであった場合、前記切り取られたデータユニットの前記意図された時間から前記プリエンプティブデータユニットの受信継続時間とフレーム間スペースとを差し引き、
前記差し引きした結果に基づいて、前記第2の通信デバイスに対する前記データユニット送信のトランケーションを行うかどうかを判定する
ように構成されており、
前記トランケーション通知は、前記進行中のデータユニットのトランケーションが行われるべきであることを示す
上記実施形態のいずれか1つに記載の第1の通信デバイス。
13. 前記回路は、
前記第2の通信デバイスの送信機会中に、前記第3の通信デバイスから低レイテンシセンシティブ・トラフィックを送受信する要求を示す通知を受信した結果として、前記第2のデバイスとの間で前記進行中のデータ交換のトランケーションを実行する
ように構成されており、
前記通知は、前記第1の通信デバイスと前記第2の通信デバイスとの間で前記進行中のデータ交換が実行されるリンクとは異なるリンクで受信される
上記実施形態のいずれか1つに記載の第1の通信デバイス。
14. 前記回路は、
第1のプリエンプティブデータユニットとして、前記第1の通信デバイスと前記第2の通信デバイスとの間のデータ交換のために得られた送信機会の間に、さらなるプリエンプティブデータユニットを送信することを前記第3の通信デバイスに要求かつ/または可能にするトリガフレーム、または、前記第3の通信デバイスとのプリエンプティブデータ交換をスケジューリングするフレームを送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
15. 前記回路は、
データユニットの送受信と同時に前記第3の通信デバイスにプリエンプティブデータユニットを前記第2の通信デバイスに送信し、かつ/または、
前記第2の通信デバイスからのデータユニットと同時に前記第3の通信デバイスからプリエンプティブデータユニットを受信し、かつ/または、
進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で確立された、低レイテンシトラフィック・ストリーム識別子に対応するトラフィックのみを含むプリエンプティブデータユニットを、前記第3の通信デバイスに送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
16. 前記回路は、
前記進行中のデータ交換が行われる前記第2の通信デバイスとの送信機会を確立する一部として、1つ以上の潜在的なプリエンプションを示す制御フレームの1つ以上を送信し、かつ/または、
前記進行中の送信機会の前に前記第3の通信デバイスとネゴシエートされた予め定義された時間間隔でのデータユニットの進行中の送信のトランケーションを行う
ように構成されており、
ユーザフィールドは、プリエンプティブデータユニットの意図された受信機として前記第3の通信デバイスを示し、
ユーザフィールドは、前記第3の通信デバイスが潜在的なプリエンプティブデータ交換において意図された参加者としてそれ自体を識別する一連の通信デバイスを示す
上記実施形態のいずれか1つに記載の第1の通信デバイス。
17. 前記回路は、
前記進行中の送信機会の前に、前記第3の通信デバイスとネゴシエートされた所定の時間間隔で、データユニットの前記進行中の送信のトランケーションを行う
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
18. 前記回路は、
前記プリエンプティブデータユニットの送受信と、送受信されたプリエンプティブデータユニットに対する必要な応答の後に、前記第2の通信デバイスとの元のデータユニットの交換を再開する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
19. 前記回路は、
前記プリエンプティブデータユニットに含まれるMPDUのMACヘッダ内で前記継続時間インジケータを送信する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
20. 前記回路は、
前記プリエンプティブデータユニットを送信する前に、前記プリエンプティブデータユニットにパディングデータを追加する
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
21. 前記回路は、
前記プリエンプティブデータユニットにパディングデータの量を追加し、前記プリエンプティブデータユニットの終端が、切り取られていなかった場合に、切り取られたデータユニットの終端に対応するようにする
ように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
22. 第2の通信デバイスおよび第3の通信デバイスと通信するように構成された第1の通信デバイスであって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信し、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信し、
前記第3の通信デバイスとの新たな送信機会を確立する
ように構成された回路を具備し、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信デバイス。
23.終端指示の継続時間、および、前記第3の通信デバイスとの送信機会の確立の継続時間を差し引いて切り取れなかった場合に、前記プリエンプティブデータユニットの継続時間が、現在の送信機会継続時間よりも長いときに、
残りのネット継続時間を表す前記差は、前記残りのネット継続時間の前に前記プリエンプティブデータユニットの第1の部分を送信し、前記残りのネット継続時間の後に前記プリエンプティブデータユニットの第2の部分を送信する
実施形態22に記載の第1の通信デバイス。
24. 新たな前記送信機会の継続時間は、トランケーションなしに、前記終端指示の継続時間を差し引いて、かつ、前記第3の通信デバイスとの前記送信機会の確立の継続時間を差し引いた現在の送信機会継続時間を超えないように設定されている
実施形態22または23に記載の第1の通信デバイス。
25. 前記回路は、現在の送信機会の終端と位置合わせされた前記プリエンプティブデータユニットの前記第1の部分を、切り取られていない場合、送信するように構成されている
実施形態24に記載の第1の通信デバイス。
26. 前記回路は、
前記第2の通信デバイスのためのデータユニットと、前記第3の通信デバイスのためのデータユニットとを備えるマルチユーザPPDUにおいて、前記プリエンプティブデータユニットの前記第1の部分および/または第2の部分を送信する
ように構成されている
実施形態24または25に記載の第1の通信デバイス。
27. 前記新たな送信機会は、現在の送信機会用に意図された残りのトラフィックの少なくとも一部の交換のために、前記第2の通信デバイスと共有することができる
実施形態22～26のいずれか1つに記載の第1の通信デバイス。
28. 前記回路は、
前記第3の通信デバイスと交換されるトラフィックのアクセスカテゴリが、低レイテンシセンシティブ・アクセスカテゴリを示す場合、および/または、進行中のデータ交換の前に前記第1の通信デバイスと前記第3の通信デバイスの間で低レイテンシセンシティブ・セッションが確立された場合に、
現在の送信機会を前記第3の通信デバイスと終了または共用するように構成されている
上記実施形態のいずれか1つに記載の第1の通信デバイス。
29. 前記プリエンプティブデータユニットは、前記進行中のデータ送信の前に実行されるセットアップフェーズ内で確立されたパラメータを有する低レイテンシトラフィックを含む
上記実施形態のいずれか1つに記載の第1の通信デバイス。
30. 前記プリエンプティブデータユニットの送信は、意図されたデータユニットの最初に意図した継続時間を超えないか、もしくは、短いフレーム間空間、または、短いフレーム間空間、スロット時間、およびフレーム間許容レベルの関数を超えてはならない。
上記実施形態のいずれか1つに記載の第1の通信デバイス。
31. 第1の通信デバイスと通信するように構成された第3の通信デバイスであって、
第2の通信デバイスにアドレス指定されたデータユニットを受信し、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定し、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定し、かつ、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信する
ように構成された回路を具備する
第3の通信デバイス。
32. 前記回路は、
前記切り取られたデータユニットの意図された継続時間とデータユニットインジケータの和から、前記切り取られたデータユニットの推定受信継続時間、前記プリエンプティブデータユニットの受信継続時間およびフレーム間空間を差し引き、
前記差し引きと等しい継続時間指示を含むプリエンプティブデータユニットを送信する
ように構成されており、
前記データユニットインジケータは、ゼロより大きい整数であり、前記切り取られたデータユニットが、現在の前記送信機会内に送信される最後のデータユニットではないことを示し、かつ、前記進行中の送信継続時間の予想継続時間を示す
実施形態31に記載の第3の通信デバイス。
33. 前記回路は、
前記プリエンプティブデータユニットの送信が、前記切り取られたデータユニットの最初の意図された終端を超えないように、もしくは、短いフレーム間空間、または、短いフレーム間空間、スロット時間およびフレーム間許容レベルの関数を超えないように、もしくは、前記第1の通信デバイスから前記第2の通信デバイスへの前記データユニットの最初の意図された終端を超えないように、前記プリエンプティブデータを送信する
ように構成されている
実施形態31または32に記載の第3の通信デバイス。
34. 前記回路は、
前記進行中のデータ交換の意図的な早期終了、
前記第3の通信デバイスからのプリエンプティブデータユニット送信を要求するトリガフレームの受信、
応答を要求するプリエンプティブデータユニットの受信、および
潜在的なトランケーション指示で定義される時間間隔
のうちの1つ以上の決定に応じて、前記第1の通信デバイスから第2の通信デバイスへの、前記進行中の送信機会の終端前および/または前記データユニットの意図された継続時間の終端前に、ネットワーク割当てベクトルNAVをリセットする
ように構成されている
実施形態31～33のいずれか1つに記載の第3の通信デバイス。
35. 前記回路は、
低レイテンシトラフィック識別子の指示が前記プリエンプティブデータユニット内に存在するかどうか、または、前記プリエンプティブデータユニットの送信を要求するトリガフレームが受信されたどうかを判定する
ように構成されている
実施形態31～34のいずれか1つに記載の第3の通信デバイス。
36. 低レイテンシトラフィック識別子およびプリエンプションパラメータが、前記進行中のデータ交換の前の位相でネゴシエートされている
実施形態31～35のいずれか1つに記載の第3の通信デバイス。
37. 前記回路は、
前記第3の通信データとの間のデータユニットの受信または送信の一部として、前記データユニットの進行中の送信のトランケーションの後に、前記プリエンプティブデータユニットの送信が完了した後に、意図された前記送信機会の残り継続時間を示す第2の継続時間インジケータを送受信するように
構成されている
実施形態31～36のいずれか1つに記載の第3の通信デバイス。
38. 前記回路は、
第1のプリエンプティブデータユニットとして、前記第1の通信デバイスと前記第2の通信デバイスとの間のデータ交換のために得られた送信機会の間に、さらなるプリエンプティブデータユニットを送信することを前記第3の通信デバイスに要求かつ/または可能にするトリガフレーム、または、前記第3の通信デバイスとのプリエンプティブデータ交換をスケジューリングするフレームを受信する
ように構成されている
実施形態31~37のいずれか1つに記載の第3の通信デバイス。
39. 第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
前記データユニットの推定送信時間前に前記データユニットの前記進行中の送信を終了させるステップと、
前記進行中のデータユニットの交換のために前記第1の通信デバイスと前記第2の通信デバイスとの間で確立される、切り取られたデータユニットの残りの継続時間内または送信機会の残りの継続時間内に前記第3の通信デバイスとの間で、前記プリエンプティブデータユニットを受信かつ/または送信するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示す
第1の通信方法。
40. 第2の通信デバイスおよび第3の通信デバイスと通信するための第1の通信方法であって、
前記第2の通信デバイスとの進行中のデータユニットの交換中にトランケーション通知を受信するステップと、
現在の送信機会の終端前に前記現在の送信機会の終端を示す終了通知を送信するステップと、
前記第3の通信デバイスとの新たな送信機会を確立するステップと
を含み、
前記トランケーション通知は、1つのデータユニットの進行中の送信が切り取られ、プリエンプティブデータユニットが、前記第3の通信デバイスとの間で受信かつ/または送信されることを示し、
前記新たな送信機会の継続時間は、前記第3の通信デバイスとの間の、前記プリエンプティブデータの少なくとも送信および/または受信をカバーする
第1の通信方法。
41. 第1の通信デバイスと通信するための第3の通信方法であって、
第2の通信デバイスにアドレス指定されたデータユニットを受信するステップと、
データユニットの進行中の送信の予想継続時間および/または進行中の送信機会の予測継続時間を示す継続時間指示を判定するステップと、
前記データユニットの推定送信時間前にデータユニットの送信が終了したかどうかを判定するステップと、
切り取られたデータユニットの残りの継続時間内および/または前記送信機会の残りの継続時間内にプリエンプティブデータユニットを前記第1の通信デバイスとの間で受信かつ/または送信するステップと
を含む
第3の通信方法。
42.プロセッサによって実行されると、実施形態39,40または41に記載の方法を実行させる、コンピュータプログラム製品内に記憶される
非一時的なコンピュータ読み取り可能な記録媒体。
43. コンピュータプログラムがコンピュータ上で実行されるときに、実施形態39、40または41に記載の方法のステップを前記コンピュータに実行させるためのプログラムコード手段を具備する
コンピュータプログラム。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14A】
【図14B】
【図15】
【図16A】
【図16B】
【図17】
【図18】
【図19】
【国際調査報告】