(57)【要約】【課題】通信時における消費電力を低減する。【解決手段】通信先となる通信装置との通信で用いられる受信ウィンドウサイズを、通信先となる通信装置から受信する送受信部と、送受信部が受信した受信ウィンドウサイズに基づいて、遷移する電力モードを判定する電力モード判断部と、通信先となる通信装置との間でデータを送受信したタイミングで、判定を要求するプロトコルスタック部と、電力モード判断部が判定した電力モードにしたがって、電力を制御する電力モード制御部と、を備える。【選択図】図２
2017027196.tif 000002
【特許請求の範囲】
【請求項１】
通信先となる通信装置との通信で用いられる受信ウィンドウサイズを、前記通信先となる通信装置から受信する送受信部と、
前記送受信部が受信した前記受信ウィンドウサイズに基づいて、遷移する電力モードを判定する電力モード判断部と、
前記通信先となる通信装置との間でデータを送受信したタイミングで、前記判定を要求するプロトコルスタック部と、
前記電力モード判断部が判定した前記電力モードにしたがって、電力を制御する電力モード制御部と、
を備えることを特徴とする通信装置。
【請求項２】
前記電力モード判断部は、前記通信装置のバッファの使用または空き状態に基づいて、遷移する電力モードを判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項３】
前記電力モード制御部は、あらかじめ前記通信装置に組み込まれまたは指定された前記受信ウィンドウサイズのしきい値に基づいて、遷移する電力モードを判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項４】
前記電力モード判断部は、所定のアプリケーションがユーザからの指定に基づいて設定した前記しきい値に基づいて、遷移する電力モードを判定する、
ことを特徴とする請求項３に記載の通信装置。
【請求項５】
前記プロトコルスタック部は、前記通信先となる通信装置との間のRTT（Round-Trip  Time）を計測し、
前記電力モード判断部は、前記RTTの計測値が前記RTTのしきい値を満たすか否かを判定し、前記RTTの計測値が前記RTTのしきい値を満たさないと判定した場合、電力モードを遷移させない、
ことを特徴とする請求項１に記載の通信装置。
【請求項６】
前記通信装置は、複数の前記通信先となる通信装置と通信し、
前記電力モード判断部は、前記通信装置と複数の前記通信先となる通信装置のそれぞれとの間の通信で生成されるセッションごとに、遷移する電力モードを判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項７】
前記電力モード判断部は、前記セッションごとに設定された優先度に基づいて、遷移する電力モードを判定する、
ことを特徴とする請求項６に記載の通信装置。
【請求項８】
ハードウェアにより構成された前記プロトコルスタック部が、前記受信ウィンドウサイズの変化を検知した場合に割り込み信号を出力し、
前記電力モード判断部は、前記ハードウェアにより構成された前記プロトコルスタック部が前記割り込み信号を出力したか否かを判定し、前記前記割り込み信号を出力したと判定した場合に、遷移する電力モードを判定する、
ことを特徴とする請求項１に記載の通信装置。
【請求項９】
通信先となる通信装置との通信で用いられる受信ウィンドウサイズを、前記通信先となる通信装置から受信し、
受信された前記受信ウィンドウサイズに基づいて、遷移する電力モードを判定し、
前記通信先となる通信装置との間でデータを送受信したタイミングで、前記判定を要求し、
判定された前記電力モードにしたがって、電力を制御する、
ことを特徴とする電力制御方法。
【請求項１０】
コンピュータに、
通信先となる通信装置との通信で用いられる受信ウィンドウサイズを、前記通信先となる通信装置から受信する処理と、
受信された前記受信ウィンドウサイズに基づいて、遷移する電力モードを判定する処理と、
前記通信先となる通信装置との間でデータを送受信したタイミングで、前記判定を要求する処理と、
判定された前記電力モードにしたがって、電力を制御する処理と、
を実行させることを特徴とする電力制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置、電力制御方法、及び電力制御プログラムに関する。
【背景技術】
【０００２】
従来から、組み込み機器で使用される通信機器では、消費電力の低減が求められている。このような要請に対して、例えば、パケットの種類に応じて電力モードを変更する技術、受信バッファに格納されているパケット件数に応じて電力モードを変更する技術がある。さらには、データ流量に応じて電力モードを変更する技術、プロトコルタイマの値を使用して予測スリープ時間を算出することにより電力モードを変更する技術がある。
また、通信プロトコルであるTCP（Transmission  Control  Protocol）では、データの送受信の前にコネクション/セッションを確立して通信を行うこと、送信元からのデータ通信に対して送信先はACK（acknowledgement）パケットでその応答を行うことが知られている。さらに、再送タイマーや持続タイマーなどのタイマーが管理されていること、送受信に関わるバッファが管理されることが知られている。特に通信相手の受信ウィンドウ（バッファ）に空きがない場合は、受信ウィンドウが空いたことに関する通知を送信先が受信するまで送信待ちすることなどが知られている。
例えば、特許文献１では、通信機器の消費電力を低減させるために、送受信間隔やプロトコルタイマ値を利用し、予測スリープ時間を算出することにより電力モードを切り替える構成が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
特許文献１では、通信に係るデータに応じて電力モードを切り替えているが、データ送信待ちが発生した場合に消費電力を無駄にするという問題は解消できていない。より具体的には、特許文献１では、図１２に例示するように、通信機器からのデータ送信時（ａ）における応答（ｂ）に基づいて予測スリープ時間を設定し、これに応じて電力モードを遷移させている。しかし、通信相手の受信バッファに空きがない場合、図１３に例示するように、受信ウィンドウサイズが0であることを通知するACKが返信される場合がある（ｃ）。このとき、通信機器は予測スリープ時間に合わせて電力モードを遷移させているが、通信相手の受信バッファに空きが無いため、データを送信することができず、消費電力を無駄にしてしまう。
このように、従来技術における電力モード制御方式では、組み込み機器からのパケット送信時において、次の問題があった。すなわち、パケット送信の効率を向上させるためにより消費電力が高い電力モードに変更したにもかかわらず、通信相手の性能等によっては送信待ちやパケットの再送を行う必要が発生し、その間の消費電力が無駄になってしまうという問題があった。
本発明は、上記に鑑みてなされたものであって、通信時における消費電力を低減することが可能な通信装置を提供することを目的とする。
【課題を解決するための手段】
【０００４】
上記課題を解決し、目的を達成するために、本発明にかかる通信装置は、通信先となる通信装置との通信で用いられる受信ウィンドウサイズを、前記通信先となる通信装置から受信する送受信部と、前記送受信部が受信した前記受信ウィンドウサイズに基づいて、遷移する電力モードを判定する電力モード判断部と、前記通信先となる通信装置との間でデータを送受信したタイミングで、前記判定を要求するプロトコルスタック部と、前記電力モード判断部が判定した前記電力モードにしたがって、電力を制御する電力モード制御部と、を備えることを特徴とする通信装置として構成される。
【発明の効果】
【０００５】
本発明の通信装置によれば、通信時における消費電力を低減することが可能となる。
【図面の簡単な説明】
【０００６】
【図１】本発明にかかる通信装置、電力制御方法、及び電力制御プログラムを適用した通信機器が行う通信処理の概要を示す図である。
【図２】通信機器が行う通信処理のメリットの概要を示す図である。
【図３】通信機器のハードウェア構成を示す図である。
【図４】通信機器のソフトウェア構成を示す図である。
【図５】通信機器による通信開始時のシーケンス図である。
【図６】通信機器によるデータ送信時のシーケンス図である。
【図７】電力モード判定テーブルの例を示す図である。
【図８】通信機器によるデータ受信時のシーケンス図である。
【図９】RAMに確保されている送受信バッファの空き状態を含めた電力モード判定テーブルの例を示す図である。
【図１０】通信開始時に電力モードが指定される場合のシーケンス図である。
【図１１】ステップＳ６０７で行われる電力モードを判断する処理の処理手順を示すフローチャートである。
【図１２】従来技術の例を示す図である。
【図１３】従来技術の課題の例を示す図である
【発明を実施するための形態】
【０００７】
以下に添付図面を参照して、本発明にかかる通信装置、電力制御方法、及び電力制御プログラムの実施の形態を詳細に説明する。なお、以下では、本発明にかかる通信装置、電力制御方法、及び電力制御プログラムを、TCP通信で用いられる通信機器に適用した場合について説明しているが、これに限らず、様々なセッション指向の通信に適用することができる。
【０００８】
以下に示すように、本実施の形態における通信機器では、消費電力/クロック制御の処理に際して、通信相手の受信ウィンドウおよび自身の送受信バッファを監視し、通信相手の受信ウィンドウサイズの値に基づき電力モードを制御する特徴がある。
【０００９】
図１は、本発明にかかる通信装置、電力制御方法、及び電力制御プログラムを適用した通信機器１００が行う通信処理の概要を示す図である。通信機器１００には、一般的なコンピュータと同様に、後述するハードウェアやソフトウェアが実装されている。
図１に示すように、通信機器１００では、通信先である対向通信機器２００に対して、セグメントごとに分割されたパケットを送信（send_data）した後のタイミングで電力モードを変更する（１）。また、通信機器１００は、対向通信機器２００から受信したパケット（ack(rx  window)）により通知される対向機器２００の受信ウィンドウサイズの値に基づいて、電力モードの遷移条件を判定する（２）。
図１に示すように、通信機器１００では、セグメント単位で電力モードを判定し、対向通信機器２００から受信ウィンドウサイズの値を受信した場合にはその受信ウィンドウサイズの値に応じて電力モードを判定する。さらに、通信機器１００では、送信するセグメントが最後のセグメントである場合、必ず電力消費が低くなる低電力モード（Low  Power）に電力モードを遷移させる。これらの具体的な処理については後述する。
【００１０】
図２は、通信機器１００が行う通信処理のメリットの概要を示す図である。従来処理では、対向通信機器２００の内部処理が遅延している等、対向通信機器２００が通信機器１００に対してZero  Window（ack(rx  windowzero)）を通知する場合においても、あらかじめ予測された時間に応じて電力モードが遷移されてしまう。しかし、本方式では、通信機器１００が上記Zero  Windowを受信した場合に電力モードを判定して最新の状態に更新し（３）、低電力モードを維持することが可能となっている。
【００１１】
図３は、通信機器１００のハードウェア構成を示す図である。図３に示すように、通信機器１００は、演算装置であるCPU（Central  Processing  Unit）１０１と、不揮発記憶装置であるROM（Read  Only  Memory）１０２と、書き換え可能なメモリ装置であるRAM（Random  Access  Memory）１０３と、電力制御装置であるPower  Control  Unit１０４と、ネットワーク・インターフェース装置であるNetwork  I/F１０５とを有している。
CPU１０１は、ROM１０２もしくはROM１０２に格納されたプログラムを実行する。ROM１０２は、上記プログラムや通信機器１００が実行する通信処理に必要なデータを記憶する。RAM１０３は、上記プログラムの実行領域であり、通信機器１００の送受信バッファ等、通信処理に必要な領域を確保する。Power  Control  Unit１０４は、CPU１０１やバス・各ペリフェラルに対するクロック供給を制御する。Network  I/F１０５は、アプリケーションにより生成された各種情報を送受信する。
【００１２】
図４は、通信機器１００のソフトウェア構成を示す図である。図４に示すように、通信機器１００は、機能的には、アプリケーション部１０１１と、プロトコルスタック部１０１２と、ネットワークデータ送受信部１０１３と、電力モード判断部１０１４と、電力モード制御部１０１５とを有して構成されている。
アプリケーション部１０１１は、 ユーザから要求されたアプリケーションを実行する。例えば、アプリケーション部１０１１は、外部サーバに対する認証処理アプリケーションやセンサ情報の送信アプリケーションを実行する。
プロトコルスタック部１０１２は、 アプリケーション部１０１１から要求されたデータを構成するパケットの送受信処理を実行する。また、プロトコルスタック部１０１２は、TCP/IPに関する情報を保持/解釈し、パケット生成/解析処理を実行し、通信単位であるセグメントごとにパケットを分割する。さらに、プロトコルスタック部１０１２は、パケット送受信のタイミングにおいて、電力モード判断部１０１４に対して電力モードの変更要求をする。上記TCP/IPに関わる情報とは、例えば、TCPステート、TCP送受信バッファの情報やRTT（Round-Trip  Time）、対向通信機器２００の受信ウィンドウサイズなど、セッション通信に関する様々な情報が含まれる。
ネットワークデータ送受信部１０１３は、 プロトコルスタック部１０１２により生成されたパケットをNetwork  I/F１０５を利用してネットワークに送信する。また、ネットワークデータ送受信部１０１３は、Network  I/F１０５が受信したパケットをプロトコルスタック部１０１２に通知する。
電力モード判断部１０１４は、 プロトコルスタック部１０１２から受け取った電力モードの変更要求により、電力モードを変更するか否か、どのモードに変更するのかといった変更判断をする。また、電力モード判断部１０１４は、その変更判断の結果、電力モード制御部１０１５に対して電力モードを変更する指示をする。
電力モード制御部１０１５は、 電力モード判断部１０１４から受け取った上記指示にしたがって、Power  Control  Unit１０４により電力モードを変更する。
【００１３】
なお、上記アプリケーション部１０１１、プロトコルスタック部１０１２、ネットワークデータ送受信部１０１３、電力モード判断部１０１４、電力モード制御部１０１５が有する各機能は、実際には、上記ROM１０２にインストールされたプログラムをCPU１０１が読み出して実行することにより実現される。
【００１４】
これらのプログラムは、上記ROM１０２に予め組み込まれて提供されるほか、インストール可能な形式又は実行可能な形式のファイルでCD-ROM、CD-R、DVD（Digital  Versatile  Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供、配布してもよい。さらには、上記プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供したり、配布してもよい。
【００１５】
図５は、通信機器１００による通信開始時のシーケンス図である。図５に示すように、通信機器１００では、アプリケーション部１０１１が、アクターであるユーザからアプリケーションの実行指示を受け付ける（ステップＳ５０１）。アプリケーション部１０１１は、その指示基づいて、プロトコルスタック部１０１２に対して、対向通信機器２００に対する通信処理の開始要求を通知する（ステップＳ５０２）。
プロトコルスタック部１０１２は、アプリケーション部１０１１から受け取った上記開始要求に基づいて、対向通信機器２００との間で通信するための新規セッションを生成する（ステップＳ５０３）。プロトコルスタック部１０１２は、対向通信機器２００に対するSYNパケットをネットワークデータ送受信部１０１３に出力する（ステップＳ５０４）。その後、ネットワークデータ送受信部１０１３は、プロトコルスタック部１０１２から受け取った上記SYNパケットを対向通信機器２００に送信する。
ネットワークデータ送受信部１０１３は、対向通信機器２００からACKパケットを受信すると、そのACKパケットをプロトコルスタック部１０１２に出力する（ステップＳ５０５）。
プロトコルスタック部１０１２は、ネットワークデータ送受信部１０１３から受け取ったACKパケットから、対向通信機器２００が通信時に受信可能な受信ウィンドウサイズの最大値を取得し、RAM１０３に記憶する（ステップＳ５０６）。上記受信ウィンドウサイズは、データ送受信時の電力モードを判断するために必要となる情報である。RAM１０３に記憶された上記受信ウィンドウサイズの最大値は、電力モード判断部１０１４により読み取られる。なお、後述するように、通信セッション終了時には、電力モード判断部１０１４による判断の結果にしたがって、電力モード制御部１０１５が、電力モードを低電力モードに移行させる。
プロトコルスタック部１０１２は、上記受信ウィンドウサイズの最大値を記憶すると、ACKパケットをネットワークデータ送受信部１０１３に出力する（ステップＳ５０７）。その後、ネットワークデータ送受信部１０１３は、プロトコルスタック部１０１２から受け取った上記ACKパケットを対向通信機器２００に送信する。ステップＳ５０７の処理が終了すると、図５に示したシーケンスが終了する。
【００１６】
図６は、通信機器１００によるデータ送信時のシーケンス図である。上述したように、通信機器１００は、データ送信時に、遷移すべき電力モードを判定し、判定した電力モードに遷移させる。
アプリケーション部１０１１は、アクターであるユーザからアプリケーションで処理されるデータの送信指示を受け付ける（ステップＳ６０１）。アプリケーション部１０１１は、その指示基づいて、プロトコルスタック部１０１２に対して、そのデータの送信処理要求を通知する（ステップＳ６０２）。
このとき、アプリケーション部１０１１は、上記データの送信先となる対向通信機器２００のセッション情報及び、通信機器１００が必要とする送受信バッファおよび上記データのサイズを引き渡す。このデータのサイズは、ネットワーク送受信部１０１３が送信する１パケットごとのサイズより大きい場合もある。なお、図６では、ユーザから上記送信指示を受け付けた場合について説明したが、アプリケーション部１０１１が、図５に示したＳ５０７の処理終了後に続けて実行してもよい。
プロトコルスタック部１０１２は、アプリケーション部１０１１から受け取ったデータを、TCP/IPで用いられるパケット形式に変換し、変換後のパケットを対向通信機器２００に送信するための送信処理を実行する（ステップＳ６０３）。この送信処理では、次のステップＳ６０４〜Ｓ６０８までの処理が、セグメントごとに実行される。
具体的には、プロトコルスタック部１０１２は、アプリケーション部１０１１から送信対象となるデータを受け取ると、そのデータをセグメント単位に分割し、上記パケット形式に変換する。そして、プロトコルスタック部１０１２は、セグメント単位に分割されたパケットの送信処理要求を、ネットワーク処理部１０１３に通知する（ステップＳ６０４）。
【００１７】
さらに、プロトコルスタック部１０１２は、上記送受信バッファをRAM１０３上に確保し（ステップＳ６０５）、電力モード判断部１０１４に対して電力モードの変更要求を通知する。このとき、プロトコルスタック部１０１２は、送信するパケットが最終セグメントを含むパケットであるか否かによって、電力モード判断部１０１４に対して、異なる電力モードの変更要求をする（ステップＳ６０６）。
具体的には、プロトコルスタック部１０１２は、送信するパケットが最終セグメントのパケットでないと判定した場合には、電力モード判断部１０１４に対して、その時点でRAM１０３に記憶されている対向通信機器２００の受信ウィンドウサイズの値を通知し、電力モードの遷移を判定する要求を通知する。対向通信機器２００から受信ウィンドウサイズの値を受信する処理については、図７を用いて後述する。
【００１８】
一方、プロトコルスタック部１０１２は、送信するパケットが最終セグメントのパケットであると判定した場合、対向通信機器２００の受信ウィンドウサイズの値にかかわらず、電力モード判断部１０１４に対して電力モードを低電力モードに遷移する要求を通知する。なお、最終的な電力モードの判断は、電力モード判断部１０１４が実行する。その理由は、通信機器１００内部の他のアプリケーションが実行されている場合や複数のセッションが生成されている場合、プロトコルスタック部１０１２がこれらの処理の影響を受けて適切な電力モードに遷移できなくなることを回避するためである。
電力モード判断部１０１４は、対向通信機器２００から受信した受信ウィンドウサイズの値と、図５のステップＳ５０６で通信開始時に記憶された受信ウィンドウサイズの最大値と、あらかじめROM１０２に記憶されている電力モード判定テーブル１０２１とを参照し、遷移する電力モードを決定する（ステップＳ６０７）。なお、上記受信ウィンドウサイズの値は、本ステップの処理実行時点でRAM１０３に記憶されているものである。
そして、電力モード判断部１０１４は、電力モード制御部１０１５に対して、決定した電力モードで電力を制御する要求をする（ステップＳ６０８）。その後、電力モード制御部１０１５は、電力モード判断部１０１４から要求された電力モードで通信機器１００の電力を制御する。
【００１９】
図７は、電力モード判定テーブル１０２１の例を示す図である。電力モード判定テーブル１０２１は、電力モード判断部１０１４が、遷移させるべき電力モードを判定するためのテーブルである。図７に示すように、電力モード判定テーブル１０２１は、判定条件と電力モードとが対応付けて記憶されている。判定条件として、対向通信機器２００から受信した受信ウィンドウサイズの値の大きさ（小：Rx  Empty、中：Rx  Mid、大：Rx  Full）が定められている。また、電力モードとして、通信機器１００が遷移する電力レベル（高：High  Power、中：Mid  Power、低：Low  Power）が定められている。この例では、対向通信機器２００から受信した受信ウィンドウサイズの値が小である場合、電力モードが高に遷移する。すなわち、上記受信ウィンドウサイズの値が小さい場合には対向通信機器２００の送受信バッファに空きが多くあるため、通信機器１００を高電力モードに遷移させることを表している。
【００２０】
なお、上記例では、電力モードが３つのレベルに遷移する場合について説明しているが、その判定方法として、以下の手法をとることができる。
例えば、電力モード判断部１０１４は、通知された対向通信機器２００の受信ウィンドウサイズの値と、図５のステップＳ５０６で記憶された受信ウィンドウサイズの最大値とを比較し、その比率に応じて判定することができる。具体的には、電力モード判断部１０１４は、上記受信ウィンドウサイズの値が上記受信ウィンドウサイズの最大値の1/3未満の場合（0<(通知された受信ウィンドウサイズの値)<(上記受信ウィンドウサイズの最大値)/3）には、判定条件が小（Rx  Empty）であると判定する。
また、電力モード判断部１０１４は、上記受信ウィンドウサイズの値が上記受信ウィンドウサイズの最大値の1/3以上であってその2/3未満の場合（上記受信ウィンドウサイズの最大値)/3<=(通知された受信ウィンドウサイズの値)<(上記受信ウィンドウサイズの最大値)*2/3）には、判定条件が中（Rx  Mid）であると判定する。
さらに、電力モード判断部１０１４は、上記受信ウィンドウサイズの値が上記受信ウィンドウサイズ最大値の2/3以上であってその最大値未満の場合（上記受信ウィンドウサイズの最大値)*2/3<=(通知された受信ウィンドウサイズの値)<(上記受信ウィンドウサイズの最大値)には、判定条件が大（Rx  Full）であると判定する。
【００２１】
なお、上記例では、制御される電力モードが、High  Power/Mid  Power/Low  Powerの３つのレベルに遷移する。これは、CPU１０１の動作クロックに対応し、High  Powerの場合には動作クロックを400MHz、Mid  Powerの場合には動作クロックを100MHz、Low  Powerの場合には動作クロックを50MHzのように変更することと対応づけられる。これ以外にも、バスの周波数や各ペリフェラルの周波数などを組み合わせて、それぞれ電力モードを定義、変更してもよい。
【００２２】
このように、通信機器１００は、セグメントごとの送信処理が終了した時点で、そのときにRAM１０３に記憶されている受信ウィンドウサイズの値を用いて電力モードを変更している。したがって、上記通信機器１００では、セグメント単位で、対向通信機器２００の通信処理性能よりも過剰な速度で送信処理を行うことを防止し、より低消費電力で送信処理を行うことができる。また、上記通信機器１００では、最終セグメント送信時には必ず低消費電力モードに移行している。このため、対向通信機器２００からの応答を待ち受ける間に行うべき処理がないにもかかわらず高電力モードで動作することを回避し、より低消費電力で送信処理を行うことができる。
【００２３】
図８は、通信機器１００によるデータ受信時のシーケンス図である。上述したように、通信機器１００は、データ受信時においても電力モードの遷移を判定し、電力モードを遷移させる。
ネットワークデータ送受信部１０１３は、対向通信機器２００から受信したパケットを検知し、プロトコルスタック部１０１２に対して通知する（ステップＳ８０１）。
プロトコルスタック部１０１２は、ネットワークデータ送受信部１０１３から受け取ったパケットをアプリケーション部１０１１で使用される形式に変換するための受信処理を実行する（ステップＳ８０２）。
さらに、プロトコルスタック部１０１２は、上記送受信バッファをRAM１０３上に確保してＳ８０１でパケットとともに通知された受信ウィンドウサイズの値をRAM１０３に記憶する（ステップＳ８０３）。その後、プロトコルスタック部１０１２は、電力モード判断部１０１４に対して電力モードの変更要求を通知する（ステップＳ８０４）。
電力モード判断部１０１４は、ステップＳ８０３で記憶された受信ウィンドウサイズの値と、図５のステップＳ５０６で通信開始時に記憶された受信ウィンドウサイズの最大値と、上記電力モード判定テーブルとを参照し、遷移する電力モードを決定する（ステップＳ８０５）。
電力モード判断部１０１４は、電力モード制御部１０１５に対して、決定した電力モードで電力を制御する要求をする（ステップＳ８０６）。その後、電力モード制御部１０１５は、電力モード判断部１０１４から要求された電力モードで通信機器１００の電力を制御する。
また、プロトコルスタック部１０１２は、ネットワークデータ送受信部１０１３からセグメント単位に分割されたパケットをアプリケーションで用いられる形式に変換し、アプリケーション部１０１１に引き渡す（ステップＳ８０７）。
【００２４】
これにより、例えば、対向通信機器２００から、ステップＳ８０１においてZero  Windowが通知された場合には、その通知されたタイミングで電力モードを低電力モードに遷移させることが可能となるため、より低消費電力で通信を行うことができる。
このように、本実施例では、通信相手となる対向通信機器２００の受信ウィンドウの値（すなわち、利用率）に応じて電力モードを切り替えるので、TCPのようなセッション志向の通信において、消費電力を効率的に低減ができる。
【００２５】
なお、上記通信機器１００は、上記実施例や下記変形例を適宜組み合わせて実施し、より適切な電力制御を行うことが可能である。
例えば、図７に示した電力モード判定テーブル１０２１に通信機器１００の送受信バッファの状態を示す項目を追加することが可能である。
【００２６】
図９は、電力モード判定テーブル１０２１に、RAM１０３に確保されている送受信バッファの空き状態を含めた電力モード判定テーブル１０２２の例を示す図である。図９では、電力モード判定テーブル１０２１に記憶される各情報について示していないが、実際には、電力モード判定テーブル１０２１と電力モード判定テーブル１０２２とが対応づけて記憶されている。
図９に示すように、電力モード判定テーブル１０２２では、上記判定条件と、送受信バッファの状態とが対応付けて記憶されている。図９では、図７に示した場合と同様、判定条件として、対向通信機器２００から受信した受信ウィンドウサイズの値の大きさが定められている。また、通信機器１００の送受信バッファの状態として、使用されている領域の大きさ（小：Tx  Empty、中：Tx  Mid、大：Tx  Full）が定められている。
電力モード判断部１０１４は、図７に示した場合と同様に、データ送受信のタイミングでこのテーブルを参照し、確保した送受信バッファと使用中の送受信バッファとの比を算出し、その比に基づいて電力モードを判定する。
例えば、電力モード判断部１０１４は、対向通信機器２００から受信した受信ウィンドウサイズの値が中（すなわち、判定条件が中）であると判定した場合、さらに、通信機器１００の送受信バッファの状態を確認する。電力モード判断部１０１４は、電力モード判定テーブル１０２２を参照し、通信機器１００の送受信バッファが使用されておらず十分空きがある（すなわち、小：Tx  Emptyの状態である）と判定した場合、対向通信機器２００よりも自機器の送信処理能力のほうが高いと判断し、電力モードをLow  Powerに遷移させる。図７では、電力モード判断部１０１４が、判定条件が中であると判定した場合、電力モードがMid  Powerに遷移するが、この構成によればLow  Powerに遷移するため、より通信機器１００の消費電力を抑えることが可能となる。すなわち、通信の多寡に応じて、より適切な電力モードに遷移させ、低消費電力化を実現することができる。
【００２７】
なお、本例では、使用中の送受信バッファを用いた場合について示したが、空いている送受信バッファとの比を算出してもよい。さらに、送信バッファと受信バッファとが分かれている場合には、確保した送信バッファまたは受信バッファと使用中または空いている送信バッファまたは受信バッファとの比を算出してもよい。
このような方式により、対向通信機器２００と通信機器１００の性能を相対的に比較することができるため、対向通信機器２００の性能に合わせつつ低消費電力で通信することができる。
また、他の変形例として、対向通信機器２００から受信した受信ウィンドウサイズの値と受信ウィンドウサイズの最大値との比以外の電力モードの判定条件を用いることが可能である。
例えば、対向通信機器２００から受信した受信ウィンドウサイズの最大値が小さい場合、判定条件の幅（すなわち、Rx  Empty、Rx  Mid、Rx  Fullそれぞれの範囲）が狭くなる。その結果、電力モードの遷移回数が増えてしまい省電力効果を得にくい場合が生じ得る。
【００２８】
そこで、電力モード判断部１０１４が、対向通信機器２００から受信した受信ウィンドウサイズのしきい値に基づいて電力モードを判断してもよい。上記しきい値は、電力モード判断部１０１４が、判定条件の大きさのレベルを判定するための値である。上記しきい値は、通信機器１００のROM１０２に事前に設定値として組み込まれても良いし、通信を行うアプリケーション部１０１１ごとに、所定のインタフェースを介して、ユーザまたは管理者等の外部から設定されてもよい。この場合、ユーザまたは管理者等が意図したしきい値を設定することができる。上記しきい値は、例えば、以下のように設定される。
【００２９】
<即値に基づく固定値>
Rx  EmptyとRx  Midとの間のしきい値を8Kbyteとし、Rx  MidとRx  Fullとの間のしきい値を16Kbyteとする。
【００３０】
<通信時に決定されるMSS（Maximum  Segment  Size）に基づく指定値>
Rx  EmptyとRx  Midとの間のしきい値を4*MSSとし、Rx  MidとRx  Fullとの間のしきい値を8*MSとする。ここで、MSSは通信開始時に、通信機器１００と対向通信機器２００との間で整合される値であり、１パケットあたりの最大送信可能データサイズである。
【００３１】
<自通信機器の送受信バッファに基づくしきい値>
Rx  EmptyとRx  Midとの間のしきい値を1/3*TxBufferとし、Rx  MidとRx  Fullとの間のしきい値:2/3*TxBufferとする。
【００３２】
このような方式により、通信機器１００の通信能力や送受信バッファのサイズと対向通信機器２００の受信ウィンドウサイズの値とに差異があり、両者の通信性能に偏りがある場合においても、適切に通信機器１００の消費電力モードを維持することが可能となる。
さらに、他の変形例として、 送信処理時の電力モードの判定条件に、RTTの計測結果を用いることができる。
【００３３】
先に示した構成では、図６のステップＳ６０６で説明したように、最終セグメントのパケットを送信して一連の送信処理が終了した後、低電力モードに遷移する。しかし、通信規格がOnLinkやEthernet（登録商標）の場合においてはRTTが高速となる。そのため、通信機器１００が都度電力モード変更するとオーバーヘッドを生じ、余分な電力を消費することが考えられる。そのため、電力モード判断部１０１４は、RTTがしきい値以下である場合、電力モード変更を行わないようにする。
【００３４】
具体的には、あらかじめROM１０２にRTTのしきい値を記憶しておき、プロトコルスタック部１０１２が、図６のステップＳ６０４の処理を実行したときに、RTTの計測を開始する。プロトコルスタック部１０１２は、あらかじめ記憶されているRTTのしきい値を読み出し、ステップＳ６０６の処理を実行したときに、読み出したその値を電力モード判断部１０１４に引き渡し、図８のＳ８０１の処理を実行して対向通信機器２００からの応答を受信したときに、RTTの計測を終了する。上記RTTの計測は、実際には、プロトコルスタック部１０１２が不図示のタイマを監視して行われる。
電力モード判断部１０１４は、例えば、上記RTTの計測値が上記RTTのしきい値を満たすか否かを判定し、上記RTTのしきい値に満たない場合、判定条件が中であると判定した場合であっても、電力モードをMid  Powerに遷移させることなく、その時点の電力モードを維持する。
このような方式により、通信の応答時間がしきい値で指定された時間よりも短い場合には電力モードを変更しないため、電力モードの変更に伴う処理のオーバーヘッドを抑えることが可能となる。
【００３５】
また、他の変形例として、 アプリケーション側から電力モードをロックする仕組みを電力モード判定条件に設定することができる。
先に示した構成では、通信機器１００は、対向通信機器２００との通信において対向通信機器２００の受信ウィンドウサイズの値が小さく、対向通信機器２００に余裕がある限り電力モードを高電力モードにして高速に通信し、余裕がなければ低電力モードに遷移させた。しかし、アプリケーションによっては、対向通信機器２００に余裕がある場合でも、必ずしも高速に通信する必要がなく、常に低電力モードで動作させたい場合もある。例えば、一定期間ごとにログを送信するようなアプリケーションなどがこれに該当する。
このような場合には、以下に示すように、ロックしたい電力モードを、通信機器１００のROM１０２に事前に設定値として組み込まれても良いし、通信を行うアプリケーション部１０１１ごとに、所定のインタフェースを介して、ユーザまたは管理者等の外部から設定されてもよい。
【００３６】
<通信開始時の処理>
図１０は、通信開始時に電力モードが指定される場合のシーケンス図である。図１０に示すように、図５に示した場合と同様、アプリケーション部１０１１が、アクターであるユーザから、アプリケーションの実行指示とともに、所望の電力モードをロックする指示を受け付ける（ステップＳ１００１）。
アプリケーション部１０１１は、図５のステップＳ５０２の場合と同様、プロトコルスタック部１０１２に対して通信処理の開始要求を通知するとともに、プロトコルスタック部１０１２からセッションIDを取得する（ステップＳ１００２）。
そして、プロトコルスタック部１０１２は、図５のステップＳ５０３と同様に新規セッションを生成して、対向通信機器２００に対するSYNパケットをネットワークデータ送受信部１０１３に出力する（ステップＳ１００３、Ｓ１００４）。
ネットワークデータ送受信部１０１３は、図５のステップＳ５０５の場合と同様、対向通信機器２００からACKパケットを受信し、そのACKパケットをプロトコルスタック部１０１２に出力する（ステップＳ１００５）。
プロトコルスタック部１０１２は、図５のステップＳ５０５の場合と同様、ネットワークデータ送受信部１０１３から受け取ったACKパケットから、対向通信機器２００が通信時に受信可能な受信ウィンドウサイズの最大値を取得してRAM１０３に記憶し、ACKパケットをネットワークデータ送受信部１０１３に出力する（ステップＳ１００６、Ｓ１００７）。
アプリケーション部１０１１は、ステップＳ１００２で取得したセッションIDとロックする電力モードとを、電力モード判断部１０１４に通知する（ステップＳ１００８）。その後、電力モード判断部１０１４は、アプリケーション部１０１１から通知された上記ロックする電力モードを、ROM１０２に記憶されている電力モード判断テーブル１０２１の中から特定し、特定した電力モードと上記セッションIDとを対応付けてRAM１０３に記憶する。
【００３７】
<データ送信時の処理>
プロトコルスタック部１０１２は、図６に示したステップＳ６０６において、電力モード判断部１０１４に対して電力モードの変更要求をするとともに、RAM１０３に記憶されているセッションIDを、電力モード判断部１０１４に通知する。その後、電力モード判断部１０１４は、以下に示すフローチャートに示す処理手順により、上記電力モードを判定する。
【００３８】
図１１は、上記ステップＳ６０７で行われる電力モードを判断する処理の処理手順を示すフローチャートである。
図１１に示すように、上記ステップＳ６０７では、まず、電力モード判断部１０１４は、通知された上記セッションIDをキーとして電力モード判定テーブル１０２１を検索し（ステップＳ１１０１）、上記セッションIDに対応する上記ロックする電力モードがRAM１０３に記憶されているか否かを判定する（ステップＳ１１０２）。
電力モード判断部１０１４は、上記セッションIDに対応する上記ロックする電力モードがRAM１０３に記憶されていると判定した場合（ステップＳ１１０２；Ｙｅｓ）、電力モード制御部１０１５に対して、その電力モードに変更する要求をする（ステップＳ１１０３）。そして、電力モード制御部１０１５は、その要求にしたがって、電力モードを変更する。
【００３９】
一方、電力モード判断部１０１４は、上記セッションIDに対応する上記ロックする電力モードがRAM１０３に記憶されていないと判定した場合（ステップＳ１１０２；Ｎｏ）、図６に示したように、対向通信機器２００から受信した受信ウィンドウサイズの値と、図５のステップＳ５０６で通信開始時に記憶された受信ウィンドウサイズの最大値と、あらかじめROM１０２に記憶されている電力モード判定テーブルとを参照し（ステップＳ１１０４）、遷移する電力モードを決定する（ステップＳ１１０５）。そして、電力モード制御部１０１５は、その決定にしたがって、電力モードを変更する。
さらに、他の変形例として、 電力モード判断部１０１４が、複数セッションにおける判定結果を使用し、電力モードを判定してもよい。
【００４０】
通信機器１００が複数の対向通信機器２００との間で通信するなど、複数セッションが同時に発生する場合、電力モード判断部１０１４は、対向通信機器２００のそれぞれに対して電力モードを判断するため、電力モードの遷移回数が多くなる。その結果、通信機器１００が期待した電力モードで動作できないことが考えられる。
例えば、対向通信機器２００が２台存在し、一方の対向通信機器２００から受信した受信ウィンドウサイズの値がRx  Fullであり、他方の対向通信機器２００から受信した受信ウィンドウサイズの値がRx  Emptyであった場合を考える。この場合、電力モード判断部１０１４が最後に判定した電力モードを、前者の情報に基づいて低電力モードに遷移させると、上記他方の対向通信機器２００との通信に必要な処理があるにも関わらず低速に通信することとなってしまう。そのため、通信機器１００は、それぞれの対向通信機器２００と通信機器１００との間で生成されるセッション毎に図７に示した電力モード判定テーブル１０２１を記憶する。このような構成とすることにより、電力モード判断部１０１４が電力モードを判定する際に、他の対向通信機器２００の受信ウィンドウサイズの値に影響を受けることが無くなる。したがって、期待しない電力モードに遷移してしまうことを回避することができ、複数の通信相手と同時に通信する場合において、より効率よく電力を制御することができる。
【００４１】
なお、上記のように対向通信機器２００が複数存在する場合、ある対向通信機器２００から受信した受信ウィンドウサイズの値がRx  Emptyであっても、優先度が高くないセッションであることが考えられる。このような場合には、電力モード判断部１０１４は、それぞれの対向通信機器２００との間で生成された各セッションに対してさらに優先度を設定し、電力モードを判断する際に、優先度の高いセッションの電力モードを採用することで、より期待通りの電力制御を行うことができる。
例えば、電力モード判断部１０１４は、上記一方の対向通信機器２００との間で生成されたセッションのほうが、上記他方の対向通信機器２００との間で生成されたセッションよりも優先度が高い場合を考える。電力モード判断部１０１４は、最初に、前者の情報に基づいて低電力モードに遷移させる判定をしたものの、後者の情報に基づいて高電力モードに遷移させるような状況であっても、前者とのセッションの優先度が高いため、高電力モードではなく低電力モードに遷移させる判定をする。
このような方式により、セッションの優先度を考慮しつつ、複数の通信相手との同時通信においてより効率のよい電力制御を行うことが可能となる。
【００４２】
さらに、他の変形例として、IC（Integrated  Circuit）チップのようにハードウェア化されたプロトコルスタック部１０１２が上記機能を実現する場合、ソフトウェアのように処理の実行が制御できない。したがって、図６のステップＳ６０５や図８のステップＳ８０３において、プロトコルスタック部１０１２が送受信バッファを確保した後、TCPによる送信処理や受信処理が自動で行われてしまう。その結果、通信機器１００は、例えば、対向通信機器２００からパケットを受信したタイミングで、図８に示したステップＳ８０４以降の処理を実行できない可能性がある。
この場合には、ハードウェア化されたプロトコルスタック部１０１２が、対向通信機器２００から応答パケットを受信した時に割り込みを発生させることにより、上記問題点を解決することができる。しかし、その結果、CPU１０１が動作することとなって自動応答によるパフォーマンス向上および省電力化を妨げる結果を招き、ハードウェア化されたメリットが生かされない可能性がある。
【００４３】
そこで、ハードウェア化されたプロトコルスタック部１０１２が、対向通信機器２００から受信した受信ウィンドウサイズが変化したことを検知したときに、割り込み信号を出力する。電力モード判断部１０１４は、上記ハードウェア化されたプロトコルスタック部１０１２が割り込み信号を出力したか否かを判定し、上記割り込み信号を出力した場合にのみ遷移する電力モードを判定する。
このように、ハードウェア化されたプロトコルスタック部１０１２が受信ウィンドウサイズの変化を検知した場合にのみ割り込みを発生させ、電力モード判断部１０１４が電力モードを判断している。したがって、受信ウィンドウサイズの変化が検知されない場合には、割り込み自体も発生することがなく、電力モード判断部１０１４が電力モードを判断することもない。したがって、より省電力に通信処理を実現することができる。
【符号の説明】
【００４４】
１００              通信機器
２００              対向通信機器
１０１              CPU
１０１１            アプリケーション部
１０１２            プロトコルスタック部
１０１３            ネットワークデータ送受信部
１０１４            電力モード判断部
１０１５            電力モード制御部
１０２              ROM
１０２１、１０２２  電力モード判定テーブル
１０３              RAM
１０４              Power  Control  Unit
１０５              Network  I/F。
【先行技術文献】
【特許文献】
【００４５】
【特許文献１】特開２００４−１９２２５６号公報
【図１】
2017027196.tif 000003
【図２】
2017027196.tif 000004
【図３】
2017027196.tif 000005
【図４】
2017027196.tif 000006
【図５】
2017027196.tif 000007
【図６】
2017027196.tif 000008
【図７】
2017027196.tif 000009
【図８】
2017027196.tif 000010
【図９】
2017027196.tif 000011
【図１０】
2017027196.tif 000012
【図１２】
2017027196.tif 000013
【図１３】
2017027196.tif 000014
【図１１】
2017027196.tif 000015