JP2009540687A - パケット・グループ化によって省電力を達成すること - Google Patents

Abstract

パケットをグループ化することにより、パケット交換システムにおける省電力が達成される。例えば、システムの一部が待機状態にある間、パケットがキューされうる。いくつかの実施形態では、通話時間を長くするために、無線システムにおいて、省電力が備えられている。ここで、例えば無線デバイスのラジオのような１または複数の構成要素が待機状態にある間、パケットがキューされうる。

Description

本願は一般に通信に関し、さらに詳しくは、パケットをグループ化することに関する。

電子デバイスは、他の電子デバイスとの情報の送信および／または受信のために、１または複数の通信プロトコルをサポートすることができる。例えば、イーサネット（登録商標）ベースのプロトコルは、様々な切り換え／ルーティング構成要素および対応する相互接続ケーブリングを含むネットワークを介した電子デバイス間の通信を容易にする。反対に、無線プロトコルは、１または複数のモバイル・デバイスへの電波による通信を容易にする。

多くのアプリケーションでは、電子通信デバイスにおける電力を節約することが望ましい。例えば、デバイスがある期間中使用されていない場合、有線デバイスを低電力モードへ切り換えることが望ましい。さらに、モバイル・デバイスは従来、バッテリ電力で動作する。この場合、モバイル・デバイスによって消費される電力を低減することは、バッテリの充電間のデバイスの通話時間を効果的に増加させる。

例えば（ＩＥＥＥ ８０２．１１に関連する仕様に基づく）Ｗｉ−Ｆｉのような通信プロトコルは、データの送信も受信もしていない場合、デバイスが省電力モードに遷移することをイネーブルする手順を定義することによって、無線通信デバイスにおける省電力をサポートすることができる。例えば、デバイスが省電力モードである場合、デバイスにフレームを提供するアクセス・ポイントは、フレームをバッファすることができる。くわえて、プロトコルは、デバイスが、省電力モードから通常動作モードへと遷移すると、フレームの送信および／または受信のために通信チャネルにアクセスすることをイネーブルする手順を定義することができる。

本願は、２００６年６月８日に出願され、本願の譲受人に譲渡され、本明細書において参照によってその開示が組み込まれている「ＡＣＨＩＥＶＩＮＧ ＰＯＷＥＲ ＳＡＶＥ ＵＳＩＮＧ ＶＯＩＰ ＰＡＣＫＥＴ ＣＯＭＢＩＮＩＮＧ」と題された米国仮出願６０／８１２，３９６号の優先権を主張する。

本開示の選択された局面の概要は以下の通りである。便宜上、１または複数の局面は、本明細書において単に「局面」と称されうる。

幾つかの局面では、省電力は、装置においてパケットをグループ化することによって達成される。例えば、装置が待機状態にある間、パケットがキューされうる。待機状態では、（例えば、媒体アクセス制御レイヤおよび物理レイヤに関連する構成要素のような）装置の少なくとも一部が、低電力状態とされる。その後、装置は、キューされたパケットのグループの送信および／または受信のために、待機状態からウェイク状態（例えば、通常動作状態）へと遷移することができる。有利なことに、キューされたパケットのグループは、単一のウェイク状態中、比較的連続に近い状態で送信および／または受信されうる。

幾つかの局面では、パケットは、設定可能な時間長さにわたってキューされる。例えば、装置が待機状態にある場合、パケットは、設定可能な時間長さにわたってキューされうる。設定可能な時間長さを経過すると、設定可能な時間長さ中にキューされた任意のパケットがグループとして送信されるように、装置は、ウェイク状態に遷移することができる。

あるいは、幾つかの局面では、設計可能な数のパケットがキューされる。例えば、装置が待機状態にある場合、指定された数のパケットがキューされるまで、パケットがキューされうる。この時点では、キューされたパケットがグループとして送信されるように、装置はウェイク状態に遷移することができる。

幾つかの局面では、例えば無線ローカル・エリア・ネットワーク（“ＷＡＬＮ”）ラジオのような装置の１または複数の構成要素が待機状態にある場合、パケットをキューすることによって、ＷＡＬＮ装置における省電力が達成される。例えば、ＷＬＡＮラジオが待機状態にある場合、上部レイヤ動作を提供する構成要素（例えば、アプリケーション・レイヤ構成要素および送信レイヤ構成要素）は、装置によって送信されるアップリンク・パケットをキューすることができる。さらに、アクセス・ポイント（“ＡＰ”）は、この時点において装置に向けられているダウンリンク・パケットを含むフレームをキューすることができる。ＷＬＡＮラジオがウェイク状態に戻る場合、装置は、キューされたアップリンク・パケットを含む一連のフレームをＡＰに送信することができる。さらに、要求がなされると、ＡＰは、キューされたダウンリンク・パケットを含むフレームを、順に装置へ送信することができる。有利なことに、これらのアップリンク・パケットおよびダウンリンク・パケットは、装置の単一のウェイク状態中に送信されうる。ここでは、幾つかの局面において、パケットは、１または複数の８０２．１１ｅ送信機会（“ＴＸＯＰ”：transmit opportunity）中に送られたフレームによって送信される。

幾つかの局面では、データが、上部レイヤ構成要素によってバンドルされうる。例えば、下部レイヤ構成要素が待機状態にある場合、（例えば、ＲＴＰパケット・フォーマットの）データが、上部レイヤにおいてキューされうる。データが送られる準備ができている場合、データ（例えば、ＲＴＰパケット・データ）が、単一のＩＰパケットに集められうる。その後、下部レイヤ構成要素がウェイク状態に遷移すると、単一のフレームを介してＡＰへ送信するために、ＩＰパケットが下部レイヤに送られうる。

幾つかの局面では、正しく送信されなかったデータに対処するために、プロビジョンがなされうる。例えば、下部レイヤから受信したアクノレッジメント情報に基づいて、上部レイヤ構成要素は、下部レイヤに送られる次のＩＰパケットのタイミングおよび／またはデータ・インを調節することができる。

幾つかの局面では、ユーザ機器における省電力方法は、ユーザ機器のトランシーバが待機状態にある間、ユーザ機器において、複数のパケットをキューすることと、トランシーバの単一のウェイク状態中、キューされたパケットを、ユーザ機器によって送信することとを備える。

幾つかの局面では、装置は、単一のウェイク状態中、キューされたパケットを送信するように適応されたトランシーバと、トランシーバが待機状態にある間、複数のパケットをキューするように適応されたパケット・キューワー（queuer）とを備える。

幾つかの局面では、装置は、単一のウェイク状態中、キューされたパケットを送信する手段と、送信する手段が待機状態にある間、複数のパケットをキューする手段とを備える。

幾つかの局面では、コンピュータ読取可能媒体に格納された命令群を含むコンピュータ読取可能媒体は、ユーザ機器のトランシーバが待機状態にある間、ユーザ機器において、複数のパケットをキューする第１の命令セットと、トランシーバの単一のウェイク状態中に、キューされたパケットを、ユーザ機器によって送信する第２の命令セットとを備える。

本開示のこれらおよびその他の機能、局面、および利点は、以下の詳細な説明、特許請求の範囲、および添付図面と関連して考慮された場合に、より十分に理解されうる。

図１は、パケットのグループを送信および／または受信するように適応された通信システムの幾つかの局面の簡略図である。 図２は、パケットのグループを送信および／または受信するために実行されうる動作の幾つかの局面のフローチャートである。 図３は、パケットのグループを送信するために実行されうる上部レイヤ動作の幾つかの局面のフローチャートである。 図４は、パケット交換ネットワークを介してパケットのグループの送信および／または受信を行うように適応されたユーザ機器の幾つかの局面の簡略図である。 図５は、単一のＩＰパケットにグループ化されたパケットの送信および／または受信を行うように適応されたユーザ機器の幾つかの局面の簡略図である。 図６は、パケットのグループを送信および／または受信するために実行されうる下部レイヤ動作の幾つかの局面の簡略フローチャートである。 図７は、単一のＩＰパケットにグループ化されたパケットの送信および／または受信のために実行されうる下部レイヤ動作の幾つかの局面の簡略フローチャートである。 図８は、下部レイヤに送られるＩＰパケットのタイミングおよび／またはデータ・インの調節の幾つかの局面を例示する簡略図である。 図９は、パケットのグループの送信および／または送信を行うように適応されたユーザ機器の幾つかの局面の簡略図である。 図１０は、パケットのグループを送信および／または受信するように適応されたユーザ機器の幾つかの局面の簡略図である。

一般的な実施にしたがって、これら図面中に例示された様々な機能は、スケールするように描かれていないこともありうる。したがって、様々な機能の大きさは、明瞭さのために、任意に拡大または縮小されうる。さらに、図面のうちのいくつかは、明瞭さのために単純化されうる。したがって、これら図面は、与えられた装置または方法の構成要素の全てを示しているとは限らない。最後に、同一の参照番号は、明細書および図面を通じて、同一の機能を示すために使用されうる。

本開示の様々な局面は以下に述べられる。本明細書における教示は、広範な様々な形態で具体化され、しかも、本明細書で開示された任意の具体的構造および／または機能は単に代表例であることが明白であるべきである。本明細書の教示に基づいて、当業者であれば、本明細書に開示された局面は、その他任意の局面において独立して実現され、しかも、これら局面の２またはそれ以上が組み合わせられうることを認識すべきである。例えば、本明細書に記載された任意の数の局面を用いて装置が実施され、および／または、方法が実現されうる。さらに、本明細書に記載の局面の１または複数に加えて、あるいはそれとは異なる他の構造および／または機能を用いて、装置が実施され、および／または、方法が実現されうる。

図１は、パケットをグループ化することによってシステム１００が有利に省電力することができるパケット交換ネットワーク１０６に、１または複数のユーザ機器デバイス（例えば、ユーザ機器１０２およびユーザ機器１０４）が接続されたシステム１００のある局面を例示する。複数のユーザ機器デバイスは、互いに、および／または、パケット交換ネットワーク１０６に接続された１または複数のその他のデバイス（図示せず）と、パケットの送信および／または受信を行う。実際には、パケット交換ネットワーク１０６に接続されるユーザ機器デバイスの数は、与えられたアプリケーションの要件に依存するだろう。したがって、（例えば、１、２、３などのような）任意の数のそのようなデバイスが、パケット交換ネットワーク１０６に接続されうる。便宜上、ユーザ機器デバイスの典型的な動作および構成要素が、ユーザ機器１０２に関して説明されよう。しかしながら、（例えば、ユーザ機器１０４および／またはネットワーク１０６に接続されたその他のユーザ機器のような）その他のユーザ機器は、類似した動作を実行し、および／または、類似した構成要素を含みうることが認識されるべきである。ある場合には、互いに通信しているユーザ機器は、パケットをグループ化することによって、おのおの有利に省電力することができる。ユーザ機器（“ＵＥ”）はまた、アクセス端末、ステーション（“ＳＴＡ”）、無線通信デバイス、端末、ユーザ端末、モバイル機器、加入者ユニット、あるいはその他の用語で称することができる。ＵＥは、セルラ電話、スマート・フォン、コードレス・フォン、ラップトップ・コンピュータ、ＰＤＡ、無線デバイス、無線モデム、モバイル・デバイス、ハンドセット、ハンドヘルド・デバイス、衛星ラジオ、全地球測位システム、あるいはその他幾つかの通信デバイスでありうる。

典型的なシナリオでは、ユーザ機器１０２上で実行する１または複数のアプリケーション（以下、便宜上、アプリケーション１０８と称する）は、ネットワーク１０６を介して送信される場合にパケットにフォーマットされるデータの生成および受信を行う。したがって、ユーザ機器１０２は、アプリケーション・データおよび関連するパケットを取り扱うための１または複数の上部レイヤ構成要素（以下により詳細に説明する）を含んでいる。

さらに、ユーザ機器１０２は、ネットワーク１０６を経由してパケットを送受信する１または複数の下部レイヤ構成要素を含んでいる。例えば、トランシーバ１１０は、ユーザ機器１０２との間でのパケットの物理的な送信を取り扱う物理レイヤ・インタフェース（および、オプションとして、データ・リンク・レイヤ・インタフェース）を備えることができる。

いくつかのアプリケーションでは、ユーザ機器１０２は、パケット交換ネットワーク・インタフェース１１２を経由してネットワーク１０６に接続することができる。例えば、ユーザ機器１０２および１０４、ならびにネットワーク・インタフェース１１２は、例えば、ローカル・エリア・ネットワーク（“ＬＡＮ”）、パーソナル・エリア・ネットワーク（“ＰＡＮ”）、あるいはその他幾つかのタイプのネットワークのようなサブネットワークを備えることができる。さらに、ネットワーク１０６は、通信リンク１１４を介して、１つのタイプのネットワーク・プロトコル（例えば、イーサネット（登録商標））によって通信することができる一方、サブネットワークは、その他幾つかのプロトコル（例えば、有線ベースのプロトコル、あるいは、無線ベースのプロトコル）によって通信することができる。したがって、ネットワーク・インタフェース１１２は、データを再フォーマットし、（例えば、ユーザ機器１０２あるいはユーザ機器１０４のような）与えられたユーザ機器デバイスと、ネットワーク１０６との間でデータを送信するために必要とされるその他任意の動作も行なうことができる。

一般に、ユーザ機器１０２との間のパケット・フローは、絶対的に連続的であるものではない。例えば、パケット・フローは、（例えば、バースト状のような）散発的なものであるかもしれないし、あるいは比較的等間隔で生じるかもしれない。いずれの場合も、パケットの送信の間および／または受信の間に、比較的有意な長さの時間が存在しうる。したがって、省電力が望ましいアプリケーションにおいては、パケットが送信されていない場合、および／または、パケットが受信される予定ではない場合には、ユーザ機器１０２の構成要素のうちの１または複数の電源を効果的にオフすることが有利であることが分かる。例えば、送信構成要素と受信構成要素との両方が、指定された時間期間において、省電力モードに設定されうる。あるいは、送信構成要素および受信構成要素は、アクティブ・モードと省電力モードとの間で独立して遷移することができる。例えば、ネットワーク・インタフェース１１２が、ダウンリンク・トラフィックをバッファしないアプリケーションにおいては、受信構成要素がアクティブ・モードであり続ける一方、送信構成要素は、省電力モードに設定されうる。このように、いくつかの省電力は、ダウンリンク・トラフィックが失われないことを保証しながら達成されうる。

図１の例では、状態コントローラ１２０は、ユーザ機器１０２の１または複数の構成要素の状態を制御する。便宜上、そのような構成要素は、本明細書では、下部レイヤ構成要素と称することができる（例えば、トランシーバ１１０）。しかしながら、本明細書における教示に基づいて、下部レイヤ構成要素およびトランシーバといった用語は、物理レイヤ構成要素に限定されないことが認識されるべきである。むしろ、この用語は、データおよびパケットを生成しキューを実行する構成要素と、その他の関連する動作がアクティブ状態（例えば、ウェイク状態）を維持しながら、有利に待機する（例えば、省電力モードとされる）（例えば、ＭＡＣ機能を有する）他のレイヤ構成要素、または、ユーザ機器１０２のその他任意の構成要素を含むことができる。したがって、下部レイヤ構成要素という用語は、本明細書では、上部レイヤに関連付けられた構成要素が、下部レイヤのためのパケットを、アクティブ状態に戻った下部レイヤに提供するためにアクティブを維持する一方、構成要素が有利に待機状態（あるいは、電力ダウン状態等）等とされる、１または複数のレイヤに関連付けられた構成要素を称するために使用されうる。

いくつかのアプリケーションでは、状態コントローラ１２０は、トランシーバ１１０を、アクティブ状態（例えば、フル動作状態）と、待機状態（例えば、低電力状態）との間で切り換えることができる。後者の場合、トランシーバ１１０の構成要素（例えば、比較的高電力を消費する構成要素）のうちの１または複数は、ディセーブルまたは電源オフされうる。しかしながら、ある場合には、ある情報（例えば、デジタル信号プロセッサのためにダウンロードされたコーディング、状態情報等）が、待機状態の間、保持される（例えば、トランシーバ１１０内のデータ・メモリに格納される）。例えば、待機状態の間、トランシーバ１１０内のデータ・メモリ（図示せず）の少なくとも一部にしか電力が供給されない。したがって、状態コントローラ１２０は、省電力が望まれると、トランシーバ１１０を待機状態にするために使用されうる。しかしながら、待機状態中、パケットは、ユーザ機器１０２によって、リンク１１６を介して、送信も受信もされない。

トランシーバ１１０が待機状態にある時間の長さを延長（し、さらに電力を節約する）するために、ユーザ機器１０２および／またはネットワーク・インタフェース１１２は、トランシーバ１１０が待機状態にある間、パケットをキューするように適応されうる。ユーザ機器１０２およびネットワーク・インタフェース１１２は、トランシーバ１１０がアクティブ状態にある場合、通信リンク１１６によって送信するためにキューされたパケットをグループ化（例えば、統合、バンドル、結合等）するように適応されうる。ここでは、ユーザ機器１０２によって送信のためにパケットが生成される毎に、あるいは、ユーザ機器１０２がパケットを受信すると予期される毎に、トランシーバ１１０を待機状態からアクティブ状態に遷移させないことによって電力が節約される。したがって、パケット・トラフィックのトラフィック・グループへの再スケジュールを行うことによって、省電力が達成されうる。

例として、いくつかのアプリケーションは、比較的規則的なパケット・ストリームを生成する。そのようなアプリケーションに適応するために、ユーザ機器１０２は、トランシーバ１１０が待機状態にある間、パケットをキューするように適応されうる。例えば、ユーザ機器１０２は、パケットのキューと、パケットのデータ・メモリ１２４内の一時的な格納とを容易にするパケット・キューワー（queuer）構成要素１２２を含むことができる。トランシーバ１１０がアクティブ状態に遷移した場合、キューされたパケットが、（インタフェース１１２を経由して）ネットワーク１０６へ送信されるためにトランシーバ１１０へ提供される。

同様に、トランシーバ１１０が待機状態にある場合、ネットワーク・インタフェース１１２は、ユーザ機器１０２に向けられたパケットをキューするように適応されうる。この場合、トランシーバ１１０がアクティブ状態に遷移すると、ネットワーク・インタフェース１１２は、キューされたパケットを、トランシーバ１１０へ送ることができる。

いずれの場合も、キューされたパケットは、通信リンク１１６を介した送信のためにグループ化されうる。例えば、トランシーバ１１０は、（アプリケーション１０８から受け取った）キューされたアップリンク・パケットを、通信リンク１１６を介して、ネットワーク・インタフェース１１２へ連続的に送ることができる。反対に、トランシーバ１１０による要求、あるいはその他のある指示に応答して、ネットワーク・インタフェース１１２は、キューされたダウンリンク・パケットの幾つかを、通信リンク１１６を介してトランシーバ１１０へ連続的に送ることができる。

図２のフローチャートは、待機状態中にパケットをキューし、アクティブ状態中に、送信のためにキューされたパケットをグループ化することによって省電力を達成するように実行されうる幾つかの局面における選択動作を例示している。便宜上、図２の動作は、本明細書に記述された特定の構成要素と共に記述されうる。しかしながら、これらの動作は、その他の構成要素と連携して、あるいは、その他の構成要素を用いて実行されうることが認識されるべきである。

ブロック２０２によって示されるように、ユーザ機器１０２のアプリケーション１０８またはその他幾つかの構成要素は、パケット交換ネットワーク１０６を介して送信されるデータを生成する。ネットワーク１０６を介したデータの送信を容易にするために、ユーザ機器１０２は、送信のためのアップリンク・パケットを集め、フォーマットする適切な上部レイヤ構成要素を含んでいる。例えば、アプリケーション１０８は、ボイス・オーバ・インターネット・プロトコル（“ＶｏＩＰ”）構成要素を含みうる。この場合、ＶｏＩＰコールが確立されると、アプリケーションおよび関連するプロトコル・レイヤが、規則的なベースで（例えば、１０ｍｓまたは２０ｍｓ毎に）ＶｏＩＰパケットを生成することができる。

ブロック２０４によって示されるように、ユーザ機器１０２のトランシーバ１１０および／またはその他任意の適切な構成要素が待機状態にある場合、ブロック２０２で生成されたパケットがキューされうる。パケットをキューすることは、例えば、パケット情報が生成され、コピーされ、あるいは移動された場合にパケット情報が格納される幾つかの方式および／または参照によって、パケットを単純に格納することを備えうる。したがって、パケットは、ある特定のシーケンスにおいては、必ずしも格納される訳ではない。以下により詳細に説明するように、パケットは、設定可能な時間長さにわたってキューされうる。この場合、設定可能な時間長さの経過後、キュー内のパケットの数は、パケットが生成されるレートと、設定可能な時間長さの開始時点とに部分的に依存するだろう。あるいは、ブロック２０４において、設定可能な数のパケットがキューされる。

ブロック２０６によって示されるように、設定可能な時間長さが経過したか、あるいは、設定可能なパケット数がキューされると、トランシーバ１１０は、アクティブ（例えば、ウェイク）状態に遷移する。したがって、トランシーバ１１０は、キューされたパケットを上部レイヤから取得し、ネットワーク・インタフェース１１２との通信を確立することができる。例えば、トランシーバ１１０は、通信リンク１１６によって示されるような通信チャンネルへのアクセスを取得することができる。

その後、ブロック２０８によって示されるように、トランシーバ１１０は、キューされたアップリンク・パケットを、通信リンク１１６を介して送信する。有利なことに、パケットの全てが、トランシーバ１１０の単一のウェイク状態中にパケットの全てが送信されるように、キューされたパケットが、送信のためにグループ化される。例えば、上述するように、トランシーバ１１０は、キューされたパケットを、通信リンク１１６を介して、比較的連続に近い状態で送ることができる。

ブロック２１０によって示されるように、同じ単一のウェイク状態中、トランシーバ１１０はまた、ネットワーク・インタフェース１１２内にキューされた任意のダウンリンク・パケットを受信することもできる。例えば、ネットワーク・インタフェース１１２は、キュー内の任意のダウンリンク・パケットを送信するためのトリガとして、アップリンク・パケットの受信を用いることができる。あるいは、トランシーバ１１０は、ネットワーク・インタフェース１１２へメッセージを送り、キューされた全てのパケットの送信を要求することができる。繰り返すが、上述したように、ネットワーク・インタフェース１１２は、キューされたパケットを、通信リンク１１６を介して、比較的に連続に近い状態で送ることができる。

ブロック２１２によって示されるように、トランシーバ１１０は、その後、通信リンク１１６をリリースし、受信したダウンリンク・パケットを、ユーザ機器１０２の上部レイヤ構成要素（例えば、アプリケーション１０８）に転送することができる。この時点では、トランシーバ１１０は、省電力するために、待機状態に戻ることができる。

ブロック２１４によって示されるように、上述した動作が必要に応じて繰り返され、ユーザ機器１０２においてパケットの送信および／または受信がなされる。例えば、ＶｏＩＰコールが維持されている限り、これらの動作が繰り返されうる。

上述した技術および構成要素は、広範で様々なユーザ機器および通信システムに組み込まれうる。例えば、本明細書における教示は、有線ベースの通信システムまたは無線ベースの通信システムに組み込まれうる。そのようなシステムの詳細の幾つかをより完全に例示するために、図３乃至図７は、ローカル・ネットワークを介したＶｏＩＰ接続をサポートする無線ベースの通信システムにおいて実施されうる様々な局面を説明する。しかしながら、図３乃至図７の詳細は、例のみとして提供されており、本明細書における教示は、開示されたプロトコル、構造、および機能に限定されないことが認識されるべきである。

図３は、ユーザ機器の上部レイヤ構成要素によって実行される幾つかの動作を例示する簡略フローチャートである。これらの構成要素は、例えば、アプリケーション・レイヤ構成要素、トランスポート・レイヤ構成要素、およびネットワーク・レイヤ構成要素を含むことができる。したがって、図３の動作は、例えば、データを生成し、このデータを、インターネット・プロトコル（“ＩＰ”）パケットへアセンブルするアップリンク動作と、相補的なダウンリンク動作とを含むことができる。

図４および図５は、ユーザ機器デバイス４０２および５０２（例えば、モバイル・デバイス）それぞれの２つの異なる例を例示している。図４では、デバイス４０２は、グループ化されたパケットを、アクセス・ポイント４０４へと連続フレームで送る。ここでは、図３の動作は、デバイス４０２の上部レイヤ４０６の動作に少なくとも部分的に関連する。図５では、デバイス５０２は、複数の上部レイヤ・パケットを含むＩＰパケットを、単一のフレームによって、アクセス・ポイント５０４へ送る。ここでは、図３の動作は、デバイス５０２の上部レイヤ５０６の動作に少なくとも部分的に関連する。

図６および図７は、ユーザ機器の下部レイヤ構成要素によって実行されうる動作を少なくとも部分的に例示している。特に、図６は、デバイス４０２によって実行される動作に関連し、図７は、デバイス５０２によって実行される動作に関連する。下部レイヤ構成要素は、例えば、データ・リンク・レイヤ（例えば、媒体アクセス・コントローラ）構成要素および物理レイヤ（例えば、ラジオ）構成要素を含みうる。したがって、図６および図７の動作のうちの幾つかは、チャネルにアクセスすることと、チャネルを介してフレームを受信することとに関連しうる。

次に、デバイス４０２および５０２の動作について説明する。具体的には、図４の構成要素の動作は、先ず、図３および図６と関連付けて説明されよう。次に、図５の構成要素の動作が、図３および図７と関連付けて説明されよう。

図４に関連する図３の例に示すように、ブロック３０２では、デバイス４０２の構成要素が、パケットのストリームを生成することができる。例えば、ＶｏＩＰコールが確立された場合、ＶｏＩＰコーデック４０８が、ＶｏＩＰデータのストリームを生成する。コーデック４０８によって生成されたデータ（例えば、Ｇ７１１、Ｇ７２３、Ｇ７２９、ＥＶＲＣ、ＳＭＶ、４ＧＶあるいはＡＭＲ）は、上部レイヤ４０６のうちの１または複数の構成要素によってラップされ、コーデック４０８に依存して、おおよそ１０ｍｓまたは２０ｍｓ毎にＶｏＩＰパケットが生成される。例えば、上部レイヤ４０６のプロトコル構成要素は、ＲＴＰ／ＵＤＰ／ＩＰパケットを生成するために、リアルタイム・トランスポート・プロトコル（“ＲＴＰ”）、ユーザ・データグラム・プロトコル（“ＵＤＰ”）、およびＩＰを起動する。便宜上、これらのパケットは、本明細書において“ＲＴＰ／ＩＰパケット”と称されうる。有利なことに、デバイス４０２の下部レイヤ４１０に関連する構成要素が待機状態にある間、パケットが生成されうる。

一般的なＷＬＡＮデバイスでは、ＷＬＡＮトランシーバは、ＶｏＩＰコール中、連続的に電源がオンされているか、あるいは、ＶｏＩＰパケットが生成されるときに依存して電源が繰り返しオン／オフされうる。前者の場合、ＷＬＡＮトランシーバは、ＷＬＡＮを介してパケットを送信または受信するために、常に準備ができた状態を保つ。後者の場合、ＷＬＡＮトランシーバは、与えられたパケットを送信するために電源がオンされ、次のパケットが生成されるまで電源がオフされる。さらに、ＷＬＡＮトランシーバは、ある間隔において電源がオンされ、その間隔において予期されているパケットを受信する。ここで、おのおののパケットの送信時間は、特定のＷＬＡＮバージョン（例えば、８０２．１１ａ／ｂ／ｇ）とネットワークにおける集中度に依存する。さらに、パケットが送信または受信される毎にＷＬＡＮトランシーバをオンまたはオフすることに関連する遅れ時間が存在する。

対照的に、本明細書で教示されるようなパケット・キューおよびグループ化を用いることによって、ＷＬＡＮトランシーバがオンされる時間の長さが短縮され、ＷＬＡＮトランシーバがオンおよびオフされる回数が低減される。具体的には、パケットをキューすること、および組み合わせることによって、パケット送信の間、および／またはパケット受信の間、より長期の待機状態（例えば、省電力モード）を用いることが可能になる。したがって、電力消費量を低減することは、それに対応して通話時間が延長されることとともに達成されうる。

図４に示すように、デバイス４０２は、１または複数の構成要素の状態を制御するための状態制御モジュール４１２を含んでいる。例えば、状態制御モジュール４１２は、構成要素を待機状態（例えば、省電力状態）４１４、または、アクティブ状態（例えば、ウェイク状態）４１６に設定することができる。いくつかのアプリケーションでは、待機状態は、与えられたモジュールの構成要素のうちの１または複数が、一時的にディセーブルまたはオフされることになる。しかしながら、ここで、モジュールの他の構成要素には未だに電力が供給されうる。例えば、状態情報を維持するために、待機状態中、モジュール内のデータ・メモリ（図示せず）の少なくとも一部に電力が供給される。状態制御モジュール４１２は、状態４１４および４１６のうちの１または複数に加えて、あるいはその代わりに、他の状態を利用することができることが認識されるべきである。

様々な構成要素が、状態制御モジュール４１２によって制御されうる。例えば、状態制御モジュール４１２は、デバイス４０２の下部レイヤ４１０における１または複数の構成要素を制御することができる。幾つかのアプリケーションでは、これは、１または複数の下部レイヤ制御モジュール（例えば、媒体アクセス・コントローラ４１８）、および／または、１または複数の物理レイヤ・モジュール（例えば、ラジオ４２０）の状態を制御することを含みうる。しかしながら、状態制御モジュール４１２は、デバイス４０２のその他の構成要素（例えば、上部レイヤ４０６に関連する１または複数の構成要素）を制御することができることが認識されるべきである。幾つかのアプリケーションでは、状態制御モジュール４１２は、デバイス４０２の異なる物理的な構成要素を独立して制御することができる。例えば、より下部レイヤ・モジュールのうちの１または複数は、個別の集積回路または回路カード上に実装されうる。この場合、状態制御モジュール４１２は、全ての構成要素（例えば、集積回路あるいは回路カード）の状態を制御することができる。

ブロック３０４および３０６に示されるように、ブロック３０２において生成されたパケットは、構成要素が待機状態にある間、パケット・キュー（例えば、データ・メモリ）内にキューされうる。例えば、パケットは、設定可能な時間長さにキューされうるか、あるいは、設定可能なパケット数が一度にキューされうる。前者の場合、デバイス４０２内のデータ・メモリ（図示せず）に格納された時間変数は、信号４２４によってタイマ４２６に提供されうる。後者の場合、データ・メモリに格納されたカウンタ変数が、信号４２４によってカウンタ４２６に提供されうる。

設定可能な変数の大きさは、与えられたアプリケーション（例えば、ＶｏＩＰ）について許容されているパケット遅延の量に依存して選択されうる。特に、システム性能における遅延の影響と、その遅延によって実現される省電力量との間でのトレードオフがなされうる。ここで遅延は、パケットが、デバイス４０２によって、アクセス・ポイント４０４および（例えば、インターネットのような広域ネットワーク４２８のような）ネットワークを介して、ＶｏＩＰコールが確立されるエンドポイント（図示せず）へと送信されるのに要する時間によって規定されうる。最大２００ｍｓの合計遅延が許容されているアプリケーションでは、６０ｍｓのオーダのキュー遅延が許容されうる。そのような場合、時間変数が６０ｍｓのオーダでありうるか、あるいは、カウント変数が３のオーダでありうる（ＶｏＩＰパケットが２０ｍｓ毎に生成される場合）。

デバイス４０２は、図１と連携して上述したパケット・キューワー１２２と類似した機能を提供する上部レイヤ制御モジュール４３０を含むことができる。図３のブロック３０８によって示されるように、制御モジュール４３０は、パケット・キュー４２２内のパケットをいつ下部レイヤ４１０（例えば、媒体アクセス・コントローラ４１８）の構成要素に利用可能（例えば、送ったり、あるいは、アクセスを提供する）にするかを決定するために、タイマ／カウンタ４２６の出力を用いることができる。

時間変数が６０ｍｓに設定され、パケットが２０ｍｓ毎に生成されるデバイス４０２では、平均して３つのパケットが、設定可能な時間期間毎にパケット・キュー４２２内にキューされるだろう。この場合、設定可能な時間期間が経過するごとに、制御モジュール４３０は、下部レイヤに配信するために、平均して３つのパケットを提供するだろう。有利なことに、制御モジュール４３０は、これらのパケットを、下部レイヤ４１０に対して連続的（例えば、おのおののパケットにアクセスする間の遅延が、パケット間期間２０ｍｓよりも有意に小さい）に利用可能にすることができる。言い換えれば、アップリンク・パケットは、下部レイヤ４１０に送られる場合に、グループ化（バンドル）される。

下部レイヤ４１０によって実行されうる幾つかの動作について、図６を用いて説明する。ブロック６０２によって示されるように、アップリンク・パケットを処理するために、状態制御モジュール４１２は、下部レイヤ構成要素をアクティブ状態（例えば、ウェイク状態）に遷移させる。上述したように、送信構成要素および受信構成要素は、独立して、アクティブ状態と待機状態との間を遷移する。したがって、この動作は、送信構成要素および／または受信構成要素の電源をオンにすることを含むことができる。ここで、下部レイヤ４１０の構成要素は、例えば、現在の無線性能に依存して、適切な時間において、上部レイヤからパケットを検索することによって、アップリンク・パケットの集合を取得することができる。

ブロック６０４および６０６によって示されるように、下部レイヤ構成要素（例えば、ＭＡＣ構成要素およびラジオ構成要素）は、アクセス・ポイント４０４との確立された通信に対するチャネルを獲得することができる。例えば、８０２．１１ｅをサポートするＷＬＡＮでは、デバイス４０２は、ある期間にわたってチャネルの制御を取得するために８０２．１１ｅ ＴＸＯＰを発行することができる。

チャネルに対するアクセスが取得されると、デバイス４０２は、ブロック６０８、６１０、および６１２によって示されるように、キューされたアップリンク・パケットをアクセス・ポイント４０４へ連続して送るだろう。言い換えれば、アクセス・ポイント４０４へ送られる場合、アップリンク・パケットはグループ化（バンドル化）されうる。ブロック６０８によって示されるように、この処理は、おのおののパケットを単一の物理レイヤ送信で（例えば、８０２．１１規格にしたがった単一フレーム内で）送ることを含む。その後、この処理は、送信されたおのおののフレームについて、アクセス・ポイント４０４からのアクノレッジメント（“ＡＣＫ”）が受信されたことを確認することができる（ブロック６１０）。ここで、パケットの全てが配信されるまで、あるいは、最大ＴＸＯＰ間隔が経過するまで、おのおのの送信は、ネットワーク・アロケーション・ベクトル（“ＮＡＶ”）を拡張することができる。

送信されたフレームの最後を除く全てをもって、デバイス４０２は、アクセス・ポイント４０４に対して、現在のアップリンク・パケットに続いて少なくとももう１つのアップリンク・パケットが送られることを通知することができる。例えば、デバイス４０２は、フレーム内のヘッダによって、適切な表示（例えば、“ｍｏｒｅ ｐａｃｋｅｔ”フラグ）をアクセス・ポイント４０４へ送ることができる。

同じアクティブ状態中、デバイス４０２はまた、受信構成要素が待機状態に設定されるアプリケーションにおいて、アクセス・ポイント４０４にキューされた任意のダウンリンク・パケット４３２をダウンロードすることができる。例えば、ブロック６１４に示されるようなアプリケーションでは、８０２．１１ｅをサポートするＷＬＡＮにおいて、デバイス４０２は、ある時間期間にわたってチャネルの制御を獲得するためにＴＸＯＰを発行することができる。有利なことに、ＴＸＯＰは、ビーコン内のトラフィック表示マップ（“ＴＩＭ”）が、未決定のトラフィックが存在することを示しているかを判定するために、アクセス・ポイント４０４からビーコンを受信するために待機することよりも比較的迅速にチャネルの制御を取得するために使用されうる。例えば、６０ｍｓである待機間隔が、ビーコン間隔よりも有意に短いのであれば、この場合、より優れた性能が達成されうる。あるいは、デバイス４０２は、アクセス・ポイント４０４からパケットを受信するために、省電力ポール（“ＰＳ Ｐｏｌｌ”）メカニズム、または、アンスケジュール自動省電力配信（“ＵＡＰＳＤ”）メカニズムを起動することができる。

ブロック６１６乃至６２２によって示されるように、アクセス・ポイント４０４は、キューされたパケットを、チャネルを介して連続的にデバイス４０２へ送る。したがって、ダウンリンク・パケットは、デバイス４０２へ送られる場合、グループ化（バンドル）される。この処理は、例えば、おのおののパケットを単一のフレーム内で送信すること（ブロック６１６）と、送信されたおのおののフレームについて、デバイス４０２からのアクノレッジメントが受信されたことを確認することとを含みうる。

ブロック６１８およびブロック６２０に示されるように、幾つかの局面では、トランシーバが待機状態にある時間期間の長さを調節するために、プロビジョンがなされうる。例えば、デバイス４０２は、ＴＸＯＰにおいて、固定間隔で、アクセス・ポイント４０４において予期されるバッファ時間期間よりも短いためにアクセス・ポイント４０４がパケットを落とすことによって引き起こされる比較的安定したフレーム喪失に遭遇しうる。例えば、デバイス４０２は、６０ｍｓ間隔でバンドルするように設定され、アクセス・ポイント４０４は、４０ｍｓ間隔でバンドルするように設定される。この場合、アクセス・ポイント４０４は、４０ｍｓよりも遅延の大きい全てのフレームを破棄する。したがって、デバイス４０２は、３フレーム毎に失われたフレームを受信することができる。例として、アクセス・ポイント４０４は、ダウンリンク・フレーム１、２、３、４、５、６、７、８、９・・・を受信するが、ダウンリンク・フレーム２、３、５、６、８、９・・・のみを転送することができる。そのような失われたフレームをデバイス４０２が検出するイベント（ブロック６１８）では、デバイス４０２は、アクセス・ポイント４０４のバンドル間隔に一致させるために、そのバンドル間隔（例えば、スリープ間隔）を調節することができる。上述した状況の場合、デバイス４０２は、バンドル間隔を４０ｍｓに調節することができる。これは、例えば、ブロック３０４およびブロック３０６と連携して上述した時間／カウント信号４２４を調節することを含みうる。

送信されたフレームの最後を除く全てをもって、アクセス・ポイント４０４は、デバイス４０２に対して、現在のダウンリンク・パケットに続いて少なくとももう１つのダウンリンク・パケットが送られることを通知することができる。例えば、アクセス・ポイント４０４は、フレーム内のヘッダによって、適切な表示（例えば、“ｍｏｒｅ ｄａｔａ”フラグ）をデバイス４０２へ送ることができる。したがって、ＴＸＯＰは、“ｍｏｒｅ ｄａｔａ”フラグが設定されている限り、ダウンリンク・パケットのダウンロードを続けるように維持されうる。

ダウンリンク・パケットの全てが受信された後、デバイス４０２はチャネルをリリースする（ブロック６２４）。この時点において、状態制御モジュール４１２は、下部レベル構成要素を待機状態に戻すことができる（ブロック６２６）。その後、パケットをグループで送信および受信することを繰り返すために、必要に応じて、上述した動作が繰り返される。

対称パケット・フロー（例えば、ＶｏＩＰ）をサポートするアプリケーションのために、平均して同等数のアップリンク・パケットおよびダウンリンク・パケットが、与えられたアクティブ状態の間、ダウンロードされうることが認識されるべきである。例えば、ＶｏＩＰコーデックと、エンドポイント（図示せず）における関連する上部レイヤ構成要素とは、ＶｏＩＰコーデック４０８およびその関連する上部レイヤ構成要素と同じレートでダウンリンクＶｏＩＰパケットを生成することができる。したがって、ＶｏＩＰコーデック４０８から、与えられた数のアップリンク・パケットが（例えば、６０ｍｓ）キューされると、エンドポイントから発行された同等数のダウンリンク・パケットが、アクセス・ポイント４０４においてキューされうる。したがって、１つの局面では、本開示は、アップリンク動作およびダウンリンク動作に対して対称的な挙動を提供する。さらに、この対称的な挙動は、高次レイヤの実施に対して悪影響（例えば、変化）を与えずに達成されうる。

図５に示すように、本開示のこの局面では、デバイス５０２の上部レイヤ５０６のうちの１または複数の構成要素が、アップリンク・パケットを生成する。そして、ＲＴＰバンドリングを用いて、単一のＲＴＰ／ＩＰパケット内にアップリンク・パケットのセットをグループ化する。ここで、デバイス５０２のアプリケーションと、ネットワーク５３２（例えば、インターネット）に接続されたエンドポイント（図示せず）の別のアプリケーションとの間の通信（例えば、コール）が確立された場合、これらアプリケーションはネゴシエートして、パケットを交換するためのＲＴＰバンドリング・スキームを用いることができる。例えば、ＲＴＰバンドリングと、おのおののＩＰパケットにバンドルされるＲＴＰパケットの数とを用いることが、例えばセッション記述プロトコルを用いてセッション開始プロトコル（“ＳＩＰ”）によって指定されうる。

図５の構成要素の幾つかは、図４に関連して上述された構成要素と類似している。したがって、その類似した機能の多くの局面は、以下では繰り返さない。図５のシステム５００の典型的な上部レイヤ動作および下部レイヤ動作の記述が、それぞれ図３および図７と連携して説明される。

図３におけるブロック３０２および図５に示されるように、ＶｏＩＰコーデック５０８は、図４と連携して上述したように、データのストリーム（例えば、ＶｏＩＰデータ）を生成することができる。くわえて、上部レイヤ５０６の構成要素は、ＲＴＰを、その後、ＵＤＰを用いてデータをラップし、１０ｍｓまたは２０ｍｓ毎のオーダでパケットを生成する。この場合、生成されたパケットは、ＶｏＩＰデータおよび関連するＲＴＰ／ＵＤＰヘッダ情報を含むことができる。

図４と連携して上述したものと同じ方式で、これらのパケットは、デバイス５０２のうちの１または複数の構成要素が待機状態にある場合に生成されうる。したがって、デバイス５０２は、デバイス５０２のうちの１または複数の構成要素の状態を制御する状態制御モジュール５１０を含むことができる。例えば、状態制御モジュール５１０は、デバイス５０２の下部レイヤ５１２の構成要素を、待機状態５１４とアクティブ状態５１６との間で遷移させることができる。そのような下部レイヤ構成要素は、１または複数の下部レイヤ制御構成要素（例えば、媒体アクセス・コントローラ５１８）、および／または、物理レイヤ構成要素（例えば、ラジオ５２０）を含むことができる。

ブロック３０４およびブロック３０６によって示されるように、ブロック３０２において生成されたパケットは、デバイス５０２の構成要素のうちの１または複数が待機状態にある間、パケット・キュー５２２（例えば、データ・メモリ）内にキューされる。ある基準に達するまで、パケットはキューされうる。上述したように、この基準は、例えば、設定可能な時間長さ、設定可能なパケット数、または、その他幾つかの適切なパラメータのような設定可能な変数に基づきうる。繰り返すが、設定可能な変数は、信号５２４によって、基準に達したときを判定するために使用されるタイマ／カウンタ５２６に提供されうる。

ブロック３０８によって示されるように、（例えば、タイマ／カウンタ５２６の出力によって示されるように）一旦基準に達すると、キューされたパケットが、さらなる処理のために下部レイヤ構成要素に提供される。この動作は、図７におけるブロック７０２およびブロック７０４によってさらに示される。

ブロック７０２によって示されるように、キューされたパケットはまず、ＩＰ構成要素に提供される。例えば、デバイス５０２内のＲＴＰ／ＩＰパケット・アセンブラ５２８は、キューされたＲＴＰパケットを、ＩＰパケットにラップする。すなわち、いくつかのＲＴＰパケットが、単一のＩＰパケットにグループ化（バンドル）される。

ここで、ＲＴＰ／ＩＰパケットのサイズが、最大送信ユニット・サイズよりも小さいことを保証するためにプロビジョンがなされる。例えば、ＲＴＰ／ＩＰパケットのサイズは、Request to Send/Clear to Send（“ＲＴＳ／ＣＴＳ”）しきい値、およびフラグメンテーションしきい値よりも小さい。ここで、パケットを送るために、あるいは、複数のフレームでパケットを送るまでパケットを分割するために、下部レイヤに対して、ＲＴＳ／ＣＴＳを起動させるＲＴＰ／ＩＰパケットの生成を回避することが望ましい。したがって、必要ならば、キューされたＲＴＰパケットのうちの１または複数が、現在のＲＴＰ／ＩＰパケットではなく、次のＲＴＰ／ＩＰパケットにカプセル化されうる。

ブロック７０４によって示されるように、このＲＴＰ／ＩＰパケットは、デバイス５０２の下部レイヤ５１２の構成要素に送られる。例えば、ＲＴＰ／ＩＰパケットは、媒体アクセス・コントローラ５１８に送られうる。

ブロック７０６によって示されているように、アップリンク・パケットを処理するために、状態制御モジュール５１０は、下部レイヤ構成要素をアクティブ状態に遷移させうる。くわえて、下部レイヤ構成要素は、アクセス・ポイント５０４との通信を確立するためにチャネルを獲得する。繰り返すが、ある時間期間にわたって、チャネルの制御を取得するために、例えばＴＸＯＰのようなメカニズム、あるいはその他幾つかの適切なメカニズムが適用されうる。

ブロック７０８によって示されるように、デバイス５０２は、チャネルを経由してアクセス・ポイント５０４へとＲＴＰ／ＩＰパケットを送信する。ここで、アップリンク・パケットは、ＲＴＰ／ＩＰパケット内のグループとして送信されることが認識されるべきである。その後、デバイス５０２は、ＲＴＰ／ＩＰパケットが、アクセス・ポイント５０４によって正しく受信されたことを確認することができる（ブロック７１０）。

同じアクティブ状態中、デバイス５０２はまた、アクセス・ポイント５０４内にキューされた任意のダウンリンク・パケット５３０をダウンロードすることもできる（ブロック７１２）。上述したように、ダウンリンク・パケット５３０は、ＲＴＰバンドリングを用いるＲＴＰ／ＩＰパケットによって提供されうる。したがって、ダウンリンク・パケットは、デバイス５０２へ送られる場合にグループ化（バンドル）されうる。

ダウンリンク・パケットを含むＲＴＰ／ＩＰパケットのうちの全てが受信された後、デバイス５０２は、チャネルをリリースし、状態制御モジュール５１０が、下部レイヤ構成要素を、待機状態に戻す（ブロック７１４）。上記動作は、パケットをグループで繰り返し送信および受信するために、必要に応じて繰り返される。

比較的対称なパケット・フローを提供するアプリケーションのために、平均して同等数のアップリンク・パケットおよびダウンリンク・パケットが、与えられたアクティブ状態の間、ダウンロードされうることが認識されるべきである。上述したように、これは、同等の時間長さの間に引き続きキューされるパケット内のおのおののエンドポイントによって、同じレートで生成されるパケットからの結果である。

別の局面では、上述したように、設定可能な変数（例えば、６０ｍｓ毎）にしたがって静的にパケットをグループ化するのではなく、前に送信されたパケットが正しく受信されたかを考慮する動的なアプローチが使用されうる。例えば、パケットが正しく受信されない（例えば、ＭＡＣレイヤにおいてフレーム喪失がある）イベントでは、処理は、オリジナルのパケット・バンドルを再送信するか、あるいは、修正されたパケット・バンドルを送信する。後者の場合、古すぎるパケット・バンドル内のパケットが破棄され、より新しいパケットと交換されうる。これらの局面は、図８およびブロック７１０、７１６−７２４と連携されてより詳細に記述される。

図８は、上部レイヤ８０２と、下部レイヤ８０４と、アクセス・ポイント８０６との間の相対的なタイミングを、簡略した方式で例示している。概念的に、ブロック８０２、８０４、および８０６はそれぞれ、図５における上部レイヤ５０６、下部レイヤ５１２、およびアクセス・ポイント５０４に対応している。

アップリンク・パケット（Ｐ１、Ｐ２、Ｐ３等）を表す上部レイヤ８０２のブロックは、規則的な時間間隔（例えば、Ｔ１、Ｔ２、Ｔ３等）で生成される。ライン８０８は、パケットＰ１、Ｐ２、およびＰ３が生成された後のある時点において、パケットＰ１、Ｐ２、およびＰ３がグループとして下部レイヤ８０４に送られることを示す。例えば、上述したように、パケットＰ１、Ｐ２、およびＰ３は、単一のＩＰパケット内にカプセル化されうる。ブロック８１０およびライン８１２によって示されるように、パケットＰ１、Ｐ２、およびＰ３は、グループとして（ＩＰパケットによって）アクセス・ポイント８０６へ送信される。ブロック８１４およびライン８１６は、アクセス・ポイント８０６が、パケットＰ１、Ｐ２、およびＰ３の受信のアクノレッジメント（例えば、ＭＡＣレイヤＡＣＫ）を、下部レイヤ８０４に送ることを示す。くわえて、ライン８１８は、アクノレッジメント（またはその他幾つかの関連するまたは適切な表示）が上部レイヤ８０２に転送されることを示す。したがって、上部レイヤ８０２は、アップリンク・パケットＰ１、Ｐ２、またはＰ３が、アクセス・ポイント８０６によって正しく受信されたかどうかに関する表示を受信する。

ライン８２０およびブロック８２２は、３つのアップリンク・パケットＰ４、Ｐ５およびＰ６の後の送信を示す。しかしながら、この場合、アップリンク・パケットＰ４、Ｐ５、およびＰ６は、アクセス・ポイント８０６によって受信されない。したがって、アクセス・ポイント８０６は、（ブロック８２４によって示されるように）アクノレッジメントを送信しない。

図７に再び示すように、ブロック７１２において、アクノレッジメントが受信されないイベントでは、上部レイヤ８０２が、（例えば、Ｐ４、Ｐ５、およびＰ６を含む）オリジナルのパケットを未だに再送信できるか否かを判定することができる。ここで、特定のアプリケーションの最大遅延境界をクロスする前に、これらパケットのうちの何れかが、宛先エンドポイントに到着しないだろうと判定された場合（ブロック７１６）、上部パケットＰ４、Ｐ５、およびＰ６の全てを再送信できる訳ではない。例として、パケットが生成される時間と、パケットが宛先エンドポイントにおいて受信される時間との間の最大許容遅延は、２００ｍｓのオーダにある。ユーザ機器の外部にあるネットワークにおける遅延を考慮すると、例えば、待機期間（例えば、６０ｍｓ）よりも古い場合、パケットは、古すぎると見なされうる。

したがって、与えられたＲＴＰ／ＩＰパケットを運ぶフレームについて、アクセス・ポイント８０６から（例えば、データ・リンク・レイヤまたは物理レイヤに関連する）アクノレッジメントを受信していないと上部レイヤ８０２が判定するイベントでは、上部レイヤ８０２は、ＲＴＰパケット（例えば、パケットＰ４）のうちの１または複数が、６０ｍｓよりも古いか否かを判定することができる。このように、上部レイヤ８０２は、再送信時に、パケットが最初に生成されてから２００ｍｓ以上経過する後まで、パケット（例えば、パケットＰ４）のうちの１または複数が宛先エンドポイントに達しないであろうか否かを判定することができる。

ブロック７１８によって示されるように、最大遅延境界をクロスしないイベントにおいて、オリジナルのＲＴＰが再送信されうる。これは例えば、オリジナルのＲＴＰパケット、および、オプションとして新たなＲＴＰパケットを含むＲＴＰ／ＩＰパケットを生成することを含むことができる。ここで、新たな任意のパケット（例えば、Ｐ７）が、キュー内で交換されるイベントにおいて、新たなパケットが、オリジナルのパケットとともに含まれる。しかしながら、新たなＲＴＰパケットを加えることが、ＲＴＰ／ＩＰパケットのサイズを、ＲＴＳ／ＣＴＳしきい値およびフラグメントしきい値を超えさせないことを保証するためにプロビジョンがなされる。言い換えれば、新たなパケットが次のＲＴＰ／ＩＰパケットで送信され、ＲＴＳ／ＣＴＳを経由して送られるか、あるいは、分割されて複数のフレームを経由して送られるパケットを生成することが回避される。ブロック７０８によって示されているように、下部レイヤ８０４がパケットをアクセス・ポイント８０６に送信できるように、上部レイヤ８０２は、その後、ＲＴＰ／ＩＰパケットを下部レイヤ８０４に送るだろう。

最大遅延境界がクロスされるか、あるいはクロスしたイベントでは、上部レイヤ８０２が、古いＲＴＰパケットを破棄し（ブロック７２０）、もしも新たなＲＴＰパケットがキュー内に存在するのであれば、新たな交換ＲＴＰパケットをセットに加える（ブロック７２２）。ここで、新たな交換ＲＴＰ／ＩＰパケットのサイズは、ＲＴＳ／ＣＴＳしきい値およびフラグメントしきい値よりも小さいサイズに制限されうる。繰り返すが、ＲＴＳ／ＣＴＳを経由して送られるか、あるいは、複数のフレームを経由して送信するために分割されうる新たなパケットの生成を回避することが望ましい。

上記動作の一例は、ライン８２６およびブロック８２８によって図８で示されている。これらの表示は、上部レイヤ８０２が、パケットＰ４を破棄し、続いて下部レイヤ８０４へと送られるパケットＰ５、Ｐ６、およびＰ７を含む新たなパケット・セットを生成したことを例示する。ライン８３０およびブロック７０８（図７）によって示されているように、下部レイヤ８０４は、新たなＲＴＰ／ＩＰパケットをアクセス・ポイント８０６へ送信する。

図８はさらに、新たなＲＴＰ／ＩＰパケット８２８がアクノレッジされる（ブロック８３２）と、パケットのバンドル化が、オリジナルの時間間隔（例えば、時間Ｔ３の直後に終了する６０ｍｓ時間間隔）と一致しない時間においてパケット８２８の送信によって調節されたタイミングで続くことを例示している。例えば、新たなパケット８２８は、時間Ｔ７の直後（Ｐ４、Ｐ５、およびＰ６を含むパケットが送られた後約２０ｍｓ）に送られうるしたがって、いつパケットを送信すべきかを決定するために使用される任意のカウンタのカウントまたは任意のタイマのタイミングが、それに従って調節されうる。

上記を考慮して、本明細書に記載の技術を用いて、多くの利点が達成されうることが認識されるべきである。パケットを組み合わせることによって、１０ｍｓまたは２０ｍｓ毎にウェイク・アップし、送信を完了するためにアクティブ状態に残ることと比べて、（例えば、省電力モードにおける時間である）スリープ期間をより長くすることが可能となる。例えば、いくつかの局面では、トランシーバは、６０ｍｓの遅延期間のうちの５−１０ｍｓのオーダでのみアクティブでありうる（例えば、ウェイク状態である）。パケットの送信および／または受信のためにさほど「ウェイク」しないことによって、アクティブ状態と待機状態との間の遷移（例えば、トラシーバをオンおよびオフすること）の数が低減されるだろう。したがって、トランシーバをオンおよびオフすることに関連する遅延時間を回避することによって省電力が達成されうる。ここで、遅延時間のうちのいくつかに関連する電力消費が節約されるので、トランシーバは、少ない電力しか使用しない。くわえて、全てのパケットの送信を完了するために、“ｍｏｒｅ ｐａｃｋｅｔ”フラグ、および単一のチャネル取得を用いることによって、ユーザ機器は、待機状態により長い期間とどまることが可能となり、もって、さらに電力を節約することができる。

さらに、パケットを送信するためにウェイクした後、アクセス・ポイントからのパケットを要求することによって、到来するパケットのためのアクセス・ポイントをポーリングするための決定論的方法が提供される。ここでは、比較的対称なトラフィック（例えば、ＶｏＩＰ）を用いるアプリケーションでは、アップリンク・パケットがキューされている間、前の待機時間の結果として、幾つかのダウンリンク・パケットがアクセス・ポイント内にキューされることがかなり保証される。くわえて、アクセス・ポイントによって送信されたフレーム内の“ｍｏｒｅ ｄａｔａ”フィールドを使用することによって、次のポーリング要求がアナウンスされる。したがって、ダウンリンク・パケットを取得するための最良の時間を決定することを試みる従来の手段を実行する必要は必ずしもない。

上述したように、本明細書における教示は、様々なプロトコル、ユーザ機器デバイス、および関連するネットワーク構成要素に適用可能である。したがって、ユーザ機器は、例えばＷｉ−Ｆｉ、ＷｉＭＡＸ、あるいは、パケット交換トラフィックを伝送するのに適したその他任意の有線プラットフォームまたは無線プラットフォームのような様々な無線プラットフォームを経由してネットワークへの接続を得るための様々な構成要素を組み込むことができる。くわえて、ＶｏＩＰ以外の様々なタイプのパケット・トラフィックも、上記の方法で取り扱うことができる。さらに、様々な技術は、パケットをキューし、グループ化するために使用することができる。さらに、複数の状態（例えば、電力低減状態）および本明細書で具体的に述べられたもの以外の状態を提供するために他の技術を用いることができる。本明細書に具体的に述べられたもの以外の構成要素の状態は、電力を低減するように制御されうる。所望の機能を提供するために、異なる上部レイヤ・プロトコルおよび下部レイヤ・プロトコルさらにはプロトコル動作を使用することができる。

いくつかの実施形態では、本明細書における教示を、複数の通信プロトコルをサポートするユーザ機器デバイスに組み込むことができる。例えばモバイル・デバイスは、従来のセルラ通信のみならず、例えば、電子メール、インターネット・アクセスを提供する多機能デバイスとして実施することができる。そのようなデバイスは、例えば、第三世代無線システムまたはセルラ・システム（３Ｇ）技術、ＷｉＭＡＸ（例えば、８０２．１６）技術、およびその他の無線広域ネットワーク（ＷＷＡＭ）技術を利用する広域無線接続を備えることができる。くわえて、上述したように、デバイスは、ＩＥＥＥ ８０２．１１ベースの無線ローカル・エリア・ネットワーク（ＷＬＡＮ）接続を組み込むことができる。さらには、デバイスは、超広帯域（ＵＷＢ）および／またはＢｌｕｅｔｏｏｔｈ（登録商標）ベースの無線パーソナル・エリア・ネットワーク（ＷＰＡＮ）ローカル接続を組み込むことができる。

一般に、ＷＷＡＮ技術は、広域（ユビキタス）カバレッジおよび広域展開によって識別される。しかしながら、それらは、ビルディング貫通ロス、カバレッジ・ホール、および、ＷＬＡＮとＷＰＡＮに対して比較的限定された帯域幅を被る。ＷＬＡＮ技術およびＷＰＡＮ技術は、何百Ｍｐｂｓにもおよぶ非常に高いデータ・レートで配信するが、カバレッジは、一般に、ＷＬＡＮの場合は数１００フィート、ＷＰＡＮの場合は数１０フィートに限定される。

ユーザおよびアプリケーションの様々な要求を満足する適切な機能を提供するための試みにおいて、様々なネットワークおよびプロトコルが規定されている。そのような異種のネットワークおよびプロトコルは、ユーザが切り換えるのは面倒であり、多くの場合、ユーザは、与えられた時間においてどれが最適なネットワークであるか考慮することなく、ネットワーク内に捕らわれている。したがって、いくつかの局面では、ユーザ機器は、ユーザにとって最良の通信プロトコルに関する最適化および集中化のためのネットワークおよび／またはプロトコル間での、シームレスな遷移を提供するように適応されている。

再び図１に示すように、システム１００は、有線ローカル・エリア・ネットワーク（ＬＡＮ）に関連するＷＬＡＮを組み込むことができる。この場合、ネットワーク・インタフェース１１２は、ＷＬＡＮ接続をサポートするように構成されたユーザ機器１０２および１０４（例えば、８０２．１１モバイル局）と通信することができるアクセス・ポイントを備えることができる。アクセス・ポイントは、有線インタフェース１１４を経由して、有線ＬＡＮ（図示せず）のためのスイッチまたはイーサネット（登録商標）ハブに接続することができる。イーサネット・ハブはまた、パーソナル・コンピュータ、周辺機器（例えば、ファクシミリ装置、コピア、プリンタ、スキャナ等）、サーバ等を含みうる１または複数の電子デバイス（図示せず）に接続されうる。イーサネット・ハブはまた、モデム（図示せず）にデータ・パケットを送信するルータに接続されうる。モデムは、例えばインターネットのような広域ネットワーク（ＷＡＮ）にデータ・パケットを送信することができる。システム１００は、単一の、比較的単純なネットワーク構成を示している。しかしながら、代替ユーザ機器を含むシステム１００の多くの追加構成が可能であることが認識されるべきである。このシステム１００が、ＬＡＮに関して例示および説明されているが、システム１００が、別々または同時の何れかによって、ＷＷＡＮおよび／またはＷＰＡＮを含むその他の技術を利用することもできる。

システム１００は、モバイル・デバイス（例えば、ユーザ機器１０２）が、モバイル・デバイスによって現在利用されているアクセス・ポイントと、システム１００に関連するアクセス・ポイント１１２とをシームレスに切り換えることをイネーブルすることができる。アクセス・ポイント１１２へ、および、アクセス・ポイント１１２によってサポートされるネットワークへの転送は、モバイル・デバイスのユーザに、重要な機能を提供するために、望ましいことである。したがって、そのような転送は、モバイル・デバイスの位置の関数であるか、および／または、ユーザがアクセスを望むかモバイル・デバイスにアップロードすることを望むデータでありうる。限定ではなく一例として、モバイル・デバイスは、電子デバイスを介して利用することができるＷＷＡＮ機能および／またはＷＬＡＮ機能を利用するために、イーサネット（登録商標）ハブに接続された電子デバイスのうちの１または複数に結合されうる。そのような遷移は、ユーザによって起動されるか、あるいは、システム１００によって自動的に実行されうる。

図９に示すように、複数の通信プロトコルをサポートするユーザ機器デバイス９００（例えば、モバイル・デバイス）の様々な局面が、より詳細に説明されよう。モバイル局とも呼ばれるデバイス９００は、幾つかの局面において、例えば符号分割多元接続（“ＣＤＭＡ”）、および／または、例えば広帯域符号分割多元接続（“ＷＣＤＭＡ”）のような３Ｇ技術であるＷＷＡＮをサポートする。デバイス９００はまた、ＷＬＡＮ（例えば、ＩＥＥＥ ８０２．１１）技術および／またはその他の適切な技術をサポートすることができる。

いくつかの局面では、デバイス９００は、アプリケーション、セルラ・モジュール９０２、および無線ネットワーク・モジュール９０４を組み込むことができる。このモジュール９０２は、例えば、ユーザ・アプリケーション構成要素およびユーザ・インタフェース構成要素を組み込むことができる。くわえて、このモジュール９０２は、例えばＣＤＭＡ、ＧＳＭ、３Ｇ、あるいはその他の幾つかの技術のようなセルラ・タイプ技術によって通信をサポートすることができる。このモジュール９０２は、対応する広域無線ネットワークとの間で情報を送信および受信する１または複数のアンテナ９１０に結合されたトランシーバ９０６とインタフェースすることができる。このモジュール９０２はまた、無線ネットワーク・モジュール９０４と通信するインタフェース９０８を含むことができる。インタフェース９０８は例えば、Secure Digital Input Output（“ＳＤＩＯ”）インタフェースまたはその他幾つかの適切なインタフェースを備えることができる。

本明細書で説明するように、無線ネットワーク・モジュール９０４は、例えばパケット交換ネットワークのようなネットワークを介した通信をサポートすることができる。そのようなネットワークは、例えば、Ｗｉ−Ｆｉ、ＷｉＭＡＸ、あるいはその他任意の適切な技術をサポートすることができる。ネットワーク・モジュール９０４は、適切なトランシーバを組み込み、かつ、１または複数アンテナ９１２と結合されうる。あるいは、トランシーバ９０６は、モジュール９０２とモジュール９０６によって共有されることを可能にする十分な機能を組み込むことができる。

図９に示す構成では、モジュール９０２は、本明細書で説明するようなモジュール９０４のための上部レイヤ動作を提供することができる。例えば、パケットを生成するアプリケーション、および、関連するパケット・キューイング構成要素が、モジュール９０２内に組み込まれうる。この場合、モジュール９０４の全体（例えば、ＭＡＣ構成要素およびＰＨＹ構成要素を組み込んだＷＬＡＮモジュール）が、待機状態とされ、本明細書で説明したように、電力を節約する。したがって、モジュール９０４が待機状態にある場合、モジュール９０２は、必要に応じて、パケット生成およびキューを実行するために、アクティブ状態であり続ける。

いくつかの局面では、ユーザ機器は、ＶｏＩＰ電話機能を提供することができる。一般に、ＶｏＩＰは、インターネットおよび／またはＩＰネットワークを介した音声電話会話の送信を含む。上述したように、幾つかの局面では、ＶｏＩＰ接続が、ＷＬＡＮ構成要素を介して提供される。したがって、ユーザは、ＶｏＩＰサービスを提供するブロードバンド・ネットワークに接続された無線アクセス・ポイントの近傍にいる場合、デバイス９００のＶｏＩＰ機能を利用することができる。他の状況では、デバイス９００は、通信サービスを提供しながら、規則的な無線モバイル電話として機能することができる。

デバイス９００は、デバイス９００の機能に関連する１または複数の基準に基づいて、ＷＷＡＮまたはＷＬＡＮのうちの何れかに接続しているか、あるいはそれら両方に同時に接続している。さらに、プロトコルおよび／またはネットワークのおのおのの間を切り換えるための基準および処理もまた提供される。この基準は、デバイス９００のデータ・メモリに格納され、プロセッサは、格納された基準に基づいてネットワークを分析することができる。

本明細書の教示に基づいて、ユーザ機器は、様々な方法で実施されうることが認識されるべきである。例えば、いくつかの実施においては、ＷＷＡＮ機能構成要素および／またはＷＬＡＮ機能構成要素は、デバイス９００のプロセッサに含まれうる。いくつかの実施においては、ＷＷＡＮ機能およびＷＬＡＮ機能は、別個の集積回路によって提供されうる。他の実施においては、ＷＷＡＮ機能およびＷＬＡＮ機能は、１または複数の集積回路、プロセッサ、ＡＳＩＣ、ＦＰＧＡ、こられの組み合せ、あるいは、適切な機能を含む同等のものによって提供されうる。サービスおよびユーザ経験の豊富な組合せを可能にするために、デバイス９００は、広域（ＷＷＡＮ）およびローカル・エリア（ＷＬＡＮおよびＷＰＡＮ）のための接続オプションを備えている。

同様に、図１の構成要素、および、本明細書に記載のその他の関連する構成要素は、様々な方法で実現されうる。例えば、図１０に示すように、ユーザ機器１０００は、図１のユーザ機器１０２の構成要素１０８、１２２、１２４、１１０および１２０に対応する構成要素１００２、１００４、１００６、１００８および１０１０を含む。図１０は、いくつかの局面では、これら構成要素が、適切なプロセッサ構成要素によって実現されうることを例示している。これらプロセッサ構成要素は、幾つかの局面において、少なくとも部分的に、本明細書で教示したような構成を用いて実現されうる。

くわえて、図１０によって示される構成要素および機能は、本明細書に記載のその他の構成要素および機能と同様、任意の適切な手段を用いて実現されうる。そのような手段はまた、本明細書で教示された対応する構成を少なくとも部分的に用いて実現されうる。例えば、いくつかの局面では、送信する手段は送信機を備え、パケットをキューする手段はパケット・キューワーを備え、トランシーバを待機状態からウェイク状態へ切り換える手段は、状態コントローラを備え、パケットを受信する手段は、トランシーバを備え、キューされたパケットを集める手段は、パケット・キューワーを備えうる。また、そのような手段のうちの１または複数は、図１０のプロセッサ構成要素のうちの１または複数に従って実現されうる。

当業者であれば、これら情報および信号が、種々異なった技術や技法を用いて表されることを理解するであろう。例えば、上述した記載の全体で引用されているデータ、命令群、コマンド、情報、信号、ビット、シンボル、およびチップは、電圧、電流、電磁波、磁場または磁性粒子、光学場または光学微粒子、あるいはこれら何れかの組み合わせによって表現されうる。

当業者であれば、さらに、本明細書で開示された局面に関連して記載された様々な例示的な論理ブロック、モジュール、プロセッサ、手段、回路、およびアルゴリズム・ステップが、電子工学ハードウェア、様々な形態のプログラムまたは設計コード（本明細書では、便宜上、“ソフトウェア”と称する）、あるいはこれらの組み合わせとして実現されることを理解するであろう。ハードウェアとソフトウェアとの相互置換性を明確に説明するために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、それらの機能に関して一般的に記述された。それら機能がハードウェアとしてまたはソフトウェアとして実現されるかは、特定のアプリケーション及びシステム全体に課せられている設計制約に依存する。当業者であれば、各特定のアプリケーションに応じて変化する方法で上述した機能を実現することができる。しかしながら、この適用判断は、本開示の範囲からの逸脱をもたらすものと解釈されるべきではない。

本明細書で開示された実施形態に関連して記述された様々な例示的な論理ブロック、モジュール、および回路は、汎用プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）あるいはその他のプログラマブル論理デバイス、ディスクリート・ゲートあるいはトランジスタ・ロジック、ディスクリート・ハードウェア部品、または上述された機能を実現するために設計された上記何れかの組み合わせを用いて実現または実施されうる。

汎用プロセッサとしてマイクロプロセッサを用いることが可能であるが、代わりに、従来技術によるプロセッサ、コントローラ、マイクロコントローラ、あるいは状態機器を用いることも可能である。プロセッサは、例えばＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアに接続された１または複数のマイクロプロセッサ、またはその他任意のこのような構成である計算デバイスの組み合わせとして実現することも可能である。

開示された処理におけるステップの具体的なステップの階層または順序は、典型的なアプローチの例であることが理解される。設計の好みに基づいて、処理におけるステップの具体的な階層または順序は、本開示の範囲内に維持されたまま再アレンジされうることが理解される。方法請求項は、一例である順序で様々なステップの要素を表しており、ここに示す具体的な階層または順序に限定されることは意味されてない。

本明細書で開示された実施形態に関連して記述された方法やアルゴリズムのステップは、ハードウェアによって直接的に、プロセッサによって実行されるソフトウェア・モジュールによって、または、これらの組み合わせによって具体化される。（例えば、実行可能命令および関連するデータを含む）ソフトウェア・モジュール、および、その他のデータは、例えばＲＡＭメモリ、フラッシュ・メモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハード・ディスク、リムーバブル・ディスク、ＣＤ−ＲＯＭ、あるいは当該技術分野で知られているその他の型式の記憶媒体のようなデータ・メモリ（例えば、コンピュータ読取可能媒体）内に存在しうる。典型的な記憶媒体は、プロセッサがそこから（例えば、ソフトウェア命令のような）情報を読み取り、またそこに情報を書き込むことができるように、例えばコンピュータまたはプロセッサ（本明細書では、便宜上“プロセッサ”と称される）のような機械に結合されうる。典型的な記憶媒体はプロセッサに統合されうる。プロセッサと記憶媒体とはＡＳＩＣ内に存在することができる。ＡＳＩＣは、ユーザ機器内に存在することができる。あるいは、プロセッサと記憶媒体は、ユーザ機器内の別々の構成要素として存在することができる。

開示された実施形態における上述した記載は、当業者をして、本発明の製造または利用を可能とするように提供される。これらの実施形態への様々な変形例もまた、当業者には明らかであって、本明細書で定義された一般的な原理は、本発明の主旨または範囲から逸脱することなく他の実施形態にも適用されうる。このように、本発明は、本明細書で示された実施形態に限定されるものではなく、本明細書に記載された原理および新規な特徴に一致した最も広い範囲に相当することが意図されている。

Claims (49)

1. ユーザ機器における省電力方法であって、
   ユーザ機器のトランシーバが、待機状態にある間、前記ユーザ機器において、複数のパケットをキューすることと、
   前記トランシーバの単一のウェイク状態の間に、前記キューされたパケットを前記ユーザ機器によって送信することと
   を備える方法。
2. 前記ユーザ機器は、パケット交換ネットワーク内の単一のチャネルを獲得している間、前記キューされたパケットを送信する請求項１に記載の方法。
3. 前記パケット交換ネットワークは、無線ローカル・エリア・ネットワークを備える請求項２に記載の方法。
4. 前記キューされたパケットを送信するＴＸＯＰを生成することをさらに備える請求項３に記載の方法。
5. 前記パケットはＶｏＩＰパケットを備える請求項１に記載の方法。
6. キューされたパケットの現在の送信において、単一のウェイク状態の間、前記キューされたパケットのうちのさらなるパケットが、次の送信において送信されるべきであることを示すことをさらに備える請求項１に記載の方法。
7. 前記パケットは、設定可能な時間長さの間、キューされる請求項１に記載の方法。
8. 前記設定可能な時間長さが経過した後、前記キューされたパケットを送信するために、前記トランシーバを、前記待機状態から前記ウェイク状態へ切り換えることをさらに備える請求項７に記載の方法。
9. 単一のウェイク状態の間、前記ユーザ機器に送信するために以前にキューされたパケットを受信することをさらに備える請求項１に記載の方法。
10. 受信した指示に応じて、前記ユーザ機器に送信するためにキューされたパケットを受信するために、前記トランシーバを前記ウェイク状態に保つことをさらに備える請求項１に記載の方法。
11. 前記ユーザ機器はモバイル・デバイスを備え、前記トランシーバはラジオを備える請求項１に記載の方法。
12. 前記待機状態は、省電力モードに関連付けられている請求項１に記載の方法。
13. 前記キューされたパケットのセットを、ＲＴＰ／ＩＰパケット内に集めることをさらに備え、前記キューされたパケットを送信することは、前記ＲＴＰ／ＩＰパケットを送信することを備える請求項１に記載の方法。
14. 前記パケットは、設定可能な時間長さの間、キューされ、前記設定可能な時間長さが経過した後、前記キューされたパケットが、前記ＲＴＰ／ＩＰパケット内に集められる請求項１３に記載の方法。
15. 前のパケットが正しく送信されたかにしたがって、前記キューされたパケットから、送信用のパケットを選択することをさらに備える請求項１３に記載の方法。
16. 遅延境界をクロスしたキューされたパケットを、正しく送信されなかったキューされたパケットのセットから取り除くことと、
    パケットの新たなセットを形成するために、新たなパケットを、前記キューされたパケットのセットに追加することと、
    前記トランシーバの単一のウェイク状態の間、前記パケットの新たなセットを送信することと
    をさらに備える請求項１３に記載の方法。
17. 前記ＲＴＰ／ＩＰパケットを送信することは、無線ローカル・エリア・ネットワークを介して前記ＲＴＰ／ＩＰパケットを送信することを備える請求項１３に記載の方法。
18. 前記トランシーバが前記待機状態にある場合、前記トランシーバの送信構成要素と、前記トランシーバの受信構成要素とが、省電力モードまたはアクティブ・モードの何れかに独立して設定される請求項１に記載の方法。
19. 失われたダウンリンク・フレームに応答して、前記待機状態のための時間期間の長さを調節することをさらに備える請求項１に記載の方法。
20. 単一のウェイク状態の間に、キューされたパケットを送信するように適応されたトランシーバと、
    前記トランシーバが待機状態にある間、複数のパケットをキューするように適応されたパケット・キューワーと
    を備える装置。
21. 前記トランシーバはさらに、パケット交換ネットワーク内の単一のチャネルを獲得している間、前記キューされたパケットを送信するように適応された請求項２０に記載の装置。
22. 前記パケット交換ネットワークは、無線ローカル・エリア・ネットワークを備える請求項２１に記載の装置。
23. 前記トランシーバはさらに、前記キューされたパケットを送信するＴＸＯＰを生成するように適応された請求項２２に記載の装置。
24. 前記パケットは、ＶｏＩＰパケットを備える請求項２０に記載の装置。
25. 前記パケット・キューワーはさらに、設定可能な時間長さにわたって前記パケットをキューするように適応され、前記装置はさらに、前記設定可能な時間長さが経過した後、前記キューされたパケットを送信するために、前記トランシーバを、前記待機状態から前記ウェイク状態へ切り換えるように適応された請求項２０に記載の装置。
26. 前記トランシーバはさらに、前記単一のウェイク状態の間、前記装置への送信のために以前にキューされたパケットを受信するように適応された請求項２０に記載の装置。
27. 前記トランシーバはさらにラジオを備える請求項２０に記載の装置。
28. 前記パケット・キューワーはさらに、前記キューされたパケットのセットを、ＲＴＰ／ＩＰパケット内に集めるように適応され、前記キューされたパケットを送信することは、前記ＲＴＰ／ＩＰパケットを送信することを備える請求項２０に記載の装置。
29. 前記パケット・キューワーはさらに、設定可能な時間長さの間、前記パケットをキューするように適応され、
    前記設定可能な時間長さが経過した後、前記パケット・キューワーはさらに、前記キューされたパケットを、前記ＲＴＰ／ＩＰパケット内に集めるように適応される請求項２０に記載の装置。
30. 単一のウェイク状態の間、キューされたパケットを送信する手段と、
    前記送信する手段が待機状態にある間、複数のパケットをキューする手段と
    を備える装置。
31. 前記送信する手段は、パケット交換ネットワーク内の単一のチャネルを獲得している間、前記キューされたパケットを送信する請求項３０に記載の装置。
32. 前記パケット交換ネットワークは、無線ローカル・エリア・ネットワークを備える請求項３１に記載の装置。
33. 前記送信する手段は、前記キューされたパケットを送信するＴＸＯＰを生成する請求項３２に記載の装置。
34. 前記パケットはＶｏＩＰパケットを備える請求項３０に記載の装置。
35. 前記キューする手段は、設定可能な時間長さの間、前記パケットをキューし、前記装置はさらに、前記設定可能な時間長さが経過した後、前記キューされたパケットを送信するために、前記送信する手段を、前記待機状態から前記ウェイク状態へ切り換える手段を備える請求項３０に記載の装置。
36. 前記単一のウェイク状態の間、前記装置への送信のために以前にキューされたパケットを受信する手段をさらに備える請求項３０に記載の装置。
37. 前記送信する手段および前記受信する手段はラジオを備える請求項３６に記載の装置。
38. 前記キューされたパケットのセットを、ＲＴＰ／ＩＰパケット内に集める手段をさらに備え、前記キューされたパケットを送信することは、前記ＲＴＰ／ＩＰパケットを送信することを備える請求項３０に記載の装置。
39. 前記キューする手段は、設定可能な時間長さの間、前記パケットをキューし、前記装置はさらに、前記設定可能な時間長さが経過した後、前記キューされたパケットを、前記ＲＴＰ／ＩＰパケット内に集める請求項３０に記載の装置。
40. コンピュータ読取可能媒体に格納された命令群を含むコンピュータ読取可能媒体であって、
    ユーザ機器のトランシーバが、待機状態にある間、前記ユーザ機器において、複数のパケットをキューするための第１の命令セットと、
    前記トランシーバの単一のウェイク状態の間に、前記キューされたパケットを前記ユーザ機器によって送信するための第２の命令セットと
    を備えるコンピュータ読取可能媒体。
41. 前記第２の命令セットは、パケット交換ネットワーク内の単一のチャネルを獲得している間、前記キューされたパケットを送信するための第３の命令セットを備える請求項４０に記載のコンピュータ読取可能媒体。
42. 前記パケット交換ネットワークは無線ローカル・エリア・ネットワークを備える請求項４１に記載のコンピュータ読取可能媒体。
43. 前記キューされたパケットを送信するＴＸＯＰを生成するための第４の命令セットをさらに備える請求項４２に記載のコンピュータ読取可能媒体。
44. 前記パケットはＶｏＩＰパケットを備える請求項４０に記載のコンピュータ読取可能媒体。
45. 前記第１の命令セットは、設定可能な時間長さの間、前記パケットをキューするための第３の命令セットを備え、前記コンピュータ読取可能媒体はさらに、前記設定可能な時間長さが経過した後、前記キューされたパケットを送信するために、前記トランシーバを、前記待機状態から前記ウェイク状態へ切り換えるための第４の命令セットを備える請求項４０に記載のコンピュータ読取可能媒体。
46. 単一のウェイク状態の間、前記ユーザ機器に送信するために以前にキューされたパケットを受信するための第３の命令をさらに備える請求項４０に記載のコンピュータ読取可能媒体。
47. 前記ユーザ機器はモバイル・デバイスを備え、前記トランシーバはラジオを備える請求項４０に記載のコンピュータ読取可能媒体。
48. 前記キューされたパケットのセットを、ＲＴＰ／ＩＰパケット内に集めるための第３の命令をさらに備え、前記第２の命令セットは、前記ＲＴＰ／ＩＰパケットを送信するための第４の命令を備える請求項４０に記載のコンピュータ読取可能媒体。
49. 前記第１の命令セットは、設定可能な時間長さの間、前記パケットをキューするための第５の命令セットを備え、前記コンピュータ読取可能媒体はさらに、前記設定可能な時間長さが経過した後、前記キューされたパケットを、前記ＲＴＰ／ＩＰパケット内に集めるための第６の命令セットを備える請求項４８に記載のコンピュータ読取可能媒体。

Images