(57)【要約】      （修正有）【課題】モバイル・デバイスの要素の「アクティブ」モードと「スリープ」モードとの間の移行の頻度を低くして、電力消費を減少させる。【解決手段】電力節約のために、モバイル・デバイスの「アクティブ」モードと「スリープ」モードとの間の移行の頻度を低くする必要がある。また、スリープの期間を長くする必要がある。本発明では、無線クライアントとアクセス・ポイント構成、特にクライアントの無線インターフェースの電力消費に関連するそれらの設定のリモート・ディスカバリーのアプローチが広範に企図されている。【選択図】図４
2007151121.tif 000002
【特許請求の範囲】
【請求項１】
無線アクセス・ポイントと通信する少なくとも１つのクライアントのためのネットワーク通信を促進し、前記クライアントの無線インターフェースが少なくとも２つの電力状態の間を移行する装置であって、前記電力状態の間を移行するように前記クライアントの構成を決定する手段を備える装置。
【請求項２】
前記無線アクセス・ポイントは、周期的なビーコン・メッセージを前記クライアントに送信し、前記手段は、  
(a)クライアントにおいて少なくとも１つのビーコンを受信した時間を確定すること及び
(b) クライアントによって受信される継続的なビーコンの間の少なくとも１つのインターバルを確定すること、のうち少なくとも１つを実行するように構成されている請求項１記載の装置。
【請求項３】
前記無線インターフェースの前記の状態は、低消費電力状態と高消費電力状態とを含み、
前記手段は、
(a)前記消費高電力状態に留まるクライアント・タイムアウト・インターバル、
(b)「Awake」状態に留まるクライアント・タイムアウト・インターバル及び
(c)アクティブ・モードに留まるクライアント・タイムアウト・インターバル、
のうち少なくとも１つを確定するように構成されている請求項１記載の装置。
【請求項４】
前記手段は、(a) 及び (b) の全てからなる請求項２記載の装置。
【請求項５】
無線通信トラフィックは、インターネット・トラフィックからなる請求項１記載の装置。
【請求項６】
アクセス・ポイント及びクライアント・インターフェースは８０２．１１技術を使用する請求項１記載の装置。
【請求項７】
前記手段は、１つ以上のさらなるクライアントにおける１つ以上のさらなるビーコンの受信の前に、１つのクライアントにおいて、専ら開始ビーコンの受信の時間を確定するように構成されている請求項１記載の装置。
【請求項８】
前記手段は、プローブ・パケットを送信すること、プローブ・パケットの送信に続くクライアントの応答の遅延を測定すること及び応答遅延が予め決定された最小往復時間と実質上同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけることを通じて、開始ビーコンの受信の時間を確定するように構成されている請求項１記載の装置。
【請求項９】
前記手段は、プローブ・パケットを送信すること、プローブ・パケットの送信に続くクライアントの応答の遅延を測定すること、もし応答遅延が予め決定された最小往復時間と実質的に同等でなければ、新たなビーコン倍数を計算し、また新たなビーコンを待ち受けること及び応答遅延が予め決定された最小往復時間と実質的に同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけることを通じて、クライアントによって受信された継続的ビーコンの間の少なくとも１つのインターバルを確定するように構成されている請求項１記載の装置。
【請求項１０】
前記手段は、１組のプローブ・パケットを送信すること、プローブ・パケットの送信に続くクライアントの応答遅延を測定すること、もしも応答遅延が予め決定された最小往復時間と実質的に同等でなければ、パケット送信インターバルを調整し、また新たなビーコンを待ち受けること及び 応答遅延が予め決定された最小往復時間と実質的に同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけることを通じて、アクティブ・モードにとどまるクライアントのタイム・インターバルを確定するように構成されている請求項１記載の装置。
【請求項１１】
無線アクセス・ポイントと通信する少なくとも１つのクライアントのためのネットワーク通信を促進し、前記クライアントの無線インターフェースが少なくとも２つの電力状態の間を移行する方法であって、前記電力状態の間を移行するように前記クライアントの構成を決定するステップを備える方法。
【請求項１２】
前記無線アクセス・ポイントは、周期的なビーコン・メッセージを前記クライアントに送信し、前記クライアントの構成の前記決定は、
(a)クライアントにおける少なくとも１つのビーコンを受信した時間を確定するステップ及び
(b)継続的ビーコンがクライアントによって受信される間、少なくとも１つのインターバルを確定するステップ、のうち少なくとも１つを実行するステップを備える請求項１１記載の方法。
【請求項１３】
前記無線インターフェースの前記状態は低消費電力状態及び高消費電力状態を含み、前記クライアントの構成の前記決定は、
(a)前記高消費電力状態に留まるクライアント・タイムアウト・インターバル、
(b)前記「Awake」状態に留まるクライアント・タイムアウト・インターバル及び
(c)アクティブ・モードに留まるクライアント・タイムアウト・インターバル、
のうちの少なくとも１つを確定するステップを備える請求項１１記載の方法。
【請求項１４】
前記クライアントの構成の前記決定が、(a)及び (b) の全てからなる請求項１２記載の方法。
【請求項１５】
無線通信トラフィックは、インターネット・トラフィックからなる請求項１１記載の方法。
【請求項１６】
アクセス・ポイントは、８０２．１１クライアント・インターフェースからなる請求項１１記載の方法。
【請求項１７】
前記クライアント構成の前記決定は、１つ以上のさらなるクライアントにおける１つ以上のさらなるビーコンの受信の前に、１つクライアントにおいて、専ら開始ビーコンの受信の時間を確定するステップからなる請求項１１記載の方法。
【請求項１８】
前記クライアント構成の前記決定は、
プローブ・パケットを送信するステップと、
プローブ・パケットの送信に続くクライアントの応答遅延を測定するステップ及び
応答遅延が、予め決定された最小往復時間と実質上同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけるステップ、を通じて
開始ビーコンの受信の時間を確定するステップからなる請求項１１記載の方法。
【請求項１９】
前記クライアント構成の前記決定は、
プローブ・パケットを送信するステップと、
プローブ・パケットの送信に続くクライアントの応答遅延を測定するステップと、
もし応答遅延が予め決定された最小往復時間と実質的に同等ではなければ、新たなビーコン倍数を計算し、また新たなビーコンを待ち受けるステップ及び
応答遅延が、予め決定された最小往復時間と実質的に同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけるステップを通じて、継続的ビーコンがクライアントによって受信される間の少なくとも１つのインターバルを確定するステップからなる請求項１１記載の方法。
【請求項２０】
前記クライアント構成の前記決定は、
プローブ・パケットを送信するステップと、
プローブ・パケットの送信に続くクライアントの応答遅延を測定するステップと、
もしも応答遅延が予め決定された最小往復時間と実質的に同等でなければ、パケット送信インターバルを調整し、また新たなビーコンを待ち受けるステップ及び
応答遅延が、予め決定された最小往復時間と実質的に同等になるまで、追加的なプローブ・パケットの送信に続くクライアントの応答遅延を測定しつづけるステップとを通じて、アクティブ・モードに留まるクライアント・タイム・インターバルを確定するステップからなる請求項１１記載の方法。
【請求項２１】
無線アクセス・ポイントと通信する少なくとも１つのクライアントのネットワーク通信を促進する方法のステップを実行する機械によって実行可能な命令のプログラムを効果的に具体化し、前記クライアントの無線インターフェースが少なくとも２つの電力状態の間を移行する機械可読プログラム・ストレージ・デバイスであって、
アクセス・ポイントとの通信に関連する前記クライアントの無線インターフェースの構成を決定する前記機械を備え、前記ステップは、
(a)クライアントにおける少なくとも１つのビーコンの受信の時間を確定するステップと、
(b)クライアントによって受信される継続的ビーコンの間の少なくとも１つのインターバルを確定するステップと、
(c)前記高消費電力状態に留まるクライアント・タイムアウト・インターバルを確定するステップと、
(d)「Awake」状態に留まるクライアント・タイムアウト・インターバルを確定するステップ及び
(e) アクティブ・モードに留まるクライアント・タイムアウト・インターバルを確定するステップ、
のうち少なくとも１つを実行するステップを備える方法。
【請求項２２】
決定された構成パレメーターの少なくとも１つに基づいて、少なくとも１つのクライアントとの無線通信トラフィックをスケジューリングする手段を備える請求項１記載の装置。
【請求項２３】
無線通信トラフィックをスケジューリングするための前記手段は、決定された構成パレメーターの全てに基づいてトラフィックをスケジューリングするように構成されている請求項２２記載の装置。
【請求項２４】
前記クライアント構成を決定する前記手段は、パケット・プロービングを使用する請求項１記載の装置。
【請求項２５】
前記クライアント構成を決定する前記ステップは、パケット・プロービングを使用する請求項１１記載の方法。
【請求項２６】
前記方法ステップは、前記クライアントの前記構成を決定するために、前記機械から前記クライアントにプローブ・パケットを送信し、プローブ応答を受信して遅延を測定するステップを含む請求項２１記載のプログラム・ストレージ・デバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にコンピューターソフトウェアの分野に関し、特に、サーバーベースのリソースへのアクセスのためのクライアント・アプリケーションをサポートするソフトウェアの一部であるネットワーク・プロキシの設計と開発に関する。
【背景技術】
【０００２】
ネットワーク・プロキシ・サーバーは、クライアント・アプリケーションがリモート・サーバーと効果的に相互作用することを支援するように設計されたネットワーク化されたアプリケーションである。
【０００３】
典型的には、プロキシ・サーバーは、ユーザーレベルのアプリケーションとして、専用の、高性能のネットワーク化されたサーバー・マシン上で実行される。
【０００４】
より性能を上げるために、サーバーのカーネルの内部のモジュール又はネットワーク化された装置において同じ機能を実行することができる。ＳＯＣＫＳサーバーは、ネットワーク・プロキシの初期の例を示す。
【０００５】
ウェブ・プロキシ・キャッシュ（例えば、Ari Lutonenの“Web Proxy Servers”「 ウェブ・プロキシ・サーバー」, Prentice Hall, 1998を参照）は、おそらくネットワーク・プロキシのもっともよく知られた例であろう。
【０００６】
ウェブ・プロキシ・キャッシュは、ページダウンロードの待ち時間を減少させることによって、クライアント・ブラウザとユーザー・エクスペリエンスの性能を改善するように設計される。クライアント・ブラウザーは、ウェブ・プロキシ・キャッシュからコンテンツをリクエストするように構成される。
【０００７】
プロキシがリクエストされたドキュメントのローカル・コピーを持っているときは、プロキシは、そのドキュメントをクライアントに返す。そうでないときは、プロキシは、クライアントのリクエストをオリジン・サーバーに転送し、そしてその応答をクライアントに転送する。
【０００８】
プロキシは、その転送されたドキュメントのコピーをローカル・キャッシュ（ディスク）に保存することができる。
【０００９】
企業又はキャンパスのネットワークに亘ってウェブ・プロキシ・サーバーにアクセスする待ち時間のほうが、インターネットに亘ってオリジンサーバーにアクセスする待ち時間よりはるかに短いために、ページダウンロードの待ち時間は減少する。
【００１０】
キャッシュにヒットする割合が高ければ高いほど、ページダウンロード待ち時間は減少する。高いキャッシュのヒット率を実現するためには、プロキシ・キャッシュは、大きなクライアント群に供されることが必要である。
【００１１】
そうでない場合には、キャッシュにヒットする確率、即ち、他のクライアントによって予めリクエストされていたドキュメントをリクエストする確率は、相対的に低くなる。
【００１２】
キャッシュのヒット率は、複数の施設に供される大きなプロキシ装置では５０％に達する。ユーザーが感じる待ち時間の減少に加えて、プロキシはオリジン・ウェブ・サーバーの負荷を減少させる。
【００１３】
ユーザー・エクスペリエンスの改善の他に、ウェブ・プロキシ・サーバーはクライアントに間接的インターネット・アクセスを提供する。その結果、クライアント・マシーンは、広汎なインターネットに起因する攻撃から保護される。
【００１４】
そうした構成においては、ウェブ・プロキシの使用は、インターネットにアクセスする唯一の道方法である。即ち、企業又はキャンパスのイントラネットの外側でアクセスするサーバーからクライアントを保護するように構成されたファイアーウォールの後ろに、全てのクライアント・マシーンが置かれる。
【００１５】
ウェブ・プロキシ・サーバーは、特別なホスト構成とファイアーウォールを使って、インターネット攻撃から保護される。
【００１６】
ウェブ・プロキシ・サーバーは、典型的には単一目的のマシーンであり、それがファイアーウォール構成を単純化している。HTTPトラフィックのみが、ウェブ・プロキシ・サーバーから又はウェブ・プロキシ・サーバーへ通過することを許される。
【００１７】
他のネットワーク・アプリケーション、例えばメディア・プレーヤーや電子メール・クライアントなどは、このプロキシ・ベースのセキュリティー・アーキテクチャを活用し、HTTPをトランスポート・プロトコルとして使用するように変更される。
【００１８】
その結果、クライアント・トラフィックのかなりの量が、ローカル・ウェブ・プロキシを通じて送信されるか、あるいは送信されることができる。
【００１９】
帯域幅の使用可能性及びクライアントのローカル・キャッシュが増大するにつれて、またより多くのウェブ・サイトがCDN（Content Distribution Networks）などの待ち時間短縮技術を使うにつれて、ウェブ・プロキシをキャッシュとして使用する価値は減少する。
【００２０】
しかしながら、ウェブ・プロキシを使うセキュリティー関連の利点は明白に増大している。というのは、アプリケーション・レベルのプロキシは、ネットワーク・トラフィック、即ち、ウェブ・プロキシ・サーバーのためのHTTPペイロードの徹底的な検査を可能にする唯一の現実的な方法だからである。
【００２１】
独立して、リソースの制約があるモバイル・デバイスを支援するために、新たなカテゴリーのアプリケーション・レベルのプロキシが開発された。
【００２２】
ＰＤＡ／スマートフォンのブラウザがウェブ・コンテンツを小さなスクリーンに表示することを支援するトランスコーディング・プロキシは、このカテゴリーにおいて最も知られた例であろう。
【００２３】
それに加えて、ウェブ・プロキシ・キャッシュは、デスクトップ・クライアントに比べて無線クライアントにより多くの利点を提供する。というのは、モバイル・クライアントは、デスクトップ・クライアントに比べてローカル・キャッシュが小さく、また無線接続は有線のＬＡＮ接続に比べて待ち時間が長く帯域幅が小さいからである。
【００２４】
ごく最近、トランスコーディング・プロキシは、マルチメディア・ストリームをモバイル・クライアントの能力に適合させ、あるいはストリームを再生するために消費するエネルギーを低減するように拡張されてきた。
【００２５】
要するに、アプリケーション・レベルのプロキシは、特にＨＴＴＰプロキシは、リソースに制約があるモバイル無線クライアントを支援するために、ますます重要な役割を演じていくことが予想される。
【００２６】
過去数年にわたって、デバイス部品の性能と同じ速度では、バッテリーの能力は増大してこなかったのであるから、エネルギー消費を減少させることは非常に重要な問題である。
【００２７】
大きな技術的改善によって、これらの部品によって消費される電力は減少してきたが、それらの改善のほとんどは、部品の性能も低めるものであり、あるいはモバイル・システムの他の特性、例えば応答性を低下させるものである。
【００２８】
現在、モバイル・デバイスの能力は、そのバッテリーの能力によって著しく制約されており、この電力に関連した制約は予見しうる将来において消滅するとは期待できない。
【００２９】
ウェブ・プロキシを、着信してくる無線ＬＡＮトラフィックをシェーピングするために使用すること、あるいはメディアストリームを省電力的な方法でトランスコーディングしまたスケジューリングすることは、クライアント・デバイス又はモバイル・クライアント・デバイスの無線ＬＡＮインターフェースによって消費されるエネルギーを大幅に節約することを可能にする（以下を参照：J. Clark et al, “System for low power operation of wireless LAN interfaces”「無線ＬＡＮインターフェースの低電力動作のためのシステム」,米国特許出願 Docket #YOR9-2002-0230, Marcel C Rosu et al., “PAWP: A Power Aware Proxy for Wireless LAN Clients”「ＰＡＷＰ：無線ＬＡＮクライアントのための電力認識プロキシ」, WMCSA 2004, English Lake District, December 2-3 2004及びS. Mohapatra et al., “Integrated Power Management for Video Streaming to Mobile Handheld Devices”「モバイル・ハンドヘルド・デバイスへのビデオ・ストリーミングのための総合パワーマネージメント」,In Proceedings of ACM Multimedia 2003）
【発明の開示】
【発明が解決しようとする課題】
【００３０】
これらのアプローチは、１つのアプリケーション（ウェブ・ブラウザ又はメディア・プレイヤー）を実行している１つのクライアントに焦点をあてており、これらのアプローチを複数のアプリケーションとモバイル・クライアントに明確に拡張するものは存在しない。
【００３１】
その一方、モバイル・デバイスの一群を一つのグループとしてサポートすること、そしてそれらの共有リソースをグループ的な方法によって使用することを最適化することについては、比較的少ない研究しか行われてこなかった。
【００３２】
より具体的には、モバイル・クライアントによって消費されるエネルギーの大きな部分が直接あるいは間接に通信関連であるという事実にもかかわらず、モバイル・クライアント間で共有された無線ＬＡＮ帯域幅での電力認識スケジューリングのための既知の技術は存在しないのである。
【００３３】
残念ながら、無線ＬＡＮトラフィックのエネルギーを大幅に節約することができる効果的なスケジューリングには、クライアントの構成、現在の状態、アプリケーション及びアプリケーション・ペイロードについて現在入手できるよりも多くの情報が必要である。
【００３４】
ユーザー又はアプリケーションを識別するために、ＩＰアドレスあるいはＴＣＰ／ＵＤＰポート番号などのトランスポート・レベルあるいはネットワーク・レベルの属性を使用することは、無線ＬＡＮトラフィックの大部分が、ＨＴＴＰペイロードを伝送する、即ち、ＴＣＰポート８０を使用するＴＣＰパケットからなるために、困難である。
【００３５】
ウェブ・ブラウザ以外にも、マルチメディア・ストリーミングや電子メール・クライアントなどのますます多数のネットワーク化されたアプリケーションが、ファイアーウォール構成を大幅に単純化するためにＨＴＴＰを使用しており、このトレンドは、今後も持続するものと予想されている。
【００３６】
それに加えて、動的ＩＰアドレスの割り当ては、モバイル無線ＬＡＮのアドレスの管理のために望ましい方法であるが、それはネットワーク・レベル／トランスポート・レベルの属性を用いて、無線ＬＡＮ上での異なったアプリケーション／ユーザーの間で識別することを一層困難にする。
【００３７】
従って、ユーザー及びアプリケーションを特定するためのアプリケーション・レベルの情報を使用する必要がある。それは、クライアント・アプリケーションを支援するネットワーク・プロキシが利用できるか、あるいは利用できるようにするということである。
【００３８】
残念なことに、無線インターフェースの構成などの現状のモバイル・クライアント・システムでは、十分な情報がアプリケーション・レベルで利用されてはいない。
【００３９】
従って、そうしたさらなるクライアント情報を提供するように既存のクライアント・プロトコル及びアプリケーションを強化するか、あるいは変更されていないクライアントからこの情報を遠隔的に収集するための新たな方法及び装置を設計する必要がある。
【００４０】
モバイル・デバイスの構成及び現在の状態についての十分な情報が収集されることを前提にして、管理下にある全てのクライアント・デバイスにおけるエネルギー節約を促進するような方法で、無線ＬＡＮ帯域幅などの共有リソースの使用を制御するメカニズムを提供することに関する必要性が認識されてきた。
【００４１】
このようなメカニズムがないと、１つのアプリケーションを実行する１つのクライアント・デバイスのために開発された既存の技術は、互いに衝突し、期待されるようなエネルギー節約はできないであろう。
【００４２】
従って、予め決められたグループ方針に従って、グループ内のモバイル・デバイス間のエネルギー使用を最適化することに関する必要性が認識されてきた。
【課題を解決するための手段】
【００４３】
本発明の少なくとも１つの目下の好ましい実施態様により、無線クライアントの構成及び無線アクセス・ポイントについての情報を得るリモート・ネットワークに接続したコンピューターを含む方法及び装置が、広範に企図されている。
【００４４】
このような構成の例には、クライアントの電力関連のパラメーター、例えば、無線アクセス・ポイントからビーコンを受信するためにクライアントの無線インターフェースが目を覚ます（wake up）正確な時期やバッテリーやディスプレーの輝度レベルなどのクライアントのエネルギー関連の現在の状態が含まれる。
【００４５】
要約すれば、本発明の１つの側面は、アクセス・ポイントと通信し、また省電力モードとアクティブ・モードとの間を移行する少なくとも１つのクライアントのための無線通信トラフィックを促進するための装置を提供する。その装置は、次のものを備える。
【００４６】
アクセス・ポイントとの通信に関するクライアントの状態を決定するためにクライアントをプロービングするための装置であって、このプロービング装置は、
(a) クライアントにおいて開始ビーコンを受信した時間を確定すること、
(b) クライアントによって受信される継続的なビーコンの間の少なくとも１つのインターバルを確定すること及び
(c) アクティブ・モードにとどまるクライアントのタイムアウト・インターバルを確定すること、
のうちの少なくとも１つを実行するように構成されている。
【００４７】
さらに、その装置は、以前に確定された構成パラメーターのうち少なくとも１つを使用して少なくとも１つのクライアントの無線トラフィックをスケジューリングするための装置を含むように拡張される。
【００４８】
本発明の他の側面は、アクセス・ポイントと通信し、また省電力モードとアクティブ・モードとの間を移行する少なくとも１つのクライアントのための無線通信トラフィックを促進するための方法を提供する。その方法は、次のステップを備える。
【００４９】
アクセス・ポイントとの通信に関するクライアントの状態を決定するためにクライアントをプロービングするステップであって、このプロービング・ステップは、
(a) クライアントにおいて開始ビーコンを受信した時間を確定するステップ、
(b) クライアントによって受信される一連のビーコンの間の少なくとも１つのインターバルを確定するステップ、及び
(c) アクティブ・モードにとどまるクライアントのタイムアウト・インターバルを確定するステップ、
のうちの少なくとも１つを実行するステップを備える。
【００５０】
さらに、本発明の他の側面は、アクセス・ポイントと通信し、また省電力モードとアクティブ・モードとの間を移行する少なくとも１つのクライアントの無線通信トラフィックを促進する方法のステップを実行するための、機械によって実行可能な命令のプログラムを効果的に具体化する機械可読プログラム・ストレージ・デバイスを提供する。その方法は以下のステップを備える。
【００５１】
アクセス・ポイントとの通信に関するクライアントの状態を決定するためにクライアントをプロービングするステップであって、このプロービング・ステップは、
(a) クライアントにおいて開始ビーコンを受信した時間を確定するステップ、
(b) クライアントによって受信される一連のビーコンの間の少なくとも１つのインターバルを確定するステップ及び
(c) アクティブ・モードにとどまるクライアントのタイムアウト・インターバルを確定するステップ、
のうちの少なくとも１つを実行することを備える。
【００５２】
本発明の他の及びさらなる特徴と利点とともに、本発明をさらによく理解するために、添付の図面とあわせて次の説明を参照されたい。そして本発明の範囲は添付のクレームの中で示される。
【発明を実施するための最良の形態】
【００５３】
【実施例】
【００５４】
図１は、無線クライアント１１０−１１４が、無線アクセス・ポイント１３０及び１３１、電力認識プロキシ・サーバ１４０及びインターネット１５０などの様々なネットワーク要素を通じてオリジン・サーバ１２０と通信するネットワーク環境１００を示す。プロキシ１４０は、リモート・ネットワークに接続したコンピューターであり、クライアント・アプリケーションをサポートし、無線クライアント１１０−１１４のために、着信してくるインターネットトラフィックをスケジューリングする。
【００５５】
図１から判るように、この場合インターネット１５０からコンテンツを受信し、又はインターネット１５０にコンテンツを提供する電力認識プロキシ１４０は、１つ以上の無線アクセス・ポイント１３０及び１３１と通信しており、そしてそれら自体はさまざまな無線クライアント１１０−１１４と通信している。
【００５６】
以下では、プロキシという用語は、リモート・ネットワークに接続されたクライアント自体を除くあらゆるコンピューターを指す。
【００５７】
例示的で非制限的な例として、ここで扱うアプリケーションは、一般に普及している801.11無線ＬＡＮ技術を使用している。
【００５８】
８０２．１１仕様（Part 11, “Wireless LAN Medium Access Control [MAC] and Physical layer [PHY] Specifications”「無線LANのMAC及びPHY仕様」, ANSI/IEEE Std 802.11, 1999を参照）は、２つのパワーマネージメント・モード、すなわちアクティブ・モードと省電力モードを規定している。
【００５９】
省電力モード、即ち、８０２．１１用語のスリープモードでは、無線ＬＡＮインターフェースは、アクティブ・モードよりも５分の一乃至５０分の一の電力を消費する。
【００６０】
典型的な無線ＬＡＮドライバは、約１００ミリ秒のアイドル・インターバルの後でインターフェースを省電力モードに切り替える。
【００６１】
こうした構成においては、無線ＬＡＮインターフェースによって消費される相対的な電力は、高性能ラップトップの５−１０％からＰＤＡの５０％以上まで変化する。
【００６２】
シェーピングされたトラフィック（shaped traffic）の集中的性格によって、無線ＬＡＮインターフェースは、より短いアイドルタイム・インターバルの後で、省電力モードに安全に切り替えることができる。即ち、より小さいタイムアウト値を使うことができ、それはエネルギー消費を削減する。
【００６３】
プロキシを使用しないと、着信するトラフィックの予測し難い性格のために、着信トラフィックをシェーピング（shaping）せずに、インターフェース・タイムアウトを減少させることにより、エネルギーを節約することは不可能である。
【００６４】
この単純化しすぎたアプローチは、ＴＣＰ接続の往復時間を増大させ、そのことはクライアント・アプリケーションの性能を劣化させる。
【００６５】
さらにバックグランドを加えることによって、本開示は、インフラストラクチャー・ネットワークにおける８０２．１１クライアント・インターフェース又はステーションのパワーマネージメント機能の特徴についてここで簡単に概観する。
【００６６】
ステーションのパワーマネージメント・モードは、アクティブ・モードであるか、あるいは省電力モードである。
【００６７】
ステーションの電力状態は「Awake」、即ち、ステーションがフルに電力消費されている時か、あるいは「Doze」、即ち、フレームを受信したり送信したりすることは出来ないが、ステーションが非常に少ない電力しか消費しない状態である。
【００６８】
アクティブ・モードにおいては、ステーションは「Awake」状態にある。省電力モードにおいては、ステーションは典型的には「Doze」状態にあるが、それは無線アクセス・ポイントから１０２．４ミリ秒ごとに発信される選択ビーコンを受信するために「Awake」状態に移行する。
【００６９】
ステーションは、アクセス・ポイントに接続する時、どのような頻度でビーコンを受信するために目を覚ます（wake up）かを選択する。
【００７０】
モード間の移行は、常にステーションによって開始され、アクセス・ポイントとの正常なフレーム交換を必要とする。
【００７１】
アクセス・ポイントは、省電力モードにあることが知られているステーションのためのペンディングになっている全てのトラフィックをバッファリングし、これらのステーションに適切なビーコンで警告する。
【００７２】
ステーションが、そのフレームがアクセス・ポイントにおいてペンディングになっていることを検知すると、ステーションはポーリング・メッセージをアクセス・ポイントに送信する。
【００７３】
ステーションは、そのポーリングへの応答を受信するまでは「Awake」状態にとどまる。
【００７４】
アクセス・ポイントのポーリングへの応答は、次のペンディング・フレームかＡＣＫフレーム（acknowledgement frame）かのいずれかであり、後者はアクセス・ポイントがペンディング・フレームの送信を遅延させて、当然に、その配信の開始に責任を負うことを合図するものである。
【００７５】
ステーションは、各受信フレームに確認応答する（ＡＣＫフレームを送信する）必要がある。
【００７６】
もし、フレームのモア・データ・フィールドがさらにペンディング・フレームを示すならば、ステーションはさらにポーリング・フレームを送信することができる。そうでない時は、ステーションは「Doze」電力状態に戻る。
【００７７】
クライアント・ステーションの電力モードは、無線ＬＡＮデバイス・ドライバによって制御される。
【００７８】
ステーションは、いかなる時点でも、例えばアクセス・ポイントから最初のデータ・フレームを受信した後、あるいはアクセス・ポイントにデータ・フレームを送信した後に、省電力モードからアクティブ・モードに切り替わることができる。
【００７９】
ステーションは、データ・フレームが受信されなくなった後で、あるいはそれが予め決められたインターバルで発信されなくなった後で、省電力モードに再度切り替わることになる。
【００８０】
アクティブ・モードから省電力モードへの切り替えは、次のビーコンが受信される後まで、あらゆるフレームの受信を遅らせる。
【００８１】
フレームを受信するためにクライアントを省電力モードからアクティブ・モードに切り替えることは、性能の観点から非常に利点がある。というのは、アクティブ・モードにおいては、アクセス・ポイントはデータ・フレームをそれが着信すると直ちにクライアントに転送することになるからである。これに対して、省電力モードにおいては、データ・フレームを待ち行列に入れ、クライアントが目を覚ます（wake up）まで待たねばならないからである。
【００８２】
残念なことに、パケット配信の差異を吸収するために、クライアントはさらなるデータを待つ間、アクティブ・モードに留まらねばならず、それが電力を浪費する。
【００８３】
このように、エネルギーの観点からは、非常に高い割合でデータが着信してくることが知られているか、あるいはそれが大いに期待される場合を除いて、アクティブ・モードへの移行は決して利益にならない。
【００８４】
前記のすべてのことを考慮して、本発明の少なくとも１つの目下の望ましい実施態様により、図２、３及び４に示されているようなプロトコルが広範に企図されている。
【００８５】
特に、図２、３及び４は、８０２．１１の使用可能なモバイル・デバイスを、そのインターフェース操作と同期させ、その無線ＬＡＮインターフェースの構成パラメーターを決定し、また特にビーコンと情報を交換するインターバル時間又は前記のような省電力モードに留まることを決定するためのプロービング手順を示している。
【００８６】
図２、３及び４に図示された手順はプロキシ１４０上で実行される。
【００８７】
図２、３及び４は、基地局のためのビーコンタイム、ビーコン・インターバル又は多数の既定の無線ＬＡＮクライアントとクライアントのタイムアウト・インターバルを決定するプロセスを示している。
【００８８】
以下においては、無線ＬＡＮクライアントは、省電力モードを活用するように構成されていることを前提とする。
【００８９】
従って、クライアントに送信されたパケットは、時に基地局でクライアントが受信待機するように構成されている次のビーコンまでバッファリングされる。
【００９０】
さらに、クライアントは、常にこれらのプローブ・パケットに直ちに応答することを前提とする。応答パケットは、基地局によって遅延されることは決してない。
【００９１】
クライアントがアクティブ・モードにある時あるいはビーコンの直前にクライアントが省電力モードにある時に、クライアントに送信されるパケットは、即時に応答される。
【００９２】
以下においては、そうした迅速な応答にかかる時間を「min_rtt」（minimum round trip time：最小往復時間）と呼ぶ。
【００９３】
その値は、クライアントに送信する一連のパケットを使用するプロキシによって決定することができる。それらのパケットのうちのいくつかは、基地局によって直ちに転送されることが保証されている。それは、クライアントがアクティブ・モードにあるか、あるいはそれらはビーコンが送信される直前にたまたま送信されるからである。
【００９４】
ＭＡＣレベルの遅延が非常に小さいので、測定される「min_rtt」値は、実際にはランダムに拡散した値の集合であり、それの下限はプローブ・パケットのサイズ、無線ＬＡＮ技術及び使用される基地局によって決定される。
【００９５】
要約すれば、いかなる測定された「rtt」 (round trip time：往復時間）も非常に近接していて、この限界から１ないし２ミリ秒以内であって、１つの「min_rtt」とみなせる。
【００９６】
図２は、「ビーコン時間」パラメーターを決定するプロービングのプロセス２００を図示している。
【００９７】
このパラメーターが、無線ＬＡＮ基地局の特性を示すのであり、従って、基地局を使用する最初のクライアントにとってのみ決定される必要があることに留意されたい。
【００９８】
示されているように、プロキシはステップ２１０からプロセスを開始する。
【００９９】
次にステップ２２０において、プローブ・パケットがデバイスに送信され、応答が待たれ、そして応答遅延が測定される。
【０１００】
ステップ２３０において、もし測定された応答遅延が予め決定されたパラメーター「min_rtt」とほぼ等しくなければ、遅延が計算されて、別のプローブ・パケットをステップ２２０で送信する前にステップ２４０で遅延インターバルがトラバースされる。
【０１０１】
ステップ２３０において、もし応答遅延が、確かに「min_rtt」とほぼ等しければ、ステップ２５０において、得られたパラメーター・ビーコン・タイムが記録される。
【０１０２】
図３は、ビーコン・インターバル・パラメーターを決定するプロービングのプロセス３００を示す。示されているように、プロキシは、ステップ３１０でプロセスを開始する。
【０１０３】
次にステップ３２０において、プローブ・パケットがデバイスに送信され、応答が待ち受けられ、そして応答遅延が測定される。
【０１０４】
ステップ３３０において、もし測定された応答遅延が「min_rtt」とほぼ等しくなければ、ステップ３４０で新たなビーコン倍数が選択され、予想されるビーコンが計算され、そして別のプローブ・パケットがステップ３２０で送信される前に次のビーコンを待ち受ける。
【０１０５】
ステップ３３０において、もし測定された応答遅延が、「min_rtt」とほぼ等しいのであれば、ステップ３５０において得られたパラメーター・ビーコン・インターバルが記録される。
【０１０６】
実際には、個々のビーコンが遅延するかもしれないし、又はクライアントは一時的に「Awake」状態にあるかもしれないし、又はクライアントはアクセス・ポイントからバッファリングされたパケットを受け取る最初のクライアントではない。
【０１０７】
すべてのこれらの効果は、プロキシにおけるビーコン・タイム及びビーコン・インターバルの測定に誤った影響を与えるであろう。
【０１０８】
これらの効果を打ち消すために、ビーコン・タイムとビーコン・インターバルは、より長い期間にわたって数回測定され、アクセス・ポイントがビーコンを送信する１０２．４ミリ秒のインターバル又はその倍数につき、ビーコン・タイムの測定値の間隔がその倍数にあるか、そしてビーコン・インターバルがその倍数にあるか否かを決定すべきである。
【０１０９】
図４は、「アイドル・タイムアウト」のパラメーターを決定するためのプロービングのプロセス４００を図示している。
【０１１０】
示されているように、プロキシは、ステップ４１０で開始する。
【０１１１】
次に、ステップ４２０においてパケット送信インターバルは最初にゼロに設定され、そして２つのプローブ・パケットがステップ４３０において送信される。
【０１１２】
この２つのパケットは、前回のビーコン・タイムとビーコン・インターバルの２つの測定によって決定された、クライアントがビーコンを受信することが知られている時間に送信される必要がある。
【０１１３】
次に、ステップ４３０においてまた、この２つのプローブ・パケットへの応答が待ち受けられ、応答遅延が測定される。
【０１１４】
もし、ステップ４４０において測定された応答遅延が「min_rtt」とほぼ等しければ、パケット送信インターバルが拡大され、そしてさらに２つのプローブ・パケットがステップ４３０で送信される前に、ステップ４５０において次のビーコンが待ち受けられる。
【０１１５】
この送信インターバルは、応答遅延が「min_rtt」とほぼ等しくはなくなるまで拡大され、その点で得られたパラメーターであるアイドル・タイムアウトがステップ４６０における送信インターバルと等しいと決定される。
【０１１６】
実際には、個々のビーコンが遅延するかもしれないし、又はクライアントは一時的に「Awake」状態にあるかもしれないし、又はクライアントはアクセス・ポイントからバッファリングされたパケットを受け取る最初のクライアントではないかもしれない。
【０１１７】
全てのこれらの効果は、プロキシにおけるアイドル・タイムアウトの測定に誤った影響を与えるであろう。
【０１１８】
これらの効果を打ち消すために、アイドル・タイムアウトが拡張された期間にわたって数度測定され、アイドル・タイムアウトの測定値が反復可能であるか否かを決定すべきである。
【０１１９】
無線ＬＡＮインターフェースの電力モード及び状態に加えて、本発明は、バッテリーの残存電力、アイドル時電力浪費、無線インターフェースの電力消費及びクライアントの全般的電力消費などの無線ＬＡＮクライアントの電力関連の他の特性、そして転送速度やバースト性などの着信するトラフィックの特性との関係をも同様に考慮に入れることが望ましい。
【０１２０】
本明細書で別に表示しないかぎり、本明細書で言及され、引用されたすべての特許、特許出願、特許公報及び他の出版物（ウェブベースの出版を含む）は、それがその全体を本明細書で説明された如くに、本明細書によって参照により完全に組み入れられていると想定すべきである。
【０１２１】
本発明の例示的な実施態様が、本明細書において添付の図面を参照して説明されているとはいえ、本発明は、それらの厳密な実施態様に限定されるものではないことは当然である。そして、本発明の範囲と精神から逸脱することなく、さまざまな他の変更、修正が当業者によってなし得ることも当然である。
【産業上の利用可能性】
【０１２２】
また、本発明は、少なくとも１つの望ましい実施態様によれば、アクセス・ポイントとの通信に関するクライアントの状態を決定するために、クライアントをプロービングするための手段を当然含むものである。そのことは、適合するソフトウェア・プログラムを実行する少なくとも１つの汎用コンピューター上で実施することができる。
【０１２３】
これらは、また、少なくとも１つの集積回路又は少なくとも１つの集積回路の一部の上で実行することもできる。
【０１２４】
このように、本発明は、ハードウェア、ソフトウェアあるいはそれらの両方の組み合わせにおいて、当然実施することができる。
【図面の簡単な説明】
【０１２５】
【図１】クライアント・アプリケーションをサポートし、無線クライアントに着信してくるインターネット・トラフィックをスケジューリングするための電力認識プロキシを用いたネットワーク環境を示す。
【図２】クライアントがビーコンを受信する時間基準点（time reference point）を決定するための802.11の使用可能な無線クライアントをプロービングする手順を示す。
【図３】クライアントがビーコンを受信する時間インターバルを決定するための802.11の使用可能な無線クライアントをプロービングする手順を示す。
【図４】クライアントが、高消費電力状態から低消費電力状態に復帰するアイドル・タイムアウト値（idle timeout value）をその後決定するための802.11の使用可能な無線クライアントをプロービングする手順を示す。
【符号の説明】
【０１２６】
１００  ネットワーク環境
１１０、１１１、１１２、１１３、１１４  無線クライアント
１２０、１２１  オリジン・サーバ
１３０、１３１  無線アクセス・ポイント
１４０   電力認識プロキシ・サーバ
１５０  インターネット
２００  ビーコン時間パラメーターを決定するプロービングのプロセス
３００  ビーコン・インターバル・パラメーターを決定するプロービングのプロセス
４００  アイドル・タイムアウトのパラメーターを決定するためのプロービングのプロ
セス
【図１】
2007151121.tif 000003
【図２】
2007151121.tif 000004
【図３】
2007151121.tif 000005
【図４】
2007151121.tif 000006