JP2004192256A - ネットワークコントローラ - Google Patents
ネットワークコントローラ Download PDFInfo
- Publication number
- JP2004192256A JP2004192256A JP2002358391A JP2002358391A JP2004192256A JP 2004192256 A JP2004192256 A JP 2004192256A JP 2002358391 A JP2002358391 A JP 2002358391A JP 2002358391 A JP2002358391 A JP 2002358391A JP 2004192256 A JP2004192256 A JP 2004192256A
- Authority
- JP
- Japan
- Prior art keywords
- time
- cpu
- protocol
- network controller
- cpu operation
- 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.)
- Withdrawn
Links
Images
Landscapes
- Power Sources (AREA)
Abstract
【課題】ＴＣＰ／ＩＰ処理のタイマ値、バッファ容量、パケットの送信間隔等の情報の組み合わせにより、ＣＰＵの動作速度を変更し、低消費電力を実現するネットワークコントローラを提供する。
【解決手段】プロトコル処理を行うプロトコル処理部と、プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間をタイマ値に基づいて算出し、予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを比較結果に基づいて変更する。
【選択図】 図４
【解決手段】プロトコル処理を行うプロトコル処理部と、プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間をタイマ値に基づいて算出し、予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを比較結果に基づいて変更する。
【選択図】 図４
Description
【０００１】
【発明の属する技術分野】
本発明は、アプリケーションの通信状態やＴＣＰ／ＩＰプロトコルの通信状態に応じてＣＰＵの動作クロックを変更し、低消費電力を実現するＴＣＰ／ＩＰ処理を実行するネットワークコントローラに関する。
【０００２】
【従来の技術】
近年、デジタル家電等の分野における技術開発の結果、データ通信のプロトコルとしてＴＣＰ／ＩＰ処理機能を持ったデジタル家電が登場しつつある。ＴＣＰ／ＩＰのような機能は、従来では、ＯＳのモジュールとして提供されてきたが、組み込み機器のような製品用にＥｔｈｅｒｎｅｔ（登録商標）処理やＴＣＰ／ＩＰ処理を１チップのＬＳＩで実現するネットワークコントローラのような製品が検討されている。
【０００３】
組み込み機器用ＬＳＩの低消費電力の実現方法として、低消費電力の機構を組み込み用プロセッサ本体の設計やプロセスルールで実現する方法が取られている。
また、ネットワークコントローラにおいても、ＯＳＩ７階層のうち、物理層、データリンク層に対して、ハードウェア設計、実装技術において低消費電力を実現する方法が取られている。
【０００４】
【特許文献１】
特開平１１−４２５５
【０００５】
【発明が解決しようとする課題】
上述したように、従来はＴＣＰ／ＩＰ処理はほとんどがＯＳのカーネルモジュールやＲＴＯＳのタスクとしてソフトウェアで実装されていたため、低電力を実現するための仕組みが提供されていない。
一方で、本発明がターゲットとする情報家電のようなシステムでは、ネットワーク接続機能を実現するために消費電力が増大してしまうという問題点があった。
【０００６】
本発明は、このような事情を考慮してなされたものであり、その目的は、ＴＣＰ／ＩＰ処理のタイマ値、バッファ容量、パケットの送信間隔等の情報の組み合わせにより、ＣＰＵの動作速度を変更し、低消費電力を実現するネットワークコントローラを提供することにある。
【０００７】
【課題を解決するための手段】
本発明は上記の課題を解決すべくなされたもので、本発明のネットワークコントローラは、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部と、該プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更するＣＰＵ動作変更判断処理部を具備することを特徴とする。
【０００８】
また本発明のネットワークコントローラは、前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、前記ＣＰＵ動作モードを該パケット送受信間隔及び直近のパケット送受信時刻に基づいて変更することを特徴とする。
【０００９】
また本発明のネットワークコントローラは、前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、次パケットの送受信予測時刻を算出し、現在時刻に前記予測スリープ時間を加算した時刻と、該送受信予測時刻とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更することを特徴とする。
【００１０】
また本発明のネットワークコントローラは、前記ＣＰＵ動作変更時間は、前記ネットワークコントローラに接続されたホストＣＰＵより指定された値であることを特徴とする。
【００１１】
また本発明のネットワークコントローラは、前記パケット送受信間隔は、連続したパケットの送受信間隔幅に基づいて決定されることを特徴とする。
【００１２】
また本発明のＣＰＵ動作変更制御方法は、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御方法であって、前記プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更することを特徴とする。
【００１３】
また本発明のＣＰＵ動作変更制御プログラムは、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御処理を該ＣＰＵに実行させるためのプログラムであって、前記プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出する処理と、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更する処理を
前記ＣＰＵに実行させるためのプログラムである。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。
図１は、本実施形態のネットワークコントローラを適用したデジタル家電の構成を示す構成図である。本実施形態において、デジタル家電は、Ｈｏｓｔ ＣＰＵ・１と、ネットワークコントローラ２と、ＰＨＹ（Ｐｈｉｓｉｃａｌ Ｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）・３からなる。
Ｈｏｓｔ ＣＰＵ・１は、本デジタル家電のメインのアプリケーションを実行するＣＰＵ（中央演算処理装置）であり、ネットワークコントローラ２とバスを介して接続される。
ＰＨＹ・３は、ＯＳＩ参照モデルの物理層レイヤとして、伝送リソース、すなわちケーブルやコネクタなどの物理的な条件や、伝送フレームなど各信号を伝送するために必要な機能を実装する物理層インターフェイスであり、ネットワークコントローラ２とバスを介して接続される。
【００１５】
図２は、本実施形態のネットワークコントローラ２のハードウェア構成を示すブロック図である。本実施形態において、ネットワークコントローラ２は、コントローラ用のＣＰＵ・４と、ＲＯＭ・５と、ＲＡＭ・６と、タイマ７と、Ｈｏｓｔ インターフェイス（以下、ＩＦとする。）・８と、ＭＩＩ（Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ Ｉｎｔｅｒｆａｃｅ）・９とから構成される。
【００１６】
ＣＰＵ・４は、半導体メモリ等の記憶部であるＲＯＭ・５に記憶されたモニタ、ＲＴＯＳ用の制御ソフトウェアモジュール等を読み出して、ネットワークコントローラ２におけるＴＣＰ／ＩＰ処理等を実行する。
ここで、ＣＰＵ・４は、例えば、動作周波数が１００ＭＨｚの通常モードと動作周波数が５０ＭＨｚの低消費電力モードを有しており、ネットワークコントローラ２で動作するファームウェア（後述するＣＰＵ動作変更判断処理部・１４に相当）から、ＣＰＵ・４へ所定の命令を実行することで通常モードから低消費電力モードへの移行、低消費電力モードから通常モードへの復帰が可能である。
ＲＡＭ・６は、ＴＣＰ／ＩＰ処理のためのプロトコルデータ等を一時的に記憶する半導体メモリ等の記憶部である。
タイマ７は、ＣＰＵ・４の制御切替のトリガとなるタイムスライスを生成するハードウェアタイマである。
Ｈｏｓｔ ＩＦ・８は、ネットワークコントローラ２をＨｏｓｔ ＣＰＵ・１に接続するためのＣＰＵインターフェイスである。
ＭＩＩ・９は、ネットワークコントローラ２をＰＨＹ・３に接続するためのメディア独立インターフェイスである。
【００１７】
図３は、本実施形態のネットワークコントローラ２のソフトウェア構成を示す機能ブロック図である。本実施形態のネットワークコントローラ２は、ＴＣＰ／ＩＰ処理部１０と、プロトコルデータ管理部１１と、ＣＰＵ動作設定処理部１３と、ＣＰＵ動作変更判断処理部１４と、プロトコル処理部１５と、パケット送受信間隔監視部１６とから構成される。
【００１８】
ＴＣＰ／ＩＰ処理部１０は、ＴＣＰ／ＵＤＰ／ＩＰｖ４／ＩＰｖ６／ＩＣＭＰｖ４／ＩＣＭＰｖ６等のＴＣＰ／ＩＰのプロトコル処理を行い、プロトコル管理データをプロトコルデータ管理部１１に、パケット送受信間隔及び直近のパケット受信時刻、送信時刻をパケット送受信間隔監視部１６にそれぞれ書き込む。
ここで、プロトコル処理としては、ＩＰｖ４ Ｏｎｌｙ／ＩＰｖ６ Ｏｎｌｙ／Ｄｕａｌ Ｓｔａｃｋ、すなわち、ＩＰｖ４のみを使用する場合、ＩＰｖ６のみを使用する場合、ＩＰｖ４及びＩＰｖ６を共存して使用する場合がある。
プロトコルデータ管理部１１は、ＴＣＰ／ＩＰ処理部１０、プロトコル処理部１５における各プロトコル処理に必要なデータ、すなわち、ＣＰＵ・４の動作モード変更に関するパラメータを管理する。
ここで、ＣＰＵ・４の動作モード変更に関するパラメータとは、ＴＣＰ処理であれば、各種タイマ値（再送タイマ、持続タイマ、保留タイマ等）、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）、遅延ＡＣＫ時間、ウィンドウサイズ等のコネクション管理情報である。また、ＩＰｖ４処理であれば、ルーティングテーブルや設定されたアドレス情報等である。また、ＩＰｖ６処理であれば、アドレスの有効時間のタイマ、Ｐｒｅｆｉｘの有効時間のタイマ、Ｍｕｌｔｉｃａｓｔに関するタイマ等である。
【００１９】
ＣＰＵ動作設定処理部１３は、外部プログラムモジュール１２とのインターフェイスとなり、ＣＰＵ・４の動作条件として、例えば、ＣＰＵ動作変更時間の設定要求を受け付け、その要求をＣＰＵ動作変更判断処理部１４に対して出力する。
ここで、外部プログラムモジュール１２は、例えば、ＣＰＵ・４がスリープ状態に遷移する条件や動作クロックを変化させる条件、すなわち、ＣＰＵの動作モードの移行条件、すなわち、ＣＰＵ動作変更時間を指定する。
ＣＰＵ動作変更判断処理部１４は、プロトコルデータ管理部１１が管理するＣＰＵ・４の動作モード変更に関するパラメータの値が更新される場合、パケット送受信部１６を参照し、次のパケット送信までの時間、次のパケット受信での時間を更新されたパラメータの値に基づいて計算する機能を有する。（本発明においては、この計算結果を「予測スリープ時間」と定義する。）また、ＣＰＵ動作変更判断処理部１４は、予測スリープ時間と、ＣＰＵ動作設定処理部１３から入力されるＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを比較結果に基づいて変更するインターフェイスを持つ。
ここで、ＣＰＵ動作モードを変更するインターフェイスとは、例えば、アセンブラのｓｌｅｅｐ命令や動作クロックを変更する命令などである。
【００２０】
プロトコル処理部１５は、ＴＣＰ／ＩＰ以外のＨＴＴＰ、ＳＮＭＰ、ＤＨＣＰ、ＲＩＰ等のアプリケーションプロトコルのプロトコル処理を実行し、プロトコル管理データをプロトコルデータ管理部１１に書き込む。
パケット送受信間隔監視部１６は、パケット送信時における連続したパケットの送信間隔を保持し、時間的に最近の、つまり直近のパケット送信時刻を保持する（図６の上段を参照）。また、パケット送受信間隔監視部１６は、パケット受信時における連続したパケットの受信間隔を保持し、時間的に最近の、つまり直近のパケット受信時刻を保持する（図６の下段を参照）。
【００２１】
以下、本実施形態のネットワークコントローラ２の動作について、図面を参照して説明する。まず本実施形態のネットワークコントローラ２の動作の前提条件について説明する。
（前提条件）
・ ネットワークコントローラ２は、ＩＰｖ６機能を搭載しており、特定のＭｕｌｔｉｃａｓｔ Ｇｒｏｕｐに属している（要請Ｍｕｌｔｉｃａｓｔ／ＩＣＭＰ Ｎａｍｅ Ｌｏｏｋｕｐ等のＭｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓを利用しており、２０秒おきにＭＬＤパケットを再送するものとする。）。
・ 本実施形態においては、ＴＣＰセッションの管理データとＩＰｖ６（ＭＬＤ用）の管理データを参照して予測スリープ時間を算出する。
以上の前提に基づいて、本実施形態のネットワークコントローラ２の動作について説明する。
【００２２】
図４は、ＣＰＵ動作変更判断処理部１４におけるＣＰＵ動作モード変更処理の過程を示すフローチャートである。
まず上述のデジタル家電におけるシステム初期化時に、Ｈｏｓｔ ＣＰＵ・１はネットワークコントローラ２に対して、５００ｍｓｅｃ以上の待ち時間検出時に動作周波数を下げることを指令するコマンドを出力する。
ネットワークコントローラ２において、ＣＰＵ動作設定処理部１３が、このコマンド（＝ＣＰＵ動作変更時間の設定要求）を受け付け、ＣＰＵ・４のＣＰＵ動作変更時間を設定する。すなわち、本実施形態においては、Ｈｏｓｔ ＣＰＵ・１が外部プログラムモジュール１２と同様の制御処理を行う。
【００２３】
次に、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションは、ＴＣＰ／ＩＰ処理部１０に対してセッション生成要求を送信する。ネットワークコントローラ２において、ＴＣＰ／ＩＰ処理部１０は、Ｈｏｓｔ ＩＦ・８経由でＴＣＰセッション要求を受信し、プロトコルデータ管理部１１にＴＣＰセッション管理データ１をセットする（図５のＴＣＰセッション管理データ１を参照）。
【００２４】
今、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションとＴＣＰ／ＩＰ処理部１０の間でこの処理を複数回、例えばもう一度行い、ＴＣＰ／ＩＰ処理部１０が計２つのＴＣＰセッション（図５のＴＣＰセッション管理データ１、ＴＣＰセッション管理データ２を参照）を生成して、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションがデータ通信を開始したとする。
このとき、図５に示すように、プロトコルデータ管理部１１には、ＴＣＰセッション管理データ１と、ＴＣＰセッション管理データ２と、ＩＰｖ６管理データがセットされている。
【００２５】
ＣＰＵ動作変更判断処理部１４は、定期的（例えば、１００ｍｓｅｃ毎）、あるいは、前回算出した予測スリープ時間よりも長いタイマ値がプロトコルデータ管理部１１にセットされた時点で処理を開始する。
【００２６】
すなわち、ＣＰＵ動作変更判断処理部１４は、まず受信バッファにデータがあるか否かを確認する（図４のステップＳ１を参照）。
受信バッファにデータがあれば（ステップＳ１でＹｅｓの場合）、続いてパケットが送信されてくる可能性が高いことから、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。一方、受信バッファにデータがなければ（ステップＳ１でＮｏの場合）、ＣＰＵ動作変更判断処理部１４は、チェックしていないプロトコル管理データがあるか否かを確認する（ステップＳ２）。
例えば、ＴＣＰセッション管理データ１、２またはＩＰｖ６管理データのうち、いずれかが未チェックのプロトコル管理データである場合（ステップＳ２でＹｅｓの場合）、ＣＰＵ動作変更判断処理部１４は、未チェックのプロトコル管理データに書き込まれたタイマ値を読み出して、予測スリープ時間を算出し、前回算出した予測スリープ時間を更新する（ステップＳ３）。
ここで読み出すタイマ値は、例えば、ＴＣＰセッションデータ１、２のＲＴＴ、各種タイマ値、ＩＰｖ６管理データのＭＬＤパケット再送タイマ値である。
また、予測スリープ時間は、読み出したＲＴＴ、各種タイマ値の残り時間の最小値とする。
【００２７】
予測スリープ時間の更新後、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作設定処理部１３に設定されたＣＰＵ動作変更時間と更新後の予測スリープ時間とを比較し、予測スリープ時間がＣＰＵ動作変更時間より短い場合は、ステップＳ２に戻って、ステップＳ２〜Ｓ４を繰り返す。そして、ＴＣＰセッション管理データ１、２またはＩＰｖ６管理データがすべてチェック済みとなった場合（ステップＳ２でＮｏの場合）、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００２８】
一方、ＣＰＵ動作変更時間と更新後の予測スリープ時間とを比較し、予測スリープ時間がＣＰＵ動作変更時間より長い場合（ステップＳ４でＹｅｓの場合）、ＣＰＵ動作変更判断処理部１４は、パケット送受信間隔監視部１６よりパケットの受信間隔、送信間隔、直近のパケット受信時刻、送信時刻を読み出す。
そして、ＣＰＵ動作変更判断処理部１４は、この直近のパケット受信時刻にパケットの受信間隔時間分を加算した時刻（＝次のパケットの受信予想時刻）と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの受信予想時刻の方が早い場合（ステップＳ５でＮｏの場合）、すなわち、
次のパケットの受信予想時刻 ＜ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、
ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００２９】
また、ＣＰＵ動作変更判断処理部１４は、同様に、この直近のパケット送信時刻にパケットの送信間隔時間分を加算した時刻（＝次のパケットの送信予想時刻）と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの送信予想時刻の方が早い場合（ステップＳ５でＮｏの場合）、すなわち、
次のパケットの送信予想時刻 ＜ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００３０】
一方、次のパケットの受信予想時刻と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの受信予想時刻の方が遅く、かつ、次のパケットの送信予想時刻と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの送信予想時刻の方が遅い場合（ステップＳ５でＹｅｓの場合）、
すなわち、
次のパケットの受信予想時刻 ＞ 現在時刻＋予測スリープ時間分
かつ
次のパケットの送信予想時刻 ＞ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ・４の動作モードを低消費電力モードに変更する命令を出力する（ステップＳ７）。
【００３１】
ＣＰＵ・４は、この命令を受けて、動作モードを低消費電力モードに変更する。そして、ＣＰＵ・４は、外部からの割り込みがかかるまで、つまり他の通信デバイスからパケットを受信するまで、又は、Ｈｏｓｔ ＣＰＵ・１から送信パケットを受信するまで、プロトコル処理を低消費電力モードで実行する（ステップＳ８）。
【００３２】
次に、以上の動作の具体例を説明する。Ｈｏｓｔ ＣＰＵ・１側のメインアプリケーションがデータ通信中に通信経路上で輻輳が発生した場合、ＴＣＰセッションで管理しているＲＴＴ値が大きくなり、１つのＴＣＰセッションのＲＴＴが５５０ｍｓｅｃ、他方のＴＣＰセッションのＲＴＴ値が６００ｍｓｅｃに更新されたとする。このとき、その他のタイマ値の残り時間が５５０ｍｓｅｃより大きい状態であれば、ステップＳ３でＣＰＵ動作判断処理部１４は、予測スリープ時間を５５０ｍｓｅｃに更新する。このとき、設定された５００ｍｓｅｃを超える待ち時間が発生する可能性があるので、ＣＰＵの動作クロックを５０ＭＨｚに変更する命令をＣＰＵ・４に対して出力する。また、この際、パケット送受信間隔監視部１６の情報を参照してより精度の高い予測を行うことも考えられる。
【００３３】
たとえば、図６の上段に示す送信間隔の例では、送信間隔と現在時刻の関連から連続した送信処理が予測され、予測スリープ時間が５５０ｍｓｅｃになっても、ＣＰＵの動作クロックを下げないという判断が可能である。
また、図６の下段に示す受信間隔の例では、例えば、Ｈｏｓｔ ＣＰＵ・１がネットワークコントローラ２に対して、２００ｍｓｅｃ以下の予測スリープ時間を検出した際にＣＰＵの動作クロックを変更する設定を行った場合、ＴＣＰにおける遅延ＡＣＫの残り時間を考慮して予測スリープ時間を計算することができる。すなわち、遅延ＡＣＫにより、ＡＣＫの送信を遅らせている期間は、パケット送信処理が発生しないことから、ＣＰＵの動作クロックを下げることが考えられる。
【００３４】
ネットワークコントローラ２は、動作クロックを５０ＭＨｚに下げた状態でプロトコル処理を続行し、パケットの送受信間隔が５００ｍｓｅｃより小さくなると、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ・４に対して、ＣＰＵの動作クロックを元の１００ＭＨｚに復帰させる命令を出力する。ＣＰＵ・４はこの命令を実行し、動作クロックを１００ＭＨｚに戻す。
なお、ここでは、パケット送受信間隔の情報を動作クロック復帰の判断に利用したが、Ｈｏｓｔ ＣＰＵ・１から複数パケット化が必要な量のデータ送信コマンドを受け付けた場合に復帰することも考えられる。
【００３５】
以上説明したように、本実施形態のネットワークコントローラによれば、ＣＰＵ動作変更時間をＨｏｓｔ ＣＰＵ・１側から設定可能とすることで、ＨｏｓｔＣＰＵ・１のメインアプリケーションの特性に応じて、柔軟に変更できる効果が得られる。したがって、ネットワークコントローラの消費電力をＨｏｓｔ ＣＰＵ・１のメインアプリケーションの特性に応じて、最適化する制御を行うことで低消費電力を実現することができる効果が得られる。
また、パケットの送受信間隔の情報を基にＣＰＵの動作変更判断を実行可能となり、より精度の高い予測が可能となり、ネットワークコントローラの消費電力をより最適化することができる効果が得られる。
特に通常、通信プロトコル処理では、統計データを残す目的やＳＮＭＰのＭＩＢデータとする目的のために送受信が完了後にパケット数等を更新する。本発明は、その更新処理の追加処理としてパケット送受信間隔の更新を行うため、計算負荷が小さい。
【００３６】
また、本発明のネットワークコントローラは、ネットワークコントローラとのインターフェイスを備えたＣＰＵであって、コマンド命令やデータ送受信が可能なＣＰＵであれば、どのような種類のＣＰＵも適用可能である。
また、本発明のネットワークコントローラは、データリンク層、物理層に依存しないので様々な通信方式に適用可能である。
また、本発明のネットワークコントローラは、ＴＣＰ／ＩＰ処理に限られず、ＭＡＣ層の処理を内蔵したネットワークコントローラであっても良い。ＭＡＣ層の処理を内蔵する場合、ＭＡＣプロトコルのタイマ値をＣＰＵの動作モード変更のトリガとすることが考えられる。
また、本実施形態のネットワークコントローラでは、動作モードが通常モードと低消費電力モードとを有する場合を示したが、本発明はこれに限られず、ＣＰＵコアの実装する動作モードを採用してもよい。なお、ＣＰＵの動作クロックが変更不可能な場合は、一定時間の予測スリープ時間を検出したら、ＣＰＵはｓｌｅｅｐ状態に移行し、ｓｌｅｅｐ状態の復帰は、割り込みやＨｏｓｔ ＣＰＵ・１からのコマンド等のイベント検出をトリガとして行う。
また、ＣＰＵ動作変更時間を直接、ＣＰＵ動作変更判断処理部１４に設定するのではなく、要求受付のインターフェイスとなるＣＰＵ動作設定部を設けることにより、新しい設定パラメータの追加が容易にできる効果が得られる。
【００３７】
なお、本実施形態のネットワークコントローラにおいては、予測スリープ時間の計算アルゴリズムとして、各種タイマ値から最短のものを選ぶという方法を示したが、実装段階では、接続するデバイス毎（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ＩＥＥＥ８０２．３ｘ、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈ、ＵＳＢ）、また、ネットワークコントローラを搭載している機器が、常時電源に接続されている場合、または、機器内増のバッテリで動作している場合毎にテストシミュレーションを行うことにより最適化されて決定される。
また、本実施形態のネットワークコントローラ２では、送受信バッファ量については、これを積極的に利用しない例を示したが、本発明はこれに限られず、ステップＳ１において、送受信バッファ量の大小に応じた判定処理をおこなってもよい。
また、本実施形態のネットワークコントローラ２では、主にＴＣＰ／ＩＰ処理部１０のプロトコル管理データによりＣＰＵの動作変更判断処理を行ったが、本発明はこれに限られず、プロトコル処理部１５のプロトコル処理におけるタイマ値やバッファ等をも考慮してＣＰＵの動作変更判断処理をしてもよい。
また、本実施形態のネットワークコントローラ２では、主にプロトコル処理の低消費電力をネットワークコントローラ側でのせイ魚により実現するが、本発明はこれに限られず、Ｈｏｓｔ ＣＰＵ・１が明示的にネットワークコントローラ・２に対して命令を発行し、低消費電力モードへ移行させても良い。
【００３８】
本発明がターゲットとするデジタル家電等のネットワーク機器では、汎用のＰＣと異なり、明確なアプリケーションの利用が想定される。したがって、本システムでは、不特定多数のサービスを提供する情報機器というよりは、少人数の利用者に対して、特定のサービスを提供する機器、あるいは、クライアントとして特定のサービスを利用する端末機器として採用されることが想定される。
このようなシステムでは、同時に生成するＴＣＰセッションや管理するプロトコルデータの情報量も少なく、ネットワークに接続されていても、常に通信しているとは限らないので、本発明で利用するタイムアウト値、バッファ量、パケット送受信間隔により低消費電力モードへの判断基準とする方式は、低消費電力の実現方法として有効である。
【００３９】
なお、上述したネットワークコントローラにおけるＣＰＵ動作変更判断処理に関する一連の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【図面の簡単な説明】
【図１】本実施形態のデジタル家電の構成を示すブロック図である。
【図２】本実施形態のネットワークコントローラ２のハードウェア構成を示すブロック図である。
【図３】本実施形態のネットワークコントローラ２のソフトウェア構成を示すブロック図である。
【図４】ＣＰＵ動作変更判断処理部１４の動作を示すフローチャートである。
【図５】プロトコルデータ管理部１１に格納されるプロトコル管理データを示すブロック図である。
【図６】パケットの送受信間隔と現在時刻の関連を示す図である。
【符号の説明】
１…Ｈｏｓｔ ＣＰＵ・４…ネットワークコントローラ、３…ＰＨＹ、４…ＣＰＵ、５…ＲＯＭ、６…ＲＡＭ、７…タイマ、８…Ｈｏｓｔ ＩＦ、９…ＭＩＩ、１０…ＴＣＰ／ＩＰ処理部、１１…プロトコルデータ管理部、１２…外部プログラムモジュール、１３…ＣＰＵ動作設定処理部、１４…ＣＰＵ動作変更判断処理部、１５…プロトコル処理部、１６…パケット送受信間隔監視部
【発明の属する技術分野】
本発明は、アプリケーションの通信状態やＴＣＰ／ＩＰプロトコルの通信状態に応じてＣＰＵの動作クロックを変更し、低消費電力を実現するＴＣＰ／ＩＰ処理を実行するネットワークコントローラに関する。
【０００２】
【従来の技術】
近年、デジタル家電等の分野における技術開発の結果、データ通信のプロトコルとしてＴＣＰ／ＩＰ処理機能を持ったデジタル家電が登場しつつある。ＴＣＰ／ＩＰのような機能は、従来では、ＯＳのモジュールとして提供されてきたが、組み込み機器のような製品用にＥｔｈｅｒｎｅｔ（登録商標）処理やＴＣＰ／ＩＰ処理を１チップのＬＳＩで実現するネットワークコントローラのような製品が検討されている。
【０００３】
組み込み機器用ＬＳＩの低消費電力の実現方法として、低消費電力の機構を組み込み用プロセッサ本体の設計やプロセスルールで実現する方法が取られている。
また、ネットワークコントローラにおいても、ＯＳＩ７階層のうち、物理層、データリンク層に対して、ハードウェア設計、実装技術において低消費電力を実現する方法が取られている。
【０００４】
【特許文献１】
特開平１１−４２５５
【０００５】
【発明が解決しようとする課題】
上述したように、従来はＴＣＰ／ＩＰ処理はほとんどがＯＳのカーネルモジュールやＲＴＯＳのタスクとしてソフトウェアで実装されていたため、低電力を実現するための仕組みが提供されていない。
一方で、本発明がターゲットとする情報家電のようなシステムでは、ネットワーク接続機能を実現するために消費電力が増大してしまうという問題点があった。
【０００６】
本発明は、このような事情を考慮してなされたものであり、その目的は、ＴＣＰ／ＩＰ処理のタイマ値、バッファ容量、パケットの送信間隔等の情報の組み合わせにより、ＣＰＵの動作速度を変更し、低消費電力を実現するネットワークコントローラを提供することにある。
【０００７】
【課題を解決するための手段】
本発明は上記の課題を解決すべくなされたもので、本発明のネットワークコントローラは、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部と、該プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更するＣＰＵ動作変更判断処理部を具備することを特徴とする。
【０００８】
また本発明のネットワークコントローラは、前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、前記ＣＰＵ動作モードを該パケット送受信間隔及び直近のパケット送受信時刻に基づいて変更することを特徴とする。
【０００９】
また本発明のネットワークコントローラは、前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、次パケットの送受信予測時刻を算出し、現在時刻に前記予測スリープ時間を加算した時刻と、該送受信予測時刻とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更することを特徴とする。
【００１０】
また本発明のネットワークコントローラは、前記ＣＰＵ動作変更時間は、前記ネットワークコントローラに接続されたホストＣＰＵより指定された値であることを特徴とする。
【００１１】
また本発明のネットワークコントローラは、前記パケット送受信間隔は、連続したパケットの送受信間隔幅に基づいて決定されることを特徴とする。
【００１２】
また本発明のＣＰＵ動作変更制御方法は、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御方法であって、前記プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更することを特徴とする。
【００１３】
また本発明のＣＰＵ動作変更制御プログラムは、プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御処理を該ＣＰＵに実行させるためのプログラムであって、前記プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出する処理と、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更する処理を
前記ＣＰＵに実行させるためのプログラムである。
【００１４】
【発明の実施の形態】
以下、図面を参照して本発明の実施形態について説明する。
図１は、本実施形態のネットワークコントローラを適用したデジタル家電の構成を示す構成図である。本実施形態において、デジタル家電は、Ｈｏｓｔ ＣＰＵ・１と、ネットワークコントローラ２と、ＰＨＹ（Ｐｈｉｓｉｃａｌ Ｍｅｄｉａ Ｉｎｔｅｒｆａｃｅ）・３からなる。
Ｈｏｓｔ ＣＰＵ・１は、本デジタル家電のメインのアプリケーションを実行するＣＰＵ（中央演算処理装置）であり、ネットワークコントローラ２とバスを介して接続される。
ＰＨＹ・３は、ＯＳＩ参照モデルの物理層レイヤとして、伝送リソース、すなわちケーブルやコネクタなどの物理的な条件や、伝送フレームなど各信号を伝送するために必要な機能を実装する物理層インターフェイスであり、ネットワークコントローラ２とバスを介して接続される。
【００１５】
図２は、本実施形態のネットワークコントローラ２のハードウェア構成を示すブロック図である。本実施形態において、ネットワークコントローラ２は、コントローラ用のＣＰＵ・４と、ＲＯＭ・５と、ＲＡＭ・６と、タイマ７と、Ｈｏｓｔ インターフェイス（以下、ＩＦとする。）・８と、ＭＩＩ（Ｍｅｄｉａ Ｉｎｄｅｐｅｎｄｅｎｔ Ｉｎｔｅｒｆａｃｅ）・９とから構成される。
【００１６】
ＣＰＵ・４は、半導体メモリ等の記憶部であるＲＯＭ・５に記憶されたモニタ、ＲＴＯＳ用の制御ソフトウェアモジュール等を読み出して、ネットワークコントローラ２におけるＴＣＰ／ＩＰ処理等を実行する。
ここで、ＣＰＵ・４は、例えば、動作周波数が１００ＭＨｚの通常モードと動作周波数が５０ＭＨｚの低消費電力モードを有しており、ネットワークコントローラ２で動作するファームウェア（後述するＣＰＵ動作変更判断処理部・１４に相当）から、ＣＰＵ・４へ所定の命令を実行することで通常モードから低消費電力モードへの移行、低消費電力モードから通常モードへの復帰が可能である。
ＲＡＭ・６は、ＴＣＰ／ＩＰ処理のためのプロトコルデータ等を一時的に記憶する半導体メモリ等の記憶部である。
タイマ７は、ＣＰＵ・４の制御切替のトリガとなるタイムスライスを生成するハードウェアタイマである。
Ｈｏｓｔ ＩＦ・８は、ネットワークコントローラ２をＨｏｓｔ ＣＰＵ・１に接続するためのＣＰＵインターフェイスである。
ＭＩＩ・９は、ネットワークコントローラ２をＰＨＹ・３に接続するためのメディア独立インターフェイスである。
【００１７】
図３は、本実施形態のネットワークコントローラ２のソフトウェア構成を示す機能ブロック図である。本実施形態のネットワークコントローラ２は、ＴＣＰ／ＩＰ処理部１０と、プロトコルデータ管理部１１と、ＣＰＵ動作設定処理部１３と、ＣＰＵ動作変更判断処理部１４と、プロトコル処理部１５と、パケット送受信間隔監視部１６とから構成される。
【００１８】
ＴＣＰ／ＩＰ処理部１０は、ＴＣＰ／ＵＤＰ／ＩＰｖ４／ＩＰｖ６／ＩＣＭＰｖ４／ＩＣＭＰｖ６等のＴＣＰ／ＩＰのプロトコル処理を行い、プロトコル管理データをプロトコルデータ管理部１１に、パケット送受信間隔及び直近のパケット受信時刻、送信時刻をパケット送受信間隔監視部１６にそれぞれ書き込む。
ここで、プロトコル処理としては、ＩＰｖ４ Ｏｎｌｙ／ＩＰｖ６ Ｏｎｌｙ／Ｄｕａｌ Ｓｔａｃｋ、すなわち、ＩＰｖ４のみを使用する場合、ＩＰｖ６のみを使用する場合、ＩＰｖ４及びＩＰｖ６を共存して使用する場合がある。
プロトコルデータ管理部１１は、ＴＣＰ／ＩＰ処理部１０、プロトコル処理部１５における各プロトコル処理に必要なデータ、すなわち、ＣＰＵ・４の動作モード変更に関するパラメータを管理する。
ここで、ＣＰＵ・４の動作モード変更に関するパラメータとは、ＴＣＰ処理であれば、各種タイマ値（再送タイマ、持続タイマ、保留タイマ等）、ＲＴＴ（Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）、遅延ＡＣＫ時間、ウィンドウサイズ等のコネクション管理情報である。また、ＩＰｖ４処理であれば、ルーティングテーブルや設定されたアドレス情報等である。また、ＩＰｖ６処理であれば、アドレスの有効時間のタイマ、Ｐｒｅｆｉｘの有効時間のタイマ、Ｍｕｌｔｉｃａｓｔに関するタイマ等である。
【００１９】
ＣＰＵ動作設定処理部１３は、外部プログラムモジュール１２とのインターフェイスとなり、ＣＰＵ・４の動作条件として、例えば、ＣＰＵ動作変更時間の設定要求を受け付け、その要求をＣＰＵ動作変更判断処理部１４に対して出力する。
ここで、外部プログラムモジュール１２は、例えば、ＣＰＵ・４がスリープ状態に遷移する条件や動作クロックを変化させる条件、すなわち、ＣＰＵの動作モードの移行条件、すなわち、ＣＰＵ動作変更時間を指定する。
ＣＰＵ動作変更判断処理部１４は、プロトコルデータ管理部１１が管理するＣＰＵ・４の動作モード変更に関するパラメータの値が更新される場合、パケット送受信部１６を参照し、次のパケット送信までの時間、次のパケット受信での時間を更新されたパラメータの値に基づいて計算する機能を有する。（本発明においては、この計算結果を「予測スリープ時間」と定義する。）また、ＣＰＵ動作変更判断処理部１４は、予測スリープ時間と、ＣＰＵ動作設定処理部１３から入力されるＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを比較結果に基づいて変更するインターフェイスを持つ。
ここで、ＣＰＵ動作モードを変更するインターフェイスとは、例えば、アセンブラのｓｌｅｅｐ命令や動作クロックを変更する命令などである。
【００２０】
プロトコル処理部１５は、ＴＣＰ／ＩＰ以外のＨＴＴＰ、ＳＮＭＰ、ＤＨＣＰ、ＲＩＰ等のアプリケーションプロトコルのプロトコル処理を実行し、プロトコル管理データをプロトコルデータ管理部１１に書き込む。
パケット送受信間隔監視部１６は、パケット送信時における連続したパケットの送信間隔を保持し、時間的に最近の、つまり直近のパケット送信時刻を保持する（図６の上段を参照）。また、パケット送受信間隔監視部１６は、パケット受信時における連続したパケットの受信間隔を保持し、時間的に最近の、つまり直近のパケット受信時刻を保持する（図６の下段を参照）。
【００２１】
以下、本実施形態のネットワークコントローラ２の動作について、図面を参照して説明する。まず本実施形態のネットワークコントローラ２の動作の前提条件について説明する。
（前提条件）
・ ネットワークコントローラ２は、ＩＰｖ６機能を搭載しており、特定のＭｕｌｔｉｃａｓｔ Ｇｒｏｕｐに属している（要請Ｍｕｌｔｉｃａｓｔ／ＩＣＭＰ Ｎａｍｅ Ｌｏｏｋｕｐ等のＭｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓを利用しており、２０秒おきにＭＬＤパケットを再送するものとする。）。
・ 本実施形態においては、ＴＣＰセッションの管理データとＩＰｖ６（ＭＬＤ用）の管理データを参照して予測スリープ時間を算出する。
以上の前提に基づいて、本実施形態のネットワークコントローラ２の動作について説明する。
【００２２】
図４は、ＣＰＵ動作変更判断処理部１４におけるＣＰＵ動作モード変更処理の過程を示すフローチャートである。
まず上述のデジタル家電におけるシステム初期化時に、Ｈｏｓｔ ＣＰＵ・１はネットワークコントローラ２に対して、５００ｍｓｅｃ以上の待ち時間検出時に動作周波数を下げることを指令するコマンドを出力する。
ネットワークコントローラ２において、ＣＰＵ動作設定処理部１３が、このコマンド（＝ＣＰＵ動作変更時間の設定要求）を受け付け、ＣＰＵ・４のＣＰＵ動作変更時間を設定する。すなわち、本実施形態においては、Ｈｏｓｔ ＣＰＵ・１が外部プログラムモジュール１２と同様の制御処理を行う。
【００２３】
次に、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションは、ＴＣＰ／ＩＰ処理部１０に対してセッション生成要求を送信する。ネットワークコントローラ２において、ＴＣＰ／ＩＰ処理部１０は、Ｈｏｓｔ ＩＦ・８経由でＴＣＰセッション要求を受信し、プロトコルデータ管理部１１にＴＣＰセッション管理データ１をセットする（図５のＴＣＰセッション管理データ１を参照）。
【００２４】
今、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションとＴＣＰ／ＩＰ処理部１０の間でこの処理を複数回、例えばもう一度行い、ＴＣＰ／ＩＰ処理部１０が計２つのＴＣＰセッション（図５のＴＣＰセッション管理データ１、ＴＣＰセッション管理データ２を参照）を生成して、Ｈｏｓｔ ＣＰＵ・１のメインアプリケーションがデータ通信を開始したとする。
このとき、図５に示すように、プロトコルデータ管理部１１には、ＴＣＰセッション管理データ１と、ＴＣＰセッション管理データ２と、ＩＰｖ６管理データがセットされている。
【００２５】
ＣＰＵ動作変更判断処理部１４は、定期的（例えば、１００ｍｓｅｃ毎）、あるいは、前回算出した予測スリープ時間よりも長いタイマ値がプロトコルデータ管理部１１にセットされた時点で処理を開始する。
【００２６】
すなわち、ＣＰＵ動作変更判断処理部１４は、まず受信バッファにデータがあるか否かを確認する（図４のステップＳ１を参照）。
受信バッファにデータがあれば（ステップＳ１でＹｅｓの場合）、続いてパケットが送信されてくる可能性が高いことから、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。一方、受信バッファにデータがなければ（ステップＳ１でＮｏの場合）、ＣＰＵ動作変更判断処理部１４は、チェックしていないプロトコル管理データがあるか否かを確認する（ステップＳ２）。
例えば、ＴＣＰセッション管理データ１、２またはＩＰｖ６管理データのうち、いずれかが未チェックのプロトコル管理データである場合（ステップＳ２でＹｅｓの場合）、ＣＰＵ動作変更判断処理部１４は、未チェックのプロトコル管理データに書き込まれたタイマ値を読み出して、予測スリープ時間を算出し、前回算出した予測スリープ時間を更新する（ステップＳ３）。
ここで読み出すタイマ値は、例えば、ＴＣＰセッションデータ１、２のＲＴＴ、各種タイマ値、ＩＰｖ６管理データのＭＬＤパケット再送タイマ値である。
また、予測スリープ時間は、読み出したＲＴＴ、各種タイマ値の残り時間の最小値とする。
【００２７】
予測スリープ時間の更新後、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作設定処理部１３に設定されたＣＰＵ動作変更時間と更新後の予測スリープ時間とを比較し、予測スリープ時間がＣＰＵ動作変更時間より短い場合は、ステップＳ２に戻って、ステップＳ２〜Ｓ４を繰り返す。そして、ＴＣＰセッション管理データ１、２またはＩＰｖ６管理データがすべてチェック済みとなった場合（ステップＳ２でＮｏの場合）、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００２８】
一方、ＣＰＵ動作変更時間と更新後の予測スリープ時間とを比較し、予測スリープ時間がＣＰＵ動作変更時間より長い場合（ステップＳ４でＹｅｓの場合）、ＣＰＵ動作変更判断処理部１４は、パケット送受信間隔監視部１６よりパケットの受信間隔、送信間隔、直近のパケット受信時刻、送信時刻を読み出す。
そして、ＣＰＵ動作変更判断処理部１４は、この直近のパケット受信時刻にパケットの受信間隔時間分を加算した時刻（＝次のパケットの受信予想時刻）と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの受信予想時刻の方が早い場合（ステップＳ５でＮｏの場合）、すなわち、
次のパケットの受信予想時刻 ＜ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、
ＣＰＵ動作変更判断処理部１４は、ＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００２９】
また、ＣＰＵ動作変更判断処理部１４は、同様に、この直近のパケット送信時刻にパケットの送信間隔時間分を加算した時刻（＝次のパケットの送信予想時刻）と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの送信予想時刻の方が早い場合（ステップＳ５でＮｏの場合）、すなわち、
次のパケットの送信予想時刻 ＜ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、ＣＰＵ動作変更判断処理部１４はＣＰＵ動作変更処理を停止して、プロトコル処理を継続する（ステップＳ６）。
【００３０】
一方、次のパケットの受信予想時刻と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの受信予想時刻の方が遅く、かつ、次のパケットの送信予想時刻と、現在時刻に予測スリープ時間分を加算した時刻とを比較し、次のパケットの送信予想時刻の方が遅い場合（ステップＳ５でＹｅｓの場合）、
すなわち、
次のパケットの受信予想時刻 ＞ 現在時刻＋予測スリープ時間分
かつ
次のパケットの送信予想時刻 ＞ 現在時刻＋予測スリープ時間分
の関係式を満たす場合、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ・４の動作モードを低消費電力モードに変更する命令を出力する（ステップＳ７）。
【００３１】
ＣＰＵ・４は、この命令を受けて、動作モードを低消費電力モードに変更する。そして、ＣＰＵ・４は、外部からの割り込みがかかるまで、つまり他の通信デバイスからパケットを受信するまで、又は、Ｈｏｓｔ ＣＰＵ・１から送信パケットを受信するまで、プロトコル処理を低消費電力モードで実行する（ステップＳ８）。
【００３２】
次に、以上の動作の具体例を説明する。Ｈｏｓｔ ＣＰＵ・１側のメインアプリケーションがデータ通信中に通信経路上で輻輳が発生した場合、ＴＣＰセッションで管理しているＲＴＴ値が大きくなり、１つのＴＣＰセッションのＲＴＴが５５０ｍｓｅｃ、他方のＴＣＰセッションのＲＴＴ値が６００ｍｓｅｃに更新されたとする。このとき、その他のタイマ値の残り時間が５５０ｍｓｅｃより大きい状態であれば、ステップＳ３でＣＰＵ動作判断処理部１４は、予測スリープ時間を５５０ｍｓｅｃに更新する。このとき、設定された５００ｍｓｅｃを超える待ち時間が発生する可能性があるので、ＣＰＵの動作クロックを５０ＭＨｚに変更する命令をＣＰＵ・４に対して出力する。また、この際、パケット送受信間隔監視部１６の情報を参照してより精度の高い予測を行うことも考えられる。
【００３３】
たとえば、図６の上段に示す送信間隔の例では、送信間隔と現在時刻の関連から連続した送信処理が予測され、予測スリープ時間が５５０ｍｓｅｃになっても、ＣＰＵの動作クロックを下げないという判断が可能である。
また、図６の下段に示す受信間隔の例では、例えば、Ｈｏｓｔ ＣＰＵ・１がネットワークコントローラ２に対して、２００ｍｓｅｃ以下の予測スリープ時間を検出した際にＣＰＵの動作クロックを変更する設定を行った場合、ＴＣＰにおける遅延ＡＣＫの残り時間を考慮して予測スリープ時間を計算することができる。すなわち、遅延ＡＣＫにより、ＡＣＫの送信を遅らせている期間は、パケット送信処理が発生しないことから、ＣＰＵの動作クロックを下げることが考えられる。
【００３４】
ネットワークコントローラ２は、動作クロックを５０ＭＨｚに下げた状態でプロトコル処理を続行し、パケットの送受信間隔が５００ｍｓｅｃより小さくなると、ＣＰＵ動作変更判断処理部１４は、ＣＰＵ・４に対して、ＣＰＵの動作クロックを元の１００ＭＨｚに復帰させる命令を出力する。ＣＰＵ・４はこの命令を実行し、動作クロックを１００ＭＨｚに戻す。
なお、ここでは、パケット送受信間隔の情報を動作クロック復帰の判断に利用したが、Ｈｏｓｔ ＣＰＵ・１から複数パケット化が必要な量のデータ送信コマンドを受け付けた場合に復帰することも考えられる。
【００３５】
以上説明したように、本実施形態のネットワークコントローラによれば、ＣＰＵ動作変更時間をＨｏｓｔ ＣＰＵ・１側から設定可能とすることで、ＨｏｓｔＣＰＵ・１のメインアプリケーションの特性に応じて、柔軟に変更できる効果が得られる。したがって、ネットワークコントローラの消費電力をＨｏｓｔ ＣＰＵ・１のメインアプリケーションの特性に応じて、最適化する制御を行うことで低消費電力を実現することができる効果が得られる。
また、パケットの送受信間隔の情報を基にＣＰＵの動作変更判断を実行可能となり、より精度の高い予測が可能となり、ネットワークコントローラの消費電力をより最適化することができる効果が得られる。
特に通常、通信プロトコル処理では、統計データを残す目的やＳＮＭＰのＭＩＢデータとする目的のために送受信が完了後にパケット数等を更新する。本発明は、その更新処理の追加処理としてパケット送受信間隔の更新を行うため、計算負荷が小さい。
【００３６】
また、本発明のネットワークコントローラは、ネットワークコントローラとのインターフェイスを備えたＣＰＵであって、コマンド命令やデータ送受信が可能なＣＰＵであれば、どのような種類のＣＰＵも適用可能である。
また、本発明のネットワークコントローラは、データリンク層、物理層に依存しないので様々な通信方式に適用可能である。
また、本発明のネットワークコントローラは、ＴＣＰ／ＩＰ処理に限られず、ＭＡＣ層の処理を内蔵したネットワークコントローラであっても良い。ＭＡＣ層の処理を内蔵する場合、ＭＡＣプロトコルのタイマ値をＣＰＵの動作モード変更のトリガとすることが考えられる。
また、本実施形態のネットワークコントローラでは、動作モードが通常モードと低消費電力モードとを有する場合を示したが、本発明はこれに限られず、ＣＰＵコアの実装する動作モードを採用してもよい。なお、ＣＰＵの動作クロックが変更不可能な場合は、一定時間の予測スリープ時間を検出したら、ＣＰＵはｓｌｅｅｐ状態に移行し、ｓｌｅｅｐ状態の復帰は、割り込みやＨｏｓｔ ＣＰＵ・１からのコマンド等のイベント検出をトリガとして行う。
また、ＣＰＵ動作変更時間を直接、ＣＰＵ動作変更判断処理部１４に設定するのではなく、要求受付のインターフェイスとなるＣＰＵ動作設定部を設けることにより、新しい設定パラメータの追加が容易にできる効果が得られる。
【００３７】
なお、本実施形態のネットワークコントローラにおいては、予測スリープ時間の計算アルゴリズムとして、各種タイマ値から最短のものを選ぶという方法を示したが、実装段階では、接続するデバイス毎（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ、ＩＥＥＥ８０２．３ｘ、ＩＥＥＥ１３９４、Ｂｌｕｅｔｏｏｔｈ、ＵＳＢ）、また、ネットワークコントローラを搭載している機器が、常時電源に接続されている場合、または、機器内増のバッテリで動作している場合毎にテストシミュレーションを行うことにより最適化されて決定される。
また、本実施形態のネットワークコントローラ２では、送受信バッファ量については、これを積極的に利用しない例を示したが、本発明はこれに限られず、ステップＳ１において、送受信バッファ量の大小に応じた判定処理をおこなってもよい。
また、本実施形態のネットワークコントローラ２では、主にＴＣＰ／ＩＰ処理部１０のプロトコル管理データによりＣＰＵの動作変更判断処理を行ったが、本発明はこれに限られず、プロトコル処理部１５のプロトコル処理におけるタイマ値やバッファ等をも考慮してＣＰＵの動作変更判断処理をしてもよい。
また、本実施形態のネットワークコントローラ２では、主にプロトコル処理の低消費電力をネットワークコントローラ側でのせイ魚により実現するが、本発明はこれに限られず、Ｈｏｓｔ ＣＰＵ・１が明示的にネットワークコントローラ・２に対して命令を発行し、低消費電力モードへ移行させても良い。
【００３８】
本発明がターゲットとするデジタル家電等のネットワーク機器では、汎用のＰＣと異なり、明確なアプリケーションの利用が想定される。したがって、本システムでは、不特定多数のサービスを提供する情報機器というよりは、少人数の利用者に対して、特定のサービスを提供する機器、あるいは、クライアントとして特定のサービスを利用する端末機器として採用されることが想定される。
このようなシステムでは、同時に生成するＴＣＰセッションや管理するプロトコルデータの情報量も少なく、ネットワークに接続されていても、常に通信しているとは限らないので、本発明で利用するタイムアウト値、バッファ量、パケット送受信間隔により低消費電力モードへの判断基準とする方式は、低消費電力の実現方法として有効である。
【００３９】
なお、上述したネットワークコントローラにおけるＣＰＵ動作変更判断処理に関する一連の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【図面の簡単な説明】
【図１】本実施形態のデジタル家電の構成を示すブロック図である。
【図２】本実施形態のネットワークコントローラ２のハードウェア構成を示すブロック図である。
【図３】本実施形態のネットワークコントローラ２のソフトウェア構成を示すブロック図である。
【図４】ＣＰＵ動作変更判断処理部１４の動作を示すフローチャートである。
【図５】プロトコルデータ管理部１１に格納されるプロトコル管理データを示すブロック図である。
【図６】パケットの送受信間隔と現在時刻の関連を示す図である。
【符号の説明】
１…Ｈｏｓｔ ＣＰＵ・４…ネットワークコントローラ、３…ＰＨＹ、４…ＣＰＵ、５…ＲＯＭ、６…ＲＡＭ、７…タイマ、８…Ｈｏｓｔ ＩＦ、９…ＭＩＩ、１０…ＴＣＰ／ＩＰ処理部、１１…プロトコルデータ管理部、１２…外部プログラムモジュール、１３…ＣＰＵ動作設定処理部、１４…ＣＰＵ動作変更判断処理部、１５…プロトコル処理部、１６…パケット送受信間隔監視部
Claims (7)
- プロトコル処理を行うプロトコル処理部と、
該プロトコル処理におけるプロトコルタイマ値を保持する記憶部と、
該プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更するＣＰＵ動作変更判断処理部
を具備することを特徴とするネットワークコントローラ。 - 前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、
前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、前記ＣＰＵ動作モードを該パケット送受信間隔及び直近のパケット送受信時刻に基づいて変更する
ことを特徴とする請求項１に記載のネットワークコントローラ。 - 前記記憶部は、さらに、前記プロトコル処理におけパケット送受信間隔及び直近のパケット送受信時刻を保持し、
前記ＣＰＵ動作変更判断処理部は、さらに、該パケット送受信間隔及び直近のパケット送受信時刻を読み出して、次パケットの送受信予測時刻を算出し、現在時刻に前記予測スリープ時間を加算した時刻と、該送受信予測時刻とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更する
ことを特徴とする請求項１に記載のネットワークコントローラ。 - 前記ＣＰＵ動作変更時間は、前記ネットワークコントローラに接続されたホストＣＰＵより指定された値である
ことを特徴とする請求項１から請求項３のいずれかの項に記載のネットワークコントローラ。 - 前記パケット送受信間隔は、連続したパケットの送受信間隔幅に基づいて決定される
ことを特徴とする請求項１から請求項３のいずれかの項に記載のネットワークコントローラ。 - プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御方法であって、
前記プロトコルタイマ値を読み出し、
自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出し、
該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、
ＣＰＵ動作モードを該比較結果に基づいて変更する
ことを特徴とするＣＰＵ動作変更制御方法。 - プロトコル処理を行うプロトコル処理部と、該プロトコル処理におけるプロトコルタイマ値を保持する記憶部とを有するネットワークコントローラにおいて、該ネットワークコントローラのＣＰＵの動作モードを変更するＣＰＵ動作変更制御処理を該ＣＰＵに実行させるためのプログラムであって、
前記プロトコルタイマ値を読み出し、自身が次にパケットを送信、又は受信するまでの時間である予測スリープ時間を該タイマ値に基づいて算出する処理と、
該予測スリープ時間と予め設定されたＣＰＵ動作変更時間とを比較し、ＣＰＵ動作モードを該比較結果に基づいて変更する処理を
前記ＣＰＵに実行させるためのＣＰＵ動作変更制御プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002358391A JP2004192256A (ja) | 2002-12-10 | 2002-12-10 | ネットワークコントローラ |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002358391A JP2004192256A (ja) | 2002-12-10 | 2002-12-10 | ネットワークコントローラ |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004192256A true JP2004192256A (ja) | 2004-07-08 |
Family
ID=32758118
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002358391A Withdrawn JP2004192256A (ja) | 2002-12-10 | 2002-12-10 | ネットワークコントローラ |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004192256A (ja) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008087727A1 (ja) | 2007-01-18 | 2008-07-24 | Panasonic Corporation | 通信装置及び電力供給方法 |
| JP2011113202A (ja) * | 2009-11-25 | 2011-06-09 | Ricoh Co Ltd | 情報処理装置、情報処理方法、プログラム及び記録媒体 |
| CN102457424A (zh) * | 2010-10-19 | 2012-05-16 | 英业达集团(天津)电子技术有限公司 | 多播封包的发送速度控制方法 |
| JP2013516009A (ja) * | 2010-01-11 | 2013-05-09 | クアルコム，インコーポレイテッド | 動的電力管理のためのドメイン固有言語、コンパイラ、およびｊｉｔ |
| JP2013516710A (ja) * | 2010-01-11 | 2013-05-13 | クアルコム，インコーポレイテッド | 中央処理装置内のデータをサンプリングするシステムおよび方法 |
| US9235251B2 (en) | 2010-01-11 | 2016-01-12 | Qualcomm Incorporated | Dynamic low power mode implementation for computing devices |
| US10051562B2 (en) | 2015-07-17 | 2018-08-14 | Ricoh Company, Ltd. | Communication apparatus, power control method, and recording medium |
| CN114072741A (zh) * | 2019-08-20 | 2022-02-18 | 欧姆龙株式会社 | 控制系统、控制装置以及程序 |
-
2002
- 2002-12-10 JP JP2002358391A patent/JP2004192256A/ja not_active Withdrawn
Cited By (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2008087727A1 (ja) | 2007-01-18 | 2008-07-24 | Panasonic Corporation | 通信装置及び電力供給方法 |
| JP4732523B2 (ja) * | 2007-01-18 | 2011-07-27 | パナソニック株式会社 | 通信装置及び電力供給方法 |
| US8171313B2 (en) | 2007-01-18 | 2012-05-01 | Panasonic Corporation | Communication device and power supply method |
| JP2011113202A (ja) * | 2009-11-25 | 2011-06-09 | Ricoh Co Ltd | 情報処理装置、情報処理方法、プログラム及び記録媒体 |
| JP2013516009A (ja) * | 2010-01-11 | 2013-05-09 | クアルコム，インコーポレイテッド | 動的電力管理のためのドメイン固有言語、コンパイラ、およびｊｉｔ |
| JP2013516710A (ja) * | 2010-01-11 | 2013-05-13 | クアルコム，インコーポレイテッド | 中央処理装置内のデータをサンプリングするシステムおよび方法 |
| US9182810B2 (en) | 2010-01-11 | 2015-11-10 | Qualcomm Incorporated | Domain specific language, compiler and JIT for dynamic power management |
| US9235251B2 (en) | 2010-01-11 | 2016-01-12 | Qualcomm Incorporated | Dynamic low power mode implementation for computing devices |
| CN102457424A (zh) * | 2010-10-19 | 2012-05-16 | 英业达集团(天津)电子技术有限公司 | 多播封包的发送速度控制方法 |
| US10051562B2 (en) | 2015-07-17 | 2018-08-14 | Ricoh Company, Ltd. | Communication apparatus, power control method, and recording medium |
| CN114072741A (zh) * | 2019-08-20 | 2022-02-18 | 欧姆龙株式会社 | 控制系统、控制装置以及程序 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Gunaratne et al. | Managing energy consumption costs in desktop PCs and LAN switches with proxying, split TCP connections, and scaling of link speed | |
| Lim et al. | Design, implementation, and evaluation of energy-aware multi-path TCP | |
| US8165015B1 (en) | Modifying a rate based on at least one performance characteristic | |
| KR101379869B1 (ko) | 패킷 데이터 네트워크들에서 물리 계층 디바이스들에 대한 자기 적응 동적 전력 감소 메커니즘을 위한 방법 및 시스템 | |
| JP5867188B2 (ja) | 情報処理装置、輻輳制御方法および輻輳制御プログラム | |
| US9112781B2 (en) | Deactivating a packet tunnel based on at least one performance characteristic | |
| KR101552382B1 (ko) | 네트워크 접속을 유휴화하기 위한 방법 및 장치 | |
| US11671210B2 (en) | Retransmission control method, communications interface, and electronic device | |
| CN104052684A (zh) | 动态适配计算机网络中的最大传输单元大小的方法和系统 | |
| JP5573844B2 (ja) | 通信端末および通信方法 | |
| JP2004192256A (ja) | ネットワークコントローラ | |
| Araujo et al. | BEEP: Balancing energy, redundancy, and performance in fat-tree data center networks | |
| CN110192378B (zh) | 控制非最佳路径的使用的装置和方法 | |
| JP5218979B2 (ja) | データ転送装置 | |
| JP3918859B2 (ja) | ネットワーク、ルータ装置及びそれに用いる経路更新抑止方法並びにそのプログラム | |
| WO2005055546A1 (ja) | セッション中継装置、セッション中継方法及びセッション中継プログラム | |
| US10972442B1 (en) | Distributed predictive packet quantity threshold reporting | |
| JP2010239299A (ja) | ネットワークの管理システム及び管理方法 | |
| KR101001046B1 (ko) | 중계 장치 및 중계 방법 | |
| US20100070668A1 (en) | Interrupt control apparatus, interrupt control system, interrupt control method, and interrupt control program | |
| WO2021073367A1 (zh) | 一种数据处理方法、设备及系统 | |
| JP7110573B2 (ja) | 情報処理装置、情報処理プログラム及び情報処理方法 | |
| JP6405692B2 (ja) | 送信装置、送信装置の制御方法、送信プログラム及び通信システム | |
| JP5915755B2 (ja) | 情報処理装置 | |
| KR100951532B1 (ko) | 홈 네트워크 시스템의 활성/비활성 선택 장치 및 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A300 | Withdrawal of application because of no request for examination |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20060307 |