JP2016063423A - 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム - Google Patents
情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム Download PDFInfo
- Publication number
- JP2016063423A JP2016063423A JP2014190426A JP2014190426A JP2016063423A JP 2016063423 A JP2016063423 A JP 2016063423A JP 2014190426 A JP2014190426 A JP 2014190426A JP 2014190426 A JP2014190426 A JP 2014190426A JP 2016063423 A JP2016063423 A JP 2016063423A
- Authority
- JP
- Japan
- Prior art keywords
- information
- communication
- unit
- acquisition
- acquisition unit
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W48/00—Access restriction; Network selection; Access point selection
- H04W48/18—Selecting a network or a communication service
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/02—Terminal devices
- H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
【課題】情報の先行取得と低消費電力化とを両立させる。【解決手段】本発明の一態様としての情報処理装置は、先行取得部と制御部とを備える。前記先行取得部は、アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する。前記制御部は、周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する。【選択図】図1
Description
本発明の実施形態は、情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラムに関する。
アプリケーションが発した通信要求を一時的に保存し、当該通信要求を実行可能と判断されたときに、当該通信要求を実行する技術が知られている。また、トラフィックがひっ迫している携帯電話網から、無線LANネットワークへのオフローディングを行う際に、無線LANによる通信が可能となるまで一定時間待機し、その待機時間に上限を設けることが知られている。また、携帯電話網よりも通信効率がよい無線LAN通信が利用できる際に、将来利用が見込まれる情報を先行取得する技術が知られている。
しかしながら、無線LANによる通信が可能となるまで一定時間待機させる場合、待機させる時間が明確ではない、もしくは固定値となっており、柔軟な通信可否の判断ができない。例えば、待機中に、通信可能と判断する基準値をわずかに下回る無線LANエリアを検出しているにもかかわらず、無線LANでの通信を行わず、トラフィックがひっ迫している携帯電話網を使ってデータを送受信してしまう可能性がある。この結果、通信の開始まで長時間待機することとなるとともに、消費エネルギーの増加にもなる。
一方、先行取得する技術に対しては、無線LAN通信が安定して利用できる状況であると、情報を際限なく先行取得してしまう恐れがある。その結果、バッテリー駆動の装置の場合、バッテリーに蓄えたエネルギーを必要以上に消費し、駆動時間が短くなってしまう可能性がある。
Kyunghan Lee , et al., "Mobile Data Offloading: How Much Can WiFi Deliver?", Co-NEXT '10
本発明の実施形態は、情報の先行取得と、低消費電力化を両立させることを目的とする。
本発明の一態様としての情報処理装置は、先行取得部と制御部とを備える。前記先行取得部は、アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する。前記制御部は、周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する。
以下、図面を参照しながら、本発明の実施形態について説明する。ここで示す形態は一例であり、本願発明は、必ずしも同一の形態で実施される必要はない。また、図面において、同一の構成要素には同じ番号を付し、説明は適宜省略する。
(第1の実施形態)
図1に本発明の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。なお、図1には本願発明の説明に必要な要素のみを記しており、他の要素の存在を排除するものではない。
(第1の実施形態)
図1に本発明の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。なお、図1には本願発明の説明に必要な要素のみを記しており、他の要素の存在を排除するものではない。
通信装置100は、中央処理部101、メモリ105、ストレージ106、および通信I/F部107を備える。中央処理部101は、本実施形態に係る情報処理装置に相当する。
中央処理部(情報処理装置)101は、本装置の動作を司る中央処理部であり、アプリ実行部102、通信処理部103、先行取得部104、制御部108を備える。
アプリ実行部102、通信処理部103、先行取得部104、制御部108は、それぞれ個別のハードウェア要素として構成されてもよいし、CPU等のプロセッサの上で動作するソフトウェアによって実現されてもよい。
アプリ実行部102は、通信装置100上で動作するアプリケーション(例えばウェブブラウザ、ニュースアプリ、地図アプリ、動画プレイヤー、音楽プレイヤーなど)の実行を担当する。
通信処理部102は、TCP/IPなどの通信プロトコルを実行する。アプリ実行部101や後述の先行取得部103は、通信処理部102を用いて、ネットワークを介した情報取得を行う。
先行取得部104は、先行取得部104は、アプリ実行部101で動作するアプリケーションからの指示や、ネットワークを介した外部のサーバからの指示に基づき、将来参照する可能性がある情報(すなわちアプリケーションから将来、取得を要求される可能性がある情報)を取得する。たとえば、アプリ実行部101が、自身の要求に応じて取得したHTMLファイル内に含まれるURL等のリンク先を特定し、特定したリンク先の情報の取得の指示を、先行取得部104に指示する。当該情報の取得の実際の要求は、例えばユーザ等によりリンクが指定されたときに行われるが、そのような指定を受ける前に事前に取得しておく。先行取得した情報は、後述するようにURL等の識別子と関連づけて、メモリ105やストレージ106に格納しておく。
また、先行取得部104は、アプリ実行部101で動作するアプリケーションからの要求に応じて取得された情報を独自に解析することにより、将来参照する可能性がある情報を自律的に取得する機能を備えていてもよい。例えば、アプリ実行部101からの要求に応じて取得されたHTMLファイルを受けとってURL等のリンク先を特定し、当該リンク先の情報をネットワークを介して取得してもよい。この場合、アプリ実行部102は、情報の取得要求を先行取得部104に出力するようにし、先行取得部104は当該取得要求に応じて取得した情報(HTMLファイル等)をアプリ実行部102に返すようにしてもよい。先行取得部104は、アプリ実行部102から要求された情報が、先行取得済みである場合はその情報をメモリ105またはストレージ106から読み出して返すことができる。
また、先行取得部104は、アプリ実行部101で動作するアプリケーションからの要求に応じて取得された情報を独自に解析することにより、将来参照する可能性がある情報を自律的に取得する機能を備えていてもよい。例えば、アプリ実行部101からの要求に応じて取得されたHTMLファイルを受けとってURL等のリンク先を特定し、当該リンク先の情報をネットワークを介して取得してもよい。この場合、アプリ実行部102は、情報の取得要求を先行取得部104に出力するようにし、先行取得部104は当該取得要求に応じて取得した情報(HTMLファイル等)をアプリ実行部102に返すようにしてもよい。先行取得部104は、アプリ実行部102から要求された情報が、先行取得済みである場合はその情報をメモリ105またはストレージ106から読み出して返すことができる。
メモリ105はDRAMなどの揮発性メモリや、MRAMなどの不揮発性メモリであり、中央処理部101で実行されるプログラムや、各種のデータなどを一時的に格納する記憶部である。
ストレージ106は、中央処理部101で実行されるプログラムや、各種のデータを、永続的に保存する記憶部である。ストレージ106は、例えば、HDD(ハードディスクドライブ)やSSD(ソリッドステートドライブ)で構成される。
通信I/F部107は、通信処理部103で実行される通信プロトコル(例えばTCP/IPなどの)に従って構成された情報列を、ネットワークとの間で交換するインタフェースである。ネットワークの例としてはLTE、CDMAやGSM、WiMAXなどのセルラー通信技術、IEEE 802.11に準拠する無線LANなどである。
制御部108は、大きく二つの機能を具備する。
第一に、制御部108は、先行取得部104が先行取得を行うか否かを判断するための条件を制御(変更)する。
第二に、制御部108は、周囲の通信環境の把握、および通信装置の現在の状態(装置状態)の把握との少なくとも一方を行い、通信環境および現在の状態の少なくとも一方に基づいて先行取得の可否を判断する。通信環境の把握は、通信I/F部107を用いてRSSIやSN比等のパラメータ値を測定することで可能である。センサを用いた通信環境の把握も可能である。この場合、図2に示すように、センサ109を通信装置100に搭載すればよい。センサ109は、加速度、音、照度、磁気、電流・電圧などのセンサである。センサ109は、中央処理部101によって動作が制御されることができる。また、装置状態は、センサ109を用いて把握できる。例えばセンサ109を用いて、バッテリーなどの一時的な電源手段から給電されているか、ACアダプタ等の恒久的な電源手段から給電されているかを、判断することもできる。
図3に、第1の実施形態に係る第1の動作例のフローチャートを示す。前提として、このフローチャートの処理は、先行取得部104による先行取得処理とは、同時並行的に(時分割を含む)実行されるものとする。ここでは、通信環境および装置状態のうち、通信環境のみ把握する場合を想定する。最初に通信環境Eiを把握(通信環境のパラメータ値を測定)する(S201)。そして、把握した現在の通信環境Eiに基づき、現在の通信環境の評価値を計算する。通信環境Eiの値(パラメータの測定値)そのものを評価値として扱ってもよいし、所定の値域(0〜100の範囲など)内の値に変換したものを評価値としてもよい。評価値を計算したら、当該計算した評価値と、過去に計算された評価値を用いて、短期総合評価値および長期総合評価値を計算する。
すなわち、短期的な変化に基づく総合評価関数Evalshort()と長期的な変化に基づく総合評価関数Evallong()を計算する。これら2つの関数は、現在および過去の通信環境の評価値に基づき、現状が通信にどの程度適しているかを表す短期総合評価値および長期総合評価値(例えば0〜100の間の整数で、値が大きい方が適している)を出力するものである。短期と長期の違いは、例えば参照する過去のデータ数であり、短期の評価関数は、長期の評価関数よりも少ないデータ数を用いる。短期の評価関数Evalshort()の出力値を短期総合評価値Rs、長期の評価関数Evallong()の出力値を長期総合評価値RLとする。
例えば、短期の評価関数の場合はEj(j=i、i−1、…、i−4)を使用して、過去5回の移動平均を短期総合評価値Rsとして算出し、長期の評価関数の場合はEj(j=i、i−1、…、i−19)を使用して、過去20回の移動平均を長期総合評価値RLとして算出する。移動平均を求める際に関数の入力(評価値)に適切に重みづけを行ってもよく、加重移動平均や指数移動平均などの形で使用してもよい。
評価関数Evalshort()とEvallong()の具体例を示す。通信環境Eiが無線LANアクセスポイントから受信する電波の強度(RSSI)の場合を考える。この場合、通信できなくなる下限の強度を0とし、想定される最大の強度を100とする評価値を通信環境Eiの値から計算し、それらの現在および過去の評価値の平均を出力する評価関数が設計できる。通信環境Eiが複数のパラメータからなる場合も同様である。例えば、受信電波強度(RSSI)と信号対雑音比(SNR)で規定されている場合、各々に対して0〜100のスコアをつけ、それらの平均値を評価値とするなどとすればよい。他にも、使用する通信・符号化方式(256QAMや64QAMなど)ごとにRSSIとSNRの組み合わせに対して事前にスコアを決めておき、それらの平均値を評価値とすることもできる。
フローチャートの説明に戻る。S204にて先行取得部104が先行取得動作中か否かを判断する。先行取得動作中だった場合(S204−YES)、ステップS205に進む。S205では短期および長期の総合評価値に基づき、先行取得の可否の判断を行う。短期総合評価値RSが基準値(閾値)Vshort以上であり、かつ長期総合評価値が基準値(閾値)Vlong未満である場合(S205−YES)、先行取得を許可する。すなわち、現在の先行取得動作の現状維持を判断し、一定時間待機(S207)した後、最初のステップS201に戻る。
ここで、短期総合評価値RSが基準値Vshort以上の場合、通信環境は、短期的な視点で通信に適した状態にあると言える。短期総合評価値RSが基準値Vshort未満の場合、通信環境は、短期的な視点で通信に適していない状態にあるといえる。長期総合評価値が基準値Vlong以上の場合、通信環境は、長期的な視点で通信に適した状態にあると言える。長期総合評価値が基準値Vlong未満の場合、通信環境は、長期的な視点で通信に適していない状態にあると言える。ここでは、短期および長期とも総合評価値が閾値(基準値)以上の場合に通信に適した状態と判断したが、測定する通信環境のパラメータ値によっては閾値未満の場合に通信に適した状態と判断する構成も可能である。例えば、通信環境として環境ノイズを測定する場合に、環境ノイズの値に応じた評価値群から計算する短期および長期の総合評価値が閾値未満の場合に、それぞれ通信に適した状態と判断してもよい。
前述の条件を満たしていない場合(S205−NO)、すなわち短期総合評価値RSが基準値Vshort未満、または長期総合評価値が基準値Vlong以上である場合には、先行取得を許可しないと判断し、先行取得を停止する(S206)。そして、一定時間待機(S207)した後、最初のステップ(S201)に戻る。
先行取得中ではない場合(S204−NO)、S208に進む。S208では、S205と同様の判断を行う。上述の条件が満たされる場合(S208−YES)先行取得を開始し(S209)、一定時間待機(207)した後、最初のステップS201に戻る。条件が満たされない場合(S208−NO)、現状維持と判断され、一定時間待機(S207)した後、最初のステップS201に戻る。
一連の説明にて「先行取得を開始」(S209)もしくは「先行取得を停止」(S206)という表現を用いたが、先行取得処理の過程のどの箇所で実際に先行取得の実行と停止を行うかは、実装依存である。先に述べた通り、先行取得処理と、開始または停止の判断処理とは、独立して動作するため、「開始」と「停止」の処理は、例えばソフトウェアによる実装であれば、プロセスもしくはスレッドの起動と停止と、実行中の先行取得プロセスもしくはスレッドとの間に確立されたプロセス間通信などによる制御メッセージの交換(実行指示、停止指示)といった形で実現される。先行取得処理を行うプロセスもしくはスレッドを、どのステップで停止するかは実装依存である。同様に、ハードウェアで実装されている場合には、Enable/Disable信号の設定や、動作クロックの投入と停止などの形で実現できるが、その方法は実装依存である。
図4に、図3のフローチャートに基づく通信装置100における先行取得動作の状態遷移図を示す。長期的な視点で通信に適した状態S1と、短期的な視点で通信に適した状態S2とが存在し、これらの状態間の遷移が示される。なお、この図では、短期総合評価値または長期総合評価値が基準値以上であることをG、基準値より小さいことをB、どちらでもよいことを*と記す。また、各遷移に付された(X、Y)は、短期総合評価値がX、長期総合評価値がYであることを示す。
図4に示すように、短期的な視点で通信に適した状態S2に遷移したら、先行取得を開始し、長期的な視点で通信に適した状態S1が継続している場合には、先行取得を停止する。このように制御することにより、無線LANアクセスポイントのそばから移動しない状況など、通信環境が安定した状態で必要以上に多くの情報を先行取得することを防止できる。その結果、ネットワークを流れるトラフィックを抑制でき、送受信に要するエネルギー消費を抑制できる。
図3のフローチャートの動作例では、通信環境および装置状態のうち通信環境のみを用いて評価を行ったが、以下では、通信環境および装置状態の両方を用いて評価を行う場合を示す。前提として、制御部109は、電源の供給状態を把握することができ、この機能を用いて、商用電源(ACアダプタ)等の連続的な電源供給がなされている場合と、バッテリー等の一時的な電源供給がなされている場合とで、通信装置の装置状態を区別する。
図5に、第2の動作例のフローチャートを示す。変更点は、ステップS202、S401およびS402である。ステップS202では、通信装置100の装置状態Siを把握する。
ステップS401にて電源の供給状態に基づく判断を行う。商用電源等の連続供給可能な電源から供給されていれば(S401−YES)、ステップS402に進む。バッテリー等の連続供給できない電源の場合(S401−NO)には、ステップS205に進む。ステップS205に進んだ後の処理は、図3の動作と同じであるため省略する。
ステップS402では短期総合評価値Rsが、基準値Vshort以上であるか否かを判断する。基準値Vshort以上であれば(S402−YES)、現状維持(先行取得継続)と判断され、一定時間待機(S207)した後、最初のステップS201に戻る。基準値Vshortに達しない場合(S402−NO)、先行取得を停止し(S206)、一定時間待機(S207)した後、最初のステップS201に戻る。
図6に、図5の動作に対応する状態遷移図を示す。図4と異なり、長期的な視点で通信に適した状態S1と、短期的な視点で通信に適した状態S2とを含む状態遷移図が2つ存在し、連続的な電源供給があるか否かの装置状態に応じて、これら2つの状態遷移図が切り換えられる。
以上に述べたように、第2の動作例に従えば、バッテリー等の連続供給できない電源から電力が供給されている場合は、短期的な視点で通信に適した状態に遷移したら、先行取得を開始し、長期的な視点で通信に適した状態が継続している場合には、先行取得を停止する。このように制御することにより、無線LANアクセスポイントのそばから移動しない状況など、通信環境が安定した状態で、必要以上に多くの情報を先行取得することを防止できる。その結果、先行取得に要するエネルギー消費を抑制できる。また、商用電源等の連続供給できる電源から電力が供給されている場合には、通信環境が安定してよい場合には先行取得を継続することができ、より多くの情報をストレージ106に保存しておくことができる。
前述した図3の第1の動作例、および図5の第2の動作例では、総合評価値(短期および長期)を算出する際、通信環境のみを用いたが、装置状態を追加で用いて、総合評価値を算出してもよい。例えば、装置状態として加速度センサを用いて加速度を計算し、過去複数回(短期、長期)の加速度からの変化からユーザの歩行状態(歩いている、静止している、走っている等)を判断し、判断結果に応じて、通信環境から計算したスコアを調整した値を、総合評価値としてもよい。例えば走っているときは、現在の通信環境が変化する可能性が高いとして、通信環境から計算したスコア(例えば0〜100の範囲内の値)を小さく調整し、これを総合評価値としてもよい。
(先行取得処理の詳細)
以下、通信装置100の先行取得部104の動作について、詳細に説明する。先行取得部104は、先に述べた通り、アプリ実行部102で実行されるアプリケーションからの指示(先行取得指示)、もしくは通信I/F部107を介して接続するネットワーク上の通信相手装置からの指示(先行取得指示)に基づいて実行される。または、先行取得部104は、アプリ実行部101で動作するアプリケーションからの要求に応じて取得された情報を解析することにより、アプリ実行部101から指示を受けることなく、将来参照する可能性がある情報を自律的に取得してもよい。
以下、通信装置100の先行取得部104の動作について、詳細に説明する。先行取得部104は、先に述べた通り、アプリ実行部102で実行されるアプリケーションからの指示(先行取得指示)、もしくは通信I/F部107を介して接続するネットワーク上の通信相手装置からの指示(先行取得指示)に基づいて実行される。または、先行取得部104は、アプリ実行部101で動作するアプリケーションからの要求に応じて取得された情報を解析することにより、アプリ実行部101から指示を受けることなく、将来参照する可能性がある情報を自律的に取得してもよい。
ここで先行取得指示とは、(1)ネットワーク上の情報を特定する識別子(URL)が格納されたメモリ領域に関する情報を通知することによる指示、(2)当該URLが格納されたファイルに関する情報を通知することによる指示、(3)IPパケット群などからなるメッセージを通知することによる指示、(4)ファイルのURLを通知することによる指示などである。
上記の(1)と(2)の先行取得指示は、アプリ実行部102からメモリ105もしくはストレージ106を介して先行取得部104に通知することによって行うものである。すなわち、アプリ実行部102がメモリ105上にバッファを確保し、そのバッファ内に将来アクセスが発生すると予想されるURLを格納していき、そのバッファの位置(ポインタ)を先行取得部104に通知するなどの方法が考えられる。同様に、アプリ実行部102がストレージ106上にファイルを作成して、そのファイルにURLを格納していき、ファイル名やファイルディスクリプタ、ファイルクラスのインスタンスなどの形で先行取得部104に通知する。
(3)と(4)の先行取得指示は、ネットワークを介して受け取る指示であり、基本的には、(1)と(2)と同様である。すなわち、(3)の指示は、(1)、(2)で示したような形式の情報が、IPパケットに分割されてネットワークから伝えられることによって、先行取得指示を受信する方法である。(4)の指示は、前述のファイルと同様の形式で記載されたファイルを特定するURLを、ネットワークを介して受信し、通信装置100が該URLからファイルを取得することによって、先行取得指示を入手する方法である。
なお、取得すべき情報のURLが記載されたファイルは、通信装置100にて利用できるフォーマットであれば、どのようなフォーマットであってもよい。例えば、テキストファイル(1行に1つのURLを記載したもの、CSVフォーマット、HTMLフォーマット、XMLフォーマット、CSSフォーマット、など)や、それに所定の操作(圧縮や暗号化など)を施したバイナリファイルなどが考えられる。
図7は、先行取得部104の動作のフローチャートである。これまでに述べた何らかの方法で先行取得指示を入手すると(S601−YES)、先行取得部104は当該指示を解析する(S602)。ここで解析とは、取得すべき情報を特定する処理であり、例えば、HTMLフォーマットに従ったテキストファイルからリンク(URL)を抽出し、リンク先の情報を、取得すべき情報として特定する。メモリ105上に格納される形で、先行取得指示を受信している場合には、解析済みの情報(リンク)が渡されている可能性がある。その場合には、解析処理はスキップしてよい。いずれにせよ、情報を取得すべきURLを抽出し、メモリ105もしくはストレージ106に保存しておく(S602)。なお、先行取得指示が無い場合は(S601−NO)、引き続き待機して、先行取得指示が来るまで待つ(S603)。
この情報を先行取得すべきURLの指示は、先行取得を実行中も追加できるようにしてもよい。これにはメモリ105にFIFOキュー形式で、抽出したURLを格納しておくことで対応が可能である。もしくはストレージ106上のファイルに対して、URLを追記していくことで対応可能である。
図8は、図7のステップS602の詳細な動作のフローチャートである。先行取得処理は、情報を取得すべきURLが、メモリ105もしくはストレージ106に保存されているかを判断する(S611)。URLが保存されていない場合は、一定時間待機して(S620)、ステップS611に戻る。一方、URLが保存されている場合には、アプリ実行部102の動作とは独立して実行される(S611−YES)。
先行取得部104は格納されているURLを、メモリ105もしくはストレージ106から読み出し(S612)、HTTPなどURLで指定された通信プロトコルに従って取得要求メッセージを生成(S613)した後、TCP/IP処理を実行するために通信処理部103に処理を依頼する(S614)。この依頼は、例えば、SocketAPIを介したメッセージと制御情報の交換と捉えることができ、send()などのAPIを実行することで、取得要求メッセージを所定のサーバに送信する。
通信処理部103は受けとった取得要求メッセージを、TCP/IPに従って適切に処理した後、通信I/F部107を介して所定のサーバに送信する。その後、サーバは要求した情報を送り返し、通信I/F部107と通信処理部103を介して、先行取得部104に応答が届く(S615、S616、S617、S618)。先行取得部104は取得した応答内のデータを、情報を識別する識別子(URLなど)と関連づけた状態で、メモリ105もしくはストレージ106に保存しておく(S619)。
以上の処理を、抽出したURLに対して繰り返し実行することで、先行取得が可能となる。
(先行取得処理の実行と、制御部108による取得可否判断の関係)
一連の先行取得処理(図7、図8の処理)は、制御部108による取得可否判断(図3、図5の動作)により、実行の制約を受ける。先に述べた通り先行取得処理と取得可否判断(図3、図5の動作)とは、独立に実行されるため、先行取得処理がソフトウェアで実現されているのであれば、実装上の都合がよい箇所にて、先行取得の実行を中断することができる。
一連の先行取得処理(図7、図8の処理)は、制御部108による取得可否判断(図3、図5の動作)により、実行の制約を受ける。先に述べた通り先行取得処理と取得可否判断(図3、図5の動作)とは、独立に実行されるため、先行取得処理がソフトウェアで実現されているのであれば、実装上の都合がよい箇所にて、先行取得の実行を中断することができる。
例えば、取得すべきURLを読み出すステップ(S612)の実行タイミングにて、取得可否判断の結果を参照し、取得不可であれば、以降の処理を実行しないようにすればよい(S612の前に判断処理を加え、先行取得が許可されていなければステップS620に遷移して、一定時間待機するようにすればよい)。この方法を採用した場合、先行取得部104の内部で処理の実行と停止が実現できる。ただし、制御できる通信は先行取得部104で行う通信のみとなる。
一方、発行された取得要求メッセージが、ネットワークに送信されないように制御するという実装にすることもできる。この場合、通信処理部103に手を加え、通信I/F部107に送信される直前、もしくは通信プロトコル処理のいずれかのステップで、取得可否判断の結果を参照し、以降の処理を実行しないようにすればよい(S614の部分)。この方法を採用した場合、通信プロトコル処理の改変を伴うため実装が難しくなると考えられるが、汎用的に通信を制御することができると考えられる。
なお、先に述べた通り、実行と停止の実現方法は、ソフトウェアであればプロセスもしくはスレッドの起動と停止、プロセスもしくはスレッドの停止状態への遷移と復帰などで実現でき、ハードウェアであればクロックの投入と停止、電源の投入と停止などにより実現できる。
(補足説明:短期総合評価値と長期総合評価値および基準値の扱いについて)
第1の実施形態に関する一連の説明において、通信環境Eiおよび装置状態Siの少なくとも一方と、評価関数Evalshort()、Evallong()を使って短期総合評価値および長期総合評価値を得るとの説明をした。この部分について、図9を使ってより直感的に説明する。
第1の実施形態に関する一連の説明において、通信環境Eiおよび装置状態Siの少なくとも一方と、評価関数Evalshort()、Evallong()を使って短期総合評価値および長期総合評価値を得るとの説明をした。この部分について、図9を使ってより直感的に説明する。
図9は第1の実施形態の動作の具体例を説明するための図である。図9には各評価のタイミングで取得した生データ(評価値)の系列(700)、過去5回の生データから得た移動平均(短期総合評価値)の系列(701)、過去20回の生データから得た移動平均(長期総合評価値)の系列(702)、基準値(703)が示されている。図9の下側の「短期」と「長期」の行は、基準値に対する状態(Gが上回っている、Bが下回っていることを示す)を示す。ここでは、基準値は、短期と長期で共通としている(Vshort=Vlong)
既に述べたように、第1の実施形態では、図4もしくは図6に述べたような、状態遷移を行う。図9に記載のように、基準値に対する総合評価値(長期、短期)の上下関係が分かっているとき、図4もしくは図6の状態遷移図に従えば、先行取得機能の実行状態は、図9の下側の「先行取得」の行のようになる(ただし図9は図4の状態遷移図に基づいている)。
最初、長期および短期とも総合評価値が低く、先行取得を停止しており(区間704)、この後、短期の総合評価値が高くなったため、通信環境がある程度安定したと判断されて、先行取得が開始される(区間705)。その後、短期および長期とも総合評価値が高くなり、通信環境が長時間安定していることが確認できたと判断されて、先行取得は停止する(区間706)。その後、通信環境が短期的に悪化し(短期の総合評価値が低くなり)、さらに長期的にも悪化し(長期の総合評価値も低くなり)、先行取得は停止したままである(区間707、708)。その後、短期的に総合評価値が高くなったとき、長期の総合評価値が低くても、通信環境がある程度安定したと判断されて、先行取得が開始されるが(区間709)、その後、再び、短期の総合評価値が低くなったため、通信環境が悪化したと判断されて、先行取得は停止される(区間710)。なお、移動平均として考慮する区間の長さを変えることによって、ごく短時間の改善(短時間のみ総合評価値がよくなる状態)は、無視するように調整することもできる。
以上、第1の実施形態によれば、ネットワークを介して情報を取得する通信装置は、先行取得の機能によるメリットを享受しながら、安定的に通信が継続できる環境を検出することができ、結果的に情報を無制限に取得し続けることが避けられる。また、バッテリーのように一時的な電源供給手段を利用している際には、エネルギー消費と先行取得によるメリットとを両立できる。
(第2の実施形態)
第1の実施形態では、通信環境Eiと装置状態Siの少なくとも一方を取得して総合評価値を計算し、先行取得の可否を判断していた。これに対して、本実施形態では、先行取得済みのデータ量も用いて、先行取得の可否を判断する。
第1の実施形態では、通信環境Eiと装置状態Siの少なくとも一方を取得して総合評価値を計算し、先行取得の可否を判断していた。これに対して、本実施形態では、先行取得済みのデータ量も用いて、先行取得の可否を判断する。
図10に、第2の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。図1と同じ名称の要素には、同一の符号を付してある。図1で示した通信装置の中央処理部101に、情報管理部110が追加されている。他の部分は、以下に述べる事項を除き、第1の実施形態と同じ動作をする。
情報管理部110は、先行取得した情報に関する統計情報を管理する。例えば、先行取得部104によって先行取得されてメモリ105もしくはストレージ106に保存されている情報の数やサイズ、アプリ実行部102から先行取得指示された回数やサイズや割合、アプリ実行部102によって参照され且つメモリ105もしくはストレージ106の情報を使ってアプリ実行部102に応答できた回数やサイズや割合、先行取得したが参照されていない情報のサイズや割合などがある。先行取得部104およびアプリ実行部102からメモリ105もしくはストレージ106に格納する/された情報へのアクセスを、情報管理部110経由で行うことで、一時管理情報管理部109は、これらの管理情報を管理できる。
なお、アプリ実行部102が要求したサイズのうち、メモリ105もしくはストレージ106から取得できなかった情報のサイズは、別途アプリ実行部102から通知されると仮定する。なお、メモリ105およびストレージ106から取得できなかった情報の取得については、アプリ実行部102で実行されるアプリケーションの一部動作を情報管理部110が肩代わりするように実装し、情報管理部110が通信相手から当該情報を取得することも可能である。この場合、アプリ実行部102が要求したサイズのうち、情報管理部110は、メモリ105もしくはストレージ106から取得できなかった情報のサイズを自ら把握できるようになる。
以下、情報管理部110が、先行取得部104が先行取得した情報のサイズおよびアプリ実行部102が要求したサイズ、ならびに、実際にメモリ105もしくはストレージ106から読み出されたサイズを管理しているものとして説明する。
この仮定のもと、図11を用いて、第2の実施形態の動作の具体例を説明する。以下の説明では、「情報管理部110に『アプリ要求された情報の2倍まで先行取得許可、それ以上は不許可』と制御するルールが設定されている」と仮定する。
図11に3つのグラフが示される。横軸が経過時間、縦軸がサイズである。グラフ900は、先行取得部104がこれまで(原点を起点とした場合)取得した情報の合計サイズを表し、グラフ901はアプリ実行部102がこれまでに要求した情報の合計サイズを表し、グラフ902は、アプリ実行部102の要求に対して、メモリ105およびストレージ106からこれまでに読み出された情報の合計サイズを表す。
経過時間の軸の下に、各時間における先行取得の許可・不許可の判断結果を示す区間903−1〜903−3を表示している。区間903−1〜903−3の判断結果は、制御部108の判断結果であり、第1の実施形態で述べた環境および装置状態の少なくとも一方から、判断されたものである。また、この図では、常に(先行取得した合計サイズ)>(要求した合計サイズ)>(読み出した合計サイズ)の関係が成り立っており、先行取得した情報が読み出されているものの、一部は通信相手から直接、情報を取得している状態であることが分かる。この図は一例であり、この関係とは異なる関係になっていてもよい(例えば、先行取得した情報量以上にアプリ実行部102からの要求がある場合、など)。さらに図11おける各グラフの増加率(=合計サイズ/経過時間)についても一例であり、実際にはネットワークの状態変動や、アプリ実行部102で発生する要求の頻度などにより増加率は変化し、実装した場合には、階段状(不連続)に変化することもあると考えられる。
区間903−1では制御部108により先行取得が許可されており、グラフ900で示すように先行取得した合計サイズが増加している。区間903−2に入った段階で先行取得が制御部108により不許可になり、グラフ900は変化しない。途中でアプリケーション(アプリ実行部102)からの要求が発生し、グラフ901とグラフ902が増加していく。ここではアプリ実行部102から要求されたデータの一部がメモリ105およびストレージ106のいずれかから読み出せた場合を想定している。アプリ実行部102の当該要求の実行が完了し、その後、新たに要求も発生しなくなると、グラフ901とグラフ902の変化も止まる。
区間903−3に入り再び制御部108により先行取得が許可されると、グラフ900の値が増加する。途中、アプリ実行部102の要求が発生して、グラフ901とグラフ902が一時的に増加する。一方、グラフ900は、経過時間904にて、変化が止まっている。これは本実施形態における情報管理部110の制御により、先行取得が不許可に変化したためである(先の仮定通り、先行取得した情報のサイズ(双方向矢印付きの線905の部分)が、アプリ実行部102が要求した情報の合計サイズ(双方向矢印付きの線906の部分)の2倍に達している)。つまり、制御部108により先行取得が許可されていても、情報管理部110により不許可と判断されたため、全体の判断結果として、先行取得は不許可とされる。なお、双方向矢印付きの線907は、アプリ実行部102が要求した合計サイズと、メモリ105およびストレージ106から読み出した合計サイズとの差を示している。
このように第2の実施形態では、第1の実施形態での先行取得の許可・不許可の判断に加え、先行取得した情報のサイズなどに関する統計情報をさらに使って、先行取得の許可・不許可の判断を行い、これらの両方の判断結果を利用する。両方の判断結果が許可の場合のみ、先行取得を許可する。いずれか一方が不許可の場合に、先行取得を許可しない。このようにすることで、より直感的に先行取得する情報量を制御でき、ひいては消費エネルギーの削減につながる。また、ある程度の先行取得は行うため、利便性との両立も可能である。なお、ここで述べた条件は一例であり、『2倍』には限定されないし、『先行取得した情報の合計サイズと要求した情報の合計サイズの関係』にも限定されない。関係としては『先行取得した情報の合計サイズと読み出された情報の合計サイズ』や『要求した情報の合計サイズと読み出された情報の合計サイズ』でもよい。また、サイズではなく回数や個数、割合(先行取得情報に対する読み出し割合、など)であってもよい。
ただし、先行取得した情報に対する読み出し率は、先行取得を行うほど低下するので、当該読み出し率を条件として先行取得の許可・不許可の判断を行う場合には、先行取得量に対する読み出し率の予測値が必要となる。すなわち、合計Xバイトの先行取得を行った際に確率αを乗じて得られるαXバイトが、将来読み出されるなどの仮定をおいたうえで、全体の予想読み出しサイズを決定して、先行取得の許可・不許可を判断する必要がある。図12は、第2の実施形態の動作の他の具体例として、その様子を模式的に示したものである。先行取得済みの合計サイズを表すグラフ1000と、アプリ実行部の要求サイズの合計を表すグラフ1001と、読み出されたサイズの合計を表すグラフ1002が記載されている。区間1011では制御部108により先行取得が不許可と判断されており、区間1012では制御部108により許可と判断されている。
図12では、区間1012が始まるタイミングで先行取得が開始され、取得済みサイズの合計を表すグラフ1000の値が増加している。一方、アプリ実行部102からの要求が発生していないため、要求サイズの合計を表すグラフ1001の値は変化していない。当然、読み出しサイズの合計を表すグラフ1002の値も変化しないが、確率αで読み出されると仮定して、将来の読み出しサイズを求める。点線のグラフ1004は、当該将来の読み出しサイズを表している。この将来の読み出しサイズが、所定のサイズ(ここではαs)に達した段階(経過時間1005)で、先行取得を終了する。制御部108では先行取得は許可されたままであるが、情報管理部110の判断により、停止される。
一連の説明は情報管理部110の判断により先行取得を停止する場合を述べたが、情報管理部110の判断により先行取得を開始することも可能である。例えば、アプリケーションから要求された情報を先行取得していない状況で、アプリケーションからの要求に応答した場合『先行取得した情報による応答率』が低下する。この値が、ある閾値を下回った場合に、情報管理部110は、先行取得を許可するよう制御してもよい。
図13を用いて、第2の実施形態の動作のさらに他の具体例を説明する。情報管理部110が、アプリ実行部102の要求に対して先行取得した情報で応答ができた割合を管理している場合に、閾値である下限PLと上限PHを用いて、先行取得の実行と停止を制御する例を説明する図である。PLとPHの決定方法は任意でよいが、例えば、前述した応答率や、読み出し率などが考えられる。図13の上には、先行取得済みサイズの合計を表すグラフ1100と、アプリ実行部102から要求されたサイズの合計を表すグラフ1101を示し、図13の下には、応答率のグラフ1102を示す。
区間1101では制御部108の判断により先行取得が不許可であり、区間1102以降は許可されている。区間1102は先行取得が許可されているが、まだ実行されていない。これは、情報管理部110により先行取得の再開が保留(停止)されているためである。この段階では、先行取得した合計サイズに対する応答率Pが下限閾値PL以上であり、先行取得の効果があると見なされるので、先行取得を再開しない。一方、アプリ実行部102により要求されてデータが読み出されたとする。この時、先行取得したデータからはあまり読み出すことができず、ネットワークを介して直接取得するサイズが多かったと仮定すると、応答率が低下していく。最終的に、区間1102と区間1103の境目で、応答率が下限PLに達している。これを契機に、区間1103〜区間1104では、情報管理部110による先行取得の保留が解除され、先行取得が実行される。先行取得を行うことで、応答できる可能性がある情報が増えるため、応答率が徐々に回復すると考えられる。最終的に、区間1104と区間1105の間で上限値PHに到達したため、先行取得を終了する。
以上、第2の実施形態によれば、情報管理部110の管理によって、先行取得の実行と停止が管理される。情報管理部110にて、情報の先行取得や読み出しを管理するため、先行取得したデータ量や、先行取得した情報による応答率などを考慮した制御が可能となる。このため、第1の実施形態よりも、細かい制御が実現でき、効率よくエネルギーの削減と、利便性の両立が実現できる。
(第3の実施形態)
図14に、第3の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。これまでの実施形態とは異なり、通信装置には通信モジュール200が搭載されている。通信処理部、メモリおよびストレージは、中央処理部101側(ホスト側)と通信モジュール200側の双方に存在するので、それぞれ「第1」および「第2」を付けて呼ぶことにする。すなわち、ホスト側を第1通信処理部103A、第1メモリ105A、第1ストレージ106A、通信モジュール側を第2通信処理部103B、第2メモリ105B、第2ストレージ106Bと呼ぶ。第1及び第2の実施形態で述べた先行取得部104および制御部108は、通信モジュール200に備えられている。また、第1及び第2の実施形態で述べた通信処理部、メモリおよびストレージの機能は、第3の実施形態では、主に第2通信処理部103B、第2メモリ105Bおよび第2ストレージ106Bにて実現される。
図14に、第3の実施形態に係る情報処理装置を搭載した通信装置の機能ブロック図を示す。これまでの実施形態とは異なり、通信装置には通信モジュール200が搭載されている。通信処理部、メモリおよびストレージは、中央処理部101側(ホスト側)と通信モジュール200側の双方に存在するので、それぞれ「第1」および「第2」を付けて呼ぶことにする。すなわち、ホスト側を第1通信処理部103A、第1メモリ105A、第1ストレージ106A、通信モジュール側を第2通信処理部103B、第2メモリ105B、第2ストレージ106Bと呼ぶ。第1及び第2の実施形態で述べた先行取得部104および制御部108は、通信モジュール200に備えられている。また、第1及び第2の実施形態で述べた通信処理部、メモリおよびストレージの機能は、第3の実施形態では、主に第2通信処理部103B、第2メモリ105Bおよび第2ストレージ106Bにて実現される。
中央処理部101は、アプリ実行部102および第1通信処理部103Aに加え、第1オフロード部131を備える。第1オフロード部131は、アプリ実行部102で実行されるアプリケーションや、第1通信処理部103Aで実行される通信処理の全部もしくは一部を、通信モジュール200にオフロード(委任)するための事前処理・事後処理を担当する。
例えば、アプリ実行部102でウェブブラウザやRSSリーダなどHTTPを使って情報を取得する通信アプリケーションが稼働する場合、取得に伴う通信プロトコルの処理やTCP/IPによる通信そのものを、通信モジュール200にオフロードできる。これらをオフロードするために、アプリ実行部102は、情報の取得要求をオフロード部132に通知する。オフロード部132は、通信モジュール200に追加された第2オフロード部132との間で事前に定められた形式にしたがって、アプリケーションの処理や通信処理をオフロードする。
通信モジュール200は、第2メモリ105B、第2ストレージ106Bおよび通信I/F部107に加えて、モジュール処理部121を備える。モジュール処理部121は、第2通信処理部103B、先行取得部104、制御部108に加えて、第2オフロード部132を備える。第2オフロード部132は、第1オフロード部131からオフロードする処理の内容の通知を受け取り、その通知にしたがって、先行取得部104もしくは第2通信処理部103Bに指示を出す。具体的には、先に述べたような、HTTPを用いた情報の取得要求であれば、先行取得部104に指示を出し、単なる通信処理の要求であれば、第2通信処理部103Bに指示を出す。なお、第1通信処理部103Aと第2通信処理部103Bとの間で機能的に重複する処理があってもよく、第1通信処理部103Aで実行した処理は、第2通信処理部103Bでは行わなければよい。例えば、IPヘッダまで第1通信処理部103Aで生成されているのであれば、第2通信処理部103Bでは、対応するルーティング処理とレイヤー2以下の処理を実行する。第1通信処理部103Aでレイヤー3までのすべての処理が完了しているのであれば、第2通信処理部103Bは、そのまま通信I/F部107に転送するだけという事もありうる。
第2オフロード部132を介して先行取得部104に通知された処理は、第1もしくは第2の実施形態で述べた通り処理される。その結果、第2メモリ105Bもしくは第2ストレージ106Bに、取得した情報が蓄積される。この情報は、先行取得部104の処理結果を応答として、第2オフロード部132を介して中央処理部101に返す際に、当該情報と合わせて、第1メモリ105Aもしくは第1ストレージ106Aにコピー、もしくは移動するようにしてもよい。それらの作業の代わりに、第2メモリ105Bもしくは第2ストレージ106Bに記録された情報へのアクセス手段(例えば、ファイル名やセクタ位置、アドレスなど第2メモリ105Bまたはストレージ106Bにて保存された情報の場所や長さを特定できる情報)を、処理結果の応答と合わせて、返すようにしてもよい。この場合、中央処理部101は、適切な手段を通じて通信モジュール200上の第2メモリ105Bもしくは第2ストレージ106B上の情報にアクセスする。
なお、図14では、中央処理部101に第1通信処理部103Aが存在する形で記載したが、この第1通信処理部が無い構成も可能である。その場合、中央処理部101では、通信処理を行わず、情報の取得処理の要求を第1オフロード処理部131に指示し、その応答を第1オフロード処理部131から受け取る形にすればよい。
さらに図14では、第1オフロード処理部131と第2オフロード処理部132が互いに連携して、先行取得やオフロード処理に伴う指示や応答に関する情報を交換するとした。変形例として、第1オフロード処理部131と第2オフロード処理部132を省略した構成も可能である。その場合、第1通信処理部103Aが送受信するパケットを、通信モジュール200上で(例えば第2通信処理部103Bが)取得し、内部を解析して、情報の取得要求を検出し、先行取得部104に転送すればよい。この時、先行取得部104が、例えば、透過型プロキシサーバのように振る舞うことで、中央処理部101で動作するアプリケーションに影響を与えることなく動作できるようになる。先行取得部104は、情報の取得要求に対して、先行取得済みの情報があればそれを返し、無ければ新たに取得するよう動作すればよい。その際、関連する情報を新たに先行取得すれば、第1及び第2の実施形態と同様の動作が実現できる。
以上、第3の実施形態によれば、中央処理部101とは独立した通信モジュールに先行取得部や制御部を実行することにより、先行取得機能を独立して実現することができ、中央処理部101の負荷を低減して、中央処理部で動作する従来のアプリケーションなどの影響を最小限に抑えることができる。また、既存の装置に、モジュール的にハードウェアを追加して、ソフトウェアをインストールすることで、先行取得機能が利用できるようになる。
(第4の実施形態)
本実施形態では、通信装置内の各部を、使用されないときには電源をオフにするもしくは低消費電力な状態に遷移させる形態を示す。ここでは第3の実施形態の通信装置を例に述べるが、第1および第2の実施形態の通信装置でも、同様に実施可能である。
本実施形態では、通信装置内の各部を、使用されないときには電源をオフにするもしくは低消費電力な状態に遷移させる形態を示す。ここでは第3の実施形態の通信装置を例に述べるが、第1および第2の実施形態の通信装置でも、同様に実施可能である。
先に述べたように第3の実施形態では、原則として、第1オフロード部131と第2オフロード部132の間で、指示と応答を交換する。この動作の前後に、通信モジュール200もしくは中央処理部100や、中央処理部100を含むホスト部の動作状態を変更するような信号を追加することで、動作状態の変更が実現できる。これにより、通信モジュール200は、通信時および先行取得時のみ通電され、もしくは動作状態となり、それらの動作が終了したら、電源オフもしくは低消費電力な状態に遷移するように、通信装置全体を構成できる。なお、電源オフもしくは低消費電力な状態への遷移は、通信モジュール200自身が判断して自発的に遷移してもよいし、ホスト側の中央処理部101が応答の受信を完了したことを検出して、通信モジュール200に状態遷移するように指示してもよい。
同様に、中央処理部101、もしくは中央処理部101、第1メモリ、第1ストレージ106Aを含むホスト部も、通信モジュール200が動作している状態(例えば先行取得中)には、電源オフもしくは低消費電力な状態に遷移し、通信モジュール200の動作が完了した場合に、電源オンもしくは動作状態に遷移するようにすることもできる。通信モジュール200からの復帰信号には、何らかのハードウェア割り込み信号を用いるのが一般的であるが、通信モジュール200の処理が終了する時間を想定して、その時間の値を事前に設定されたタイマーを利用して復帰するようにしてもよい。あるいは、固定値が設定されたタイマーなど他の手段を利用して復帰するようにしてもよい。
以上、第4の実施形態によれば、中央処理部101、中央処理部101等を含むホスト部、または通信モジュール200が動作していない間に、低消費電力な状態へと遷移させることによって、装置全体の消費電力をさらに下げることができる。
(第5の実施形態)
図15に、第5の実施形態に係る情報処理装置を搭載した端末を示す。この端末は、第1の実施形態に係る通信装置に、入力インタフェース141と表示装置142を追加したものである。入力インタフェース141は、ユーザ入力用のインタフェースであり、キーボードやマウス、タッチパネル等がある。表示装置142は、メモリ105に格納されたデータを画像で表示する。表示装置142は、例えば液晶表示パネル、CRTパネル、有機ELパネル、電子ペーパーなど、画像表示できる装置であれば、何でもかまわない。その他、ハードディスクやSSDなどの補助記憶装置が、追加で接続されてもよい。図15の端末は、パーソナルコンピュータ(PC)、ノート型PC、タブレット端末、スマートフォン、ウェアラブル装置、カメラなど、通信機能を搭載する任意の装置でよい。第2〜第4の実施形態に対しても同様に、入力インタフェースおよび表示装置を追加して、端末を構成することも可能である。
図15に、第5の実施形態に係る情報処理装置を搭載した端末を示す。この端末は、第1の実施形態に係る通信装置に、入力インタフェース141と表示装置142を追加したものである。入力インタフェース141は、ユーザ入力用のインタフェースであり、キーボードやマウス、タッチパネル等がある。表示装置142は、メモリ105に格納されたデータを画像で表示する。表示装置142は、例えば液晶表示パネル、CRTパネル、有機ELパネル、電子ペーパーなど、画像表示できる装置であれば、何でもかまわない。その他、ハードディスクやSSDなどの補助記憶装置が、追加で接続されてもよい。図15の端末は、パーソナルコンピュータ(PC)、ノート型PC、タブレット端末、スマートフォン、ウェアラブル装置、カメラなど、通信機能を搭載する任意の装置でよい。第2〜第4の実施形態に対しても同様に、入力インタフェースおよび表示装置を追加して、端末を構成することも可能である。
尚、各実施形態に係る情報処理装置および通信装置は、例えば、汎用のコンピュータ装置を基本ハードウェアとして用いることでも実現可能である。すなわち、上記のコンピュータ装置に搭載されたプロセッサにプログラムを実行させることにより実現出来る。このとき、情報処理装置および通信装置は、上記のプログラムをコンピュータ装置にあらかじめインストールすることで実現することや、各種の記憶媒体に記憶、あるいはネットワークを介して上記のプログラムを配布、このプログラムをコンピュータ装置に適宜インストールすることで実現が出来る。また、情報処理装置および通信装置内の各記憶部は、上記のコンピュータ装置に内蔵あるいは外付けされたメモリ、ハードディスクもしくはCD−R、CD−RW、DVD−RAM、DVD−Rなどの記憶媒体などを適宜利用して実現することができる。
本発明は上記実施形態そのままに限定されず、実施段階では要旨を逸脱しない範囲で構成要素を変形し具体化出来る。上記実施形態に開示されている複数の構成要素の適宜な組み合わせで、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除出来、異なる実施形態に渡る要素を適宜組み合わせることも出来る。
100:通信装置
101:中央処理部
102:アプリ実行部
103、103A、103B:通信処理部
104:先行取得部
105、105A、105B:メモリ
106、106A、106B:ストレージ
107:通信I/F部
108:制御部
109:センサ
110:情報管理部
121:モジュール処理部
131:第1オフロード部
132:第2オフロード部
141:入力インタフェース
142:表示装置
101:中央処理部
102:アプリ実行部
103、103A、103B:通信処理部
104:先行取得部
105、105A、105B:メモリ
106、106A、106B:ストレージ
107:通信I/F部
108:制御部
109:センサ
110:情報管理部
121:モジュール処理部
131:第1オフロード部
132:第2オフロード部
141:入力インタフェース
142:表示装置
Claims (14)
- アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得部と、
周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御部と
を備えた情報処理装置。 - 前記制御部は、前記評価値に基づき、前記周囲の通信環境が通信に適した環境か否かを判断し、前記通信に適した環境が一定時間続いたときは、前記先行取得部の動作を停止させる
請求項1に記載の情報処理装置。 - 前記制御部は、前記周囲の通信環境が通信に適さない環境から前記通信に適した環境に遷移した後、第1の時間長の間、前記通信に適した環境にあるときは、前記先行取得部を動作させ、前記一定時間として前記第1の時間長より長い第2の時間長の間、前記周囲の通信環境が前記通信に適した環境にあるときは、前記先行取得部の動作を停止させる
請求項2に記載の情報処理装置。 - 前記第1の時間長の時間の間に取得された評価値の平均が閾値以上または以下のときは、前記周囲の通信環境が、前記第1の時間長の間、前記通信に適した環境にあると判断し、
前記第2の時間長の時間の間に取得された評価値の平均が前記閾値以上または以下のときは、前記周囲の通信環境が、前記第2の時間長の間、前記通信に適した環境にあると判断する
請求項3に記載の情報処理装置。 - 前記制御部は、第1の電源および前記第1の電源よりも長い時間電力を供給可能な第2の電源のいずれから電力の供給を受けているかを判断し、前記第2の電源から電力の供給を受けている場合は、前記通信に適した環境が前記一定時間続いても、前記先行取得部の動作を停止させない
請求項2ないし4のいずれか一項に記載の情報処理装置。 - 前記先行取得部により取得される複数の情報に関する統計情報を管理する情報管理部を備え、
前記情報管理部は、前記統計情報に基づき前記先行取得部の動作を許可するか否かを判断し、
前記制御部は、前記評価値に基づき、前記先行取得部の動作を許可するか否かを判断し、
前記情報管理部の判断結果と、前記制御部の判断結果に基づいて、前記先行取得部の動作を制御する
請求項1ないし5のいずれか一項に記載の情報処理装置。 - 前記統計情報は、
(1)前記先行取得部によって取得された情報の数、または前記情報のサイズ、
(2)前記先行取得部が前記アプリケーションから先行取得を指示される場合に前記アプリケーションから先行取得を指示された回数またはサイズ、
(3)前記アプリケーションによって取得要求された際に前記記先行取得部によって取得済みの情報を使って応答できた回数またはサイズまたは割合
(4)前記先行取得部によって取得した情報のうち前記アプリケーションから取得要求がされていない情報の数、サイズまたは割合
の少なくとも1つを含む、請求項6に記載の情報処理装置。 - 前記情報管理部は、前記統計情報に基づく値を、前記統計情報に対応して予め与えられた閾値と比較することにより、前記先行取得部の動作を許可するか否かを判断する
請求項7に記載の情報処理装置。 - 前記情報管理部は、前記(1)〜(4)の項目のうち少なくとも2つの項目に関する値の関係に基づいて、前記先行取得部の動作を許可するか否かを判断する
請求項7に記載の情報処理装置。 - 前記先行取得部は、前記制御部と前記情報管理部の両方により許可された場合のみ、前記情報の取得を行う
請求項6ないし9のいずれか一項に記載の情報処理装置。 - 請求項1ないし10のいずれか一項に記載の情報処理装置と、
前記ネットワークと無線通信を行う通信インタフェース部と、
を備えた通信装置。 - 請求項1ないし10のいずれか一項に記載の情報処理装置と、
前記ネットワークと無線通信を行う通信インタフェース部と、
前記先行取得部で取得されたデータを格納するメモリと、
前記情報処理装置に対して指示を行うユーザ入力用の入力インタフェースと、
前記メモリ内のデータを画像表示する表示装置と
を備えた端末。 - アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得ステップと、
周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御ステップと
をコンピュータが実行する情報処理方法。 - アプリケーションから要求される可能性がある情報を特定し、前記アプリケーションから前記情報の取得を要求される前に、前記情報をネットワークを介して取得する先行取得ステップと、
周囲の通信環境を計測したパラメータ値に応じた評価値に基づき、前記先行取得部の動作を制御する制御ステップと
をコンピュータに実行させるためのコンピュータプログラム。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014190426A JP2016063423A (ja) | 2014-09-18 | 2014-09-18 | 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム |
US14/857,025 US20160088520A1 (en) | 2014-09-18 | 2015-09-17 | Information processing device, communication apparatus, terminal, communication processing method, and non-transitory computer readable medium |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2014190426A JP2016063423A (ja) | 2014-09-18 | 2014-09-18 | 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2016063423A true JP2016063423A (ja) | 2016-04-25 |
Family
ID=55527072
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2014190426A Pending JP2016063423A (ja) | 2014-09-18 | 2014-09-18 | 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム |
Country Status (2)
Country | Link |
---|---|
US (1) | US20160088520A1 (ja) |
JP (1) | JP2016063423A (ja) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2016063424A (ja) * | 2014-09-18 | 2016-04-25 | 株式会社東芝 | 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7680897B1 (en) * | 2003-04-08 | 2010-03-16 | Novell, Inc. | Methods and systems for managing network traffic |
JP4352312B2 (ja) * | 2003-08-08 | 2009-10-28 | ソニー株式会社 | 情報処理装置および方法、プログラム、並びに記録媒体 |
JP5393977B2 (ja) * | 2007-12-27 | 2014-01-22 | ソニー株式会社 | 情報処理装置、情報処理方法、コンテンツ授受システム、およびコンピュータプログラム |
CA2785052C (en) * | 2009-12-21 | 2020-10-27 | Francis Fernandes | Method and system for obtaining location information regarding a device in a wireless network |
US8594021B2 (en) * | 2010-07-19 | 2013-11-26 | Qualcomm Incorporated | Effective timing measurements by a multi-mode device |
GB2493785B (en) * | 2011-08-19 | 2016-04-20 | Sca Ipla Holdings Inc | Wireless communications system and method |
US9258764B2 (en) * | 2013-01-29 | 2016-02-09 | Broadcom Corporation | System and methods for anonymous crowdsourcing of network condition measurements |
EP3022960B8 (en) * | 2013-07-16 | 2019-10-09 | Avast Software s.r.o. | Mobile device tracking prevention method and system |
US9407563B2 (en) * | 2013-08-12 | 2016-08-02 | Qualcomm Incorporated | Methods and apparatuses for adapting application uplink rate to wireless communications network |
JP2016019101A (ja) * | 2014-07-07 | 2016-02-01 | 株式会社東芝 | タイミング決定装置、タイミング決定方法およびコンピュータプログラム |
US10158413B2 (en) * | 2015-05-08 | 2018-12-18 | Newracom, Inc. | Uplink sounding for WLAN system |
-
2014
- 2014-09-18 JP JP2014190426A patent/JP2016063423A/ja active Pending
-
2015
- 2015-09-17 US US14/857,025 patent/US20160088520A1/en not_active Abandoned
Also Published As
Publication number | Publication date |
---|---|
US20160088520A1 (en) | 2016-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
AU2017201532B2 (en) | Wake pattern management | |
US9939876B2 (en) | Operating system management of network interface devices | |
US8892710B2 (en) | Keep alive management | |
JP6076501B2 (ja) | 無線ネットワークのオン・オフを制御するための方法、装置、設備、システム、プログラム及び記録媒体 | |
US20130279331A1 (en) | Method for multipath scheduling based on a lookup table | |
US8655338B2 (en) | Method for operating portable terminal to reduce power during support of communication service and portable terminal supporting the same | |
EP2697713A2 (en) | Management of background tasks | |
KR20150032554A (ko) | 무선 연결을 통한 콘텐트의 에너지 효율적 전송 기법 | |
US10075920B2 (en) | Method and apparatus for controlling traffic in electronic device | |
US20230199049A1 (en) | Modifying content streaming based on device parameters | |
US20130073669A1 (en) | Peer-to-peer data migration | |
WO2019127954A1 (zh) | 一种网络性能提升的方法及设备 | |
WO2018161788A1 (zh) | 多媒体数据共享方法及装置 | |
WO2018219118A1 (zh) | 界面显示方法及相关产品 | |
CN110401691B (zh) | 一种资源下载控制方法、装置及终端 | |
US20230328647A1 (en) | Wi-Fi Adaptive Beacon Skipping for Battery-Powered Devices | |
JP2016063423A (ja) | 情報処理装置、通信装置、端末、通信処理方法およびコンピュータプログラム | |
US9535699B2 (en) | Processor, multiprocessor system, compiler, software system, memory control system, and computer system | |
JPWO2015151548A1 (ja) | 電子機器および記録媒体 | |
WO2023024894A1 (zh) | 一种多设备同步播放方法及装置 | |
JP2014026315A (ja) | 情報処理装置、データ提供方法、及びデータ提供プログラム | |
KR20150093341A (ko) | 클라우드 스트리밍 서비스 시스템, 클라우드 스트리밍 서비스 제공 방법 및 이를 위한 장치 |