無線通信のための電力保存の拡張
【課題】無線ネットワーク中の局によって省電力を改善するための技術を提供する。
【解決手段】ソース局は、電力保存モードで作動する受信局の送信機会(TXOP)バースト受信機能についての情報を備えたフレームを受け取る（１４１２）。ソース局はTXOPの最初にチャネル・アクセスを行ない、受信局のTXOPバースト受信機能に基づいて受信局へTXOPの中において多数のデータフレームを送信する（１４１４）。受信局は、前記TXOPバースト受信機能についての情報に基づいて、どれだけのデータフレームを予期するべきかを知っており、データフレームの予期された数を受け取った後にスリープ状態に移行することができる。
【解決手段】ソース局は、電力保存モードで作動する受信局の送信機会(TXOP)バースト受信機能についての情報を備えたフレームを受け取る（１４１２）。ソース局はTXOPの最初にチャネル・アクセスを行ない、受信局のTXOPバースト受信機能に基づいて受信局へTXOPの中において多数のデータフレームを送信する（１４１４）。受信局は、前記TXOPバースト受信機能についての情報に基づいて、どれだけのデータフレームを予期するべきかを知っており、データフレームの予期された数を受け取った後にスリープ状態に移行することができる。
【発明の詳細な説明】
【技術分野】
【０００１】
現在の出願は、「POWER SAVE ENHANCEMENTS FOR AD-HOC WIRELESS COMMUNICATION」と題され、譲受人に譲渡され、参照によって本明細書に組込まれ、2006年10月19日に出願された米国仮特許出願第60/862,146号に基づく優先権を主張します。本開示は、一般には通信に、より具体的には無線通信ネットワーク中の局の電池寿命の改善のための技術に関係がある。
【背景技術】
【０００２】
無線通信ネットワークは音声、ビデオ、パケット・データ、メッセージ、放送などのような様々な通信サービスを提供するために広く展開される。これらの無線ネットワークは、非常に大きな地理的なエリアに通信カバレージを供給する無線の広域ネットワーク(WWAN)、大きな地理的なエリアに通信カバレージを供給する無線の都市内ネットワーク(WMAN)、中くらいの地理的なエリアに通信カバレージを供給する、無線ローカルエリア・ネットワーク(WLAN)、および小さな地理的なエリアに通信カバレージを供給する無線パーソナルネットワーク(WPAN)を含んでいる。異なる無線ネットワークは典型的には異なる能力、要件およびカバレージエリアを持っています。
【０００３】
局(例えば携帯電話)は、1つ以上の無線ネットワーク(例えばWWANおよび／またはWLAN)と通信することができるかもしれない。局は移動可能であってもよくまた、内蔵電池によって動力が供給されてもよい。例えば、局がデータを送信し、かつ/または受信するために電源オンされる場合は常に、該局は電池電力を消費するかもしれない。局がデータを交換している際に、複数回の電池充電の間の待機時間および動作時間の両方を拡張するためにできるだけ電池電力消費量を削減することは望ましい。したがって、局の電池寿命を改善するための技術に対する需要が当該技術分野においてある。
【発明の概要】
【０００４】
無線ネットワーク中の局によって省電力を改善するための技術が本明細書に記述される。一の態様では、ソース局は受信局へ送られたフレームに電力保存バッファー・ステータスを含めてもよい。受信局は電力保存モードで作動するかもしれないし、一部の時間だけ起動状態であるかもしれない。バッファー・ステータスは、受信局へ送られるためのデータフレームの数を示してもよい。ソース局はバッファー・ステータスによって示されるとおりに受信局へ１つ以上のデータフレームを送ってもよい。受信局は、バッファー・ステータスに基づいてソース局からどれだけの数のデータフレームが予想されるか知っているかもしれない。受信局はデータフレームの予想された数を受け取った後にスリープ状態になってもよく、それは電池動力を節約するかもしれない。一般に、ソース局は、バッファーされたデータの量が、データフレームの数、バイト数、ビット数などのような任意の単位に基づくことを表示してもよい。受信局は、バッファー・ステータスによって示されたデータの量に基づいて、どれだけのデータが予想されるかを知っているかもしれない。
【０００５】
別の態様では、１回の送信機会(TXOP)において多数のデータフレームを受け取ることができる受信局は、このTXOPバースト受信機能を他の局へ広告することができる。１の設計では、受信局は、該局のTXOPバースト受信機能についての情報を含むフレームを送信しても良い。この情報は、単一のTXOPの中の受信局によって受け取ることができるデータフレームの数を示してもよい。受信局は、受信局のTXOPバースト受信機能に基づいて１つのTXOPの中においてソース局から多数のデータフレームをその後受信しても良い。ソース局は該TXOPの最初にチャネル・アクセスを行なうかもしれないし、別のチャネル・アクセスを実行する必要無しに、該TXOPの中の全てのデータフレームを送るかもしれない。
【０００６】
下記に述べられるように、電力保存バッファー・ステータスおよびTXOPバースト特性は様々な電力保存モードおよび様々な無線ネットワークに使用されてもよい。本開示の種々の態様および特徴もまた、一層に詳細に下記に記述される。
【図面の簡単な説明】
【０００７】
【図１】無線ネットワーク
【図２】多数の局に関する送信時間軸
【図３】電力保存バッファー・ステータスを伝達することが可能なフレーム
【図４】電力保存バッファー・ステータス特性を伴うスケジュールされていない電力保存モードでの動作
【図５】別個のチャネル・アクセスを伴うデータフレームの送信
【図６Ａ】TXOPバースト受信機能を伝達することができるフレーム。
【図６Ｂ】TXOPバースト受信機能を伝達することができるフレーム。
【図７】TXOPバースト受信機能を備えたデータフレームの送信
【図８】それぞれ電力保存バッファー・ステータスおよびTXOPバースト特性を伴う、スケジュールされた電力保存モードおよびPSMPモードにおける動作
【図９】それぞれ電力保存バッファー・ステータスおよびTXOPバースト特性を伴う、スケジュールされた電力保存モードおよびPSMPモードにおける動作
【図１０】電力保存バッファー・ステータスと共にデータを送信するための方法
【図１１】電力保存バッファー・ステータスと共にデータを送信するための装置
【図１２】電力保存バッファー・ステータスと共にデータを受信するための方法
【図１３】電力保存バッファー・ステータスと共にデータを受信するための装置
【図１４】TXOPバースト機能を備えたデータの送信のための方法
【図１５】TXOPバースト機能を備えたデータの送信のための装置
【図１６】TXOPバースト機能と共に送信されたデータを受け取るための方法
【図１７】TXOPバースト機能と共に送信されたデータを受け取るための装置
【図１８】２つの局のブロック図
【詳細な説明】
【０００８】
本明細書に記述された技術は、WLAN、WMAN、WWAN、WPANなどのような様々な無線ネットワークに使用されてもよい。WLANはIEEE 802.11、Hiperlanなどを実装するかもしれない。WWANは、符号分割多重アクセス方式(CDMA)ネットワーク、時分割多元接続方式(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、単一キャリアFDMA(SC-FDMA)ネットワークなどのようなセルラー・ネットワークかもしれない。WMANはIEEE 802.16(それは一般にWiMAXと呼ばれる)、IEEE 802.20などを実装するかもしれない。WPANはBluetooth（登録商標）を実装するかもしれない。明瞭のために、本技術はIEEE 802.11 WLANに関して下記に述べられる。
【０００９】
図1は、多数の局120を備えた無線ネットワーク100を示す。一般に、無線ネットワークは、任意の数のアクセス・ポイントおよび任意の数の局を含んでいてもよい。一の局は無線媒体によって別の局と通信することができる装置である。「無線媒体」と「チャネル」という用語はしばしば交換可能に使用される。局は、アクセス・ポイントと通信するか、またはピア・ツー・ピアで別の局と通信してもよい。局はまた、端末、移動局、ユーザー装置、加入者ユニットなどと呼ばれるかもしれないし、これらの機能性のうちのいくらかあるいは全てを含んでいるかもしれない。 局は、携帯電話、携帯型の装置、無線装置、携帯情報端末(PDA)、ラップトップ・コンピューター、無線モデム、コードレスホンなどかもしれない。アクセス・ポイントは、無線媒体によって該アクセス・ポイントに関係付けられた局に配送サービスへのアクセスを提供することができる局です。アクセス・ポイントはまた基地局、基地トランシーバー局(BTS)、ノードB、発展したノードB(eNode B)などと呼ばれるかもしれないし、これらの機能性のうちの幾らかあるいは全てを含んでいるかもしれない。
無線ネットワーク100は、IEEEによって採用された技術標準のIEEE 802.11ファミリーの中のいかなる無線技術を実装してもよい。例えば、無線ネットワーク100は、802.11a、802.11b、802.11eおよび／または802.11gのような追加仕様のうちの1つ以上を含むIEEE 802.11技術標準を実装するかもしれない。無線ネットワーク100はさらにIEEEの802.11nおよび／または802.11sを実装してもよく、それは形成されているIEEE 802.11技術標準である。IEEE 802.11、802.11a、802.11b、802.11gおよび802.11nは、異なる無線技術をカバーし、異なる能力を持っています。IEEE 802.11eは、媒体アクセス制御(MAC)層に関するサービス品質(QoS)拡張をカバーします。
【００１０】
無線ネットワーク100はインフラストラクチャー・ネットワークあるいはアドホックネットワークかもしれない。インフラストラクチャー・ネットワークは、局のための通信をサポートする1つ以上のアクセス・ポイントおよび恐らく他の実体を含んでいる。インフラストラクチャー・ネットワークはまた、IEEE 802.11において基本サービスセット(BSS)と呼ばれる。アドホックネットワークは無線媒体によって専ら互いの相互交信範囲内の局から構成されている。アドホックネットワークは、典型的にはアクセス・ポイントのような中央制御エンティティなしで必要に応じて動的に形成されてもよく、もはや必要でなくなれば、解消されてもよい。アドホックネットワークはまた、IEEE 802.11において独立したBSS(IBSS)と呼ばれる。以下の記述の多くは、無線ネットワーク100がアドホックネットワークであると仮定する。
【００１１】
無線ネットワーク100は、下記の電力保存モードあるいは仕組みのうちの１つ以上をサポートしてもよい:
* スケジュールされていない電力保存 - 起動されている期間中に送信するデータがある場合は常に、データは送信される、
* スケジュールされた電力保存 - 起動されている期間中にデータはスケジュールされたサービス時間において送信される、
* 電力保存マルチポール(PSMP) - 起動されている期間中にデータは単一の広報フレームにより多数の局へ送信される。
【００１２】
スケジュールされていない電力保存モードはまた、電力保存(PS)モード、IBSSのスケジュールされていない電力保存モード、スケジュールされていない自動的な電力保存配達(U-APSD)モードなどと呼ばれてもよい。スケジュールされた電力保存モードはまた、IBSSのスケジュールされた電力保存モード、スケジュールされたAPSD(S-APSD)モードなどと呼ばれてもよい。これらの電力保存モードは、下記に述べられるように、ステーションがスリープ状態となり、電池電力を保存するが異なる方法で作動することを可能にする。
【００１３】
図２は、無線ネットワーク100内での様々な局120に関する例示的な送信時間軸を示す。1つの局(例えば図1の中の局X)は無線ネットワークを形成してもよく、無線ネットワークのためのタイミングを維持してもよい。局Xは、他の局が局Xを検知し識別することを可能にするビーコン・フレームを周期的に送信してもよい。ビーコン・フレームが送信されるべき時間はターゲット・ビーコン送信時間(TBTT)と呼ばれる。連続する２つのビーコン・フレームの開始点の間の時間区間は、ビーコン間隔と呼ばれる。ビーコン間隔は、適切な期間(例えば100ミリ秒(ms)、または他の何らかの時間間隔にセットされてもよい。無線ネットワーク中の局は全て、局Xによって送信されたビーコン・フレームに対してそれらのタイミングを同期させてもよい。
【００１４】
様々なタイプのフレームは複数のビーコン・フレームの間の時間で送信されてもよい。これらのフレームは管理フレーム、制御フレーム、データフレームなどを含んでいるかもしれない。データフレームはまた、パケット、データ・ブロック、データユニット、プロトコルデータユニット(PDU)、サービスデータユニット(SDU)、MAC SDU(MSDU)、MAC PDU(MPDU)などと呼ばれるかもしれない。２つの局が１つ以上のトラフィック・ストリームを持っているかもしれないし、各トラフィック・ストリームとデータフレームを交換するかもしれない。
【００１５】
スケジュールされていない電力保存モードはIEEE 802.11の中のアドホックネットワーク(すなわち、IBSS)の中で使用されてもよい。この場合、局Xは広報トラフィック指示メッセージ(ATIM)ウィンドウに適切な期間を選んでもよく、各ビーコン・フレーム中でATIMウィンドウ期間をブロードキャストするかもしれない。スケジュールされていない電力保存モードで作動するものを含む無線ネットワーク中の全ての局は、これらの局に対して適用可能なフレームを受け取るために各ATIMウィンドウの期間中に起動中であることを要求される。ATIMウィンドウは、TBTTにおいて開始し、ATIMウィンドウ期間が経過したら終了する。
【００１６】
スケジュールされていない電力保存モードにおける動作は以下のように生じてもよい。所与の局Aが別の局Bに送信するための１つ以上のデータフレームを有する場合、局AはATIMウィンドウ期間内に局Bに対してATIMフレームを送信してもよい。無線ネットワーク中の全ての局は、局ＡからATIMフレームを受け取ってよい。局Bは自分がATIMフレームの受取人であり、局Ａが局Ｂへ送信するためのデータを持っていることを認識するかもしれない。局Bは該ATIMフレームに関してアクノレッジメント(ACK)を送信してもよい。ATIMウィンドウの終端において、ATIMフレームを送信しなかった、または受け取らなかった局(例えば局C)はスリープ状態に移行してよい。ATIMフレームを送信し、および/または受け取る局はATIMウィンドウの終端以降にデータを交換してもよい。図２に示される例において、ATIMウィンドウの終端以降に局Aは局Bにデータフレームを送信し、および局Bが該データフレームに対してACKを送信する。局AおよびBはビーコン間隔の終わりまで起動状態のままでい続けることが可能である。
【００１７】
IEEE 802.11におけるアドホックネットワーク中のスケジュールされていない電力保存モードについては、全ての局は各ATIMウィンドウの全期間中において起動状態であることを要求される。これは、該局が他の局に関する処理待ちデータを互いに通知することができることを保証する。ソース局がビーコン・フレームに続くATIMウィンドウの期間中に処理待ちデータを持っている各受信局に対して、該ソース局は、(図２に示されたような)ATIMフレームあるいは送信要求(RTS)フレームを送信するかもしれない。ATIMまたはRTSのフレームを受け取る局、およびATIMまたはRTSのフレームを送信する局は、図２に示されるように、次のATIMウィンドウの終端まで起動状態のままでいることを要求される。低い周期性を備えたトラフィックを有する局に関しては、ATIMウィンドウ中でバッファーされたトラフィックの表示を受け取った後に、１つのビーコン間隔全体にわたって起動状態でいることをこれらの局に要求することは過度の電池電力消費に帰着する可能性がある。このような拡張された起動状態時間は、ビーコン間隔中のほんの少数のデータフレームを受け取り、ビーコン間隔の中で早期にこれらのデータフレームの受信を完了する局には不適当かもしれない。
【００１８】
一の態様では、ソース局は、受信局へ送られたATIMフレームあるいはRTSフレームの中に電力保存バッファー・ステータスを含めてもよい。電力保存バッファー・ステータスは、受信局へ送られるためのデータの量(例えばデータフレームまたはMSDUの数、あるいはデータ・バイトあるいはビットの数)を伝えてもよい。その後、受信局は、ソース局からどれだけの量のデータ(例えばどれだけの数のデータフレーム)が予想されるか知るであろう。受信局は、次のATIMウィンドウの終端まで待たなければならない代わりに、予想される量のデータ(あるいはデータフレームの数)の受信を完了した後にスリープ状態に移行してよく、それは電池の電力を節約するかもしれない。例えば、受信局が２つのデータフレームを示す電力保存バッファー・ステータスを備えた、ATIMフレームあるいはRTSフレームを受け取る場合、受信局は２つのデータフレームを受け取った後にスリープ状態に移行してよい。バッファーされたデータの量はバイト数で与えられるかもしれず、MACフレームの断片化が生じた場合、これは有用であろう。
【００１９】
図３は、電力保存バッファー・ステータスを伝達することができるフレーム300の設計を示す。フレーム300はATIMフレーム、RTSフレームなどに使用されてもよい。フレーム300は様々な情報の断片を提供するフレーム制御フィールド、該フレームの受信局を識別する宛先アドレスフィールド、該フレームを送信するソース局を識別するソース・アドレス・フィールド、電力保存バッファー・ステータス・フィールドを含んでいるフレームボディ・フィールド、そして場合によっては、明瞭さのために図３には示されなかった他のフィールドを含む。
【００２０】
フレーム制御フィールドはタイプ・サブフィールド、サブタイプ・サブフィールド、電力管理(Pwr Mgt)フィールド、および図3に示されない他のフィールドを含んでいる。タイプ・サブフィールドは管理フレームについては「00」、または制御フレームについては「01」にセットされてもよい。サブタイプ・フィールドは、ATIMフレーム(それは管理フレームの１つのタイプである)については「1001」あるいはRTSフレーム（それは制御フレームの１つのタイプのである）については「1011」にセットされてもよい。電力管理フィールドは、局が電力保存モードにあることを示すために「1」にセットされ、あるいは局がアクティブ・モードにあることを示すために「0」にセットされても良い。
【００２１】
ATIMとRTSのフレームについては、フレームボディ・フィールドは現在はどんな情報も伝えないヌルのフィールドである。図３に示される設計では、電力保存バッファー・ステータス・フィールドはフレームボディ・フィールドに含まれているかもしれないし、ソース局が受信局のためにバッファーしたデータフレームあるいはMSDUの数を示すかもしれない。電力保存バッファー・ステータスもまた、フレーム制御フィールドのサブフィールド中で提供されるかもしれないし、あるいは他の方法で、管理フレーム、制御フレームあるいはデータフレームの中で送信されるかもしれない。
【００２２】
一般に、電力保存バッファー・ステータスは、バッファーされたデータの利用可能性(例えば、「はい」、または「いいえ」)、バッファーされたデータの量、バッファーされたデータフレームの数あるいはバイト数などを示すかもしれない。電力保存バッファー・ステータスは、ATIMフレーム、RTSフレーム、データフレームあるいは他の何らかのフレーム中で伝えられてもよい。
【００２３】
図４は、電力保存バッファー・ステータス特性を伴うスケジュールされていない電力保存モードにおける例示的な動作を示す。この例において、局Aは、局Bに送信するための1つのデータフレームを持っている。駅Aは局Bに対してATIMウィンドウの期間内にATIMフレームを送信します。ATIMフレームは、局Bのためにバッファーされた１つのデータフレームを示す電力保存バッファー・ステータス(PSBS)を含んでいる。局Bは該ATIMフレームのためにACKを返します。この例において、他のATIMフレームはATIMウィンドウの期間内に全く送信されない。ATIMウィンドウの終端においては、局AおよびBは起動状態のままでいる。局Cは如何なるATIMフレームも送信または受信しておらず、この結果、スリープ状態に移行することができる。
【００２４】
電力保存バッファー・ステータスに基づいて、局Bが局Aから１つのデータフレームを受け取ることを予期する。局Aは該データフレームを送信し、また局Bは該データフレームのためにACKを返す。該データフレームを受け取った後に、局Bは、局Aからこれ以上のデータを受け取ることを予期せず、該データフレームに対してACKを送信した後にスリープ状態に移行することができる。該データフレームを送信した後に、局Aは、局Bに対するこれ以上のデータを持っておらず、該データフレームに対するACKを受け取った後にスリープ状態に移行することができる。したがって、局Aおよび局Bの両方は、次のATIMウィンドウの終端まで待たなければならない代わりに、早期にスリープ状態に移行してもよい。
【００２５】
無線チャネル上のデータの送信は信頼性が低いかもしれない。したがって、局Aからの最後のデータフレームの受信の後に局Bによって送られたACKを局Ａが受け取らない場合があるかもしれない。該チャネル・アクセス手順によれば、ACKが受信されない場合に、局Ａは最後のデータフレームを再送信するかもしれず、局Ｂが該データフレームを復号化していないので局ＢがACKを送っていないと仮定するかもしれない。局Ｂがスリープ状態に移行するならば、局Ｂは再送信を復号化しないであろう。それが最大再試行回数に達するまで、局Ａは再送信し続けるかもしれない(そのステージでは局は送信を異常終了させるだろう)。これは局Aに関する過度の電力垂れ流しに帰着し、無線媒体を浪費するかもしれない。局AおよびBの電力能力へ依存して、局Bは、最後のデータフレームのためにACKを送った後にできるだけ早くスリープ状態に移行することを選ぶかもしれない(例えば、局Bは電力に制限があるかもしれないし、局Aの電力供給とは関わりが無いかもしれない)、または局Ｂは、このACKを送った後、ある長さの時間だけ起動状態のままでいることを選択するかもしれない(例えば、局AとBは、両方とも電力に制限があるかもしれない)。第１のACKが無線チャネルによって消去された後に、局Ａが再送信するならば、最後のデータフレームに対してACKを送った後に起動状態であり続けることは、局ＢがACKを送信することを可能にするだろう。ネットワーク負荷を軽減すると同時に、局Aおよび局Bの両方によって省電力を改善するためにどれくらい長く起動状態であり続けるべきかを推定するために、局BはSIFS、DIFS、競合ウィンドウサイズ、無線媒体負荷、IBSSの中の局の数などを使用することが可能である。局Ｂが２重化されたフレームを受け取るならば、どれくらい長く起動状態であり続けるべきかを決定する際に、１つだけが考慮される。
【００２６】
一般に、最後のデータフレーム(あるいは任意のデータフレーム)に対するACKが、ソース局によって受け取られなかった場合、ソースと受信側の局は終了戦略を取り決めるかもしれません。上に記述されるように、受取人局は、ソース局から可能な再送信を受け取るための時間の長さだけ起動状態のままでいるかもしれない。代替的に、ACKが受信局から受け取られない場合、ソース局は、現在の起動状態期間中において最後のデータフレームの再送信をスキップするかもしれない。代わりにソース局は、後続する起動状態期間においてこのデータフレームを再送信してもよく、あるいは該データフレームを廃棄してもよい。そしてこの事は、最後のデータフレームのためにACKを送った直後に、受信局がスリープ状態に移行することを可能にするであろう。他の終了戦略もまた、ソースと受信側の局の間で取り決められてもよい。
【００２７】
ソース局は、受信局へ送信するための多数のデータフレームを有していてもよく、一度に１つのデータフレームを送信してもよい。各データフレームについて、ソース局は、該チャネルへのアクセスを獲得するためにチャネル・アクセスを実行しても良く、アクセスを獲得した時点で該チャネル経由で該データフレームを送信してもよい。
【００２８】
図５は、IEEE 802.11における分散協調機能(DCF)を備えた局Bに対する局Aによる多数のデータフレームの送信を示す。局Aは、送信するためのデータを持っており、チャネルが使用中か使用されていないかどうか判断するために時間T1においてチャネルのセンシングを開始する。チャネルがDCFフレーム間スペース(DIFS)と等しい期間の間使用されていない場合、局Aは、時間T2からスタートするデータフレームを送信することができる。ここで、局Bは局Aからのデータフレームを受け取り復号化する。
【００２９】
時間T3におけるデータフレームの終端の後に、局Bは短いフレーム間スペース(SIFS)時間の間待ち、時間T4からスタートするACKを送信する。ここで、SIFSがDIFSより短いので、局Bは、データフレームの終端以降に他の局より先にチャネルにアクセスすることができる。これは、局Aが適時の方法でACKを受け取ることができることを保証する。
【００３０】
局Aは、送信するための別のデータフレームを持っており、チャネルが使用中か使用されていないかどうか判断するために時間T5でチャネルのセンシングを開始する。この例において、チャネルは最初は使用中ではないが、時間T6において使用中となる。その後、時間T7において、チャネルが使用されなくなるまで局Ａは待機してもよく、そこからさらにチャネルがDIFS期間の間使用中でないことを局Aは待ってもよく、それは時間T8で生じる。その後、局Aは、０と競合ウィンドウ(CW)の間のランダムなバックオフを選択してもよい。ランダムなバックオフは、DIFS期間の間チャネルが使用されていないことをセンスした後に、多数の局が同時に送信するシナリオを回避するために使用される。その後局Aは、該ランダムなバックオフをカウントダウンし、チャネルが使用中となる場合は常に休止し、チャネルがDIFS期間にわたって使用中でない後にカウントダウンを再開する(図５に示されない)。該カウントダウンが時間T9で０に達する場合、局は該データフレームを送信することができる。局Bは局Aからのデータフレームを受け取り復号化する。時間T10におけるデータフレームの終端以降に、局BはSIFS時間の間待ち、時間T11からスタートするACKを送信する。
【００３１】
ここで、図５に示されるように、各データフレームについてチャネル・アクセスを実行することは多数のデータフレームを送信するための時間の長さを拡張するかもしれない。これは該チャネルが任意のチャネル・アクセスの期間中に使用中となることができるからであり、そしてさらに該ソース局は他の局と該チャネルをめぐって争う必要があるだろう。チャネル・アクセスの各々はアクセス遅延およびACKオーバーヘッドを加算する。多数のデータフレームに関する拡張された送信時間は、ソースと受信側の局がより長い間起動状態でいるという結果になるだろう。
【００３２】
別の態様では、１つのTXOPの中で多数のデータフレームを受け取ることができる局は、他の局に対してこのTXOPバースト受信機能を広告することができる。TXOPバースト受信機能は、単一のチャネル・アクセスを伴う１つのTXOPの中での多数のデータフレームの配送をサポートし、それは、該複数のデータフレームを送信するための時間の長さを短くするかもしれない。
【００３３】
一の局が無線ネットワークに参加する場合、該局は、アソシエーション要求フレーム中において機能情報フィールドを送信してもよい。該局はまた、ATIMフレームあるいは他の何らかの管理フレーム中において機能情報フィールドを送信しても良い。機能情報フィールドは、該局によってTXOPバースト受信がサポートされるかどうか、および１つのTXOPの中において該局によって受け取ることができるデータフレームの数についての情報を含んでいてもよく、それはN-ビット値(例えば8ビットの値)によって与えられてもよい。１つの設計では、オール０の値は、TXOPバースト受信がサポートされないことを示してもよい。オール１の値は、最も高いデータ転送速度で該局が１つのTXOPの中において任意の数のデータフレームを受け取ることができることを示してもよい。その他の値は、各TXOP毎に受け取ることができるデータフレームの数を示してもよい。別の設計では、各TXOP毎に受け取ることができるデータフレームの数は、ある許可された値(例えば0、1、2、4、オール１の値)に制限されるかもしれず、全ての局はこれをサポートすることを強制されても良い。一般に、TXOPバーストがサポートされるか否か、および各TXOP毎に受け取ることができるデータフレームの数は１つ以上のフィールドで提供されてもよく、如何なるフォーマットを使用して提供されても良い。
【００３４】
図6Aは、TXOPバースト受信機能を伝えることができるフレーム600の設計を示す。フレーム600は、アソシエーション要求フレーム、認証フレームあるいは他の何らかの管理フレーム、制御フレーム、またはデータフレームに使用されてもよい。フレーム600は、フレーム制御フィールド、宛先アドレスフィールド、ソース・アドレス・フィールド、フレームボディ・フィールド、および場合によっては明瞭さのために図6Aの中で示されない他のフィールドを含んでいる。フレームボディ・フィールドは、機能情報フィールド、および場合によっては図6Aの中で示されない他のフィールドを含んでいる。機能情報フィールドは、上に記述されるように定義されてもよいTXOPバースト受信(Rx)機能サブフィールドを含んでいる。TXOPバースト受信機能はまた、フレームボディ・フィールド内の別個のフィールドとして伝送されてもよく、あるいは他の方法で管理フレームあるいは制御フレームの中で送信されるかもしれない。TXOPバースト受信機能はまた、他の何らかのタイプのフレームの中で(例えばソース局によって送られた第１のデータフレームの中で)送られるかもしれない。
【００３５】
(アドホックネットワークを形成した)局Ｘは、(例えばアドホックネットワーク中の他の局によるアソシエーションの期間中に)これらの局のTXOPバースト受信機能を受け取ってもよい。局Ｘは、ビーコン・フレームによってこれらの局のTXOPバースト受信機能をブロードキャストしてもよい。
【００３６】
図6Bは、アドホックネットワーク中の複数の局のTXOPバースト受信機能を伝えることができる、ビーコン・フレーム610の設計を示す。ビーコン・フレーム610は、フレーム制御フィールド、フレームボディ・フィールド、および明瞭さのための図6Bの中で示されない他のフィールドを含んでいる。フレームボディ・フィールドはビーコン間隔を示すビーコン間隔フィールド、局Ｘの機能を示す機能情報フィールド、(例えばATIMウィンドウの期間中に)アドホックネットワークをサポートするために使用される一組のパラメーターを示すIBSSパラメーター・セット・フィールド、TXOPバースト受信機能情報フィールド、及び場合によっては他のフィールドを含む。TXOP受信機能情報フィールドは、そのTXOPバースト受信機能が該ビーコン・フレームの中でブロードキャストされる各局毎に１つのエントリーを含んでいてもよい。各局についての該エントリーは、局識別子すなわちアドレス(STA Yk)に関するサブフィールド、およびその局のTXOPバースト受信機能に関するサブフィールドを含んでいてもよい。局のTXOPバースト受信機能はまた、他の方法、および／または他のフレームの中でブロードキャストされてもよい。
【００３７】
さらに別の態様では、１つのTXOPの中において多数のデータフレームを送信することができる局は、他の局に対してこのTXOPバースト送信機能を広告することができる。TXOPバースト送信機能は、単一のチャネル・アクセスを伴う１つのTXOPの中において多数のデータフレームの送信を可能にする。TXOPバースト送信機能は、TXOPバースト受信機能と同様の方法で伝えられ広告されてもよい。
【００３８】
図７は、TXOPバースト機能を備えた局Bに対する局Aによる多数のデータフレームの送信を示す。局Aは、送信するためのデータを持っており、時間T1でチャネルのセンシングを開始する。DIFS時間の間チャネルが使用されていないとセンスした後に、局Aは、時間T2からスタートする第１のデータフレームを送信する。局Bは第１のデータフレームを受け取り復号化し、時間T3における第１のデータフレームの終端以降にSIFS時間待ち、時間T4からスタートするACKを送信する。局AはACKを受け取り、時間T5におけるACKの終端以降にSIFS時間の間待ち、時間T6からスタートする第２のデータフレームを送信する。SIFSがDIFSより短いので、チャネルがDIFS時間の間使用されていないことを待っている他の局からの競合無しで局Ａは第２のデータフレームを送信することができる。局Bは第２のデータフレームを受け取り復号化し、時間T7における第２のデータフレームの終端以降にSIFS時間の間待ち、時間T8からスタートするACKを送信する。任意の数のデータフレームとACKが局ＢのTXOPバースト受信機能によって制限された同様の方法で送信されてもよい。時間T10(それは以前のACK(図7に示されない)が終わってからSIFS時間後である)において、局Aは最後のデータフレームを送信する。局Bは最後のデータフレームを受け取り復号化し、時間T11で最後のデータフレームが終わってからSIFS時間待ち、時間T12からスタートするACKを送信します。
【００３９】
図7に示されるように、局Aは１つのチャネル・アクセスを伴う１つのTXOPの中において任意の数のデータフレームを送信することができ、それは、複数のデータフレームを送信するための時間の長さを短くするかもしれません。これは、局Aおよび局Bの両方がより早期にスリープ状態に移行することを可能にするかもしれず、それは電池動力を節約する可能性がある。TXOPバーストは、IEEE 802.11nにおける集約MPDU(A-MPDU)のような集約パケットに関しても良い。
【００４０】
一般に、電力保存バッファー・ステータスおよびTXOPバースト特性は別々にあるいは組み合わされて使用されてもよい。これらの２つの特性の組み合わせは、この局についての切迫したデータ転送に関する受信局に正確な情報を提供することが可能である。例えば、電力保存バッファー・ステータスが４つの保留されているデータフレームを示し、TXOPバースト受信機能が、各TXOP毎に６つのデータフレームを示す場合、ソース局は1つのTXOPの中において４つのデータフレームを送るかもしれない。電力保存バッファー・ステータスが４つの保留されているデータフレームを示し、TXOPバースト受信がサポートされない場合、受信局は一度に１つのデータフレームを受け取り、そして直ちに、あるいは、４つのデータフレームをすべて受け取ってから暫らくした後にスリープ状態に移行することができる。
【００４１】
電力保存バッファー・ステータス、および／またはTXOPバースト特性は、上にリストされた電力保存モードのうちのどれと共に使用されてもよい。これらの特性はまた、これらの電力保存モードと無関係に使用されてもよい。
【００４２】
スケジュールされていない電力保存モードに関しては、ソース局は、図４に示されるように、ATIMウィンドウ内で送られるATIMフレームあるいはRTSフレームの中に受信局のための電力保存バッファー・ステータスを含んでいてもよい。ソース局は各TXOPの中のATIMウィンドウが終わってから受信局へ１つ以上のデータフレームを送信してもよい。電力保存バッファー・ステータス、および／またはTXOPバースト特性を伴うスケジュールされていない電力保存モードは、非周期的なトラフィック、あるいはある程度の遅延およびジッタを許容することができるトラフィックを有する局によって有利に使用されてもよい。これらの特性を伴うスケジュールされていない電力保存モードも他のシナリオの中で使用されてもよい。
【００４３】
スケジュールされた電力保存モードについては、２つの局が、データを送信および／または受信するために複数のビーコン・フレーム間の固定間隔で起動状態となることを取り決めるかもしれない。この間隔はサービス期間と呼ばれる。サービス期間の交渉は、２つの局の間のトラフィック・ストリーム等のためのトラフィック仕様(TSPEC)の設定動作を介してIBSS設定動作の期間中に実行されても良い。IBSSの中でスケジュールすることはIEEE 802.11によって現在定義されていないが、任意の仕組みを使用して２つの局がサービス期間を交渉し、スケジュールしてもよい。サービス期間の交渉は、各局に関する電力保存バッファー・ステータスおよびTXOPバースト受信機能に関する情報の交換に追加されるものであっても良い。
【００４４】
図８は、電力保存バッファー・ステータスおよびTXOPバースト特性を伴うスケジュールされた電力保存モードにおける例示的動作を示す。この例において、局Aと局Bは、サービス時間をT1とすること、およびデータを交換するために該サービス時間に先立って両方の局が起動状態となることを取り決めた。
【００４５】
サービス時間T1では、局Aはチャネルにアクセスし、局Bに第１のデータフレームを送信する。このデータフレームは、局Aが局Ｂのためにバッファーしたデータフレームの数を示す電力保存バッファー・ステータスを含んでいてもよい。局BのTXOPバースト受信機能はサービス期間の交渉の間に局Ａに知らされる可能性がある。いずれにしても、局Bは、局Aからの予想されるデータフレームの数についての情報を持っているかもしれず、局Aには局BのTXOPバースト受信機能についての情報があるかもしれない。局Bは第１のデータフレームのためにACKを返す。その後局Aは、局Bへ残りのデータフレームを送信する（例えば、図７に関して上に記述されるような局BのTXOPバースト受信機能を使用するなどして）。
【００４６】
その後、局Bはチャネルにアクセスし、局Ａに対して第１のデータフレームを送信してもよい。このデータフレームは、局Bが局Aのためにバッファーしたデータフレームの数、あるいは他の何らかのバッファー情報を示す電力保存バッファー・ステータスを含んでいてもよい。局AのTXOPバースト受信機能はサービス期間の交渉の間に局Bに知らされる可能性がある。いずれにしても、局Aは、局Bからの予想されるデータフレームの数についての情報を持っているかもしれず、局Bには局AのTXOPバースト受信機能についての情報があるかもしれない。局Aは第１のデータフレームのためにACKを返す。その後局Bは、局Aに対して残りのデータフレームを送信する（例えば、図７に関して上に記述されたようにして）。局Aは最後の予期されたデータフレームに対してACKを送った後に暫くしてスリープ状態に移行してもよい。各局がスリープ状態に移行する時刻は無線媒体条件、フレーム間間隔などに依存するかもしれない。
【００４７】
一般に、サービス期間中のデータ交換は、(図８に示されるように)データを送信する両方の局について双方向かもしれないし、あるいはデータを送信するたった１つの局について片方向かもしれない。これはトラフィック・ストリームの特性に依存するかもしれないし、TSPECの設定動作中に指示されるかもしれない。
【００４８】
各サービス期間中のデータ交換は通常のチャネル・アクセス規則に従ってもよい。最初に送信するようスケジュールされた局(例えば図８の中の局A)は、チャネル・アクセスを実行しても良い。チャネル・アクセスは可変量の時間を要するかもしれず、それはサービス時間の周囲のチャネル負荷に依存するかもしれない。該最初に送信する局に対して送信するデータを２番目に送信するようにスケジュールされた局（例えば、図８における局Ｂ）が有する場合、該局もまたチャネル・アクセスを実行する（図８において示されるとおり）、または該最初に送信する局によって送信された最後のデータフレームの終端からSIFS時間経過後にACKを送信する（図８には示されていない）。
【００４９】
図８は、データを送信するための局AおよびBの両方によるTXOPバースト特性の使用を示す。一般に、各局はTXOPバースト特性を使用するかもしれないし、使用しないかもしれない。図８に示されるように、局Bがどんなデータフレームをも送信する前に、局Aはそのデータフレームをすべて送信するかもしれない。代替的に、２つの局は交互の態様でそれらのデータフレームを送信するかもしれない。例えば、局Ａにより送信された第１のデータフレームに続いて、局Bは、局Aから受け取られたデータフレームに関するACKと共にその第１のデータフレームを送信してもよい。その後局Ａは、局Bから受け取られたデータフレームに関するACKと共にその２番目のデータフレームを送信してもよい。
【００５０】
TXOPバーストが使用される場合、受信局はACKによりデータフレームを個々にアクノレッジするかもしれないし、あるいはブロックACKを有する幾つかのデータフレームをアクノレッジするかもしれない。ACKと同様に、最後の予期されたデータフレームを受け取った後にブロックACKを送信する局は、ブロックACKが別の局によって受け取られなかった場合、ブロックACKを送った後にどれくらい長く起動状態のままでいるべきかを決定しても良い。ブロックACK機能はソースと受信側の局の間で交渉されるかもしれない。
【００５１】
データフレームがどのように送信されるかには関係なく、電力保存バッファー・ステータスはソース局においてより多くのバッファーされたデータフレームが存在するか否かを判断するために使用されてもよい。より多くのバッファーされたデータフレームが存在する場合、受信局はスリープ状態に移行する前にデータフレームをすべて受け取るために待ってもよい。
【００５２】
電力保存バッファー・ステータス、および／またはTXOPバースト特性を有するスケジュールされた電力保存モードは、音声トラフィック、ビデオトラフィック、ゲームなどのような様々なタイプの周期的なトラフィックを有する局によって有利に使用されてもよい。これらの特性を有するスケジュールされた電力保存モードはまた、他のシナリオの中で使用されてもよい。
【００５３】
PSMPモードは、単一フレームを使用して、インフラストラクチャー・ネットワーク中のアクセス・ポイント(すなわちBSS)が多数の局のためのアップリンク転送とダウンリンク転送のための１回限りの来るべきスケジュールを広報することを可能にする。該アクセス・ポイントは、集約される全ての局に関する共通のサービス時間を選択してもよい。該アクセス・ポイントは共通のサービス時間においてPSMPフレームを送信してもよい。該PSMPフレームは、現在のPSMPサービス時間の中でスケジュールされた局の各々のための開始時刻を示してもよい。その後、該アクセス・ポイントは一度に、かつ、その局のための開始時刻において１つの局をサービスしてもよい。各局は該PSMPフレームを受け取り、該PSMPフレームによって示されるとおりにその開始時刻までスリープ状態となり、該アクセス・ポイントでデータを交換するためにその開始時刻に先立って起動状態となっても良い。PSMPサービス期間は、全てのスケジュールされた局に関して該PSMPフレームおよび後続するフレーム交換をカバーする。単一のチャネル・アクセスはPSMPサービス期間に関する共通のサービス時間において該アクセス・ポイントによって実行されても良い。
【００５４】
バッファーを用いたデータおよび場合によっては多数の受信局のためのスケジュールをソース局が広報することを可能にするために、PSMP機能はアドホックネットワーク(すなわち、IBSS)の中で使用されてもよい。局Ａ(あるいはアドホックネットワーク中の他の局)は、PSMPフレームを生成し受け取るための自身の機能を機能情報フィールド内で示してもよい。局Aは、IBSS設定動作中に局X(それはアドホックネットワークを形成し、周期的にビーコン・フレームを送信する局である)とこの情報を交換してもよい。局Xは、アドホックネットワーク内の他の局のPSMP機能をビーコン・フレーム中においてブロードキャストしてもよい。代替的に又は追加的に、局Aは、アドホックネットワーク中で他の局にそのPSMP機能を直接伝えるかもしれない。PSMPフレームを受け取ることができる局だけが、PSMPサービス期間に含まれている。
【００５５】
図6Bは、アドホックネットワーク中の局のPSMP機能を伝えることができるビーコン・フレーム610の設計を示す。ビーコン・フレーム610はフレームボディ・フィールドにPSMP機能情報フィールドを含んでいる。PSMP機能情報フィールドは、そのPSMP機能がビーコン・フレームの中でブロードキャストされる各局毎に１つのエントリーを含んでいてもよい。各局についてのエントリーは、局識別子すなわちアドレス(STA Zm)に関するサブフィールド、およびその局のPSMP機能に関するサブフィールドを含んでいてもよい。各局についてのエントリーは、該局がPSMPフレームを送信することができるかどうか、または、PSMPフレームを受け取ることができるどうかを示してもよい。該局のPSMP機能はまた、他の方法および／または他のフレームの中でブロードキャストされてもよい。
【００５６】
図9は、電力保存バッファー・ステータスおよびTXOPバースト特性を有するPSMPモードにおける例示的動作を示す。この例において、局Aは、2つの受信局BおよびCのためのバッファーされたデータを有しており、ATIMウィンドウの期間中に一のビーコン・フレームに続いて(多数のATIMフレームの代わりに)一のPSMPフレームを送信してもよい。アドホックネットワーク中の全ての局に同じチャネル・アクセス優先順位があるので、局Aはビーコン・フレームに直ちに続いてスケジュールを広報することができないかもしれないし、ビーコン間隔中はスケジュールを維持するかもしれない。この問題を緩和するために、図９に示されるように、２ステージPSMP広報が使用されてもよい。
【００５７】
局Aは、ATIMウィンドウの期間中に該ビーコン・フレームに続いて第１のPSMPフレームを送信する。このPSMPフレームは、局Aがそのためにデータをバッファーした各局の電力保存バッファー・ステータス(PSBS)を示すかもしれない。他の局は、それらが局Aからデータを受け取るのに起動状態でいるべきかどうか判断するために電力保存バッファー・ステータス情報を使用するかもしれない。第１のPSMPフレームはさらにPSMPサービス期間を示すかもしれず、それは、該第１のPSMPフレームの中で識別された局をサービスすることを局Aが予期する現在のビーコン間隔中の時間区間である。
【００５８】
局Aは後続するチャネル・アクセスに続くATIMウィンドウが終わってから第２のPSMPフレームを送信する。１つの設計では、第２のPSMPフレームは、第１のおよび／または第２のPSMPフレームにおいて識別される各局毎のスケジュールを示す。その後局Aは、１つの受信局を、一度に、かつ、その局のための開始時刻でサービスする。局Aはその受信局のTXOPバースト受信機能を使用して、各受信局へ送信してもよく、それは任意の方法で伝えられてもよい。各受信局は第２のPSMPフレームを受け取り、該PSMPフレームによって示されるとおりにその開始時刻までスリープ状態となり、局Aとデータを交換するためにその開始時刻に先立って起動状態となってもよい。別の設計では、第２のPSMPフレームは、該受信局の電力保存バッファー・ステータスを示し、スケジュールを含んでいなくてもよい。その後、局Aはその受信局のTXOPバースト受信機能を使用して、各受信局へ送信してもよい。一般に、第２のPSMPフレームは、スケジュールを広報するかあるいは該受信局へデータを送信するために使用されてもよい。TXOPバーストが有効化される場合、ACKあるいはブロックACKのいずれかが受信局によって送信されてもよい。最後の予期されたデータフレームの受信の後に該ACKか該ブロックACKを送信した後の起動状態でいる期間は、該受信局によって選択されても良い。サービス期間内では、第２のPSMPフレームは、電力を節約することができる、より多くの粒度を可能とする。現在のPSMP期間の終わりまでチャネル・アクセスを延期するために、第２のPSMPフレーム中の情報はIBSS中の他の局によって使用されてもよい。
【００５９】
図10は、データを送信するための方法1000の設計を示す。そこへ送るべきデータがある第２の局に関するバッファー・ステータスは第１の局で決定されてもよい(ブロック1012)。第２の局はアドホックネットワーク中において電力保存モードで作動するかもしれず、該バッファー・ステータスは、該第２の局へ送るためのデータフレームの数を示すかもしれない。該バッファー・ステータスを含むフレームが生成され(ブロック1014)、第１と第２の両方の局に関して起動状態でいる時間の間に、第１の局から第２の局へ送られるかもしれない(ブロック1016)。少なくとも1つのデータフレームは、バッファー・ステータスによって示されるとおり第２の局へ送られてもよい(ブロック1018)。
【００６０】
該バッファー・ステータスを備えたフレームはATIMフレームあるいはRTSフレームかもしれないし、第１と第２の局が両方とも起動状態でいる時間ウィンドウ内で(例えば図4に示されるようなATIMウィンドウ内で)送られるかもしれない。該バッファー・ステータスを備えたフレームはまた、そこに送るべきデータがある多数の局に関するバッファー・ステータスを含むPSMPフレームであってもよい。PSMPフレームはATIMウィンドウ内で、あるいはPSMPサービス期間中に送られるかもしれない（例えば、図９に示されるように）。該バッファー・ステータスを備えたフレームはまた、該局に関するサービス間隔中に送られた第１のデータフレームかもしれない（例えば、図８に示されたように）。
【００６１】
図11は、データを送信するための装置1100の設計を示す。装置1100は、そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを、第１の局において決定するための手段(モジュール1112)、該バッファー・ステータスを含むフレームを生成するための手段(モジュール1114)、第１と第２の両方の局に関して起動状態でいる期間中に第１の局から第2の局へフレームを送るための手段(モジュール1116)、またバッファー・ステータスによって示さるとおりに第２の局に対して少なくとも1つのデータフレームを送るための手段(モジュール1118)を含む。
【００６２】
図12は、データを受信するための方法1200の設計を示す。第１と第２の両方の局に関して起動状態でいる期間中に、第２の局のためのバッファー・ステータスを含むフレームは、第１の局から受け取られるかもしれない(ブロック1212)。少なくとも１つのデータフレームは、バッファー・ステータスによって示されるとおりに該第１の局から受信されるかもしれない(ブロック1214)。第２の局はアドホックネットワーク中では電力保存モードで作動するかもしれない。スリープ状態に移行するべきかどうかは、第１の局から受け取られた、全てのデータフレーム、およびバッファー・ステータスに基づいて決定されるかもしれません(ブロック1216)。
【００６３】
該バッファー・ステータスを備えたフレームは、ATIMフレーム、RTSフレーム、あるいはPSMPフレームかもしれないし、ビーコン間隔中のATIMウィンドウ内で受信されてもよい。少なくとも１つのデータフレームはATIMウィンドウの後に受け取られてもよい。該バッファー・ステータスを備えたフレームはまた、データフレームかもしれないし、第２の局のためのサービス間隔中で受信されるかもしれません。もしあれば、バッファー・ステータスによって示されるとおりに、追加のデータフレームが受信されるかもしれない。どんな場合も、第２の局は、バッファー・ステータスによって示されるとおりに、かつビーコン間隔の終端に先立って、全てのデータフレームを受信した後に、スリープ状態に移行してもよい。第２の局は、最後の予期されたデータフレームを含む受信されたデータフレームに対するACKあるいはブロックACKを送信しても良い。第２の局は全てのデータフレームを受信し、アクノレッジした後にスリープ状態に移行してもよい。第２の局はまた、自身のACKまたはブロックACKが失われ、いくつかのデータフレームが該第１の局によって再送信される状況に対処するためにその受信機チェインを電源オフすることを遅らせてもよい。
【００６４】
図13は、データを受信するための装置1300の設計を示す。装置1300は、第１と第２の両方の局に関して起動状態でいる期間中に第１の局から第２の局のためのバッファー・ステータスを含むフレームを受信するための手段(モジュール1312)、該バッファー・ステータスによって示されるとおりに、該第１の局からの少なくとも１つのデータフレームを受信するための手段(モジュール1314)、また該第１の局から受信された、全てのデータフレームおよびバッファー・ステータスに基づいてスリープ状態に移行するべきかどうか判断するための手段(モジュール1316)を含む。
【００６５】
図14は、データを送信するための方法1400の設計を示す。電力保存モードで作動する第２の局のTXOPバースト受信機能についての情報を含むフレームは、第１の局によって受信されても良い(ブロック1412)。TXOPバースト受信機能についての情報は、単一のTXOPの中において該第２の局によって受け取ることができるデータフレームの数を示してもよい。該フレームは管理フレームかもしれないし、第２の局とのアソシエーションの期間中に受信されても良い。該フレームはさらにビーコン・フレームかもしれないし、ターゲット・ビーコン送信時間において(TBTT)にブロードキャストされてもよい。該フレームはまた、該第２の局によって送信されたデータフレームであってもよい。どんな場合も、第２の局のTXOPバースト受信機能に基づいて単一のTXOPの中において多数のデータフレームが第２の局へ送られてもよい(ブロック1414)。ブロック1414に関しては、チャネル・アクセスはTXOPの開始時点で該第１の局によって実行されても良い。その後、該多数のデータフレームは、別のチャネル・アクセスを行なわずに、該TXOPの中において該第１の局によって送信されても良い（例えば、図７〜９の中で示されるように）。
【００６６】
図15は、データを送信するための装置1500の設計を示す。装置1500は、電力保存モードで作動する第２の局のTXOPバースト受信機能についての情報を含むフレームを第１の局において受け取るための手段(モジュール1512)、該第２の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第２の局に対して多数のデータフレームを送信するための手段(モジュール1514)を含む。
【００６７】
図16は、データを受信するための方法1600の設計を示す。電力保存モードで作動する第１の局のTXOPバースト受信機能についての情報を含むフレームが送信されても良い(ブロック1612)。該第１の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第１の局に対して第２の局によって送信された多数のデータフレームは受信されても良い(ブロック1614)。
【００６８】
図17は、データを受信するための装置1700の設計を示す。装置1700は、電力保存モードで作動する第１の局のTXOPバースト受信機能についての情報を含むフレームを送信するための手段(モジュール1712)、該第１の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第１の局に対して第２の局によって送信された多数のデータフレームを受信するための手段(モジュール1714)を含む。
【００６９】
図18は、図1の中の局120aおよび120xの設計のブロック図を示し、それらは２つの例示的な局である。局120xでは、送信(TX)データ・プロセッサ1812は送信のためにスケジュールされた局に関するデータソース1810からトラフィック・データを受け取ってもよく、コントローラ/プロセッサ1820から制御データ、およびスケジューラ1824からスケジューリング情報を受け取ってもよい(例えばスケジューリングが利用される場合)。制御データは、そこへデータが送られる局の電力保存バッファー・ステータス、TXOPバースト受信機能、および／または無線ネットワーク中の局のPSMP機能、および／または他の情報を含んでもよい。一般に、スケジューリングは各局によって利用されるかもしれないし、利用されないかもしれない。フレームは、バッファーされたデータの広報に基づいて(例えば、ATIM、RTSおよび／またはPSMPフレームを使用して)、該チャネルをめぐる競合に基づいて、あるいは他のアプローチに基づいて局の間で送信されてもよい。TXデータ・プロセッサ1812は、各局について選択されたレートに基づいて各局に関するデータを処理し(例えば、符号化し、インタリーブし、変調し、スクランブルする)、制御データおよびスケジューリング情報を処理し、出力チップを生成してもよい。送信器(TMTR)1814は出力チップを処理し(例えば、アナログに変換する、増幅する、フィルタリングする、そして周波数アップコンバートする)、変調された信号を生成してもよく、それはアンテナ1816から他の局に送信されてもよい。
【００７０】
局120aでは、アンテナ1852は局120xおよび／または他の局から変調された信号を受け取ってもよく、受信信号を提供してもよい。受信器(RCVR)1854は受信信号を処理し、サンプルを提供してもよい。受信(RX)データ・プロセッサ1856はサンプルを処理し(例えば、逆スクランブルし、復調し、逆インタリーブし、復号化する)、局120aのためにデータシンク1858へと復号化されたデータを供給し、コントローラ/プロセッサ1860に制御データおよびスケジューリング情報を供給してもよい。
【００７１】
局120aでは、TXデータ・プロセッサ1872はデータソース1870からトラフィック・データを受け取り、コントローラ/プロセッサ1860から制御データ(例えば電力保存バッファー・ステータス、TXOPバースト受信機能、PSMP機能など)を受け取ってもよい。TXデータ・プロセッサ1872は、その局について選択されたレートに基づいて、各受信局についてトラフィックと制御のデータを処理し、出力チップを生成してもよい。送信器1874は出力チップを処理し、変調された信号を生成してもよく、それはアンテナ1852から他の局に送信されてもよい。
【００７２】
局120xでは、アンテナ1816は局120aおよび／または他の局から変調された信号を受け取ってもよい。受信器1830は、アンテナ1816からの受信信号を処理し、サンプルを提供してもよい。RXデータ・プロセッサ1832はサンプルを処理し、各局のためにデータシンク1834へと復号化されたデータを供給し、コントローラ/プロセッサ1820に制御データを供給してもよい。
【００７３】
コントローラ/プロセッサ1820および1860は、それぞれ局120xおよび120aの動作を指令してもよい。コントローラー/プロセッサ1820および／または1860は、さらに図10の中の方法1000、図12の中の方法1200、図14の中の方法1400、図16の中の方法1600および／または本明細書に記述された技術に関する他の方法を実行してもよい。メモリ1822および1862は、局120xおよび120aのためにプログラム・コードおよびデータをそれぞれ格納してもよい。スケジューラ1824は、上に記述された設計のうちの何れかに基づいて複数の局のためのスケジューリングを実行しても良い。
【００７４】
ここに記述された技術は、様々な手段によって実装されてもよい。例えば、本技術はハードウェア、ファームウェア、ソフトウェアあるいはそれらの組み合わせの中で実装されてもよい。ハードウェア実装については、本技術を実行するために使用される処理装置は、1つ以上の特定用途向けIC(ASIC)、ディジタル信号プロセサ(DSP)、ディジタル信号処理デバイス(DSPD)、プログラム可能論理回路(PLD)、フィールドプログラム可能なゲート・アレイ(FPGA)、プロセッサ、コントローラ、マイクロ・コントローラ、マイクロプロセッサー、電子デバイス、本明細書で記述された機能を実行することを目指した他の電子ユニット、コンピュータあるいはそれらの組み合わせの内に実装されてもよい。
【００７５】
ファームウェアおよび／またはソフトウェア実装については、本技術は、本明細書に記述された機能を実行するモジュール(例えばプロシージャ、関数など)で実装されてもよい。ファームウェアおよび／またはソフトウェアの命令/コードは、メモリ(例えば、メモリ1822あるいは1862、図18に)に格納され、プロセッサ(例えばプロセッサ1820あるいは1860)によって実行されてもよい。メモリはプロセッサ内に実装されるか、あるいはプロセッサの外部に実装されるかもしれない。ファームウェアおよび／またはソフトウェアの命令/コードはまた、ランダムアクセス・メモリ(RAM)、読み取り専用メモリ(ROM)、不揮発性のランダムアクセス・メモリ(NVRAM)、プログラマブル読取専用メモリ(PROM)、電気的消去可能PROM(EEPROM)、FLASHメモリ、フロッピー（登録商標）ディスク、コンパクト・ディスク(CD)、ディジタル・バーサタイル・ディスク(DVD)、磁気光学のデータ保存装置などのようなコンピュータ/プロセッサ読み出し可能な媒体に格納されるかもしれない。命令/コードは１つ以上のプロセッサによって実行可能かもしれないし、本明細書に記述された機能の特定の態様をプロセッサに実行させても良い。
【００７６】
ここに記述された技術を実装する装置はスタンド・アロンのユニットかもしれないし、あるいは装置の一部かもしれない。該装置は、(i)スタンド・アロンの集積回路(IC)、(ii)データ及び／又は命令の格納のためにメモリICを含んでいるかもしれない１つ以上のICのセット、(iii)移動局モデム(MSM)のようなASIC、(iv)他のデバイス内に埋め込まれてもよいモジュール、(v)携帯電話、無線装置、送受話器あるいは移動ユニット、(vi)などかもしれない。
【００７７】
本開示の上記の記述はどんな当業者も本開示を作るか使用することを可能にするために提供される。本開示への様々な修正は当業者に容易に明白になり、ここに定義された総括的な法則は、本開示の精神または範囲から外れずに、他の変形実施例に適用されるかもしれない。したがって、その開示は、本明細書に記述された例示と設計に制限されるようには意図されず、ここに示された法則と新規な特徴と一致する最も広い範囲が与えられるべきである。
【技術分野】
【０００１】
現在の出願は、「POWER SAVE ENHANCEMENTS FOR AD-HOC WIRELESS COMMUNICATION」と題され、譲受人に譲渡され、参照によって本明細書に組込まれ、2006年10月19日に出願された米国仮特許出願第60/862,146号に基づく優先権を主張します。本開示は、一般には通信に、より具体的には無線通信ネットワーク中の局の電池寿命の改善のための技術に関係がある。
【背景技術】
【０００２】
無線通信ネットワークは音声、ビデオ、パケット・データ、メッセージ、放送などのような様々な通信サービスを提供するために広く展開される。これらの無線ネットワークは、非常に大きな地理的なエリアに通信カバレージを供給する無線の広域ネットワーク(WWAN)、大きな地理的なエリアに通信カバレージを供給する無線の都市内ネットワーク(WMAN)、中くらいの地理的なエリアに通信カバレージを供給する、無線ローカルエリア・ネットワーク(WLAN)、および小さな地理的なエリアに通信カバレージを供給する無線パーソナルネットワーク(WPAN)を含んでいる。異なる無線ネットワークは典型的には異なる能力、要件およびカバレージエリアを持っています。
【０００３】
局(例えば携帯電話)は、1つ以上の無線ネットワーク(例えばWWANおよび／またはWLAN)と通信することができるかもしれない。局は移動可能であってもよくまた、内蔵電池によって動力が供給されてもよい。例えば、局がデータを送信し、かつ/または受信するために電源オンされる場合は常に、該局は電池電力を消費するかもしれない。局がデータを交換している際に、複数回の電池充電の間の待機時間および動作時間の両方を拡張するためにできるだけ電池電力消費量を削減することは望ましい。したがって、局の電池寿命を改善するための技術に対する需要が当該技術分野においてある。
【発明の概要】
【０００４】
無線ネットワーク中の局によって省電力を改善するための技術が本明細書に記述される。一の態様では、ソース局は受信局へ送られたフレームに電力保存バッファー・ステータスを含めてもよい。受信局は電力保存モードで作動するかもしれないし、一部の時間だけ起動状態であるかもしれない。バッファー・ステータスは、受信局へ送られるためのデータフレームの数を示してもよい。ソース局はバッファー・ステータスによって示されるとおりに受信局へ１つ以上のデータフレームを送ってもよい。受信局は、バッファー・ステータスに基づいてソース局からどれだけの数のデータフレームが予想されるか知っているかもしれない。受信局はデータフレームの予想された数を受け取った後にスリープ状態になってもよく、それは電池動力を節約するかもしれない。一般に、ソース局は、バッファーされたデータの量が、データフレームの数、バイト数、ビット数などのような任意の単位に基づくことを表示してもよい。受信局は、バッファー・ステータスによって示されたデータの量に基づいて、どれだけのデータが予想されるかを知っているかもしれない。
【０００５】
別の態様では、１回の送信機会(TXOP)において多数のデータフレームを受け取ることができる受信局は、このTXOPバースト受信機能を他の局へ広告することができる。１の設計では、受信局は、該局のTXOPバースト受信機能についての情報を含むフレームを送信しても良い。この情報は、単一のTXOPの中の受信局によって受け取ることができるデータフレームの数を示してもよい。受信局は、受信局のTXOPバースト受信機能に基づいて１つのTXOPの中においてソース局から多数のデータフレームをその後受信しても良い。ソース局は該TXOPの最初にチャネル・アクセスを行なうかもしれないし、別のチャネル・アクセスを実行する必要無しに、該TXOPの中の全てのデータフレームを送るかもしれない。
【０００６】
下記に述べられるように、電力保存バッファー・ステータスおよびTXOPバースト特性は様々な電力保存モードおよび様々な無線ネットワークに使用されてもよい。本開示の種々の態様および特徴もまた、一層に詳細に下記に記述される。
【図面の簡単な説明】
【０００７】
【図１】無線ネットワーク
【図２】多数の局に関する送信時間軸
【図３】電力保存バッファー・ステータスを伝達することが可能なフレーム
【図４】電力保存バッファー・ステータス特性を伴うスケジュールされていない電力保存モードでの動作
【図５】別個のチャネル・アクセスを伴うデータフレームの送信
【図６Ａ】TXOPバースト受信機能を伝達することができるフレーム。
【図６Ｂ】TXOPバースト受信機能を伝達することができるフレーム。
【図７】TXOPバースト受信機能を備えたデータフレームの送信
【図８】それぞれ電力保存バッファー・ステータスおよびTXOPバースト特性を伴う、スケジュールされた電力保存モードおよびPSMPモードにおける動作
【図９】それぞれ電力保存バッファー・ステータスおよびTXOPバースト特性を伴う、スケジュールされた電力保存モードおよびPSMPモードにおける動作
【図１０】電力保存バッファー・ステータスと共にデータを送信するための方法
【図１１】電力保存バッファー・ステータスと共にデータを送信するための装置
【図１２】電力保存バッファー・ステータスと共にデータを受信するための方法
【図１３】電力保存バッファー・ステータスと共にデータを受信するための装置
【図１４】TXOPバースト機能を備えたデータの送信のための方法
【図１５】TXOPバースト機能を備えたデータの送信のための装置
【図１６】TXOPバースト機能と共に送信されたデータを受け取るための方法
【図１７】TXOPバースト機能と共に送信されたデータを受け取るための装置
【図１８】２つの局のブロック図
【詳細な説明】
【０００８】
本明細書に記述された技術は、WLAN、WMAN、WWAN、WPANなどのような様々な無線ネットワークに使用されてもよい。WLANはIEEE 802.11、Hiperlanなどを実装するかもしれない。WWANは、符号分割多重アクセス方式(CDMA)ネットワーク、時分割多元接続方式(TDMA)ネットワーク、周波数分割多元接続(FDMA)ネットワーク、直交FDMA(OFDMA)ネットワーク、単一キャリアFDMA(SC-FDMA)ネットワークなどのようなセルラー・ネットワークかもしれない。WMANはIEEE 802.16(それは一般にWiMAXと呼ばれる)、IEEE 802.20などを実装するかもしれない。WPANはBluetooth（登録商標）を実装するかもしれない。明瞭のために、本技術はIEEE 802.11 WLANに関して下記に述べられる。
【０００９】
図1は、多数の局120を備えた無線ネットワーク100を示す。一般に、無線ネットワークは、任意の数のアクセス・ポイントおよび任意の数の局を含んでいてもよい。一の局は無線媒体によって別の局と通信することができる装置である。「無線媒体」と「チャネル」という用語はしばしば交換可能に使用される。局は、アクセス・ポイントと通信するか、またはピア・ツー・ピアで別の局と通信してもよい。局はまた、端末、移動局、ユーザー装置、加入者ユニットなどと呼ばれるかもしれないし、これらの機能性のうちのいくらかあるいは全てを含んでいるかもしれない。 局は、携帯電話、携帯型の装置、無線装置、携帯情報端末(PDA)、ラップトップ・コンピューター、無線モデム、コードレスホンなどかもしれない。アクセス・ポイントは、無線媒体によって該アクセス・ポイントに関係付けられた局に配送サービスへのアクセスを提供することができる局です。アクセス・ポイントはまた基地局、基地トランシーバー局(BTS)、ノードB、発展したノードB(eNode B)などと呼ばれるかもしれないし、これらの機能性のうちの幾らかあるいは全てを含んでいるかもしれない。
無線ネットワーク100は、IEEEによって採用された技術標準のIEEE 802.11ファミリーの中のいかなる無線技術を実装してもよい。例えば、無線ネットワーク100は、802.11a、802.11b、802.11eおよび／または802.11gのような追加仕様のうちの1つ以上を含むIEEE 802.11技術標準を実装するかもしれない。無線ネットワーク100はさらにIEEEの802.11nおよび／または802.11sを実装してもよく、それは形成されているIEEE 802.11技術標準である。IEEE 802.11、802.11a、802.11b、802.11gおよび802.11nは、異なる無線技術をカバーし、異なる能力を持っています。IEEE 802.11eは、媒体アクセス制御(MAC)層に関するサービス品質(QoS)拡張をカバーします。
【００１０】
無線ネットワーク100はインフラストラクチャー・ネットワークあるいはアドホックネットワークかもしれない。インフラストラクチャー・ネットワークは、局のための通信をサポートする1つ以上のアクセス・ポイントおよび恐らく他の実体を含んでいる。インフラストラクチャー・ネットワークはまた、IEEE 802.11において基本サービスセット(BSS)と呼ばれる。アドホックネットワークは無線媒体によって専ら互いの相互交信範囲内の局から構成されている。アドホックネットワークは、典型的にはアクセス・ポイントのような中央制御エンティティなしで必要に応じて動的に形成されてもよく、もはや必要でなくなれば、解消されてもよい。アドホックネットワークはまた、IEEE 802.11において独立したBSS(IBSS)と呼ばれる。以下の記述の多くは、無線ネットワーク100がアドホックネットワークであると仮定する。
【００１１】
無線ネットワーク100は、下記の電力保存モードあるいは仕組みのうちの１つ以上をサポートしてもよい:
* スケジュールされていない電力保存 - 起動されている期間中に送信するデータがある場合は常に、データは送信される、
* スケジュールされた電力保存 - 起動されている期間中にデータはスケジュールされたサービス時間において送信される、
* 電力保存マルチポール(PSMP) - 起動されている期間中にデータは単一の広報フレームにより多数の局へ送信される。
【００１２】
スケジュールされていない電力保存モードはまた、電力保存(PS)モード、IBSSのスケジュールされていない電力保存モード、スケジュールされていない自動的な電力保存配達(U-APSD)モードなどと呼ばれてもよい。スケジュールされた電力保存モードはまた、IBSSのスケジュールされた電力保存モード、スケジュールされたAPSD(S-APSD)モードなどと呼ばれてもよい。これらの電力保存モードは、下記に述べられるように、ステーションがスリープ状態となり、電池電力を保存するが異なる方法で作動することを可能にする。
【００１３】
図２は、無線ネットワーク100内での様々な局120に関する例示的な送信時間軸を示す。1つの局(例えば図1の中の局X)は無線ネットワークを形成してもよく、無線ネットワークのためのタイミングを維持してもよい。局Xは、他の局が局Xを検知し識別することを可能にするビーコン・フレームを周期的に送信してもよい。ビーコン・フレームが送信されるべき時間はターゲット・ビーコン送信時間(TBTT)と呼ばれる。連続する２つのビーコン・フレームの開始点の間の時間区間は、ビーコン間隔と呼ばれる。ビーコン間隔は、適切な期間(例えば100ミリ秒(ms)、または他の何らかの時間間隔にセットされてもよい。無線ネットワーク中の局は全て、局Xによって送信されたビーコン・フレームに対してそれらのタイミングを同期させてもよい。
【００１４】
様々なタイプのフレームは複数のビーコン・フレームの間の時間で送信されてもよい。これらのフレームは管理フレーム、制御フレーム、データフレームなどを含んでいるかもしれない。データフレームはまた、パケット、データ・ブロック、データユニット、プロトコルデータユニット(PDU)、サービスデータユニット(SDU)、MAC SDU(MSDU)、MAC PDU(MPDU)などと呼ばれるかもしれない。２つの局が１つ以上のトラフィック・ストリームを持っているかもしれないし、各トラフィック・ストリームとデータフレームを交換するかもしれない。
【００１５】
スケジュールされていない電力保存モードはIEEE 802.11の中のアドホックネットワーク(すなわち、IBSS)の中で使用されてもよい。この場合、局Xは広報トラフィック指示メッセージ(ATIM)ウィンドウに適切な期間を選んでもよく、各ビーコン・フレーム中でATIMウィンドウ期間をブロードキャストするかもしれない。スケジュールされていない電力保存モードで作動するものを含む無線ネットワーク中の全ての局は、これらの局に対して適用可能なフレームを受け取るために各ATIMウィンドウの期間中に起動中であることを要求される。ATIMウィンドウは、TBTTにおいて開始し、ATIMウィンドウ期間が経過したら終了する。
【００１６】
スケジュールされていない電力保存モードにおける動作は以下のように生じてもよい。所与の局Aが別の局Bに送信するための１つ以上のデータフレームを有する場合、局AはATIMウィンドウ期間内に局Bに対してATIMフレームを送信してもよい。無線ネットワーク中の全ての局は、局ＡからATIMフレームを受け取ってよい。局Bは自分がATIMフレームの受取人であり、局Ａが局Ｂへ送信するためのデータを持っていることを認識するかもしれない。局Bは該ATIMフレームに関してアクノレッジメント(ACK)を送信してもよい。ATIMウィンドウの終端において、ATIMフレームを送信しなかった、または受け取らなかった局(例えば局C)はスリープ状態に移行してよい。ATIMフレームを送信し、および/または受け取る局はATIMウィンドウの終端以降にデータを交換してもよい。図２に示される例において、ATIMウィンドウの終端以降に局Aは局Bにデータフレームを送信し、および局Bが該データフレームに対してACKを送信する。局AおよびBはビーコン間隔の終わりまで起動状態のままでい続けることが可能である。
【００１７】
IEEE 802.11におけるアドホックネットワーク中のスケジュールされていない電力保存モードについては、全ての局は各ATIMウィンドウの全期間中において起動状態であることを要求される。これは、該局が他の局に関する処理待ちデータを互いに通知することができることを保証する。ソース局がビーコン・フレームに続くATIMウィンドウの期間中に処理待ちデータを持っている各受信局に対して、該ソース局は、(図２に示されたような)ATIMフレームあるいは送信要求(RTS)フレームを送信するかもしれない。ATIMまたはRTSのフレームを受け取る局、およびATIMまたはRTSのフレームを送信する局は、図２に示されるように、次のATIMウィンドウの終端まで起動状態のままでいることを要求される。低い周期性を備えたトラフィックを有する局に関しては、ATIMウィンドウ中でバッファーされたトラフィックの表示を受け取った後に、１つのビーコン間隔全体にわたって起動状態でいることをこれらの局に要求することは過度の電池電力消費に帰着する可能性がある。このような拡張された起動状態時間は、ビーコン間隔中のほんの少数のデータフレームを受け取り、ビーコン間隔の中で早期にこれらのデータフレームの受信を完了する局には不適当かもしれない。
【００１８】
一の態様では、ソース局は、受信局へ送られたATIMフレームあるいはRTSフレームの中に電力保存バッファー・ステータスを含めてもよい。電力保存バッファー・ステータスは、受信局へ送られるためのデータの量(例えばデータフレームまたはMSDUの数、あるいはデータ・バイトあるいはビットの数)を伝えてもよい。その後、受信局は、ソース局からどれだけの量のデータ(例えばどれだけの数のデータフレーム)が予想されるか知るであろう。受信局は、次のATIMウィンドウの終端まで待たなければならない代わりに、予想される量のデータ(あるいはデータフレームの数)の受信を完了した後にスリープ状態に移行してよく、それは電池の電力を節約するかもしれない。例えば、受信局が２つのデータフレームを示す電力保存バッファー・ステータスを備えた、ATIMフレームあるいはRTSフレームを受け取る場合、受信局は２つのデータフレームを受け取った後にスリープ状態に移行してよい。バッファーされたデータの量はバイト数で与えられるかもしれず、MACフレームの断片化が生じた場合、これは有用であろう。
【００１９】
図３は、電力保存バッファー・ステータスを伝達することができるフレーム300の設計を示す。フレーム300はATIMフレーム、RTSフレームなどに使用されてもよい。フレーム300は様々な情報の断片を提供するフレーム制御フィールド、該フレームの受信局を識別する宛先アドレスフィールド、該フレームを送信するソース局を識別するソース・アドレス・フィールド、電力保存バッファー・ステータス・フィールドを含んでいるフレームボディ・フィールド、そして場合によっては、明瞭さのために図３には示されなかった他のフィールドを含む。
【００２０】
フレーム制御フィールドはタイプ・サブフィールド、サブタイプ・サブフィールド、電力管理(Pwr Mgt)フィールド、および図3に示されない他のフィールドを含んでいる。タイプ・サブフィールドは管理フレームについては「00」、または制御フレームについては「01」にセットされてもよい。サブタイプ・フィールドは、ATIMフレーム(それは管理フレームの１つのタイプである)については「1001」あるいはRTSフレーム（それは制御フレームの１つのタイプのである）については「1011」にセットされてもよい。電力管理フィールドは、局が電力保存モードにあることを示すために「1」にセットされ、あるいは局がアクティブ・モードにあることを示すために「0」にセットされても良い。
【００２１】
ATIMとRTSのフレームについては、フレームボディ・フィールドは現在はどんな情報も伝えないヌルのフィールドである。図３に示される設計では、電力保存バッファー・ステータス・フィールドはフレームボディ・フィールドに含まれているかもしれないし、ソース局が受信局のためにバッファーしたデータフレームあるいはMSDUの数を示すかもしれない。電力保存バッファー・ステータスもまた、フレーム制御フィールドのサブフィールド中で提供されるかもしれないし、あるいは他の方法で、管理フレーム、制御フレームあるいはデータフレームの中で送信されるかもしれない。
【００２２】
一般に、電力保存バッファー・ステータスは、バッファーされたデータの利用可能性(例えば、「はい」、または「いいえ」)、バッファーされたデータの量、バッファーされたデータフレームの数あるいはバイト数などを示すかもしれない。電力保存バッファー・ステータスは、ATIMフレーム、RTSフレーム、データフレームあるいは他の何らかのフレーム中で伝えられてもよい。
【００２３】
図４は、電力保存バッファー・ステータス特性を伴うスケジュールされていない電力保存モードにおける例示的な動作を示す。この例において、局Aは、局Bに送信するための1つのデータフレームを持っている。駅Aは局Bに対してATIMウィンドウの期間内にATIMフレームを送信します。ATIMフレームは、局Bのためにバッファーされた１つのデータフレームを示す電力保存バッファー・ステータス(PSBS)を含んでいる。局Bは該ATIMフレームのためにACKを返します。この例において、他のATIMフレームはATIMウィンドウの期間内に全く送信されない。ATIMウィンドウの終端においては、局AおよびBは起動状態のままでいる。局Cは如何なるATIMフレームも送信または受信しておらず、この結果、スリープ状態に移行することができる。
【００２４】
電力保存バッファー・ステータスに基づいて、局Bが局Aから１つのデータフレームを受け取ることを予期する。局Aは該データフレームを送信し、また局Bは該データフレームのためにACKを返す。該データフレームを受け取った後に、局Bは、局Aからこれ以上のデータを受け取ることを予期せず、該データフレームに対してACKを送信した後にスリープ状態に移行することができる。該データフレームを送信した後に、局Aは、局Bに対するこれ以上のデータを持っておらず、該データフレームに対するACKを受け取った後にスリープ状態に移行することができる。したがって、局Aおよび局Bの両方は、次のATIMウィンドウの終端まで待たなければならない代わりに、早期にスリープ状態に移行してもよい。
【００２５】
無線チャネル上のデータの送信は信頼性が低いかもしれない。したがって、局Aからの最後のデータフレームの受信の後に局Bによって送られたACKを局Ａが受け取らない場合があるかもしれない。該チャネル・アクセス手順によれば、ACKが受信されない場合に、局Ａは最後のデータフレームを再送信するかもしれず、局Ｂが該データフレームを復号化していないので局ＢがACKを送っていないと仮定するかもしれない。局Ｂがスリープ状態に移行するならば、局Ｂは再送信を復号化しないであろう。それが最大再試行回数に達するまで、局Ａは再送信し続けるかもしれない(そのステージでは局は送信を異常終了させるだろう)。これは局Aに関する過度の電力垂れ流しに帰着し、無線媒体を浪費するかもしれない。局AおよびBの電力能力へ依存して、局Bは、最後のデータフレームのためにACKを送った後にできるだけ早くスリープ状態に移行することを選ぶかもしれない(例えば、局Bは電力に制限があるかもしれないし、局Aの電力供給とは関わりが無いかもしれない)、または局Ｂは、このACKを送った後、ある長さの時間だけ起動状態のままでいることを選択するかもしれない(例えば、局AとBは、両方とも電力に制限があるかもしれない)。第１のACKが無線チャネルによって消去された後に、局Ａが再送信するならば、最後のデータフレームに対してACKを送った後に起動状態であり続けることは、局ＢがACKを送信することを可能にするだろう。ネットワーク負荷を軽減すると同時に、局Aおよび局Bの両方によって省電力を改善するためにどれくらい長く起動状態であり続けるべきかを推定するために、局BはSIFS、DIFS、競合ウィンドウサイズ、無線媒体負荷、IBSSの中の局の数などを使用することが可能である。局Ｂが２重化されたフレームを受け取るならば、どれくらい長く起動状態であり続けるべきかを決定する際に、１つだけが考慮される。
【００２６】
一般に、最後のデータフレーム(あるいは任意のデータフレーム)に対するACKが、ソース局によって受け取られなかった場合、ソースと受信側の局は終了戦略を取り決めるかもしれません。上に記述されるように、受取人局は、ソース局から可能な再送信を受け取るための時間の長さだけ起動状態のままでいるかもしれない。代替的に、ACKが受信局から受け取られない場合、ソース局は、現在の起動状態期間中において最後のデータフレームの再送信をスキップするかもしれない。代わりにソース局は、後続する起動状態期間においてこのデータフレームを再送信してもよく、あるいは該データフレームを廃棄してもよい。そしてこの事は、最後のデータフレームのためにACKを送った直後に、受信局がスリープ状態に移行することを可能にするであろう。他の終了戦略もまた、ソースと受信側の局の間で取り決められてもよい。
【００２７】
ソース局は、受信局へ送信するための多数のデータフレームを有していてもよく、一度に１つのデータフレームを送信してもよい。各データフレームについて、ソース局は、該チャネルへのアクセスを獲得するためにチャネル・アクセスを実行しても良く、アクセスを獲得した時点で該チャネル経由で該データフレームを送信してもよい。
【００２８】
図５は、IEEE 802.11における分散協調機能(DCF)を備えた局Bに対する局Aによる多数のデータフレームの送信を示す。局Aは、送信するためのデータを持っており、チャネルが使用中か使用されていないかどうか判断するために時間T1においてチャネルのセンシングを開始する。チャネルがDCFフレーム間スペース(DIFS)と等しい期間の間使用されていない場合、局Aは、時間T2からスタートするデータフレームを送信することができる。ここで、局Bは局Aからのデータフレームを受け取り復号化する。
【００２９】
時間T3におけるデータフレームの終端の後に、局Bは短いフレーム間スペース(SIFS)時間の間待ち、時間T4からスタートするACKを送信する。ここで、SIFSがDIFSより短いので、局Bは、データフレームの終端以降に他の局より先にチャネルにアクセスすることができる。これは、局Aが適時の方法でACKを受け取ることができることを保証する。
【００３０】
局Aは、送信するための別のデータフレームを持っており、チャネルが使用中か使用されていないかどうか判断するために時間T5でチャネルのセンシングを開始する。この例において、チャネルは最初は使用中ではないが、時間T6において使用中となる。その後、時間T7において、チャネルが使用されなくなるまで局Ａは待機してもよく、そこからさらにチャネルがDIFS期間の間使用中でないことを局Aは待ってもよく、それは時間T8で生じる。その後、局Aは、０と競合ウィンドウ(CW)の間のランダムなバックオフを選択してもよい。ランダムなバックオフは、DIFS期間の間チャネルが使用されていないことをセンスした後に、多数の局が同時に送信するシナリオを回避するために使用される。その後局Aは、該ランダムなバックオフをカウントダウンし、チャネルが使用中となる場合は常に休止し、チャネルがDIFS期間にわたって使用中でない後にカウントダウンを再開する(図５に示されない)。該カウントダウンが時間T9で０に達する場合、局は該データフレームを送信することができる。局Bは局Aからのデータフレームを受け取り復号化する。時間T10におけるデータフレームの終端以降に、局BはSIFS時間の間待ち、時間T11からスタートするACKを送信する。
【００３１】
ここで、図５に示されるように、各データフレームについてチャネル・アクセスを実行することは多数のデータフレームを送信するための時間の長さを拡張するかもしれない。これは該チャネルが任意のチャネル・アクセスの期間中に使用中となることができるからであり、そしてさらに該ソース局は他の局と該チャネルをめぐって争う必要があるだろう。チャネル・アクセスの各々はアクセス遅延およびACKオーバーヘッドを加算する。多数のデータフレームに関する拡張された送信時間は、ソースと受信側の局がより長い間起動状態でいるという結果になるだろう。
【００３２】
別の態様では、１つのTXOPの中で多数のデータフレームを受け取ることができる局は、他の局に対してこのTXOPバースト受信機能を広告することができる。TXOPバースト受信機能は、単一のチャネル・アクセスを伴う１つのTXOPの中での多数のデータフレームの配送をサポートし、それは、該複数のデータフレームを送信するための時間の長さを短くするかもしれない。
【００３３】
一の局が無線ネットワークに参加する場合、該局は、アソシエーション要求フレーム中において機能情報フィールドを送信してもよい。該局はまた、ATIMフレームあるいは他の何らかの管理フレーム中において機能情報フィールドを送信しても良い。機能情報フィールドは、該局によってTXOPバースト受信がサポートされるかどうか、および１つのTXOPの中において該局によって受け取ることができるデータフレームの数についての情報を含んでいてもよく、それはN-ビット値(例えば8ビットの値)によって与えられてもよい。１つの設計では、オール０の値は、TXOPバースト受信がサポートされないことを示してもよい。オール１の値は、最も高いデータ転送速度で該局が１つのTXOPの中において任意の数のデータフレームを受け取ることができることを示してもよい。その他の値は、各TXOP毎に受け取ることができるデータフレームの数を示してもよい。別の設計では、各TXOP毎に受け取ることができるデータフレームの数は、ある許可された値(例えば0、1、2、4、オール１の値)に制限されるかもしれず、全ての局はこれをサポートすることを強制されても良い。一般に、TXOPバーストがサポートされるか否か、および各TXOP毎に受け取ることができるデータフレームの数は１つ以上のフィールドで提供されてもよく、如何なるフォーマットを使用して提供されても良い。
【００３４】
図6Aは、TXOPバースト受信機能を伝えることができるフレーム600の設計を示す。フレーム600は、アソシエーション要求フレーム、認証フレームあるいは他の何らかの管理フレーム、制御フレーム、またはデータフレームに使用されてもよい。フレーム600は、フレーム制御フィールド、宛先アドレスフィールド、ソース・アドレス・フィールド、フレームボディ・フィールド、および場合によっては明瞭さのために図6Aの中で示されない他のフィールドを含んでいる。フレームボディ・フィールドは、機能情報フィールド、および場合によっては図6Aの中で示されない他のフィールドを含んでいる。機能情報フィールドは、上に記述されるように定義されてもよいTXOPバースト受信(Rx)機能サブフィールドを含んでいる。TXOPバースト受信機能はまた、フレームボディ・フィールド内の別個のフィールドとして伝送されてもよく、あるいは他の方法で管理フレームあるいは制御フレームの中で送信されるかもしれない。TXOPバースト受信機能はまた、他の何らかのタイプのフレームの中で(例えばソース局によって送られた第１のデータフレームの中で)送られるかもしれない。
【００３５】
(アドホックネットワークを形成した)局Ｘは、(例えばアドホックネットワーク中の他の局によるアソシエーションの期間中に)これらの局のTXOPバースト受信機能を受け取ってもよい。局Ｘは、ビーコン・フレームによってこれらの局のTXOPバースト受信機能をブロードキャストしてもよい。
【００３６】
図6Bは、アドホックネットワーク中の複数の局のTXOPバースト受信機能を伝えることができる、ビーコン・フレーム610の設計を示す。ビーコン・フレーム610は、フレーム制御フィールド、フレームボディ・フィールド、および明瞭さのための図6Bの中で示されない他のフィールドを含んでいる。フレームボディ・フィールドはビーコン間隔を示すビーコン間隔フィールド、局Ｘの機能を示す機能情報フィールド、(例えばATIMウィンドウの期間中に)アドホックネットワークをサポートするために使用される一組のパラメーターを示すIBSSパラメーター・セット・フィールド、TXOPバースト受信機能情報フィールド、及び場合によっては他のフィールドを含む。TXOP受信機能情報フィールドは、そのTXOPバースト受信機能が該ビーコン・フレームの中でブロードキャストされる各局毎に１つのエントリーを含んでいてもよい。各局についての該エントリーは、局識別子すなわちアドレス(STA Yk)に関するサブフィールド、およびその局のTXOPバースト受信機能に関するサブフィールドを含んでいてもよい。局のTXOPバースト受信機能はまた、他の方法、および／または他のフレームの中でブロードキャストされてもよい。
【００３７】
さらに別の態様では、１つのTXOPの中において多数のデータフレームを送信することができる局は、他の局に対してこのTXOPバースト送信機能を広告することができる。TXOPバースト送信機能は、単一のチャネル・アクセスを伴う１つのTXOPの中において多数のデータフレームの送信を可能にする。TXOPバースト送信機能は、TXOPバースト受信機能と同様の方法で伝えられ広告されてもよい。
【００３８】
図７は、TXOPバースト機能を備えた局Bに対する局Aによる多数のデータフレームの送信を示す。局Aは、送信するためのデータを持っており、時間T1でチャネルのセンシングを開始する。DIFS時間の間チャネルが使用されていないとセンスした後に、局Aは、時間T2からスタートする第１のデータフレームを送信する。局Bは第１のデータフレームを受け取り復号化し、時間T3における第１のデータフレームの終端以降にSIFS時間待ち、時間T4からスタートするACKを送信する。局AはACKを受け取り、時間T5におけるACKの終端以降にSIFS時間の間待ち、時間T6からスタートする第２のデータフレームを送信する。SIFSがDIFSより短いので、チャネルがDIFS時間の間使用されていないことを待っている他の局からの競合無しで局Ａは第２のデータフレームを送信することができる。局Bは第２のデータフレームを受け取り復号化し、時間T7における第２のデータフレームの終端以降にSIFS時間の間待ち、時間T8からスタートするACKを送信する。任意の数のデータフレームとACKが局ＢのTXOPバースト受信機能によって制限された同様の方法で送信されてもよい。時間T10(それは以前のACK(図7に示されない)が終わってからSIFS時間後である)において、局Aは最後のデータフレームを送信する。局Bは最後のデータフレームを受け取り復号化し、時間T11で最後のデータフレームが終わってからSIFS時間待ち、時間T12からスタートするACKを送信します。
【００３９】
図7に示されるように、局Aは１つのチャネル・アクセスを伴う１つのTXOPの中において任意の数のデータフレームを送信することができ、それは、複数のデータフレームを送信するための時間の長さを短くするかもしれません。これは、局Aおよび局Bの両方がより早期にスリープ状態に移行することを可能にするかもしれず、それは電池動力を節約する可能性がある。TXOPバーストは、IEEE 802.11nにおける集約MPDU(A-MPDU)のような集約パケットに関しても良い。
【００４０】
一般に、電力保存バッファー・ステータスおよびTXOPバースト特性は別々にあるいは組み合わされて使用されてもよい。これらの２つの特性の組み合わせは、この局についての切迫したデータ転送に関する受信局に正確な情報を提供することが可能である。例えば、電力保存バッファー・ステータスが４つの保留されているデータフレームを示し、TXOPバースト受信機能が、各TXOP毎に６つのデータフレームを示す場合、ソース局は1つのTXOPの中において４つのデータフレームを送るかもしれない。電力保存バッファー・ステータスが４つの保留されているデータフレームを示し、TXOPバースト受信がサポートされない場合、受信局は一度に１つのデータフレームを受け取り、そして直ちに、あるいは、４つのデータフレームをすべて受け取ってから暫らくした後にスリープ状態に移行することができる。
【００４１】
電力保存バッファー・ステータス、および／またはTXOPバースト特性は、上にリストされた電力保存モードのうちのどれと共に使用されてもよい。これらの特性はまた、これらの電力保存モードと無関係に使用されてもよい。
【００４２】
スケジュールされていない電力保存モードに関しては、ソース局は、図４に示されるように、ATIMウィンドウ内で送られるATIMフレームあるいはRTSフレームの中に受信局のための電力保存バッファー・ステータスを含んでいてもよい。ソース局は各TXOPの中のATIMウィンドウが終わってから受信局へ１つ以上のデータフレームを送信してもよい。電力保存バッファー・ステータス、および／またはTXOPバースト特性を伴うスケジュールされていない電力保存モードは、非周期的なトラフィック、あるいはある程度の遅延およびジッタを許容することができるトラフィックを有する局によって有利に使用されてもよい。これらの特性を伴うスケジュールされていない電力保存モードも他のシナリオの中で使用されてもよい。
【００４３】
スケジュールされた電力保存モードについては、２つの局が、データを送信および／または受信するために複数のビーコン・フレーム間の固定間隔で起動状態となることを取り決めるかもしれない。この間隔はサービス期間と呼ばれる。サービス期間の交渉は、２つの局の間のトラフィック・ストリーム等のためのトラフィック仕様(TSPEC)の設定動作を介してIBSS設定動作の期間中に実行されても良い。IBSSの中でスケジュールすることはIEEE 802.11によって現在定義されていないが、任意の仕組みを使用して２つの局がサービス期間を交渉し、スケジュールしてもよい。サービス期間の交渉は、各局に関する電力保存バッファー・ステータスおよびTXOPバースト受信機能に関する情報の交換に追加されるものであっても良い。
【００４４】
図８は、電力保存バッファー・ステータスおよびTXOPバースト特性を伴うスケジュールされた電力保存モードにおける例示的動作を示す。この例において、局Aと局Bは、サービス時間をT1とすること、およびデータを交換するために該サービス時間に先立って両方の局が起動状態となることを取り決めた。
【００４５】
サービス時間T1では、局Aはチャネルにアクセスし、局Bに第１のデータフレームを送信する。このデータフレームは、局Aが局Ｂのためにバッファーしたデータフレームの数を示す電力保存バッファー・ステータスを含んでいてもよい。局BのTXOPバースト受信機能はサービス期間の交渉の間に局Ａに知らされる可能性がある。いずれにしても、局Bは、局Aからの予想されるデータフレームの数についての情報を持っているかもしれず、局Aには局BのTXOPバースト受信機能についての情報があるかもしれない。局Bは第１のデータフレームのためにACKを返す。その後局Aは、局Bへ残りのデータフレームを送信する（例えば、図７に関して上に記述されるような局BのTXOPバースト受信機能を使用するなどして）。
【００４６】
その後、局Bはチャネルにアクセスし、局Ａに対して第１のデータフレームを送信してもよい。このデータフレームは、局Bが局Aのためにバッファーしたデータフレームの数、あるいは他の何らかのバッファー情報を示す電力保存バッファー・ステータスを含んでいてもよい。局AのTXOPバースト受信機能はサービス期間の交渉の間に局Bに知らされる可能性がある。いずれにしても、局Aは、局Bからの予想されるデータフレームの数についての情報を持っているかもしれず、局Bには局AのTXOPバースト受信機能についての情報があるかもしれない。局Aは第１のデータフレームのためにACKを返す。その後局Bは、局Aに対して残りのデータフレームを送信する（例えば、図７に関して上に記述されたようにして）。局Aは最後の予期されたデータフレームに対してACKを送った後に暫くしてスリープ状態に移行してもよい。各局がスリープ状態に移行する時刻は無線媒体条件、フレーム間間隔などに依存するかもしれない。
【００４７】
一般に、サービス期間中のデータ交換は、(図８に示されるように)データを送信する両方の局について双方向かもしれないし、あるいはデータを送信するたった１つの局について片方向かもしれない。これはトラフィック・ストリームの特性に依存するかもしれないし、TSPECの設定動作中に指示されるかもしれない。
【００４８】
各サービス期間中のデータ交換は通常のチャネル・アクセス規則に従ってもよい。最初に送信するようスケジュールされた局(例えば図８の中の局A)は、チャネル・アクセスを実行しても良い。チャネル・アクセスは可変量の時間を要するかもしれず、それはサービス時間の周囲のチャネル負荷に依存するかもしれない。該最初に送信する局に対して送信するデータを２番目に送信するようにスケジュールされた局（例えば、図８における局Ｂ）が有する場合、該局もまたチャネル・アクセスを実行する（図８において示されるとおり）、または該最初に送信する局によって送信された最後のデータフレームの終端からSIFS時間経過後にACKを送信する（図８には示されていない）。
【００４９】
図８は、データを送信するための局AおよびBの両方によるTXOPバースト特性の使用を示す。一般に、各局はTXOPバースト特性を使用するかもしれないし、使用しないかもしれない。図８に示されるように、局Bがどんなデータフレームをも送信する前に、局Aはそのデータフレームをすべて送信するかもしれない。代替的に、２つの局は交互の態様でそれらのデータフレームを送信するかもしれない。例えば、局Ａにより送信された第１のデータフレームに続いて、局Bは、局Aから受け取られたデータフレームに関するACKと共にその第１のデータフレームを送信してもよい。その後局Ａは、局Bから受け取られたデータフレームに関するACKと共にその２番目のデータフレームを送信してもよい。
【００５０】
TXOPバーストが使用される場合、受信局はACKによりデータフレームを個々にアクノレッジするかもしれないし、あるいはブロックACKを有する幾つかのデータフレームをアクノレッジするかもしれない。ACKと同様に、最後の予期されたデータフレームを受け取った後にブロックACKを送信する局は、ブロックACKが別の局によって受け取られなかった場合、ブロックACKを送った後にどれくらい長く起動状態のままでいるべきかを決定しても良い。ブロックACK機能はソースと受信側の局の間で交渉されるかもしれない。
【００５１】
データフレームがどのように送信されるかには関係なく、電力保存バッファー・ステータスはソース局においてより多くのバッファーされたデータフレームが存在するか否かを判断するために使用されてもよい。より多くのバッファーされたデータフレームが存在する場合、受信局はスリープ状態に移行する前にデータフレームをすべて受け取るために待ってもよい。
【００５２】
電力保存バッファー・ステータス、および／またはTXOPバースト特性を有するスケジュールされた電力保存モードは、音声トラフィック、ビデオトラフィック、ゲームなどのような様々なタイプの周期的なトラフィックを有する局によって有利に使用されてもよい。これらの特性を有するスケジュールされた電力保存モードはまた、他のシナリオの中で使用されてもよい。
【００５３】
PSMPモードは、単一フレームを使用して、インフラストラクチャー・ネットワーク中のアクセス・ポイント(すなわちBSS)が多数の局のためのアップリンク転送とダウンリンク転送のための１回限りの来るべきスケジュールを広報することを可能にする。該アクセス・ポイントは、集約される全ての局に関する共通のサービス時間を選択してもよい。該アクセス・ポイントは共通のサービス時間においてPSMPフレームを送信してもよい。該PSMPフレームは、現在のPSMPサービス時間の中でスケジュールされた局の各々のための開始時刻を示してもよい。その後、該アクセス・ポイントは一度に、かつ、その局のための開始時刻において１つの局をサービスしてもよい。各局は該PSMPフレームを受け取り、該PSMPフレームによって示されるとおりにその開始時刻までスリープ状態となり、該アクセス・ポイントでデータを交換するためにその開始時刻に先立って起動状態となっても良い。PSMPサービス期間は、全てのスケジュールされた局に関して該PSMPフレームおよび後続するフレーム交換をカバーする。単一のチャネル・アクセスはPSMPサービス期間に関する共通のサービス時間において該アクセス・ポイントによって実行されても良い。
【００５４】
バッファーを用いたデータおよび場合によっては多数の受信局のためのスケジュールをソース局が広報することを可能にするために、PSMP機能はアドホックネットワーク(すなわち、IBSS)の中で使用されてもよい。局Ａ(あるいはアドホックネットワーク中の他の局)は、PSMPフレームを生成し受け取るための自身の機能を機能情報フィールド内で示してもよい。局Aは、IBSS設定動作中に局X(それはアドホックネットワークを形成し、周期的にビーコン・フレームを送信する局である)とこの情報を交換してもよい。局Xは、アドホックネットワーク内の他の局のPSMP機能をビーコン・フレーム中においてブロードキャストしてもよい。代替的に又は追加的に、局Aは、アドホックネットワーク中で他の局にそのPSMP機能を直接伝えるかもしれない。PSMPフレームを受け取ることができる局だけが、PSMPサービス期間に含まれている。
【００５５】
図6Bは、アドホックネットワーク中の局のPSMP機能を伝えることができるビーコン・フレーム610の設計を示す。ビーコン・フレーム610はフレームボディ・フィールドにPSMP機能情報フィールドを含んでいる。PSMP機能情報フィールドは、そのPSMP機能がビーコン・フレームの中でブロードキャストされる各局毎に１つのエントリーを含んでいてもよい。各局についてのエントリーは、局識別子すなわちアドレス(STA Zm)に関するサブフィールド、およびその局のPSMP機能に関するサブフィールドを含んでいてもよい。各局についてのエントリーは、該局がPSMPフレームを送信することができるかどうか、または、PSMPフレームを受け取ることができるどうかを示してもよい。該局のPSMP機能はまた、他の方法および／または他のフレームの中でブロードキャストされてもよい。
【００５６】
図9は、電力保存バッファー・ステータスおよびTXOPバースト特性を有するPSMPモードにおける例示的動作を示す。この例において、局Aは、2つの受信局BおよびCのためのバッファーされたデータを有しており、ATIMウィンドウの期間中に一のビーコン・フレームに続いて(多数のATIMフレームの代わりに)一のPSMPフレームを送信してもよい。アドホックネットワーク中の全ての局に同じチャネル・アクセス優先順位があるので、局Aはビーコン・フレームに直ちに続いてスケジュールを広報することができないかもしれないし、ビーコン間隔中はスケジュールを維持するかもしれない。この問題を緩和するために、図９に示されるように、２ステージPSMP広報が使用されてもよい。
【００５７】
局Aは、ATIMウィンドウの期間中に該ビーコン・フレームに続いて第１のPSMPフレームを送信する。このPSMPフレームは、局Aがそのためにデータをバッファーした各局の電力保存バッファー・ステータス(PSBS)を示すかもしれない。他の局は、それらが局Aからデータを受け取るのに起動状態でいるべきかどうか判断するために電力保存バッファー・ステータス情報を使用するかもしれない。第１のPSMPフレームはさらにPSMPサービス期間を示すかもしれず、それは、該第１のPSMPフレームの中で識別された局をサービスすることを局Aが予期する現在のビーコン間隔中の時間区間である。
【００５８】
局Aは後続するチャネル・アクセスに続くATIMウィンドウが終わってから第２のPSMPフレームを送信する。１つの設計では、第２のPSMPフレームは、第１のおよび／または第２のPSMPフレームにおいて識別される各局毎のスケジュールを示す。その後局Aは、１つの受信局を、一度に、かつ、その局のための開始時刻でサービスする。局Aはその受信局のTXOPバースト受信機能を使用して、各受信局へ送信してもよく、それは任意の方法で伝えられてもよい。各受信局は第２のPSMPフレームを受け取り、該PSMPフレームによって示されるとおりにその開始時刻までスリープ状態となり、局Aとデータを交換するためにその開始時刻に先立って起動状態となってもよい。別の設計では、第２のPSMPフレームは、該受信局の電力保存バッファー・ステータスを示し、スケジュールを含んでいなくてもよい。その後、局Aはその受信局のTXOPバースト受信機能を使用して、各受信局へ送信してもよい。一般に、第２のPSMPフレームは、スケジュールを広報するかあるいは該受信局へデータを送信するために使用されてもよい。TXOPバーストが有効化される場合、ACKあるいはブロックACKのいずれかが受信局によって送信されてもよい。最後の予期されたデータフレームの受信の後に該ACKか該ブロックACKを送信した後の起動状態でいる期間は、該受信局によって選択されても良い。サービス期間内では、第２のPSMPフレームは、電力を節約することができる、より多くの粒度を可能とする。現在のPSMP期間の終わりまでチャネル・アクセスを延期するために、第２のPSMPフレーム中の情報はIBSS中の他の局によって使用されてもよい。
【００５９】
図10は、データを送信するための方法1000の設計を示す。そこへ送るべきデータがある第２の局に関するバッファー・ステータスは第１の局で決定されてもよい(ブロック1012)。第２の局はアドホックネットワーク中において電力保存モードで作動するかもしれず、該バッファー・ステータスは、該第２の局へ送るためのデータフレームの数を示すかもしれない。該バッファー・ステータスを含むフレームが生成され(ブロック1014)、第１と第２の両方の局に関して起動状態でいる時間の間に、第１の局から第２の局へ送られるかもしれない(ブロック1016)。少なくとも1つのデータフレームは、バッファー・ステータスによって示されるとおり第２の局へ送られてもよい(ブロック1018)。
【００６０】
該バッファー・ステータスを備えたフレームはATIMフレームあるいはRTSフレームかもしれないし、第１と第２の局が両方とも起動状態でいる時間ウィンドウ内で(例えば図4に示されるようなATIMウィンドウ内で)送られるかもしれない。該バッファー・ステータスを備えたフレームはまた、そこに送るべきデータがある多数の局に関するバッファー・ステータスを含むPSMPフレームであってもよい。PSMPフレームはATIMウィンドウ内で、あるいはPSMPサービス期間中に送られるかもしれない（例えば、図９に示されるように）。該バッファー・ステータスを備えたフレームはまた、該局に関するサービス間隔中に送られた第１のデータフレームかもしれない（例えば、図８に示されたように）。
【００６１】
図11は、データを送信するための装置1100の設計を示す。装置1100は、そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを、第１の局において決定するための手段(モジュール1112)、該バッファー・ステータスを含むフレームを生成するための手段(モジュール1114)、第１と第２の両方の局に関して起動状態でいる期間中に第１の局から第2の局へフレームを送るための手段(モジュール1116)、またバッファー・ステータスによって示さるとおりに第２の局に対して少なくとも1つのデータフレームを送るための手段(モジュール1118)を含む。
【００６２】
図12は、データを受信するための方法1200の設計を示す。第１と第２の両方の局に関して起動状態でいる期間中に、第２の局のためのバッファー・ステータスを含むフレームは、第１の局から受け取られるかもしれない(ブロック1212)。少なくとも１つのデータフレームは、バッファー・ステータスによって示されるとおりに該第１の局から受信されるかもしれない(ブロック1214)。第２の局はアドホックネットワーク中では電力保存モードで作動するかもしれない。スリープ状態に移行するべきかどうかは、第１の局から受け取られた、全てのデータフレーム、およびバッファー・ステータスに基づいて決定されるかもしれません(ブロック1216)。
【００６３】
該バッファー・ステータスを備えたフレームは、ATIMフレーム、RTSフレーム、あるいはPSMPフレームかもしれないし、ビーコン間隔中のATIMウィンドウ内で受信されてもよい。少なくとも１つのデータフレームはATIMウィンドウの後に受け取られてもよい。該バッファー・ステータスを備えたフレームはまた、データフレームかもしれないし、第２の局のためのサービス間隔中で受信されるかもしれません。もしあれば、バッファー・ステータスによって示されるとおりに、追加のデータフレームが受信されるかもしれない。どんな場合も、第２の局は、バッファー・ステータスによって示されるとおりに、かつビーコン間隔の終端に先立って、全てのデータフレームを受信した後に、スリープ状態に移行してもよい。第２の局は、最後の予期されたデータフレームを含む受信されたデータフレームに対するACKあるいはブロックACKを送信しても良い。第２の局は全てのデータフレームを受信し、アクノレッジした後にスリープ状態に移行してもよい。第２の局はまた、自身のACKまたはブロックACKが失われ、いくつかのデータフレームが該第１の局によって再送信される状況に対処するためにその受信機チェインを電源オフすることを遅らせてもよい。
【００６４】
図13は、データを受信するための装置1300の設計を示す。装置1300は、第１と第２の両方の局に関して起動状態でいる期間中に第１の局から第２の局のためのバッファー・ステータスを含むフレームを受信するための手段(モジュール1312)、該バッファー・ステータスによって示されるとおりに、該第１の局からの少なくとも１つのデータフレームを受信するための手段(モジュール1314)、また該第１の局から受信された、全てのデータフレームおよびバッファー・ステータスに基づいてスリープ状態に移行するべきかどうか判断するための手段(モジュール1316)を含む。
【００６５】
図14は、データを送信するための方法1400の設計を示す。電力保存モードで作動する第２の局のTXOPバースト受信機能についての情報を含むフレームは、第１の局によって受信されても良い(ブロック1412)。TXOPバースト受信機能についての情報は、単一のTXOPの中において該第２の局によって受け取ることができるデータフレームの数を示してもよい。該フレームは管理フレームかもしれないし、第２の局とのアソシエーションの期間中に受信されても良い。該フレームはさらにビーコン・フレームかもしれないし、ターゲット・ビーコン送信時間において(TBTT)にブロードキャストされてもよい。該フレームはまた、該第２の局によって送信されたデータフレームであってもよい。どんな場合も、第２の局のTXOPバースト受信機能に基づいて単一のTXOPの中において多数のデータフレームが第２の局へ送られてもよい(ブロック1414)。ブロック1414に関しては、チャネル・アクセスはTXOPの開始時点で該第１の局によって実行されても良い。その後、該多数のデータフレームは、別のチャネル・アクセスを行なわずに、該TXOPの中において該第１の局によって送信されても良い（例えば、図７〜９の中で示されるように）。
【００６６】
図15は、データを送信するための装置1500の設計を示す。装置1500は、電力保存モードで作動する第２の局のTXOPバースト受信機能についての情報を含むフレームを第１の局において受け取るための手段(モジュール1512)、該第２の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第２の局に対して多数のデータフレームを送信するための手段(モジュール1514)を含む。
【００６７】
図16は、データを受信するための方法1600の設計を示す。電力保存モードで作動する第１の局のTXOPバースト受信機能についての情報を含むフレームが送信されても良い(ブロック1612)。該第１の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第１の局に対して第２の局によって送信された多数のデータフレームは受信されても良い(ブロック1614)。
【００６８】
図17は、データを受信するための装置1700の設計を示す。装置1700は、電力保存モードで作動する第１の局のTXOPバースト受信機能についての情報を含むフレームを送信するための手段(モジュール1712)、該第１の局のTXOPバースト受信機能に基づいて単一のTXOPの中において該第１の局に対して第２の局によって送信された多数のデータフレームを受信するための手段(モジュール1714)を含む。
【００６９】
図18は、図1の中の局120aおよび120xの設計のブロック図を示し、それらは２つの例示的な局である。局120xでは、送信(TX)データ・プロセッサ1812は送信のためにスケジュールされた局に関するデータソース1810からトラフィック・データを受け取ってもよく、コントローラ/プロセッサ1820から制御データ、およびスケジューラ1824からスケジューリング情報を受け取ってもよい(例えばスケジューリングが利用される場合)。制御データは、そこへデータが送られる局の電力保存バッファー・ステータス、TXOPバースト受信機能、および／または無線ネットワーク中の局のPSMP機能、および／または他の情報を含んでもよい。一般に、スケジューリングは各局によって利用されるかもしれないし、利用されないかもしれない。フレームは、バッファーされたデータの広報に基づいて(例えば、ATIM、RTSおよび／またはPSMPフレームを使用して)、該チャネルをめぐる競合に基づいて、あるいは他のアプローチに基づいて局の間で送信されてもよい。TXデータ・プロセッサ1812は、各局について選択されたレートに基づいて各局に関するデータを処理し(例えば、符号化し、インタリーブし、変調し、スクランブルする)、制御データおよびスケジューリング情報を処理し、出力チップを生成してもよい。送信器(TMTR)1814は出力チップを処理し(例えば、アナログに変換する、増幅する、フィルタリングする、そして周波数アップコンバートする)、変調された信号を生成してもよく、それはアンテナ1816から他の局に送信されてもよい。
【００７０】
局120aでは、アンテナ1852は局120xおよび／または他の局から変調された信号を受け取ってもよく、受信信号を提供してもよい。受信器(RCVR)1854は受信信号を処理し、サンプルを提供してもよい。受信(RX)データ・プロセッサ1856はサンプルを処理し(例えば、逆スクランブルし、復調し、逆インタリーブし、復号化する)、局120aのためにデータシンク1858へと復号化されたデータを供給し、コントローラ/プロセッサ1860に制御データおよびスケジューリング情報を供給してもよい。
【００７１】
局120aでは、TXデータ・プロセッサ1872はデータソース1870からトラフィック・データを受け取り、コントローラ/プロセッサ1860から制御データ(例えば電力保存バッファー・ステータス、TXOPバースト受信機能、PSMP機能など)を受け取ってもよい。TXデータ・プロセッサ1872は、その局について選択されたレートに基づいて、各受信局についてトラフィックと制御のデータを処理し、出力チップを生成してもよい。送信器1874は出力チップを処理し、変調された信号を生成してもよく、それはアンテナ1852から他の局に送信されてもよい。
【００７２】
局120xでは、アンテナ1816は局120aおよび／または他の局から変調された信号を受け取ってもよい。受信器1830は、アンテナ1816からの受信信号を処理し、サンプルを提供してもよい。RXデータ・プロセッサ1832はサンプルを処理し、各局のためにデータシンク1834へと復号化されたデータを供給し、コントローラ/プロセッサ1820に制御データを供給してもよい。
【００７３】
コントローラ/プロセッサ1820および1860は、それぞれ局120xおよび120aの動作を指令してもよい。コントローラー/プロセッサ1820および／または1860は、さらに図10の中の方法1000、図12の中の方法1200、図14の中の方法1400、図16の中の方法1600および／または本明細書に記述された技術に関する他の方法を実行してもよい。メモリ1822および1862は、局120xおよび120aのためにプログラム・コードおよびデータをそれぞれ格納してもよい。スケジューラ1824は、上に記述された設計のうちの何れかに基づいて複数の局のためのスケジューリングを実行しても良い。
【００７４】
ここに記述された技術は、様々な手段によって実装されてもよい。例えば、本技術はハードウェア、ファームウェア、ソフトウェアあるいはそれらの組み合わせの中で実装されてもよい。ハードウェア実装については、本技術を実行するために使用される処理装置は、1つ以上の特定用途向けIC(ASIC)、ディジタル信号プロセサ(DSP)、ディジタル信号処理デバイス(DSPD)、プログラム可能論理回路(PLD)、フィールドプログラム可能なゲート・アレイ(FPGA)、プロセッサ、コントローラ、マイクロ・コントローラ、マイクロプロセッサー、電子デバイス、本明細書で記述された機能を実行することを目指した他の電子ユニット、コンピュータあるいはそれらの組み合わせの内に実装されてもよい。
【００７５】
ファームウェアおよび／またはソフトウェア実装については、本技術は、本明細書に記述された機能を実行するモジュール(例えばプロシージャ、関数など)で実装されてもよい。ファームウェアおよび／またはソフトウェアの命令/コードは、メモリ(例えば、メモリ1822あるいは1862、図18に)に格納され、プロセッサ(例えばプロセッサ1820あるいは1860)によって実行されてもよい。メモリはプロセッサ内に実装されるか、あるいはプロセッサの外部に実装されるかもしれない。ファームウェアおよび／またはソフトウェアの命令/コードはまた、ランダムアクセス・メモリ(RAM)、読み取り専用メモリ(ROM)、不揮発性のランダムアクセス・メモリ(NVRAM)、プログラマブル読取専用メモリ(PROM)、電気的消去可能PROM(EEPROM)、FLASHメモリ、フロッピー（登録商標）ディスク、コンパクト・ディスク(CD)、ディジタル・バーサタイル・ディスク(DVD)、磁気光学のデータ保存装置などのようなコンピュータ/プロセッサ読み出し可能な媒体に格納されるかもしれない。命令/コードは１つ以上のプロセッサによって実行可能かもしれないし、本明細書に記述された機能の特定の態様をプロセッサに実行させても良い。
【００７６】
ここに記述された技術を実装する装置はスタンド・アロンのユニットかもしれないし、あるいは装置の一部かもしれない。該装置は、(i)スタンド・アロンの集積回路(IC)、(ii)データ及び／又は命令の格納のためにメモリICを含んでいるかもしれない１つ以上のICのセット、(iii)移動局モデム(MSM)のようなASIC、(iv)他のデバイス内に埋め込まれてもよいモジュール、(v)携帯電話、無線装置、送受話器あるいは移動ユニット、(vi)などかもしれない。
【００７７】
本開示の上記の記述はどんな当業者も本開示を作るか使用することを可能にするために提供される。本開示への様々な修正は当業者に容易に明白になり、ここに定義された総括的な法則は、本開示の精神または範囲から外れずに、他の変形実施例に適用されるかもしれない。したがって、その開示は、本明細書に記述された例示と設計に制限されるようには意図されず、ここに示された法則と新規な特徴と一致する最も広い範囲が与えられるべきである。
【特許請求の範囲】
【請求項１】
下記を備える無線通信のための装置：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定し、前記バッファー・ステータスを備えるフレームを生成し、および前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信するように構成された少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合したメモリ。
【請求項２】
請求項１記載の装置、ここにおいて、
前記第２の局は電力保存モードで動作し、前記バッファー・ステータスは前記第２の局に送信されるデータフレームの数を表示する。
【請求項３】
請求項１記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信するように構成される。
【請求項４】
請求項１記載の装置、ここにおいて、
前記フレームはデータフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第１と前記第２の局の両方に関するサービス間隔の期間中に前記データフレームを送信するように構成される。
【請求項５】
請求項１記載の装置、ここにおいて、
前記フレームは、そこに送信すべきデータが存在する複数の局に関するバッファー・ステータスを備えるＰＳＭＰフレームである。
【請求項６】
請求項１記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記バッファー・ステータスによって示されるとおりに前記第２の局に対して少なくとも一つのデータフレームを送信するように構成される。
【請求項７】
請求項６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第２の局に送信された前記少なくとも一つのデータフレームに対するＡＣＫを受信し、ＡＣＫが受信されない各データフレームを再送信する。
【請求項８】
請求項７記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記一つ以上のデータフレームに対してＡＣＫが受信されないならば、前記少なくとも一つのデータフレームの中の一つ以上のデータフレームの再送信をスキップし、前記第１と前記第２の両方の局について起動状態である次の期間中に前記一つ以上のデータフレームを再送信する。
【請求項９】
下記を備える無線通信のための方法：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定すること；
前記バッファー・ステータスを備えるフレームを生成すること；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信すること。
【請求項１０】
更に下記を備える請求項９記載の方法：
前記バッファー・ステータスによって示されるとおりに、前記第２の局に対して少なくとも一つのデータフレームを送信すること。
【請求項１１】
請求項９記載の方法、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記方法は更に下記を備える：
前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信すること。
【請求項１２】
下記を備える無線通信のための装置：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定する手段；
前記バッファー・ステータスを備えるフレームを生成する手段；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信する手段。
【請求項１３】
更に下記を備える請求項１２記載の装置：
前記バッファー・ステータスによって示されるとおりに、前記第２の局に対して少なくとも一つのデータフレームを送信する手段。
【請求項１４】
請求項１２記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記装置は更に下記を備える：
前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信する手段。
【請求項１５】
下記を備えるコンピュータ可読媒体を備えるコンピュータ・プログラム製品：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局においてコンピュータに決定させるためのコード；
前記バッファー・ステータスを備えるフレームを前記コンピュータに生成させるためのコード；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを前記コンピュータに送信させるためのコード。
【請求項１６】
下記を備える無線通信のための装置：
第１と第２の両方の局について起動状態である期間中に前記第２の局に関するバッファー・ステータスを備えるフレームを前記第１の局から受信し、前記バッファー・ステータスによって示されるとおりに前記第１の局から少なくとも一つのデータフレームを受信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項１７】
請求項１６記載の装置、ここにおいて、
前記第２の局は電力保存モードで動作し、ここで、前記少なくとも一つのプロセッサは、前記第１の局から受信した全てのデータフレーム、及び前記バッファー・ステータスに基づいて、スリープ状態に移行するか否かを決定するように構成される。
【請求項１８】
請求項１６記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記少なくとも一つのプロセッサはビーコン間隔内のＡＴＩＭウィンドウの期間中に前記フレームを受信し、前記ＡＴＩＭウィンドウの経過後に前記少なくとも一つのデータフレームを受信し、前記少なくとも一つのデータフレームを受信した後にスリープ状態に移行するか否かを決定するように構成される。
【請求項１９】
請求項１６記載の装置、ここにおいて、
前記フレームはデータフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第２の局に関するサービス間隔の期間中に前記第１の局から前記データフレームを受信し、前記バッファー・ステータスによって示されるとおりに任意の追加のデータフレームを受信し、前記バッファー・ステータスによって示される全てのデータフレームを受信した後にスリープ状態に移行するか否かを決定するように構成される。
【請求項２０】
請求項１６記載の装置、ここにおいて、
前記フレームはＰＳＭＰフレームであり、ここで、前記少なくとも一つのプロセッサは、ＡＴＩＭウィンドウの期間内に前記第１の局から前記ＰＳＭＰフレームを受信し、前記ＡＴＩＭウィンドウの経過後に前記少なくとも一つのデータフレームを受信するように構成される。
【請求項２１】
請求項１６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第１の局から受信した前記少なくとも一つのデータフレームに対してＡＣＫを送信し、受信した最後のデータフレームに対してＡＣＫを送信した後にスリープ状態に移行するように構成される。
【請求項２２】
請求項１６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第１の局から受信した前記少なくとも一つのデータフレームに対してＡＣＫを送信し、前記第１の局によるＡＣＫ受信の失敗に起因する可能な再送信を受信するための最後の受信データフレームに対してＡＣＫを送信した後に、所定の長さの時間にわたって移動状態のままでい続け、前記所定の長さの時間が経過した後にスリープ状態に移行するように構成される。
【請求項２３】
請求項２２記載の装置、ここにおいて、前記最後の受信データフレームに対して前記ＡＣＫを送信した後に、起動状態でい続ける前記時間の長さは設定可能である。
【請求項２４】
下記を備える無線通信のための装置：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信し、前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項２５】
請求項２４記載の装置、ここにおいて、
前記ＴＸＯＰバースト受信機能についての前記情報は、一つのＴＸＯＰバースト内で前記第２の局によって受信されることが可能なデータフレームの数を示す。
【請求項２６】
請求項２４記載の装置、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記少なくとも一つのプロセッサは、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信するように構成される。
【請求項２７】
請求項２４記載の装置、ここにおいて、
前記フレームは前記第２の局から受信したデータフレームである。
【請求項２８】
請求項２４記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行し、別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信するように構成される。
【請求項２９】
下記を備える無線通信のための方法：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信すること；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信すること。
【請求項３０】
請求項２９記載の方法、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記フレームを前記受信することは、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信することを備える。
【請求項３１】
請求項２９記載の方法、ここにおいて、
前記複数のフレームを前記送信することは、下記を備える：
前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行すること；および、
別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信すること。
【請求項３２】
下記を備える無線通信のための装置：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信する手段；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信する手段。
【請求項３３】
請求項３２記載の装置、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記フレームを受信する前記手段は、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信することを備える。
【請求項３４】
請求項３２記載の方法、ここにおいて、
前記複数のフレームを送信する前記手段は、下記を備える：
前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行する手段；および、
別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信する手段。
【請求項３５】
下記を備えるコンピュータ可読媒体を備えるコンピュータ・プログラム製品：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局においてコンピュータに受信させるためのコード；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームをコンピュータに送信させるためのコード。
【請求項３６】
下記を備える無線通信のための装置：
電力保存モードで動作している第１の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを送信し、前記第１の局の前記ＴＸＯＰバースト受信機能に基づいて前記第１の局に対して単一のＴＸＯＰの中において第２の局によって送信された複数のデータフレームを受信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項３７】
請求項３６記載の装置、ここにおいて、
前記フレームは管理フレームであり、ここで、前記少なくとも一つのプロセッサは、無線ネットワーク内における他の局とのアソシエーションの期間中に前記管理フレームを送信するように構成される。
【請求項１】
下記を備える無線通信のための装置：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定し、前記バッファー・ステータスを備えるフレームを生成し、および前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信するように構成された少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合したメモリ。
【請求項２】
請求項１記載の装置、ここにおいて、
前記第２の局は電力保存モードで動作し、前記バッファー・ステータスは前記第２の局に送信されるデータフレームの数を表示する。
【請求項３】
請求項１記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信するように構成される。
【請求項４】
請求項１記載の装置、ここにおいて、
前記フレームはデータフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第１と前記第２の局の両方に関するサービス間隔の期間中に前記データフレームを送信するように構成される。
【請求項５】
請求項１記載の装置、ここにおいて、
前記フレームは、そこに送信すべきデータが存在する複数の局に関するバッファー・ステータスを備えるＰＳＭＰフレームである。
【請求項６】
請求項１記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記バッファー・ステータスによって示されるとおりに前記第２の局に対して少なくとも一つのデータフレームを送信するように構成される。
【請求項７】
請求項６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第２の局に送信された前記少なくとも一つのデータフレームに対するＡＣＫを受信し、ＡＣＫが受信されない各データフレームを再送信する。
【請求項８】
請求項７記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記一つ以上のデータフレームに対してＡＣＫが受信されないならば、前記少なくとも一つのデータフレームの中の一つ以上のデータフレームの再送信をスキップし、前記第１と前記第２の両方の局について起動状態である次の期間中に前記一つ以上のデータフレームを再送信する。
【請求項９】
下記を備える無線通信のための方法：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定すること；
前記バッファー・ステータスを備えるフレームを生成すること；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信すること。
【請求項１０】
更に下記を備える請求項９記載の方法：
前記バッファー・ステータスによって示されるとおりに、前記第２の局に対して少なくとも一つのデータフレームを送信すること。
【請求項１１】
請求項９記載の方法、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記方法は更に下記を備える：
前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信すること。
【請求項１２】
下記を備える無線通信のための装置：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局において決定する手段；
前記バッファー・ステータスを備えるフレームを生成する手段；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを送信する手段。
【請求項１３】
更に下記を備える請求項１２記載の装置：
前記バッファー・ステータスによって示されるとおりに、前記第２の局に対して少なくとも一つのデータフレームを送信する手段。
【請求項１４】
請求項１２記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記装置は更に下記を備える：
前記第１と前記第２の局が両方共起動状態である時間ウィンドウ内で前記フレームを送信する手段。
【請求項１５】
下記を備えるコンピュータ可読媒体を備えるコンピュータ・プログラム製品：
そこに送信するためのデータが存在する第２の局に関するバッファー・ステータスを第１の局においてコンピュータに決定させるためのコード；
前記バッファー・ステータスを備えるフレームを前記コンピュータに生成させるためのコード；および、
前記第１と第２の両方の局について起動状態である期間中に前記第１の局から前記第２の局に対して前記フレームを前記コンピュータに送信させるためのコード。
【請求項１６】
下記を備える無線通信のための装置：
第１と第２の両方の局について起動状態である期間中に前記第２の局に関するバッファー・ステータスを備えるフレームを前記第１の局から受信し、前記バッファー・ステータスによって示されるとおりに前記第１の局から少なくとも一つのデータフレームを受信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項１７】
請求項１６記載の装置、ここにおいて、
前記第２の局は電力保存モードで動作し、ここで、前記少なくとも一つのプロセッサは、前記第１の局から受信した全てのデータフレーム、及び前記バッファー・ステータスに基づいて、スリープ状態に移行するか否かを決定するように構成される。
【請求項１８】
請求項１６記載の装置、ここにおいて、
前記フレームはＡＴＩＭフレーム、又はＲＴＳフレームであり、ここで、前記少なくとも一つのプロセッサはビーコン間隔内のＡＴＩＭウィンドウの期間中に前記フレームを受信し、前記ＡＴＩＭウィンドウの経過後に前記少なくとも一つのデータフレームを受信し、前記少なくとも一つのデータフレームを受信した後にスリープ状態に移行するか否かを決定するように構成される。
【請求項１９】
請求項１６記載の装置、ここにおいて、
前記フレームはデータフレームであり、ここで、前記少なくとも一つのプロセッサは、前記第２の局に関するサービス間隔の期間中に前記第１の局から前記データフレームを受信し、前記バッファー・ステータスによって示されるとおりに任意の追加のデータフレームを受信し、前記バッファー・ステータスによって示される全てのデータフレームを受信した後にスリープ状態に移行するか否かを決定するように構成される。
【請求項２０】
請求項１６記載の装置、ここにおいて、
前記フレームはＰＳＭＰフレームであり、ここで、前記少なくとも一つのプロセッサは、ＡＴＩＭウィンドウの期間内に前記第１の局から前記ＰＳＭＰフレームを受信し、前記ＡＴＩＭウィンドウの経過後に前記少なくとも一つのデータフレームを受信するように構成される。
【請求項２１】
請求項１６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第１の局から受信した前記少なくとも一つのデータフレームに対してＡＣＫを送信し、受信した最後のデータフレームに対してＡＣＫを送信した後にスリープ状態に移行するように構成される。
【請求項２２】
請求項１６記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記第１の局から受信した前記少なくとも一つのデータフレームに対してＡＣＫを送信し、前記第１の局によるＡＣＫ受信の失敗に起因する可能な再送信を受信するための最後の受信データフレームに対してＡＣＫを送信した後に、所定の長さの時間にわたって移動状態のままでい続け、前記所定の長さの時間が経過した後にスリープ状態に移行するように構成される。
【請求項２３】
請求項２２記載の装置、ここにおいて、前記最後の受信データフレームに対して前記ＡＣＫを送信した後に、起動状態でい続ける前記時間の長さは設定可能である。
【請求項２４】
下記を備える無線通信のための装置：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信し、前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項２５】
請求項２４記載の装置、ここにおいて、
前記ＴＸＯＰバースト受信機能についての前記情報は、一つのＴＸＯＰバースト内で前記第２の局によって受信されることが可能なデータフレームの数を示す。
【請求項２６】
請求項２４記載の装置、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記少なくとも一つのプロセッサは、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信するように構成される。
【請求項２７】
請求項２４記載の装置、ここにおいて、
前記フレームは前記第２の局から受信したデータフレームである。
【請求項２８】
請求項２４記載の装置、ここにおいて、
前記少なくとも一つのプロセッサは、前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行し、別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信するように構成される。
【請求項２９】
下記を備える無線通信のための方法：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信すること；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信すること。
【請求項３０】
請求項２９記載の方法、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記フレームを前記受信することは、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信することを備える。
【請求項３１】
請求項２９記載の方法、ここにおいて、
前記複数のフレームを前記送信することは、下記を備える：
前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行すること；および、
別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信すること。
【請求項３２】
下記を備える無線通信のための装置：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局において受信する手段；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームを送信する手段。
【請求項３３】
請求項３２記載の装置、ここにおいて、
前記フレームはビーコン・フレームであり、ここで、前記フレームを受信する前記手段は、ＴＢＴＴにおいて第３の局から前記ビーコン・フレームを受信することを備える。
【請求項３４】
請求項３２記載の方法、ここにおいて、
前記複数のフレームを送信する前記手段は、下記を備える：
前記ＴＸＯＰの開始時点においてチャネル・アクセスを実行する手段；および、
別のチャネル・アクセスを実行することなく前記ＴＸＯＰ内で前記複数のデータフレームを送信する手段。
【請求項３５】
下記を備えるコンピュータ可読媒体を備えるコンピュータ・プログラム製品：
電力保存モードで動作している第２の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを第１の局においてコンピュータに受信させるためのコード；および、
前記第２の局の前記ＴＸＯＰバースト受信機能に基づいて前記第２の局に対して単一のＴＸＯＰの中において複数のデータフレームをコンピュータに送信させるためのコード。
【請求項３６】
下記を備える無線通信のための装置：
電力保存モードで動作している第１の局のＴＸＯＰバースト受信機能についての情報を備えるフレームを送信し、前記第１の局の前記ＴＸＯＰバースト受信機能に基づいて前記第１の局に対して単一のＴＸＯＰの中において第２の局によって送信された複数のデータフレームを受信するように構成される少なくとも一つのプロセッサ；および、
前記少なくとも一つのプロセッサに結合されたメモリ。
【請求項３７】
請求項３６記載の装置、ここにおいて、
前記フレームは管理フレームであり、ここで、前記少なくとも一つのプロセッサは、無線ネットワーク内における他の局とのアソシエーションの期間中に前記管理フレームを送信するように構成される。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図２】
【図３】
【図４】
【図５】
【図６Ａ】
【図６Ｂ】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【公開番号】特開２０１２−１８６８２８（Ｐ２０１２−１８６８２８Ａ）
【公開日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１２−９９７３６（Ｐ２０１２−９９７３６）
【出願日】平成２４年４月２５日（２０１２．４．２５）
【分割の表示】特願２００９−５３３４８８（Ｐ２００９−５３３４８８）の分割
【原出願日】平成１９年１０月１６日（２００７．１０．１６）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
【公開日】平成２４年９月２７日（２０１２．９．２７）
【国際特許分類】
【出願番号】特願２０１２−９９７３６（Ｐ２０１２−９９７３６）
【出願日】平成２４年４月２５日（２０１２．４．２５）
【分割の表示】特願２００９−５３３４８８（Ｐ２００９−５３３４８８）の分割
【原出願日】平成１９年１０月１６日（２００７．１０．１６）
【出願人】（５９５０２０６４３）クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】ＱＵＡＬＣＯＭＭ ＩＮＣＯＲＰＯＲＡＴＥＤ
【Ｆターム（参考）】
[ Back to top ]