(57)【要約】【課題】端末の消費エネルギー低減およびシステムスループット改善の少なくとも一方を達成する。【解決手段】本発明の実施形態としての通信装置は、無線通信インタフェースと、無線監視部と、通信状態判断部と、通信部とを備える。前記無線通信インタフェースは無線信号を送受信する。前記無線監視部は、前記無線通信インタフェースを介して相手装置と通信するフレームに基づいて、前記相手装置との通信路の状態を測定する。前記通信状態判断部は、前記通信路の状態に基づき、前記相手装置宛に予め取得した情報を前記相手装置へ送信可能か否かを判断する。前記通信部は、前記通信状態判断部の判断結果に応じて、前記情報を前記無線通信インタフェースを介して、前記相手装置に送信する。【選択図】図２
2016096431.tif 000002
【特許請求の範囲】
【請求項１】
無線信号を送受信する無線通信インタフェースと、
前記無線通信インタフェースを介して相手装置と通信するフレームに基づいて、前記相手装置との通信路の状態を測定する無線監視部と、
前記通信路の状態に基づき、前記相手装置宛に予め取得した情報を前記相手装置へ送信可能か否かを判断する通信状態判断部と、
前記通信状態判断部の判断結果に応じて、前記情報を前記無線通信インタフェースを介して、前記相手装置に送信する通信部と、
を備えた通信装置。
【請求項２】
前記通信部は、前記相手装置から情報の取得要求を受信し、前記取得要求に応じて外部の装置と通信し、前記外部の装置から前記取得要求で要求された情報を取得し、前記通信状態判断部で送信可と判断された場合に、前記取得した情報を前記相手装置に送信する
請求項１に記載の通信装置。
【請求項３】
前記通信状態判断部は、前記通信路の状態の値の変化に基づき、前記情報を前記相手装置に送信するか否かを判断する
請求項１または２に記載の通信装置。
【請求項４】
前記通信状態判断部は、前記通信路の状態の値の変化の大きさと、前記変化の方向に基づき、前記情報を前記相手装置に送信するか否かを判断する
請求項３に記載の通信装置。
【請求項５】
前記通信状態判断部は、前記通信路の状態の値の変化に基づき、前記送信可否の判断を行う頻度、および前記無線監視部で行う前記通信路の状態の測定を行う頻度の少なくとも一方を決定する
請求項１ないし４のいずれか一項に記載の通信装置。
【請求項６】
前記通信状態判断部は、前記通信路の状態の値の変化の大きさと、前記変化の方向に基づき、前記頻度を決定する
請求項５に記載の通信装置。
【請求項７】
前記通信状態判断部は、前記相手装置が応答を返すことを誘発するトリガフレームを前記無線通信インタフェースを介して送信し、
前記無線通信インタフェースは、前記トリガフレームに対する応答フレームを受信し、
前記無線監視部は、前記無線通信インタフェースで受信された前記応答フレームに基づき前記通信路の状態を測定する
請求項１ないし６のいずれか一項に記載の通信装置。
【請求項８】
前記通信状態判断部は、前記トリガフレームとして、前記相手装置の詳細情報を問い合わせるフレーム、前記相手装置との接続性を検証するためのフレーム、および前記相手装置における電波の受信状況を確認するためのフレームの少なくともいずれか１つを送信する
請求項７に記載の通信装置。
【請求項９】
前記トリガフレームは、少なくともデータリンク層での送達確認応答フレームの返答を誘発するフレームである
請求項７または８に記載の通信装置。
【請求項１０】
前記通信部を介して前記相手装置から情報の取得要求を受信し、前記取得要求に応じて外部の装置からネットワークを介して前記情報を取得し、前記情報を記憶部に保存するキャッシュ処理部を備え、
前記キャッシュ処理部は、前記相手装置から情報の取得要求を受けた場合に、前記情報が前記記憶部に保存されているかを確認し、
前記情報が前記記憶部に保存されており、かつ、前記通信状態判断部で送信可と判断された場合に、前記記憶部に保存されている前記情報を、前記相手装置に送信する、
請求項１に記載の通信装置。
【請求項１１】
前記相手装置から前記取得要求を受けた場合に前記取得要求の後に前記相手装置から取得要求がなされる可能性がある情報である第１情報を特定し、前記第１情報を自発的に取得する、先行取得部をさらに備え、
前記キャッシュ処理部は、前記記憶部に前記第１情報を前記取得要求により指定された情報に関連付けて保存し、
前記キャッシュ処理部は、前記取得要求により指定された情報と、前記第１情報を前記相手装置に送信し、
前記キャッシュ処理部は、前記通信路の状態に基づき、前記先行取得部による前記第１情報の取得の可否、前記第１情報の取得量、前記第１情報を前記相手装置に送信するタイミングの少なくとも１つを制御する
請求項１０に記載の通信装置。
【請求項１２】
前記キャッシュ処理部は、前記通信路の状態の値の変化に基づき、前記少なくとも１つを制御する
請求項１１に記載の通信装置。
【請求項１３】
前記キャッシュ処理部は、前記通信路の状態の値の変化の大きさと、前記変化の方向に基づき、前記少なくとも１つを制御する
請求項１２に記載の通信装置。
【請求項１４】
前記キャッシュ処理部は、前記取得要求で指定された情報から直接または間接に参照されている情報識別子、または、前記相手装置および別の装置の少なくとも一方の過去の情報取得履歴に基づき、前記第１情報を特定する
請求項１１ないし１３のいずれか一項に記載の通信装置。
【請求項１５】
アクセスポイントであることを特徴とする請求項１ないし１４のいずれか一項に記載の通信装置。
【請求項１６】
アクセスポイントではない端末であることを特徴とする請求項１ないし１５のいずれか一項に記載の通信装置。
【請求項１７】
無線信号を送受信する無線通信インタフェースを介して相手装置と通信するフレームに基づいて、前記相手装置との通信路の状態を測定する無線監視ステップと、
前記通信路の状態に基づき、前記相手装置宛に予め取得した情報を前記相手装置へ送信可能か否かを判断する通信状態判断ステップと、
前記通信状態判断ステップの判断結果に応じて、前記情報を前記無線通信インタフェースを介して、前記相手装置に送信する通信ステップと、
を備えた通信方法。
【請求項１８】
無線信号を送受信する無線通信インタフェースを介して相手装置と通信するフレームに基づいて、前記相手装置との通信路の状態を測定する無線監視ステップと、
前記通信路の状態に基づき、前記相手装置宛に予め取得した情報を前記相手装置へ送信可能か否かを判断する通信状態判断ステップと、
前記通信状態判断ステップの判断結果に応じて、前記情報を前記無線通信インタフェースを介して、前記相手装置に送信する通信ステップと、
をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、通信装置、通信方法およびプログラムに関する。
【背景技術】
【０００２】
ＩＥＥＥ８０２．１１やＬＴＥに代表される無線通信方式が普及している。これらの通信方式では、無線を介した通信を有線通信技術で構成されたバックエンドのネットワークに接続するために、アクセスポイントもしくは基地局などと呼ばれる機器を使用する。アクセスポイントは、異なるネットワーク間をデータリンク層で接続する接続するブリッジとして機能し、フレームを無線側と有線側とで中継したり、異なる通信方式間で中継することを専らの役割とする。この際、アクセスポイントでは通常、フレームを長期間保存することは無く、受信したら直ちに中継先のネットワークへと転送する。
【０００３】
これに対して、ネットワーク上に存在するルータやブリッジにおいて、中継するデータを一時的に保存するキャッシュ機能を具備し、意味がある情報の塊を単位として伝送する通信方式（Ｃｏｎｔｅｎｔ−Ｃｅｎｔｒｉｃ  Ｎｅｔｗｏｒｋｉｎｇ：ＣＣＮ）が提唱されている。この方式では、利用者が要求する情報を取得する際には、ネットワーク上に存在する複数のキャッシュから最も近いものが選択され、当該キャッシュから送信された情報を受信する。
【０００４】
ところで、無線通信では送信機と受信機の間の距離に応じて、通信品質が異なる。ＩＥＥＥ８０２．１１では品質に応じて利用できる最大リンク速度が異なっており、距離が短い方が、高速でエネルギー効率がよい通信が実現できる。従来におけるＣＣＮをベースにした通信では、キャッシュに蓄積された情報を端末が要求すると、無線通信の効率を考慮することなく、アクセスポイントは情報を送信していた。例えば、アクセスポイントから遠く通信効率が悪い状況でも端末に、応答を送信していた。このため、通信時間が長くなり、結果的に端末の消費エネルギーが増加する問題があった。また、通信時間が長くなることで、同じアクセスポイントを共有する他の端末が通信できる時間を浪費するため、システムスループットが低下する問題があった。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】V. Jacobson, D. K. Smetters, J. D. Thornton, M. F. Plass, N. H. Briggs, R. L. Braynard, “Networking Named Content”, CoNEXT 2009, Rome, December, 2009.
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明の実施形態は、端末の消費エネルギー低減およびシステムスループット改善の少なくとも一方を達成することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の実施形態としての通信装置は、無線通信インタフェースと、無線監視部と、通信状態判断部と、通信部とを備える。前記無線通信インタフェースは無線信号を送受信する。前記無線監視部は、前記無線通信インタフェースを介して相手装置と通信するフレームに基づいて、前記相手装置との通信路の状態を測定する。前記通信状態判断部は、前記通信路の状態に基づき、前記相手装置宛に予め取得した情報を前記相手装置へ送信可能か否かを判断する。前記通信部は、前記通信状態判断部の判断結果に応じて、前記情報を前記無線通信インタフェースを介して、前記相手装置に送信する。
【図面の簡単な説明】
【０００８】
【図１】第１の実施形態に係るネットワークの模式図。
【図２】第１の実施形態に係るアクセスポイントの機能ブロック図。
【図３】第１の実施形態に係るアクセスポイントの変形例の模式図。
【図４】第１の実施形態に係るアクセスポイントの他の変形例の模式図。
【図５】第１の実施形態におけるアクセスポイントの動作フロー図。
【図６】無線監視部で測定されたパラメータの例を示す図。
【図７】アクセスポイントが端末に電波を送信させる働きかけを行う方法の一つを示す図。
【図８】第１の実施形態における変形例３の動作フローを示す図。
【図９】第１の実施形態における変形例４の動作フローを示す図。
【図１０】第２の実施形態に係るアクセスポイントの構成図。
【図１１】第２の実施形態に係るアクセスポイントの動作フロー図。
【図１２】第３の実施形態に係るアクセスポイントの構成図。
【図１３】第３の実施形態のアクセスポイントの動作フロー図。
【図１４】、端末の取得要求に応じて取得した情報と、プリフェッチにより取得した情報を関連付けて格納する動作を説明するための図。
【図１５】図１４の動作で格納された情報を示す図。
【図１６】本発明の実施形態に係る通信装置のハードウェア構成例を示す図。
【発明を実施するための形態】
【０００９】
以下、図面を参照しながら、本発明の実施形態について説明する。以下で示す各実施形態は一例であり、本発明は、必ずしもこれらと同一の形態で実施される必要はない。また、図面において同一の構成要素には同じ番号を付し、同じ説明は適宜省略する。
【００１０】
（第１の実施形態）
図１は、第１の実施形態に係るネットワークの模式図である。無線通信端末（以下、端末と呼ぶ）１０１が、無線ネットワークを介して無線アクセスポイント（以下、アクセスポイントと呼ぶ）１００に接続されている。本実施形態では、端末１０１とアクセスポイント１００間で、ＩＥＥＥ８０２．１１規格の無線通信方式に従って通信を行うとするが、ＩＥＥＥ８０２．１１規格以外の無線通信方式に対しても、本実施形態は適用可能である。アクセスポイント１００は、バックエンド側のネットワーク１０３にも有線または無線で接続されている。ネットワーク１０３にはサーバ１０２が接続されており、端末１０１は、アクセスポイント１００およびネットワーク１０３を介してサーバ１０２と通信する。ネットワーク１０３は、インターネット等の広域ネットワークでもよいし、ローカルエリアネットワークでもよい。また、ネットワーク１０３は有線ネットワークでもよいし、無線ネットワークでもよいし、有線ネットワークと無線ネットワークの混合でもよい。
【００１１】
図２は、アクセスポイント１００の機能ブロック図である。アクセスポイント１００は、大きく、アクセスポイント１００全体の動作を司る処理部２００、無線ネットワークに接続する無線Ｉ／Ｆ（インタフェース）２０１、有線ネットワークに接続する有線Ｉ／Ｆ２０２、処理部２００で実行されるアプリケーションなどにより利用される記憶部２０３、および通信処理に関する機能ブロック（転送部２２０、検出部２２１、通信部２２２、通信バッファ２２３）を備える。
【００１２】
無線Ｉ／Ｆ（インタフェース）２０１は、使用する無線通信方式（ここではＩＥＥＥ８０２．１１を想定）に応じて物理層およびデータリンク層のプロトコル処理を行う。物理層の処理は、物理ヘッダの処理、符号／復号、変調／復調などを含む。無線Ｉ／Ｆ（インタフェース）２０１が複数のアンテナを備えて、ビームフォーミングまたはＭＩＭＯに対応している場合は、ビームフォーミングまたはＭＩＭＯのための処理を含んでも良い。データリンク層の処理は、データリンク層ヘッダの処理、誤り訂正（あるいは誤り検出）、端末との間の通信リンクの管理（ビーコンフレームの送信を含む）、無線媒体へのアクセス制御（バックオフアルゴリズムに基づくアクセス権（ＴＸＯＰ）獲得、ＲＴＳおよびＣＴＳフレームの交換によるアクセス権（ＴＸＯＰ）の獲得など）を含む。無線Ｉ／Ｆ（インタフェース）２０１は、デジタルの物理パケットをアナログに変換して電波として放射するためのＤＡ変換器、帯域フィルタ、ミキサ、発振器、増幅器等の回路を含む。また、アンテナを介して受信した無線信号からデジタルの物理パケットを取得するため、低雑音増幅器、ミキサ、発振器、帯域フィルタ、ＡＤ変換器などの回路も含む。以上の構成の元、無線Ｉ／Ｆ（インタフェース）２０１は、後述の通信状態判断部２１１の指示に応じてフレームを生成して、アンテナ（１つまたは複数）を介して端末に送信したり、転送部２２０から検出部２２１を介して入力されたパケットまたはフレームから送信用のフレームを生成して、当該生成したフレーム（詳細には当該フレームを含む物理パケット）を端末に送信したりする。また、端末から正しく受信したフレームを検出部２２１に出力したり、無線監視部２１０で無線通信路の状態に関するパラメータを算出するために必要な情報を、送信または受信するフレームに基づき取得して、無線監視部２１０に出力したりする。当該パラメータを算出するために必要な情報の取得は、無線監視部２１０からの要求に応じて行ってもよいし、定期的、または任意のイベントで行ってもよい。
【００１３】
有線Ｉ／Ｆ（インタフェース）２０２は、使用する通信方式に応じて物理層およびデータリンク層のプロトコル処理を行う。例えばイーサーネット（登録商標）に接続されている場合は、イーサーネットに関する物理層およびデータリンク層の処理を行う。
【００１４】
処理部２００は、無線監視部２１０、通信状態判断部（ＡＰ処理部）２１１、アプリケーション（アプリ実行部）２１２を含む。各部は専用の機能ブロックでもよいし、処理部２００を汎用プロセッサとして、その上で実行されるソフトウェアとして実現してもよい。無線監視部２１０は、無線Ｉ／Ｆ２０１を介して通信されるフレームに基づき検出可能なパラメータを監視する。パラメータは、通信相手となる端末との間の無線通信路の状態を特徴づけるパラメータであり、例えば、受信電波強度、ＳＮＲ（Ｓｉｇｎａｌ  Ｎｏｉｓｅ  Ｒａｔｅ）、フレーム誤り率、フレームロス数、フレーム再送回数などである。これらは通信相手（端末）ごとに管理しているパラメータもあれば、無線ネットワーク全体で管理するパラメータもある。同一のパラメータに対して両方法で管理しておき、用途に応じて使い分けてもよい。端末側の無線Ｉ／Ｆにて検出可能なパラメータを端末から取得して、アクセスポイントの無線監視部２１０で管理してもよい。このとき端末から取得するパラメータは、アクセスポイントの無線Ｉ／Ｆ２０１で検出可能なパラメータと同じでもよいし、異なるパラメータを含んでもよい。例えば、アクセスポイントから送信されたビーコンを受信できなかった回数などのパラメータを含んでもよい。アクセスポイントで測定するパラメータの代わりに、端末で測定するパラメータを利用することも排除されない。
【００１５】
通信状態判断部２１１は、無線ＬＡＮアクセスポイントとして動作するための種々のＡＰ処理（例えば、アソシエーションおよび認証など）を実行する。また、通信状態判断部２１１は、無線監視部２１０で測定されるパラメータに基づき、端末との間の通信路の状態（通信状態）を判断し、判断結果に応じて端末への送信動作を制御する。無線監視部２１０で測定されるパラメータそのものを、通信路の状態（通信状態）として評価してもよいし、無線監視部２１０で測定される複数のパラメータから総合的に通信路の状態（通信状態）を評価してもよい。例えば複数のパラメータを総合的に判断して評価値を算出し（例えば複数のパラメータを入力として評価値を出力する関数）、これを通信路の状態（通信状態）としてもよい。あるいは、複数のパラメータからランクを算出し、このランクを通信路の状態としてもよい。アプリケーション２１２は、アクセスポイントの動作を設定するための管理アプリケーションなどである。図２ではアプリケーション２１２は１つしか記していないが、複数のアプリケーションが動作していてもよい。
【００１６】
転送部２２０は、無線Ｉ／Ｆ２０１と有線Ｉ／Ｆ２０２の間で交換されるデータリンク層のフレーム（ＭＡＣフレーム等）を双方向に転送する。検出部２２１は、両Ｉ／Ｆを通過するデータリンク層フレームを走査（例えばフレームヘッダ、パケットヘッダ、セグメントヘッダの少なくとも１つの解析、あるいはフレーム、パケット、セグメントのボディ部の少なくとも１つを解析など）し、アクセスポイント１００で処理すべきフレームを検出して、処理部２００または通信部２２２に渡す。
【００１７】
通信部２２２は、データリンク層より上位の通信プロトコル、例えば、ネットワーク層やトランスポート層の通信（ここではＴＣＰ／ＩＰの通信）を行う。加えて、アプリケーション層プロトコル（例えば、ＨＴＴＰやＤＮＳ）を含んでいてもよい。アプリケーション層プロトコルについては処理部２００で動作していてもよいし、処理部２００と通信部２２２の両方で（プロトコルごとに使い分けても、１つのプロトコルに対して協調してでもよい）動作していてもよい。また、通信部２２２は、アクセスポイント１００が主体的に行う通信を処理する部分でもある。例えば、アクセスポイント１００の設定を変更するためのリモート管理通信などが、これに該当する。
【００１８】
通信バッファ２２３は、転送部２２０および通信部２２２によって使用されるバッファである。それぞれの用途に応じて、データリンク層フレームを保存したり、ＴＣＰ／ＩＰパケットを保存したり、アプリケーションデータを保存したりする。通信バッファ２２３は、ＤＲＡＭまたはＳＲＡＭのような揮発性メモリ、またはＮＡＮＤ型フラッシュメモリやＭＲＡＭのような不揮発性メモリでもよいし、その他の記録媒体でもよい。
【００１９】
図２の構成を、図３または図４に示すように変更してもよい。図３は通信処理に関する部分をまとめて通信処理部２０４として構成した場合である。通信処理部２０４の内部には、図２で示した各機能ブロック２２０〜２２３が含まれる。図４は、処理部２００の内部に通信処理部２０４を含めて（例えばＳｏＣとして）構成した場合である。この場合、通信処理部２０４の動作は、処理部２００内の専用回路としての動作だけでなく、ソフトウェアと組み合わせて構成してもよい。例えば通信バッファはＤＲＡＭなどのハードウェア、それ以外はソフトウェアで構成してもよい。
【００２０】
本実施形態は、図２〜図４のいずれの構成であっても同じように適用可能である。よって、以下の説明は図２の構成を前提に行う。
【００２１】
図５は第１の実施形態におけるアクセスポイント１００の動作フローを示す。本フローの動作は、無線ネットワークに接続する端末１０１が、サーバ１０２に向けて情報の取得要求を送信することで開始される。取得要求は、例えばＨＴＴＰの場合、ＨＴＴＰ  ＧＥＴといった取得要求が、パケットにより端末１０１から送信される。以下で、情報取得の要求が送信または受信、および応答が送信または受信といった表現を用いるが、当該要求または応答は、実際には、使用する通信プロトコル（ＴＣＰ／ＩＰ等）に従ってパケットにより送信または受信される。もちろん、パケットはデータリンク層の処理でフレームに成形され、さらに物理層の処理を経て物理パケットとして送信されるが、パケット、フレーム、物理パケット間の遷移は、本実施形態の本質ではないため、説明を省略する。
【００２２】
アクセスポイント１００は、端末が送信した要求を無線Ｉ／Ｆ２０１で受信し（Ｓ５０１）、その要求を有線Ｉ／Ｆ２０２を介して、サーバ１０２に転送する（Ｓ５０２）。端末に要求された情報を含む応答をサーバ１０２が送り返すと、アクセスポイント１００は当該応答を検出部２２１にて検出する（Ｓ５０３）。検出された応答は、転送部２２０を介して通信バッファ２２３に一時的に格納される。この時、アクセスポイント１００は、要求と対応する形で応答を検出してもよいし、要求とは無関係に、応答が満たすべき条件だけに基づいて検出を行ってもよい。具体的には、前者は送受信のＩＰアドレスおよびＴＣＰポート番号（必要に応じてＴＣＰシーケンス番号）などを調べて、同一の通信であることを確認するのに対して、後者は送信元ＴＣＰポート番号が特定のサービス（ウェブアクセスの典型であれば８０番）に一致しているかどうかだけで判断する、という具合である。本実施形態にあっては、どのような方法で検出してもよいため、ここでは詳細は述べない。
【００２３】
応答が格納されたことが検出部２２１から処理部２００に通知され、通信状態判断部２１１にて、応答送信先となる端末との間の通信路の状態を確認する処理が行われる（Ｓ５０４）。この処理の詳細は後述する。通信路の状態に基づき、応答を端末に送信可能である（即時応答可）か否かを判断する。具体的には通信路の状態が所定の条件を満たすかで判断し、所定の条件を満たす場合は、通信状態は良いとして送信可能と判断し、満たさない場合は、通信状態は悪いとして送信不可と判断する。
【００２４】
例えば通信状態の値が実数で表される場合、当該値が閾値より大きいこと、または一定の範囲に入っていることを送信許可の条件としてもよい。通信状態の値が一定時間以上、閾値より大きいこと、または一定の範囲に入っていることを、送信許可の条件としてもよい。通信状態がランクで表される場合は、一定のランク以上であることを、送信許可の条件としてもよい。ここで述べた例は、あくまで一例であり、通信路の状態に基づき効率的な送信が可能か否かを判断できる限り、どのような条件を用いてもかまわない。例えば、通信するデータの種類（テキスト、画像など）に応じて、閾値等の条件を変更してもよい。
【００２５】
即時応答可と判断した場合（Ｓ５０５−ＹＥＳ）、通信状態判断部２１１は転送部２２０に指示を出し、転送部２２０は、通信バッファ２２３に一時保存している応答を無線Ｉ／Ｆ２０１を介して端末に送信する（Ｓ５０６）。応答を端末に送信すべきではないと判断した場合（Ｓ５０５−ＮＯ）、通信状態判断部２１１は一定時間待機した後（Ｓ５０７）、再度通信路の状態の確認を行う（Ｓ５０４）。これを送信可能と判断されるまで繰り返す。
【００２６】
図５の説明では、基本的な動作として端末１０１が通信を開始する（要求を送信する）前提で述べたが、無線ネットワーク側の端末１０１が通信を待ち受ける場合も同様に適用できる。その場合、アクセスポイント１００は、端末１０１からの要求の有無に拘わらず、接続している端末１０１宛のフレームを検出すればよい。
【００２７】
図５に述べた動作フローにおける通信状態確認処理（Ｓ５０４）について詳細に述べる。この処理は端末との間の無線通信路の状態を確認する処理であり、ＲＳＳＩやＳＮＲなど無線通信路の状態を特徴づけるパラメータを使用する。無線監視部２１０では、継続的に無線Ｉ／Ｆ２０１のアンテナを介して受信できる電波から得られる情報に基づき、通信路の状態（通信状態）を表すパラメータを算出し、保管しておく。通信状態判断部２１１から要求を受けた場合、無線監視部２１０は、当該端末に対する通信路の状態が事前に設定された条件をクリアしているかどうかを判定し、その結果を応答する。あるいは、通信状態判断部２１１から無線監視部２１０からパラメータを受信し、当該端末に対する通信路の状態が事前に設定された条件をクリアしているかどうかを判定する。これを実現するため、記憶部２０３などに図６（Ａ）のような形式で、測定されたパラメータ情報を記録しておく。図６（Ａ）の例では、端末ごとにＲＳＳＩと最新の測定時刻を記録している。最新のＲＳＳＩのみならず、後述する図６（Ｂ）に示すように、過去の複数回の測定にわたるＲＳＳＩと各々の測定時刻を記録してもよい。図６（Ａ）ではパラメータとしてＲＳＳＩの例を示したが、他のパラメータ（ＳＮＲやフレームロス率など）の場合も、同様にして記録すればよい。
【００２８】
また、ＲＳＳＩは端末ごとに値が刻々と変化するため、対象の端末から十分に電波を受信している必要がある。ここで「十分に」とは、判断に足る量的な部分だけではなく情報の新鮮さも含む。古い情報を参照しても適切な状態確認ができないためである。もし、情報が不足している場合（図６（Ａ）のような情報にエントリが無い、または最後に測定してから一定時間が経過している）には、電波を送信してもらうよう端末に働きかけを行ってもよい。
【００２９】
図７に、アクセスポイント１００が端末１０１に電波を送信してもらうよう働きかけを行う方法の一つを示す。この図はアクセスポイント１００と端末１０１との間のやり取りを描いたシーケンスである。図には（左右方向に）２種類の矢印付き線が用いられている。太い線は端末１０１からアクセスポイント１００へのフレーム送信を表し、細い線はアクセスポイント１００から端末１０１へのフレーム送信を表す。アクセスポイント１００の動作を踏まえると、端末１０１からの最初の要求の受信に関連して、少なくとも２つのフレーム（この例ではＨＴＴＰ  ＧＥＴとＬ２  ＡＣＫ。Ｌ２はレイヤー２の略である）を端末１０１から受信する。無線監視部２１０はこの２フレームに基づいて、（例えば）ＲＳＳＩをそれぞれ測定し、図６（Ａ）に示した情報の該当するエントリを更新する。例えば１番目のフレームで測定したＲＳＳＩで当該エントリを更新し、次いで２番目のフレームで測定したＲＳＳで当該エントリを再度更新してもよい。あるいは、これら２つのフレームのＲＳＳＩの平均で当該エントリを更新してもよい。
【００３０】
ここでアクセスポイント１００は、端末から一定時間を超えても要求が送られてこない場合、先の２フレームから得られた情報が古くなってしまう。そこで、アクセスポイント１００は端末１０１に対して、例えば図７に示すように、ＡＲＰ  Ｒｅｑｕｅｓｔを送信する。ＡＲＰ  Ｒｅｑｕｅｓｔは、ＩＰアドレスからそれに対応するＭＡＣアドレスを問い合わせるフレームである。ＡＲＰ  Ｒｅｑｕｅｓｔを送信すると、端末１０１は、ＡＲＰ  Ｒｅｑｕｅｓｔに対して、Ｌ２  ＡＣＫ（無線ＬＡＮのＡＣＫフレーム）と、ＡＲＰ  Ｒｅｐｌｙを応答する。アクセスポイント１００は、これら２つのフレームの受信で得られた情報を用いて、図６（Ａ）の情報の該当するエントリを更新すればよい。
【００３１】
ＡＲＰ  Ｒｅｑｕｅｓｔは、端末に応答フレームの送信を促すトリガフレームの一例であり、トリガフレームはＡＲＰ  Ｒｅｑｕｅｓｔに限定されない。端末１０１側に悪影響を与えず、かつ長さが短いフレームまたはパケットであればよい。例えばＴＣＰ  ＡＣＫなど送って、Ｌ２  ＡＣＫを受信する方法も考えられる。ただし、使用中のＴＣＰ通信に影響を与える可能性があるパラメータを伴うＡＣＫは避けるべきである。例えば同じＡＣＫ番号を３回送信するとパケットロスと判定されて、パケットロスと判定された以降のパケット（セグメント）の再送が開始されるため、同じＡＣＫ番号の送信は２回までにすることが望ましい。ＴＣＰ  ＡＣＫを用いる場合には、ＴＣＰ  Ｋｅｅｐ−Ａｌｉｖｅで規定される方法にてＴＣＰ  ＡＣＫを送信すれば影響を与えない。ＡＲＰ  Ｒｅｑｕｅｓｔは、端末１０１の詳細情報（ここではＭＡＣアドレス）を問い合わせるフレームの一例であり、他にも、ＩＰｖ６  Ｎｅｉｇｈｂｏｒ  Ｓｏｌｉｃｉｔａｔｉｏｎでも同様の効果が得られる。ただし、ＩＰｖ６  Ｎｅｉｇｈｂｏｒ  Ｓｏｌｉｃｉｔａｔｉｏｎのパケット長はＡＲＰより長いため、ＡＲＰの方がよい。
【００３２】
また、端末に応答フレームの送信を促すトリガフレームの他の例として、接続性を検証するためのパケット（ＰＩＮＧパケット、Ｔｒａｃｅｒｏｕｔｅパケットなど）を送信してもよい。
【００３３】
また、端末から応答が得られない可能性があるＩＰパケット（例えば端末に対してランダムなポートに対するＴＣＰ  ＳＹＮパケットを送信するなど。この場合、端末側のパーソナルファイアウォールでＴＣＰが破棄される可能性が高く、応答が得られないと考えられる）や、無意味なＬ２フレームを送信する方法も考えられる。いずれの場合も、フレームが正常に受信されれば、Ｌ２  ＡＣＫを受信することが期待される。ただし、送達確認応答以外の応答が得られるものを選択すれば、測定の機会が増えて精度が向上すると考えられる。
【００３４】
一方で、端末に複数回の送信を強いることで、消費エネルギーが増加するという懸念もある。よって、目的とする測定の精度に応じて、適切な種類のパケット／フレームを選択するようにしてもよい。例えば、初めて検出する端末（これは過去に接続してきた端末のＭＡＣアドレスの情報や、事前に特別処理を行うＭＡＣアドレスがアクセスポイント内に登録されていると言った前提のもと、対応可能となる）については、端末が対応できるフレームを確認するためにＡＲＰ、ＴＣＰ  ＡＣＫ、Ｎｅｉｇｈｂｏｒ  Ｄｉｓｃｏｖｅｒｙなど各々を試行する方法が考えられる。これと同様に、過去に対応した端末および設定済みの端末については、過去に利用できた方法に限定してフレームを送信すればよい。これについては、アクセスポイント内に端末の識別子（ＭＡＣアドレスでもよいし、アソシエーション時に割り当てるアソシエーションＩＤでもよいし、その他のＩＤでもよい）と、使用できたフレームの種類とを組み合わせて管理するデータベースなどを持たせればよい。もしくは、アクセスポイントの外部に設置された管理サーバで管理していてもよい。この場合、管理データベースは図６（Ａ）もしくは後述する図６（Ｂ）のようなテーブルに、追加の項目として、使用したフレームや通信量などの情報を持たせればよい。
【００３５】
他にも、過去に行った通信もしくは現在実行中の通信の頻度や量、交換される情報の種類（リアルタイム系通信か否か、非リアルタイム系の場合に動画等の大容量データの送受信か否か、など）に応じて、測定の頻度を変化させる（通信頻度・量が少ない場合は測定回数を少なくまたは間隔を広くし、通信頻度・量が多い場合は、測定回数を多くまたは間隔を細かくする）こともできる。
【００３６】
なお、アクセスポイントおよび端末間で適用する無線通信方式が、データを正常に受信できなかったときに応答を返すＮＡＣＫ応答方式を採用している場合は、端末からのＮＡＣＫ応答フレームを利用して測定を行うことも可能である。その他、ＡＣＫ応答やＮＡＣＫ応答といった送達確認応答に関するフレーム以外にも、アクセス権獲得のための一連の手順の中でＲＴＳフレームやＣＴＳフレーム等の送受信を行う場合は、これらＲＴＳフレームやＣＴＳフレームを利用して測定する方法も、もちろん可能である。
【００３７】
さらに、アクセスポイント１００および端末１０１がビームフォーミングに対応している場合には、別の方法も選択できる。具体的には、ビームフォーミングを実現するために用いられる端末位置の明示的な確認手順の中で、通信路の状態の測定を行う方法である。この方法は、端末での電波受信状態を確認するためにアクセスポイント１００からフレームを送信し、このフレームを受信した端末はその受信状況（受信電力、受信位相など）を通知するフレームをアクセスポイントに向けて送信する。アクセスポイント１００は、フレームで通知された端末の受信状況に基づき、端末の位置等を確認する。この際、アクセスポイント１００は、当該受信状況を通知するフレームに基づき、通信路の状態の測定を行う。この方法は、高度な無線技術に対応している必要があるが、通常の動作シーケンスの中で通信路の状態を把握できるため、本来不要なパケットまたはフレームを余計に送受信する必要はない。
【００３８】
＜変形例１：複数回の測定を用いて判定、変化率の導入＞
図５のステップＳ５０４で行う通信状態確認処理では、１回の処理ごとに、通信路の状態（通信状態）の測定を１回行うことに限定されず、複数回測定してもかまわない。例えば端末への応答送信を待機している間に、通信状態の測定を繰り返してもよい。さらに、その測定結果を時系列に記憶しておいてもよい。例えば、図６（Ｂ）のように、測定結果を時系列に記録してもよい（ここでは測定時刻Ｔａ−Ｘ＜Ｔｂ−Ｘ＜Ｔｃ−Ｘとする）。この図では３台の端末に対する測定結果が時系列に記録されている。Ｔａｂｌｅ（ＭＡＣ１）は、ＩＤがＭＡＣ１である端末の記録であり、ＲＳＳＩの値が徐々に大きくなっている。すなわち、電波状況が改善されていることが分かる。一方、Ｔａｂｌｅ（ＭＡＣ２）では、ＲＳＳＩの値の変化が小さく、電波状況はほとんど変化していない。Ｔａｂｌｅ（ＭＡＣ３）では、ＲＳＳＩの値が徐々に小さくなっており、電波状況が悪化している。
【００３９】
複数回の測定を通じて、電波強度が改善もしくは悪化する傾向がみられた場合、測定の頻度を高くして変化を早期に検出できるように調整してもよい。逆に変化が少ない場合には、測定の頻度を小さくしてもよい。この測定頻度は、アクセスポイント単独で決定してもよいし、端末側から通知するようにしてもよい（後者の場合、端末でもアクセスポイントと同様にパラメータを測定し、これに基づき測定頻度を判断してもよい）。端末が、測定頻度を通知する際には、加速度センサーや磁気センサーの値など、端末の状態を示す情報を付加してもよい。加速度センサーの値を利用して、端末の移動速度を推定し、端末から通知された測定頻度を調整してもよい。例えば移動速度が高いほど、測定頻度を上昇させてもよい。さらに端末のセンサーが所定の変化をした場合、例えば加速度センサーの値が一定値または一定割合以上大きく変化した場合に、測定頻度およびセンサーの値を通知するようにしてもよい、アクセスポイント側は、その通知を受信したら測定間隔を調整（例えば短く）してもよい。なお、図５のステップＳ５０７における待機時間も、複数回の測定に応じて同様にして調整してもよい。また、図５のフローとは無関係に、継続的にパラメータ測定を実施している場合に、当該実施する測定の間隔を、継続的に行っている測定の結果に基づき、同様にして決定してもよい。
【００４０】
さらに複数回の測定を行った結果から通信状態の変化を得る際に、通信状態の変化率を求めるようにしてもよい。ここで言う複数回の測定は、ステップＳ５０４で複数回の測定を行う場合でもよいし、ステップＳ５０７での待機を介してステップＳ５０４の処理が繰り返し行われることによるものでもよいし、あるいは、これらの両方を含むものでもよい。変化率を求めることで、早急な対応が必要か否かを決めることができる。すなわち変化率が大きい場合には、端末が速く移動していると考えられ、変化率が小さい場合にはゆっくり移動しているか、あるいは移動していないと考えられる。もし、変化率が小さいが改善に向かっている場合、ステップＳ５０５の即時送信の条件を満たす（閾値を超えるなど）まで待機すると長い時間がかかり、ユーザの待ち時間が増加してしまう可能性がある。これに対処するため、変化率を考慮したうえで、ステップＳ５０７での待機時間を調整（例えば短くする）するようにしてもよい。
【００４１】
＜変形例２：通信状態が悪化している場合、直ちに送信する＞
図５の動作フローで複数回の待機を繰り返した場合、通信状態が悪化していることを検出する可能性がある。その場合、端末と通信できなくなる恐れがあるため、ステップＳ５０５で通信状態が所定の条件を満たさない場合であっても、通信バッファ２２３に格納したパケットまたはフレームを送信するように判断してもよい。なお、この変更は図５のステップＳ５０５における判断条件の変更と考えられるので、動作フロー図に影響はない。
【００４２】
＜変形例３：通信状態が改善しない場合、諦めて送信する、または破棄する＞
先の図５の動作フローでは、電波状況等の通信状態が改善しない場合、フローを終了することなく、待機および測定を繰り返し続けるため、通信が完了しない。そこで一定回数の確認もしくは一定時間が経過しても通信状態が改善されない場合には、通信バッファ２２３に保存したパケットまたはフレームを、端末１０１に送信するようにしてもよい。もしくは、当該パケットまたはフレームを端末に送信せずに、破棄してもよい。この修正を加えた動作フロー図を、図８に示す。ステップＳ８０１では、ステップＳ５０５で即時可能でないと判断された場合に、合計待機時間が閾値を超えたか、および合計待機回数が閾値を超えたかのいずれか事前に定めた一方を判断する。閾値を超えた場合は、ステップＳ５０６に進み、通信バッファ２２３内のパケットまたはフレームを送信する。一方、閾値を超えていない場合は、一定時間待機し（Ｓ５０７）、当該待機した時間の値を合計待機時間に加算、および合計待機回数に１を加算のいずれか事前に定めた一方を行い、通信状態確認のステップＳ５０４に戻る。
【００４３】
＜変形例４：バッファがあふれる場合、諦めて送信する、または破棄する＞
通信バッファ２２３は有限であるため、アクセスポイントから応答を送信できない端末が多数存在すると、バッファ溢れが発生する可能性がある。この場合、適切なアルゴリズムに基づいて、バッファ内に蓄積したパケットまたはフレームを、端末に送信するか、破棄するようにしてもよい。図８に対して、この修正を加えた動作フロー図を図９に示す。ステップＳ９０１、Ｓ９０２が追加されている。ステップＳ５０３の応答検出の後、通信バッファ２２３に応答（パケットまたはフレーム）を格納するための空きがあるかを判断し（Ｓ９０１）、空きが無ければ、ステップＳ５０３で検出した応答（パケットまたはフレーム）を破棄する。図９の例では、後から来たパケットまたはフレームを破棄しているが、通信バッファ２２３にバッファリングされているパケットやフレームに先んじて、当該後から来たパケットまたはフレームをそのまま送信するようにしてもよい。または、ステップＳ９０１で空きバッファの有無を確認した後に、空きバッファが無い場合に、バッファの内容を置き換えるステップを含むようにしてもよい。バッファの内容を置き換えるとは、バッファから既存のパケットまたはフレームを抽出し、抽出したパケットもしくはフレームを一時退避して、後から来たパケットもしくはフレームを代わりにバッファに格納し、退避したパケットもしくはフレームを送信するか、破棄することである。
＜変形例５：バッファに溜められないケースに対する補足＞
なお、通信バッファ２２３にて応答（パケットまたはフレーム）をバッファして端末への送信を一時保留する場合、サーバ１０２にＴＣＰ  ＡＣＫを送信しないと後続のパケットが到着せず、スループットが大幅に低下する可能性がある。その場合には、通信部２２２にて、端末に対してＡＣＫを代理生成して、サーバ１０２に送信するようにしてもよい。ただし、代理応答した通信について端末がＡＣＫを送信するため、当該ＡＣＫをアクセスポイント１００にて検出して、破棄する必要がある。アクセスポイント１００は、端末からのＡＣＫに含まれるシーケンス番号が、代理応答したＡＣＫのシーケンス番号に達するまで、この処理（端末からのＡＣＫを破棄）を継続する必要がある。
【００４４】
＜第１の実施形態のまとめ＞
以上、本実施形態によれば、応答の送信前に端末との間の通信状態を確認し、送信に適した通信状態になるまで、応答の送信を待機させることにより、通信効率が良くなるタイミングで、応答を送信することができる。これにより、応答の送受信にかかる時間ならびにエネルギー効率を改善するとともに、システム全体のスループットの向上を図ることができる。
【００４５】
（第２の実施形態）
続いて、第２の実施形態に述べる。第２の実施形態は第１の実施形態のアクセスポイントに対してキャッシュ機能を追加したものである。キャッシュ機能は、端末から要求された情報を一時的に保存しておき、再度同じ情報が要求された場合に、保存しておいた情報を端末に提供する機能である。キャッシュ機能は、保存した情報を再利用する点が通信バッファ２２３と大きく異なる。
【００４６】
図１０に第２の実施形態に係るアクセスポイントの構成図を示す。第１の実施形態のアクセスポイントに対して、キャッシュ処理部１００２と一時記憶部１００３が追加されている（それに合わせてアクセスポイント全体は１０００、処理部は１００１と番号を振り直した）。なお、キャッシュ処理部１００２はアプリケーション２１２の一部として考えられるが、ここでは独立した要素として示す。
【００４７】
一時記憶部１００３は、情報を一時的に記憶するキャッシュである。一時記憶部１００３は、ＤＲＡＭまたはＳＲＡＭのような揮発性メモリ、またはＮＡＮＤ型フラッシュメモリやＭＲＡＭのような不揮発性メモリでもよいし、その他の記録媒体でもよい。
【００４８】
キャッシュ処理部１００２は、端末１０１から情報の取得要求（例えば取得先としてＵＲＬ等の情報識別子を含む）が受信された場合に、当該情報が一時記憶部（キャッシュ）１００３に格納されているかどうかを確認し、当該情報が一時記憶部１００３にある場合には、その情報を一時記憶部１００３から読み出し、端末１０１に通信部２２２および無線Ｉ／Ｆ２０１を介して応答として送信する。一方、一時記憶部１００３に、当該情報が格納されていなかった場合、端末１０１に代わって当該情報をサーバ１０２から代理取得する。より詳細には、キャッシュ処理部１００１がサーバ１０２に向けた取得要求を生成し、通信部２２２にてＴＣＰ／ＩＰパケットとして整形したのち、転送部２２０と有線Ｉ／Ｆ２０２を介してサーバ１０２に送信する。サーバ１０２はアクセスポイント１００から受信した要求を処理し、要求された情報のデータを含む応答をアクセスポイント１０００に向けて送信する。キャッシュ処理部１００２は、受信された応答もしくはそれに含まれるデータを、当該データを識別する情報（例えば端末からの取得要求に含まれるＵＲＬ等の情報識別子）に関連づけて一時記憶部１００３に保存する。そして、当該情報を端末１０１に通信部２２２および無線Ｉ／Ｆ２０１を介して、応答として送信する。以降、同じ情報識別子を含む要求を端末から受信した場合には、キャッシュ処理部１００２は、一時記憶部１００３を使って応答する。
【００４９】
図１１に第２の実施形態に係るアクセスポイントの動作フローを示す。この動作フローは、図５に示した第１の実施形態の動作フローを拡張したものである（なお、図５と同じ処理のステップでも異なる番号を振ってある）。
【００５０】
本動作フローの開始は、第１の実施形態と同様に、端末１０１がサーバ１０２に向けて取得要求を送信し、その要求をアクセスポイント１００が受信することで開始される。ただし、第１の実施形態と異なり、本実施形態ではアクセスポイント１００が、当該要求をインターセプトして処理する点が異なる。端末からの要求は無線Ｉ／Ｆ２０１で受信され（Ｓ１１０１）た後、検出部２２１にてインターセプトすべきパケットであるかを判断する。インターセプトすべきパケットは、例えば情報の取得要求を含むパケットである。インターセプトすべきパケットの検出ルールは事前に設定されている。例えば、ウェブアクセスであれば「宛先ＴＣＰポートが８０番である」といったルールが設定されている。検出部２２１は、事前に設定されたルールに合致しているパケットを検出し、そのパケットを通信部２２２に伝える。通信部２２２は、情報の取得先となるサーバに代わって、端末１０１とＴＣＰの確立処理などを行い、以降は、端末１０１に対してあたかもサーバと通信しているかのように振る舞う動作を行う。通信部２２２は、インターセプトしたパケットから情報の取得要求を抽出して、処理部１００１で動作するキャッシュ処理部１００２に当該要求を通知する（Ｓ１１０２）。
【００５１】
キャッシュ処理部１００２は、通信部２２２から通知された要求が、サーバ１０２から情報を取得する要求であることを確認すると（Ｓ１１０３）、取得対象となる情報が一時記憶部（キャッシュ）１００３に格納されているかどうかを確認する（Ｓ１１０４）。もし、情報が一時記憶部１００３にある場合には（Ｓ１１０４−ＹＥＳ）、その情報を一時記憶部１００３から読み出し、通信部２２２および無線Ｉ／Ｆ２０１を介して、応答として送信する。具体的には、第１の実施形態と同様に、通信状態判断部２１１が無線監視部２１０を利用して通信状態を確認し（Ｓ１１０５）、応答を即時に送信可能かどうかの判断を行う（Ｓ１１０６）。即時応答可能と判断したならば（Ｓ１１０６−ＹＥＳ）、無線Ｉ／Ｆ２０１から応答を送信して、処理を終了する（Ｓ１１０７）。もし、即時の送信は不可と判断がなされた場合には（Ｓ１１０６−ＮＯ）、一定時間待機し（Ｓ１１０８）、通信状態を確認する処理（Ｓ１１０５）に戻る。この時、待機時間または待機回数、通信状態の悪化などによって待機時間を変えたり、通信状態の測定間隔を変えたり、（即時送信のための条件を満たさなくても）即時応答を送信するようにしたり、といった変化形は、第１の実施形態の各変形例と同様に適用される。
【００５２】
一方、一時記憶部１００３に、取得対象となる情報が格納されていなかった場合（Ｓ１１０４−ＮＯ）、端末１０１に代わってアクセスポイント１０００がサーバ１０２に対して取得要求を送信して、サーバ１０２から情報を取得する（代理取得）（Ｓ１１０９）。より詳細には、キャッシュ処理部１００１がサーバ１０２に向けた取得要求を生成し、通信部２２２にてＴＣＰ／ＩＰパケットとして整形したのち、転送部２２０と有線Ｉ／Ｆ２０２を介してサーバ１０２に送信する。サーバ１０２はアクセスポイント１０１からの要求を処理し、要求された情報のデータを含む応答をアクセスポイント１０００に向けて送信する。アクセスポイント１０００は応答を受信すると、キャッシュ処理部１００２は、応答もしくはそれに含まれるデータを、当該データを識別する情報（例えばＵＲＬ）とともに一時記憶部１００３に保存する。以降、同じ情報識別子を持つ要求を端末から受信した場合には、一時記憶部１００３を使って応答する。
【００５３】
この代理取得処理と並行して、無線監視部２１０および無線Ｉ／Ｆ２０１を用いて端末１０１との間の通信路の状態（通信状態）を確認する処理を行う（Ｓ１１１０）。この処理は、第１の実施形態やステップＳ１１０５で述べた処理と同じものである。代理要求処理（Ｓ１１０９）と通信状態確認処理（Ｓ１１１０）は、有線Ｉ／Ｆ２０２と無線Ｉ／Ｆ２０１の異なるインタフェースを使用し、並列して実行可能なため、ここでは並列に実行するものとして記載している。ただし、必ずしも並列に実行する必要は無く、例えば通信路における最新の情報を正しく把握するという観点から、順序立てて実行する必要がある場合には、代理取得の後に、通信状態を把握してもよい。いずれにせよ、代理取得処理が完了し、かつ通信状態も確認できたら、即時に送信可能かどうかを判断する処理（Ｓ１１０６）に移る。以降の処理は、既に述べた通りであるため省略する。
【００５４】
＜第２の実施形態のまとめ＞
このように、本実施形態では、アクセスポイント１０００が情報を一時保管するキャッシュ機能を備え、端末から要求された情報がキャッシュに存在する場合には、キャッシュを利用して応答することで、サーバに情報を取得しに行く必要はなく、速やかな応答が可能となる。また、伝送遅延が減少するため、情報取得のスループットが向上すると予想される。さらに第１の実施形態の補足で述べたような、アクセスポイントにてＡＣＫを代理生成および送信しておく（第１の実施形態の変形例５）などの特殊な動作をする必要もない。本実施形態の説明は、図５に示した第１の実施形態の動作フローを拡張する形で述べたが、図８または図９で述べた動作フローを拡張する場合でも同じように適応できる。
【００５５】
（第３の実施形態）
続いて、第３の実施形態について述べる。第３の実施形態は、第２の実施形態に対してプリフェッチ機能を追加したことを特徴とする。プリフェチ機能は、端末から情報の取得要求を受ける前に、端末から取得要求される可能性が高い情報を自発的にサーバから取得して、一時記憶部（キャッシュ）に格納しておく機能である。
【００５６】
図１２に、第３の実施形態に係るアクセスポイントの構成図を示す。本実施形態のアクセスポイント１２００は、第２の実施形態に対して、プリフェッチ部１２０２が追加されている（それに合わせてアクセスポイント全体は１２００、処理部は１２０３、プリフェッチ部は１２０２と番号を振り直した）。
【００５７】
プリフェッチ部１２０２は、（１）端末からの要求、（２）ログに記録された端末の平均的な利用傾向、（３）要求を送信した端末やそのユーザのアクセス履歴、（４）契約しているサービスなどに基づいて、サーバなどの通信相手から情報を取得して、一時記憶部１００３にキャッシュする。（１）の端末からの要求に基づいて情報を取得する場合では、端末から直接要求された情報を取得する他、当該端末から要求された情報に関連する情報（例えば端末に要求された情報内でＵＲＬが参照されている場合に、当該ＵＲＬのリンク先の情報など）を取得することも行う。（１）における後者側で取得する情報（端末から要求された情報に関連する情報）および（２）〜（４）の情報の取得は、端末から要求を受けることなく行う情報取得であり、本実施形態でのプリフェッチに相当する。プリフェッチする情報は、端末からまだ取得要求されていないが、将来、端末から取得要求が行われる可能性が高いと考えられる情報である。
【００５８】
キャッシュ処理部１２０１は、第２の実施形態のキャッシュ処理部１００２を拡張したものであり、プリフェッチ部１２０２と連携する機能が追加されている。また、キャッシュ処理部１２０１は、端末から要求された情報と、これに関連する情報を一時記憶部１００３から抽出して、これらの情報をまとめて端末に応答を返す機能を具備する。
【００５９】
図１３に第３の実施形態のアクセスポイントの動作フローを示す。この動作フローは、図１１に示した第２の実施形態の動作フローを一部変更および拡張したものであり、図１１の代理取得ステップＳ１１０９が一括取得ステップＳ１３０１に変更され、即時送信可否判断のステップＳ１１０６の後に、一括応答生成ステップＳ１３０２が追加されている。
【００６０】
ステップＳ１３０１で示される一括取得処理では、端末が要求した情報の取得のみならず、当該要求した情報に関連する情報を事前に取得し（プリフェッチし）、一時記憶部１００３に、これらの情報を関連づけて蓄積する。ステップＳ１３０２で示される一括応答生成処理では、キャッシュ処理部１２０１が、端末が要求した情報と、これに関連して蓄積されている情報を一時記憶部１００３から抽出し、これらの情報をまとめて応答する。
【００６１】
＜一括取得処理の例（その１）＞
ステップＳ１３０１で実行する一括取得処理の例を述べる。キャッシュ処理部１２０１は、情報の取得要求を受けて、その情報が一時記憶部１００３に格納されていないことを確認すると、プリフェッチ部１２０２に当該要求を転送する。プリフェッチ部１２０２は当該要求で指定されている情報を取得して、キャッシュ処理部１２０１を介して一時記憶部１００３に格納する。また、取得した情報の解析を行い、プリフェッチする情報を特定し、特定した情報を取得（プリフェッチ）する。
【００６２】
より具体的な例で説明する。端末が送信した要求が、次のＵＲＬで表現されていたと仮定する。
ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ
プリフェッチ部１２０２は、ｉｎｄｅｘ．ｈｔｍｌで特定されるファイルを取得し、一時記憶部１００３に格納する。その後、プリフェッチ部１２０２は、ｉｎｄｅｘ．ｈｔｍｌを解析し、参照されている外部ファイル（スクリプトファイル、スタイルシート、画像ファイルなど）のＵＲＬを抽出する。これらのＵＲＬから外部ファイルを順次取得して、一時記憶部１００３に格納していく。その際、最初に格納した情報ｉｎｄｅｘ．ｈｔｍｌと関連づける形で格納することにより、関連情報として一括して読み出せるようにしておく。上記動作の模式図を図１４に示す。また、一時記憶部１００３に格納された情報の状態を図１５に示す。
【００６３】
図１５の例では、一連の構成ファイルに加え、管理情報が合わせて保存されている。管理情報には、端末から要求された情報（この例ではｉｎｄｅｘ．ｈｔｍｌ）と、当該情報から参照されている情報との関係が記録されている。この管理情報を、端末から要求された情報と合わせて保存することにより、要求された情報と関連する情報とを一括して読み出すことができる。
【００６４】
なお、一時記憶部１００３は、保存された情報の場所を特定するために一意のアドレスが付けられている。これは一時記憶部１００３で扱う絶対位置（物理位置）である。なお、処理部１２０３で動作するソフトウェアは、ファイルシステムを介して一時記憶部１００３を扱うため、内部では論理位置（やファイル名）と物理位置の変換が行われる。ファイルシステムの動作は、本実施形態の本質に影響しないため、これ以上の説明は省略する。いずれにせよ、管理情報には、最終的に情報が保存されている物理アドレスもしくは、それを得るための情報（ファイル名など）が保存される。図１５の下に示す管理情報の例では、ファイル名と論理アドレス（Ｌ（ａｄｄｒ１）など）が記録されているが、当然ファイル名だけ記録してもかまわない。
【００６５】
処理部１２０３で複数のアプリケーションが同時に実行される場合、一時記憶部１００３への書き込み処理を行うアプリケーションも複数存在する。この場合、アプリケーションごとにファイルが順序良く取得できるとは限らない。このことは処理部１２０３で動作するアプリケーションがひとつであっても同様に言えることであり、この場合もファイルが順序良く取得できるとは限らない。そのため、取得要求された情報と、これに関連する情報（プリフェッチした情報）が、一つの連続領域に保存されるとは限らない。例えば、図１５の例のように、端末から要求された情報と、プリフェッチした情報が、情報ごとに分散して配置される可能性もある。本実施形態では、このように情報が分散して配置された場合であっても、管理情報を参照することで、関連する情報を適切に読み出すことができる。
【００６６】
最終的にプリフェッチ部１２０２による処理は、最初に要求された情報とそこから参照されている情報を、全て取得できた段階で終了する。参照されている情報の取得は再帰的に行ってもよいが、その深さは事前に設定されているとする。「深さ」とは、最初に要求されたｉｎｄｅｘ．ｈｔｍｌから別のＨＴＭＬファイルが参照されている場合、そのファイルが更にほかの情報を参照していく場合に、このような参照の繰り返しの回数を深さと表現している。
【００６７】
深さ（繰り返しの回数）の設定は、端末ごと、端末を利用する利用者ごと、情報を取得するネットワーク（要求に含まれる宛先ＩＰアドレス、もしくはドメイン名）ごと、提供する無線ネットワークごと、全体での設定など、いくつかの方法が考えられる。固定的な設定に限定されず、例えば、時間帯（ネットワークが比較的空いているは深く設定し、混んでいる時間は浅くするなど）や曜日、日付、平日・休祝日の別、追加課金の有無（深いレベルのプリフェッチには追加料金が設定される、など）などによって変化させてもよい。
【００６８】
プリフェッチ部１２０２による取得が完了すると、その旨がキャッシュ処理部１２０１に通知される。キャッシュ処理部１２０１は、最初に、端末から要求された情報（ファイル）を一時記憶部１００３から読み出すとともに、その管理情報も読み出す。そして管理情報を参照しながら、関連する情報（ファイル）も順番に読み出す。その後、読み出した情報をまとめた応答を生成し、通信部２２２と無線Ｉ／Ｆ２０１を介して端末に当該応答を送信する。
【００６９】
ここで、複数の情報をまとめた応答の形には、いくつかの方法が考えられる。第１に、単純に個々のファイルを連結したうえで各ファイルの識別情報および長さ情報を含めて送信する方法がある。第２に、ＺＩＰ形式など一般的に利用されている圧縮ファイルの形にした後で１つのファイルとして送る方法がある。第３に、複数のファイルを特別な形式に変換した後、そのファイルを復元するためのプログラムと合わせて送信する方法がある。第４に、要求されたｉｎｄｅｘ．ｈｔｍｌを最初に送信し、その後、端末から新たな要求を受信する前にプリフェッチ部１２０３が取得したファイルを連続して送信する方法がある。ここで述べた以外の方法もある。本発明の実施にあたっては、いずれの方法であっても構わない。何らかの方法で端末に対して、複数の情報が連続的に送信できるようになっていればよい。
【００７０】
＜一括取得処理の例（その２）＞
先に述べた一括取得処理の例（その１）では、端末が要求した情報から参照されている情報をさらに取得することで、関連する情報を事前に取得し、端末に向けて連続的に、一括して、送信できるようにしていた。別の方法として、先に述べたように、アクセスポイントまたは周辺の管理装置（管理サーバ）で把握している過去のアクセス履歴（情報の取得履歴）などを参照して、関連する情報を取得してもよい。過去のアクセス状況は、要求を送信した端末に対するものでもよいし、何らかの特性（例えば、同じ種類の端末を使用している、同じサービスを契約しているなどの利用者に依存しない特性や利用者の年齢・性別など利用者に依存する特性のいずれでもよい）を共有する一部の端末もしくは全ての端末を対象としたものでもよい。前者の場合、端末の利用者が頻繁にアクセスする情報が事前に一時記憶部１００３に蓄積されるのに対して、後者の場合、全ての利用者にとって人気のある情報が一時記憶部１００３に蓄積されることになる。これは例えば、注目の動画やニュース記事などが該当する。プリフェッチする内容および実行タイミングは、各端末または利用者のアクセス履歴を記録しておき、当該アクセス履歴に記録されている曜日、時間、平日・休日の別、天気、場所、端末の種類、利用者の属性（年齢、性別、職業など）から総合的に判断されるものとする。この判断の方法については、種々のバリエーションが可能であり、これらの情報を利用する限り、任意の方法を用いてかまわない。
【００７１】
＜一括応答の送信タイミングの調整＞
本実施形態の先に述べた方法では、端末が情報の取得要求を送信した後、プリフェッチ部１２０２による取得処理（端末から要求された情報の取得と、当該情報に関連する情報の取得（プリフェッチ））が完了するまで端末は応答を受信することができない。この制約は端末の利用者に対して不自由を強いることになる。そこで、この問題を解決するように改良した動作例を示す。
【００７２】
図１３のフロー図に示すように、プリフェッチ部１２０２の一括取得処理（Ｓ１３０１）と、通信状態判断部２１１の通信状態確認処理（Ｓ１１１０）は並列に実行可能である。そのため、通信状態判断部２１１は、プリフェッチ部１２０２が動作中であっても、通信路の状態（通信状態）の変化、例えば端末の通信状態が改善しているか、悪化しているか、変化していないかを、検出可能である。
【００７３】
変化していないもしくは改善している場合は、なるべく多くの情報を高速に通信できるタイミングで送信したほうが効率的であるため、原則として待機を継続するように処理を行う。ただし、アプリケーションや端末の設定もしくはアクセスポイントの設定によって最大待機時間（もしくは最大待機回数）が決められている場合もあり、その上限に達した場合には待機せずに応答を返してもよい（図８参照）。
【００７４】
また、最初に要求された情報を第１〜第３の実施形態のいずれかで示した方法でまず応答しておき、プリフェッチで得た情報は、端末から要求が来た段階で、第１〜第３の実施形態のいずれかで示した方法に基づいて、一時記憶部１００３から読み出して一括送信するようにしてもよい（二段階の応答送信）。
【００７５】
さらに、二段階の応答送信を行う場合に、最初の応答にプリフェッチで取得した情報の一部を入れ、二回目の応答でその続きを送信するといった制御をしてもよい。その場合、端末ごとに、要求された情報を識別するＵＲＬと、一括で応答すべき情報（プリフェッチした情報）のうちどこまでを送信したかを、一時記憶部１００３または記憶部２０３で管理しておけばよい。
【００７６】
一方、悪化しているようであれば、待機することでさらに悪化したり、最悪通信できなくなったりする可能性がある。よって、悪化していることが検出された場合には、プリフェッチ部１２０２が動作中であっても、少なくとも端末からの要求に対する情報が取得できていれば、完了した部分まで、速やかに応答を送信するようにしてもよい。
【００７７】
なお、ここで述べた方法を用いてプリフェッチ処理の途中で応答を送信する場合、動作として、プリフェッチ部１２０２は、キャッシュ処理部１２０１に取得完了を通知する。ただし、取得完了を通知した後も、プリフェッチ部１２０２は、プリフェッチ動作をし続けるようにする。このようにすることで、他の端末から同じ情報を参照された場合に、プリフェッチした関連情報を活用して、効率的に応答が送信できる。
【００７８】
＜プリフェッチの実行可否判断、および取得する深さの変更処理を追加＞
本実施形態ではプリフェッチ部１２０２が追加されているが、端末の通信状態によってはプリフェッチを実行しない方がよい場合がある。例えば、通信状態が悪くかつ通信状態の変化率が小さい場合である。この場合、端末は移動しない可能性が高く、多くの情報をプリフェッチしたとしても、あまり大きな効果が望めない。そこでこのような状況では、プリフェッチを実行しない、もしくは比較的浅いレベルのプリフェッチを行うように調整する。以下に通信状態の変化、より詳細には変化の方向と変化率の大きさとの組み合わせに応じて、プリフェッチに関して対応可能な動作例を整理して示す。
【００７９】
以下では、通信状態の変化率は、「大きい」または「小さい」の２つに区分している。通信状態の変化の方向は、「改善」、「悪化」、「変化なし」の３つに区分している。通信状態の変化率は、例えば最新の通信状態の値と、直前の通信状態の値との差または比の絶対値をとり、その大きさによって、「大きい」または「小さい」に区分してもよいし、３回分以上の通信状態の値を近似する直線の傾きの絶対値を求め、その大きさによって、「大きい」または「小さい」に区分してもよいし、これら以外の方法で区分してもよい。さらには、区分数は、「大きい」「小さい」の２つではなく、「非常に大きい」「大きい」「小さい」「非常に小さい」など、３つ以上に区分してもよい。通信状態の変化の方向は、例えば最新の通信状態の値と、直前の通信状態の値の差または比が、第１閾値より大きければ「改善」、第１閾値以下で第２閾値より大きければ、「変化なし」、第２閾値以下であれば、「悪化」の３つに区分してもよい。あるいは３回分以上の通信状態の時間的に隣接する値の差または比のそれぞれについて「改善」、「変化なし」、「悪化」を特定し、多数決で最も回数が多い区分を採用してもよいし、ここで述べた以外の方法で区分を決定してもよい。通信状態の変化率と同様に、区分数はこの例（ここでは３）に限定されず、２、または４以上であってもかまわない。なお、「改善」、「悪化」、「変化なし」はあくまで通信状態の変化の方向であり、実際の通信状態の値（通信状態の良し悪し）は、これらの変化の方向とは別ものである点に注意する。すなわち、変化の方向が「悪化」であっても、通信状態は良い場合（例えば通信状態の値が閾値より大きい）も、悪い場合（例えば通信状態の値が閾値以下である）もあり得る。第１の実施形態およびその各変形例や、その他の実施形態でも、変化率や、通信状態の改善または悪化等の表現を用いてきたが、これらについても、本段落で述べた例に準じればよい。
【００８０】
（変化率、通信状態の変化）＝（大きい、改善）
端末がアクセスポイントに急速に近づいていると考えられるため、長時間のプリフェッチを実行すると移動しすぎる（プリフェッチ完了前に、端末がアクセスポイントを通過し遠ざかってしまう）可能性があるので、プリフェッチする情報は、少なめ（深さは浅いレベル）とする。これにより、端末がアクセスポイントに近いタイミングでプリフェッチを完了させ、端末に要求された情報と、プリフェッチした情報との即時送信（Ｓ１１０６）を可能にする。なお、これらの情報の送信の形態としては、前述したような各種のバリエーションが可能である（以下同様）。
【００８１】
（変化率、通信状態の変化）＝（大きい、悪化）    
端末がアクセスポイントから急速に遠ざかっていると考えられるため、プリフェッチはごく一部の取得にとどめて（深さを浅いレベルにし）、あるいはプリフェッチは行わないようにして、速やかに応答を送信する。この場合、即時送信（Ｓ１１０６）の所定の条件を満たした場合に応答の送信を行ってもよいし、第１の実施形態でも述べたように、所定の条件を満たさなくても、送信を行うように動作を変更しても良い。プリフェッチの深さは、測定した通信状態に基づいて決定してもよい。例えば通信状態が良いほど、プリフェッチの深さを深いレベルにしてもよい。また、通信状態が悪いほど、プリフェッチの深さを浅いレベルにしてもよい。
【００８２】
（変化率、通信状態の変化）＝（小さい、改善）
端末がアクセスポイントに徐々に近づいていると考えられるため、長時間のプリフェッチを行って問題ない。すなわち、長時間のプリフェッチを行っても、プリフェッチ完了時に、端末がアクセスポイントに近い位置に存在する、あるいはアクセスポイントに近づいていると想定される。よって、できるだけ多くの情報を取得するようにプリフェッチを実行してよい（深さを深いレベル）。実際には、ユーザの体感を考慮しながら、アプリケーションの設定に基づいて深さを決定する。
【００８３】
（変化率、通信状態の変化）＝（小さい、変化なし）
端末があまり移動していないと考えられるため、通信状態が悪ければ、プリフェッチを実行しないか、ごく一部の情報（深さを浅くする、またはテキスト等の軽量データ）を対象に、プリフェッチを行ってもよい。通信状態が良ければ、プリフェッチを深いレベルで行ってもよい。あるいは、通信状態が良ければ、端末から要求がある都度、要求された情報を送ることで、通信時間や消費エネルギーの問題もないため、プリフェッチを行わないと判断してもよい。
【００８４】
（変化率、通信状態の変化）＝（小さい、悪化）
端末が徐々にアクセスポイントから遠ざかっていると予想されるため、プリフェッチを実行する場合には一部の情報（深さを浅くする）を、プリフェッチの対象とする。プリフェッチの可否については通信状態の値に応じて決定すればよい。プリフェッチの深さは、測定した通信状態に基づいて決定してもよい。例えば通信状態が良い場合は、まだしばらくは通信状態が良い環境に端末がいると想定できるため、プリフェッチの深さを深いレベルにしてもよい。また、通信状態が悪い場合は、プリフェッチの深さを浅いレベルにしてもよい。
【００８５】
なお、（変化率、通信状態の変化）＝（大きい、変化なし）の状況は、存在しないと考えられる。
【００８６】
なお、上述した通信状態の変化の方向と変化率の大きさとの組み合わせに基づく判断は、必ずしもプリフェッチと連携させる必要は無く、第１の実施形態における待機時間およびパラメータの測定間隔の少なくとも一方の決定などにも適用可能である。
【００８７】
＜第３の実施形態のまとめ＞
以上、本実施形態では、アクセスポイントに情報を一時保管するキャッシュ機能と、要求された情報に関連する情報を能動的（自発的に）に取得するプリフェッチ機能を備えることにより、端末に効果的に情報を送信できるようになる。結果として、端末の消費エネルギーをさらに削減させ、システム全体のスループットを向上させることができる。
【００８８】
第１〜第３の実施形態は無線ＬＡＮを対象として説明したが、無線ＬＡＮ以外の無線通信技術に対しても、送信側と受信側の距離が離れることによって通信効率が変化する現象が共通であれば、適用できることは自明である。さらに無線として、いわゆる電波を用いる方法で記載しているが、距離による減衰は電波に固有のものではなく、音波、可視光や赤外線などの物理媒体を使用し、通信速度が変化する通信方式を使用しているものについては適用可能である。
【００８９】
第１〜第３の実施形態では端末からアクセスポイントに情報の取得要求を行い、アクセスポイントから端末に情報を応答として送信する場合を示したが、本発明の実施形態は、アクセスポイントを介さずに、端末同士で直接通信を行う場合において、一方の端末に適用することも可能である。アクセスポイントを介さずに、端末同士で通信する規格として、ＷｉＦｉ  Ｄｉｒｅｃｔ等が知られている。ＷｉＦｉ  Ｄｉｒｅｃｔ対応端末は、その機能を有効にすると、他の端末からはアクセスポイントとして認識され、１対１または１対多の接続が可能である。この場合、情報の取得要求を受ける側の端末に、本発明の実施形態を適用することが可能である。この際、端末構成として、アクセスポイントの構成から、バックボーン側のネットワークと接続する有線Ｉ／Ｆ、および当該有線Ｉ／Ｆおよび無線Ｉ／Ｆ間の転送機能（中継機能）を除去したものを用いてもよい。情報の取得要求を受ける端末は、取得要求された情報を事前に内部の記憶部または外部接続された記憶部に保持しており、相手端末から要求された情報を送信するサーバ機能を有する。この送信の際に、相手端末との通信路の状態に基づいて、情報送信の可否を判断する処理を行うことで、本実施形態の動作を実施できる。
【００９０】
尚、各実施形態に係る通信装置（アクセスポイントまたは端末）は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、通信装置内に各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＡＭ、ＤＶＤ−Ｒなどの記憶媒体などを適宜利用して実現することができる。また、このエネルギー管理装置は、ＬＳＩまたは専用チップにより構成することもできる。
【００９１】
図１６に本発明の実施形態に係る通信装置のハードウェア構成例を示す。ここでは通信装置がアクセスポイントとして実施される場合の構成を示す。端末として実施される場合は、上述したアクセスポイントと端末との差に応じた機能を必要に応じて除去あるいは追加すればよい。
【００９２】
通信端末は、プロセッサ５０１、主記憶装置５０２、補助記憶装置５０３、ネットワークインタフェース５０４、デバイスインタフェース５０５、入力装置５０６、ネットワークインタフェース５０７を備え、これらがバス５０８を介して接続された、コンピュータ装置として実現できる。
【００９３】
プロセッサ５０１が、補助記憶装置５０３からプログラムを読み出して、主記憶装置５０２に展開して、実行することで、各機能ブロックを実現することができる。
【００９４】
ネットワークインタフェース５０４は、アンテナ５０９などを介して、無線ネットワークに接続するためのインタフェースである。無線Ｉ／Ｆ２０１の機能は、このネットワークインタフェースにて実現できる。ネットワークインタフェース５０７は、バックボーン側のネットワークに有線接続するためのインタフェースである。有線Ｉ／Ｆ２０２の機能は、このネットワークインタフェース５０７にて実現できる。
【００９５】
また、デバイスインタフェース５０５は、外部記憶媒体５１０などの機器と接続するインタフェースである。記憶部２０３がアクセスポイントに外部接続またはネットワーク接続されている場合は、外部記憶媒体５１０が、記憶部２０３に相当する。外部記憶媒体５１０は、ＨＤＤ、ＣＤ−Ｒ，  ＣＤ−ＲＷ，  ＤＶＤ−ＲＡＭ，  ＤＶＤ−Ｒ  等の任意の記録媒体でよい。
【００９６】
ユーザは、入力装置５０６から情報を入力してもよい。入力する情報は、アプリケーションに対する指示でもよい。なお、通信装置に、情報を表示する液晶表示装置などの表示装置が追加されてもよい。
【００９７】
主記憶装置５０２は、プロセッサ５０１が実行する命令、および各種データ等を一時的に記憶するメモリ装置であり、ＤＲＡＭ等の揮発性メモリでも、ＭＲＡＭ等の不揮発性メモリでもよい。補助記憶装置５０３は、プログラムやデータ等を永続的に記憶する記憶装置であり、例えば、ＨＤＤまたはＳＳＤ等がある。記憶部２０３または一時記憶部１００３の機能が、主記憶装置５０２、補助記憶装置５０３または外部記憶媒体５１０の少なくともいずれかで実現されてもよい。
【００９８】
上記に、本発明の一実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００９９】
１０１：端末（通信装置）
１００、１０００、１２００：アクセスポイント（通信装置）
１０３：ネットワーク
１０２：サーバ
２００、１００１、１２０３：処理部
２０１：無線Ｉ／Ｆ
２０２：有線Ｉ／Ｆ
２０３：記憶部
２０４：通信処理部
２１０：無線監視部
２１１：通信状態判断部
２１２：アプリケーション
２２０：転送部
２２１：検出部
２２２：通信部
２２３：通信バッファ
５００：通信装置
５０１：プロセッサ
５０２：主記憶装置
５０３：補助記憶装置
５０４：ネットワークインタフェース
５０５：デバイスインタフェース
５０６：入力装置
５０７：ネットワークインタフェース
５０８：バス
５０９：アンテナ
５１０：外部記憶媒体
１００３：一時記憶部
１００２、１２０１：キャッシュ処理部
１２０２：プリフェッチ部
【図２】
2016096431.tif 000003
【図３】
2016096431.tif 000004
【図４】
2016096431.tif 000005
【図５】
2016096431.tif 000006
【図６】
2016096431.tif 000007
【図７】
2016096431.tif 000008
【図８】
2016096431.tif 000009
【図９】
2016096431.tif 000010
【図１０】
2016096431.tif 000011
【図１１】
2016096431.tif 000012
【図１２】
2016096431.tif 000013
【図１３】
2016096431.tif 000014
【図１５】
2016096431.tif 000015
【図１６】
2016096431.tif 000016
【図１】
2016096431.tif 000017
【図１４】
2016096431.tif 000018