JP2015136071A - 通信装置、制御方法及びプログラム - Google Patents

Abstract

【課題】 実際の通信の状況に応じた、通信処理のためのリソースの細かい電源供給及び停止制御を行うこと。
【解決手段】 通信装置は、通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有する１つ以上のリソースを含み、通信に関する複数の識別子のそれぞれに対して、１つ以上のリソースのそれぞれについての複数のブロックのうちのいずれかのブロックを対応させて管理する。通信装置は、通信プロトコルの処理が開始されると、処理の単位ごとに、複数の識別子のうちのいずれかの識別子を割り当てる。そして、通信装置は、処理の単位ごとに、処理の開始と終了とに応じて、その処理の単位に割り当てられた識別子に対応する１つ以上のリソースのそれぞれについてのブロックへの、電源の供給とその供給の停止またはクロックの供給とその供給の停止を、一括して制御する。
【選択図】 図２

Description

本発明は通信装置、制御方法及びプログラムに関する。

近年、汎用コンピュータ（ＰＣ）のみならず、コンピュータ組込機器においてもネットワークプロトコル処理を高速に実行することが要求される。しかし、ソフトウェア処理によるギガビットイーサネット（登録商標）の充分な処理速度は、コンピュータ組込機器が搭載するプロセッサの能力を遥かに超える。そこで、ＴＯＥ（ＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）といったプロトコル処理に特化した補助的デバイスを付加して、プロセッサに頼らず、広帯域なネットワーク通信を実現することが一般化している。

一方で、ＴＯＥなどのプロトコル処理装置では、複数の通信装置との通信又は１つの通信相手との間の複数のコネクションによる通信を同時に実現するために、パケットを一時的に蓄積するための大容量のメモリリソースが用意されることとなる。これらのリソースは、プロトコル処理装置が同時に通信可能な最大数の通信を行っているか、通信が行われていない又は僅かな通信のみが行われているかによらず、すべてのリソースに電力を供給するため、消費電力面で効率的ではない。

これに対して、特許文献１は、受信したパケットを一時的に蓄積するパケットバッファの有効バッファ数を受信したパケット量に応じて制御し、トラフィックが少ない時は一部のパケットバッファの電源供給を停止して消費電力を低減する手法を提案している。

特開２０１１−０６１４４３号公報

ＴＯＥでは、パケットを一時的に蓄積するメモリリソースだけでなく、プロトコル処理の高速化を図るため、さまざまなハードウェア（ＨＷ）リソース及びオンチップメモリリソースが用いられる。これらのリソースは、同時通信可能な最大数に対応する数だけ保持されるべきであるものが多く、パケットを蓄積するためのメモリリソースと同様に、少量の通信の際においてもＨＷ全体に電源が供給されることにより、多くの電力を消費してしまう。

特許文献１に示す方法は、メモリリソースの制御のみを対象としており、ＴＯＥのような、様々のＨＷリソース及びオンチップメモリを必要とする構成では、すべての電源を制御することができないという課題があった。また、特許文献１に記載の手法は、受信したパケットの量により予測的に電源の供給を行うものであり、実際の通信で要求されるリソースの電源を細かく制御できないという課題もあった。

本発明は上記課題に鑑みなされたものであり、実際の通信の状況に応じた、通信処理のためのリソースの細かい電源供給及び停止制御を行うことを目的とする。

上記目的を達成するため、本発明による通信装置は、通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有する１つ以上のリソースと、通信に関する複数の識別子のそれぞれに対して、前記１つ以上のリソースのそれぞれについての前記複数のブロックのうちのいずれかのブロックを対応させて管理する管理手段と、前記通信プロトコルの処理が開始されると、処理の単位ごとに、前記複数の識別子のうちのいずれかの識別子を割り当てる割当手段と、前記処理の単位ごとに、処理の開始と終了とに応じて、当該処理の単位に割り当てられた識別子に対応する前記１つ以上のリソースのそれぞれについてのブロックへの、電源の供給とその供給の停止またはクロックの供給とその供給の停止を、一括して制御する制御手段と、を有する。

本発明によれば、実際の通信の状況に応じた、通信処理のためのリソースの細かい電源供給及び停止制御を行うことができる。

通信装置の構成例を示す図。 ＴＯＥサブシステム構成を示す図。 サブプロセッサの役割を説明する図。 ＴＣＰソケット作成処理の流れを示すフローチャート。 ＴＣＰソケットＩＤ取得処理の流れを示すフローチャート。 ＴＣＰソケットＩＤ初期化処理の流れを示すフローチャート。 ＴＣＰソケット解放処理の流れを示すフローチャート。 ＴＣＰソケットＩＤ返却処理の流れを示すフローチャート。 新規のＩＰリアセンブル開始処理の流れを示すフローチャート。 ＩＰリアセンブルＩＤ取得処理の流れを示すフローチャート。 ＩＰリアセンブルＩＤ初期化処理の流れを示すフローチャート。 ＩＰリアセンブルリソース解放処理の流れを示すフローチャート。 ＩＰリアセンブルＩＤ返却処理の流れを示すフローチャート。

以下、添付図面を参照して本発明の実施の形態を詳細に説明する。

（通信装置の構成）
図１を用いて、本実施形態に係る通信装置の構成例について説明する。図１の通信装置において、主プロセッサ１０１は、システムバス１０２を介して、後述する各構成に接続されている。なお、システムバス１０２は、英国ＡＲＭ社が提唱するＡＭＢＡ ３．０ ＡＸＩ（Ａｄｖａｎｃｅｄ ｅＸｔｅｎｓｉｂｌｅ Ｉｎｔｅｒｆａｃｅ）仕様に代表されるクロスバースイッチ構造のオンチップバスである。システムバス１０２は、通信装置に要求される送受信データの並行転送動作が可能である。なお、主プロセッサ１０１は、通信装置全体の制御を実行するコンピュータである。

割込制御部１０６は、各構成やＴＯＥサブシステム１０５からの割込イベントを主プロセッサ１０１に伝達する。タイマ１０７は、ソフトウェアなどによって起動され、時間計測やタイムアウトイベントを発生させる。汎用入出力（ＩＯ）インタフェース１１４に接続された入力キー１１５は、通信装置の動作モードの設定や、ＩＰアドレスに代表される各種通信パラメータの入力を受け付けるための機能部である。表示制御部１０８に接続された表示部１０９は、通信装置の状態、アプリケーションの状態、設定内容などを表示する。主ＤＭＡ制御部１１２は、通信装置内のダイレクトメモリアクセス（ＤＭＡ）を制御するコントローラ（ＤＭＡＣ）である。

二次記憶制御部１１０に接続されたハードディスク（ＨＤ）装置１１１は、通信装置の機能を実現するソフトウェアとその関連データ、各サブシステムのサブプロセッサが実行するファームウェアとその関連データなどを格納する。ＨＤ装置１１１は、さらに、通信装置の動作履歴や通信履歴などの履歴情報を格納する。なお、通信装置の機能を実現するソフトウェアには、オペレーティングシステム（ＯＳ）、通信装置の各機能を実現するアプリケーションソフトウェア、アプリケーションプロトコル、関連ハードウェアを制御するためのデバイスドライバなどが含まれる。

メモリ制御部１１７に接続されたＦｌａｓｈメモリ１１８は、書き換え可能な不揮発性メモリであり、ＳＲＡＭ１１９は、書き換え可能な揮発性メモリである。Ｆｌａｓｈメモリ１１８及びＳＲＡＭ１１９の少なくともいずれかに、通信装置の起動時に動作するブートプログラム、通信装置の初期状態の設定に使用されるパラメータなどが格納される。Ｆｌａｓｈメモリ１１８及びＳＲＡＭ１１９の少なくともいずれかは、さらに、通信装置の起動時に各構成（ハードウェア）を制御するためのデバイスドライバ、各構成の起動時の設定パラメータなどを格納する。主プロセッサ１０１は、Ｆｌａｓｈメモリ１１８及びＳＲＡＭ１１９の少なくともいずれかに格納されたブートプログラムを実行する。

主メモリ制御部１０３に接続された主メモリ１０４は、例えば、主プロセッサ１０１のワークメモリとして機能する。例えば、主プロセッサ１０１は、通信装置の各ハードウエアとサブシステムとを初期化した後、ＨＤ装置１１１に格納されているソフトウェアを主メモリ１０４にロードしてＯＳを起動する。また、主プロセッサ１０１は、サブシステムの初期化時にＴＯＥサブシステム１０５に内蔵されているサブプロセッサＡ〜Ｅ（２０１〜２０５）が実行する各ファームウエアを主メモリ１０４上に展開して、各サブプロセッサを起動する。各サブプロセッサ２０１〜２０５は主メモリ１０４上に展開された各ファームウエアを、各サブプロセッサに内蔵する命令キャッシュメモリにロードして、ファームウエアプログラムを実行する。主メモリ１０４は複数のブロックに分割されており、主メモリ制御部１０３は、このブロックごとに電源の供給とその停止とを指示することができる。

ＴＯＥサブシステム１０５は、通信装置が有線ネットワーク１２０に接続するための機能部である。ＴＯＥサブシステム１０５の詳細については後述する。無線ＬＡＮサブシステム１１３は、通信装置がＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ規格に準拠する無線ＬＡＮネットワークに接続するための機能部である。汎用バスインタフェース１１６は、通信装置をＵＳＢやＩＥＥＥ１３９４などのシリアルバスに接続する。

（ＴＯＥサブシステムの構成）
続いて、図２を用いて、本実施形態に係るＴＯＥサブシステム１０５の構成例について詳細に説明する。

バスブリッジ２０６は、ＴＯＥサブシステム１０５の内部バスであるサブシステムバス２０８とシステムバス１０２とを接続する。なお、サブシステムバス２０８は、例えばクロスバースイッチ接続である。ＴＯＥサブシステム１０５は、５つのサブプロセッサ２０１〜２０５を有し、これらのサブプロセッサによるマルチプロセッサ処理により、主システムからＴＣＰ／ＩＰプロトコル処理をオフロードし、このプロトコル処理を高速に実行する。共有メモリ２１５は、サブプロセッサ２０１〜２０５間の通信と情報共有のためのメモリである。通信タイマ２１６は、ＴＣＰ／ＩＰプロトコル処理に必要な時間計測およびタイムアウトイベントを発生させる。

図３を用いて、本実施形態に係るＴＯＥサブシステム１０５のサブプロセッサ２０１〜２０５の役割について説明する。ＴＣＰ／ＩＰプロトコル処理は、アプリケーション層３０１、ソケットＡＰＩ３０２、トランスポート層（ＴＣＰ／ＵＤＰ層）３０３、インターネット層（ＩＰ層）３０４、ＭＡＣドライバ３０５、ＭＡＣ層３０６、ＰＨＹ層３０７の階層構造を有する。ここで、ＴＯＥサブシステム１０５は、図３の３１０で示される部分を処理する機能を有する。すなわち、ＴＯＥサブシステム１０５は、ＴＣＰ／ＵＤＰ層３０３、ＩＰ層３０４、ＭＡＣドライバ３０５の（処理）機能と、ソケットＡＰＩ３０２の一部の機能とを有する。なお、ＴＣＰ／ＵＤＰ層３０３はＴＣＰプロトコルとＵＤＰプロトコルとを処理し、ＩＰ層３０４はＩＰプロトコルを処理する。また、ＭＡＣドライバ３０５はＭＡＣ層３０６との間で通信データと通信情報を交換する機能であり、ソケットＡＰＩ３０２はアプリケーション通信のＡＰＩである。ＴＯＥサブシステム１０５は、これら機能を各サブプロセッサに分散して処理を行う。

例えば、ソケットＡＰＩ３０２の一部の処理をサブプロセッサ２０１に割り当てる。そして、ＴＣＰプロトコルとＵＤＰプロトコルとの処理のうち受信動作３１５に関する処理をサブプロセッサ２０２に割り当て、送信動作３１６に関する処理をサブプロセッサ２０３に割り当てる。さらに、ＭＡＣドライバ３０５とＩＰプロトコルとの処理のうち、受信動作３１５に関する処理をサブプロセッサ２０４に割り当て、送信動作３１６に関する処理をサブプロセッサ２０５に割り当てる。このように処理を分散することにより、一連のプロトコル処理を３つのパイプラインステージ３１１〜３１３に分割し、パイプライン動作を行うことが可能となる。また、送信動作３１６と受信動作３１５とを分けることで、それぞれの機能を担当するサブプロセッサ同士を並列的に動作させることが可能となる。

本実施形態では、各サブプロセッサ間の処理データの伝達と制御情報の共有は共有メモリ２１５を介して行われる。例えば、ＴＣＰは転送データの到達保証を行う観点から、受信側から送信側に対して、確認応答と称する到達確認情報をコネクション間で伝達する。この確認応答を行うには、サブプロセッサ２０２とサブプロセッサ２０３との間で確認応答の伝達（３１４）がされることとなる。ＴＯＥサブシステム１０５では、このようなＴＣＰの制御情報の伝達を、共有メモリ２１５を介して行う。なお、サブプロセッサ間における到達確認情報の伝達と制御情報の共有は主メモリ１０４を用いて行ってもよい。なお、ＴＯＥサブシステム１０５では、ＴＣＰ処理に必要となる制御情報は、後述のＴＣＢコントローラ２１８を用いて共有する。

ＴＯＥサブシステム１０５は、有線ネットワーク１２０に接続するためのハードウェアとしてＰＨＹ２１４とＭＡＣ（Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）２１３とを備える。ＰＨＹ２１４は、ＯＳＩ参照モデルの物理層（第１層）のプロトコル処理と電気信号を扱う。ＭＡＣ２１３は、ＯＳＩ参照モデルのデータリンク層（第２層）の下位副層に相当するＭＡＣ層のプロトコルを処理する。

図２に戻り、データパス制御部２１２は、受信パケットデータと送信パケットデータとを、例えば、主メモリ１０４または共有メモリ２１５とＭＡＣ２１３との間でＤＭＡ転送する機能を有する。データパス制御部２１２は、転送処理中にパケットデータのチェックサム演算を行う。検索装置２０７は、連想メモリを有し、プロトコル処理の様々な管理情報の格納と検索処理を行う。

ＴＯＥサブシステム１０５は、さらに、ＴＣＰによる通信処理のための制御情報を格納するためのメモリをコントロールするＴＣＢコントローラ２１８を有する。また、ＴＯＥサブシステム１０５は、さらに、ＩＰのリアセンブル処理において受信したパケット（フラグメント）の情報を管理するビットマップコントローラ２１９と、同時のプロトコル処理数を管理するＩＤマネージャ２１７とを有する。なお、ＩＤマネージャ２１７は、同時に並行して存在するリアセンブルされるデータの数とＴＣＰソケット数との少なくともいずれかを、処理の単位として識別子（ＩＤ）によって管理する。また、ＩＤマネージャ２１７は、電源制御部２２０を有し、通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有するハードウェアリソースに対して、各ブロックの電源供給及び停止の制御を行う。

なお、ＴＯＥサブシステム１０５は、暗号通信プロトコル処理を実行する。暗号通信プロトコルは、例えば、ＩＰｓｅｃ（Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）である。なお、暗号通信プロトコルは、例えば、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）、ＴＬＳ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）であってもよい。これらの暗号通信プロトコル処理のため、ＴＯＥサブシステム１０５は、鍵管理部２０９、乱数発生器２１０、暗号器２１１を有する。鍵管理部２０９は、暗号通信プロトコル処理のために生成した暗号鍵、乱数、素数を機密に保持する。乱数発生器２１０は、暗号処理に必要となる乱数値を生成する。暗号器２１１は、例えばＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）暗号器である。また、暗号器２１１は、さらに、認証やディジタル署名などに使われるＳＨＡ−１（Ｓｅｃｕｒｅ Ｈａｓｈ Ａｌｇｏｒｉｔｈｍ １）、ＲＦＣ２１２１として標準化されているＭＤ５（Ｍｅｓｓａｇｅ Ｄｉｇｅｓｔ ５）などのハッシュ関数器を含む。

ＴＯＥサブシステム１０５は、ＴＣＰソケットごとの、通信タイマ２１６、ＴＣＢコントローラ２１８の管理するメモリ領域、検索装置２０７の検索エントリ、主メモリ１０４のソケットバッファといったリソースを用意する。各リソースは、同時にコネクションの確立が可能なＴＣＰソケットの最大数分に対応する、電源の供給及び停止制御が可能な複数のブロックを有する。そして、各ブロックは、ＩＤマネージャ２１７で管理するＴＣＰソケットの識別子（ＩＤ）に関連付けて管理される。すなわち、ＩＤごとに、各ブロックに対する電源の供給及びその停止を制御することが可能な構成となっている。電源制御部２２０は、ＩＤに対応するＴＣＰソケットによる通信の開始または終了に応じて、ＩＤに対応する、１つ以上のリソースのそれぞれのブロックに対して、一括して電源の供給または電源の供給の停止を実行するような制御を行う。

また、ＴＯＥサブシステム１０５は、１つのデータにリアセンブルされるフラグメントの集合ごとに、通信タイマ２１６、ビットマップコントローラ２１９、検索装置２０７の検索エントリ、主メモリ１０４のＩＰリアセンブルバッファ等のリソースを用意する。各リソースは、同時にＩＰリアセンブル処理が可能なフラグメントの集合の最大数分に対応する、電源の供給及び停止制御が可能な複数のブロックを有する。そして、各ブロックは、ＩＤマネージャ２１７で管理するリアセンブルされるデータの識別子（ＩＤ）に関連づけて管理される。すなわち、ＩＤごとに、各ブロックに対する電源の供給及びその停止を制御することが可能な構成となっている。電源制御部２２０は、ＩＤに対応する１つのリアセンブルされるデータのフラグメントの集合の通信の開始または終了に応じて、各リソースのＩＤに対応するブロックに対して、一括して電源の供給、または電源の供給の停止を実行するような制御を行う。

なお、主メモリ１０４の電源制御についてはＩＤマネージャ２１７内の電源制御部２２０からの指示により主メモリ制御部１０３で行う。各ハードウェア（ＨＷ）リソースと電源制御部２２０とは、電源制御ポート２２１で接続されており、ＩＤマネージャ２１７からの指示により、電源制御部２２０は電源制御ポートを介して各ＨＷリソースの電源制御を行う。

本実施形態では、１つ以上のリソースのそれぞれについての複数のブロックのうちの１つが１つのＩＤに対応付けられ、１つのＩＤに対応する通信の開始及び終了に応じて、対応するブロックに対して電源の供給及びその停止をするように制御されるとした。しかしながら、このような構成でなくてもよい。すなわち、１つのブロックは複数のＩＤに対応付けられていてもよい。なお、１つのブロックに複数のＩＤが対応付けられている場合は、１つのブロックに対応する複数のＩＤの少なくとも１つについての通信が開始された場合に、そのブロックへの電源供給が実行されるように制御が行われる。また、この場合、そのブロックに対応する複数のＩＤの全てについての通信が終了したことに応じて、このブロックへの電源供給が停止されるように制御が行われる。

また、電源の供給及びその停止を制御するのに代えて、クロックの供給とその停止が実行されるように制御が行われてもよい。また、本実施形態では、プロトコル処理の種別として、ＴＣＰソケットにおけるプロトコル処理およびＩＰフラグメントパケットのリアセンブル処理が用いられる場合について説明するが、ＵＤＰ処理等の他のプロトコル処理の種別が用いられてもよい。

（ＴＣＰソケット作成処理）
続いて、サブプロセッサ２０２またはサブプロセッサ２０３において実行される、本実施形態に係るＴＣＰソケット作成処理の流れについて、図４及び図５を用いて説明する。この処理は、例えば、電源制御に対応する通信プロトコルの処理の単位が、１つのＴＣＰソケットによる通信に関するものである場合の処理である。なお、以下では、サブプロセッサ２０２またはサブプロセッサ２０３を、単に「サブプロセッサ」と総称する。

まず、図４のＳ４０１において、サブプロセッサは、ＩＤマネージャ２１７にＴＣＰソケットの識別子（ＴＣＰソケットＩＤ）の取得を要求し、ＩＤマネージャ２１７からＴＣＰソケットＩＤを受け取る。このときの、ＩＤマネージャ２１７におけるＴＣＰソケットＩＤ取得の処理の流れについて、図５を用いて詳細に説明する。

Ｓ５０１において、ＩＤマネージャ２１７は、現在のＴＣＰソケットＩＤカウンタが最大値に達しているかを調べる。すなわち、ＩＤマネージャ２１７は、現在使用しているＴＣＰソケットの数が、同時に取り扱える最大値に既に達しているかを判定する。そして、ＩＤマネージャ２１７は、ＴＰＣソケットの最大値に達していた場合はエラーを出力して（Ｓ５１３）、処理を終了し、最大値に達していなかった場合は、処理をＳ５０２へ進める。

Ｓ５０２では、ＩＤマネージャ２１７は、自らが保持しているＴＣＰソケットＩＤ値から（任意の）ＩＤ値を１つ選択する。すなわち、Ｓ５０２で、新たに作成されるＴＣＰソケットへのＩＤの割当処理が実行される。ＴＣＰソケットＩＤ値は、ＦＩＦＯを利用してＩＤ値を格納し、又はビットマップを用いて保持するなど、ＩＤ値を保持できる所定の方法で保持される。なお、ＩＤマネージャ２１７は、同時に取り扱うことができるＴＣＰソケットの最大値の数の分だけ、ＩＤ値を保持していてもよいし、それより多くのＩＤ値を保持していてもよい。

続いて、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＰタイマのブロックに電源が供給されているかを判定し（Ｓ５０３）、ブロックに電源が供給されていない場合は処理をＳ５０４へ進め、供給されている場合は処理をＳ５０５へ進める。ここで、「ブロック」は電源の供給を管理する単位であり、１つのブロックに対して個別に電源供給とその停止とを制御することができる。なお、ブロックは単一のＩＤに対応付けられていてもよいし、複数のＩＤに対応付けられていてもよい。Ｓ５０４では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＰタイマのブロックに対する電源供給を通信タイマ２１６に指示し、処理をＳ５０５へ移す。

Ｓ５０５では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応する検索装置２０７のＴＣＰソケット検索テーブルのエントリブロックに電源が供給されているかを調べる。そして、処理は、ブロックに電源が供給されていない場合はＳ５０６へ進み、供給されている場合はＳ５０７へ進む。Ｓ５０６では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＰソケット検索テーブルの検索エントリのブロックに対する電源供給を検索装置２０７に指示し、処理をＳ５０７へ進める。

Ｓ５０７では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＢコントローラ２１８が管理しているメモリ領域のブロックに電源が供給されているかを調べる。そして、処理は、ブロックに電源が供給されていない場合はＳ５０８へ進み、供給されている場合はＳ５０９へ進む。Ｓ５０８では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＢコントローラ管理のメモリ領域のメモリブロックに対する電源供給をＴＣＢコントローラ２１８に指示し、処理をＳ５０９へ進める。

Ｓ５０９では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応するＴＣＰソケットバッファ領域の主メモリブロックに電源が供給されているか調べる。そして、処理は、主メモリブロックに電源が供給されている場合はＳ５１１へ進み、供給されていない場合はＳ５１０へ進む。Ｓ５１０では、ＩＤマネージャ２１７は、ＴＣＰソケットＩＤに対応する主メモリ１０４のＴＣＰソケットバッファ領域の主メモリブロックに対する電源供給を主メモリ制御部１０３に指示し、処理をＳ５１１へ進める。

Ｓ５１１では、ＩＤマネージャ２１７は、Ｓ５０２で選択した（割当処理により割り当てられた）ＩＤ値を出力し、Ｓ５１２でＴＣＰソケットＩＤの使用数を管理するカウンタをインクリメントして、処理を終了する。

なお、本実施形態では、上述の手順で電源の供給指示を行ったが、各ハードウェアリソースに対して電源の供給ができればどのような手順で行ってもよい。例えば、Ｓ５０３〜Ｓ５０４の処理とＳ５０５〜Ｓ５０６の順序は逆にされてもよいし、その他の処理についても順序が変更されてもよい。また、上述の各ブロックのうちの１つ以上について常に電源が供給されている場合は、そのブロックについて電源が供給されているかの判定及び電源供給指示の処理は省略されてもよい。

図４に戻ると、上述のようにして、ＴＣＰソケットＩＤが、ＩＤマネージャ２１７からサブプロセッサへ受け渡される（Ｓ４０１）と、サブプロセッサは、Ｓ４０２において、Ｓ４０１で取得した結果を調べる。そして、ＩＤ値が取得できずエラーが出力されていた場合は、サブプロセッサは、ソケット作成失敗を出力して（Ｓ４０８）、処理を終了する。一方、ＩＤ値が取得できた場合は、処理はＳ４０３へ進む。

Ｓ４０３では、サブプロセッサは、取得したＩＤ値に対応したＴＣＢコントローラ管理のメモリ領域をロードする指示をＴＣＢコントローラ２１８に行う。そして、Ｓ４０４において、サブプロセッサは、ＴＣＢコントローラ２１８にＴＣＰコネクションの情報を書き込み、ソケット情報の初期化を行う。続いて、サブプロセッサは、取得したＴＣＰソケットＩＤに対応した通信タイマ２１６のＴＣＰタイマを設定して起動する（Ｓ４０５）。そして、サブプロセッサは、取得したＴＣＰソケットＩＤに対応した検索装置２０７のＴＣＰソケット検索テーブルの検索エントリにＴＣＰソケット検索情報を登録し（Ｓ４０６）、ソケット作成成功を出力して（Ｓ４０７）、処理を終了する。なお、これらのステップの順序等は変更されてもよい。

（ＴＣＰソケットＩＤ初期化処理）
続いて、図６を用いて、主プロセッサ１０１によるＴＣＰソケットＩＤ初期化処理の流れについて説明する。なお、本実施形態では主プロセッサがＴＣＰソケットＩＤ初期化処理を行うが、ＴＯＥ内のサブプロセッサがこの処理を実行してもよい。なお、この処理は、例えば、通信装置の電源が投入された際に実行され、この処理の後に、上述の図４及び図５の処理が実行される。

主プロセッサ１０１は、Ｓ６０１において、ＴＣＰソケットＩＤの最大値をＩＤマネージャ２１７に設定する。この設定値はシステムごとに決定するＴＣＰソケットの最大同時コネクション数である。その後、主プロセッサ１０１は、ＴＣＰソケットＩＤ値の最大数分のソケットバッファ領域を主メモリ１０４上に確保する（Ｓ６０２）。この領域は、主メモリ制御部１０３の制御により電源制御が可能な領域に確保される。なお、本実施形態では、主メモリ上にソケットバッファを確保する場合について説明しているが、バッファごとに電源制御可能なメモリ領域であれば、他のメモリ上にソケットバッファが確保されてもよい。

続いて、主プロセッサ１０１は、Ｓ６０２で確保したソケットバッファの位置情報をＩＤマネージャ２１７に設定する（Ｓ６０３）。ＩＤマネージャ２１７は、この設定情報に基づいて、ＴＣＰソケットによる通信の開始または終了時（すなわち、ＴＣＰソケットＩＤが取得され、開放された際）の電源制御の指示を行う。主プロセッサ１０１は、その後、ＴＣＢコントローラ用のメモリ領域をＴＣＢコントローラ２１８に設定する（Ｓ６０４）。ＴＣＢコントローラ２１８は、この設定情報に基づいて、サブプロセッサの指示により、ＴＣＰソケットＩＤに対応したメモリ領域のロード又はアンロードを行う。そして、主プロセッサ１０１は、ＴＣＰソケット検索用の検索テーブルの、検索装置２０７に対する設定を行う（Ｓ６０５）。その後、主プロセッサ１０１は、ＩＤマネージャ２１７に対して、ＴＣＰソケットＩＤに関連づけられたハードウェアリソースの電源制御を開始すべき旨を示す指示を行い（Ｓ６０６）、処理を終了する。なお、上述の各ステップは、順序が変更されてもよいし、一部のステップが削除されてもよい。

（ＴＣＰソケット解放処理）
続いて、サブプロセッサ２０２またはサブプロセッサ２０３において実行される、本実施形態に係るＴＣＰソケット解放処理の流れについて、図７及び図８を用いて説明する。なお、以下では、サブプロセッサ２０２またはサブプロセッサ２０３を、単に「サブプロセッサ」と総称する。

まず、あるＴＣＰソケットによる通信が終了した場合、サブプロセッサは、図７のＳ７０１において、検索装置２０７のＴＣＰソケットＩＤ値に対応した領域のエントリを削除する。そして、サブプロセッサは、ＴＣＢコントローラ２１８のＴＣＰソケットＩＤ値に対応したＴＣＰソケット情報をクリアし（Ｓ７０２）、ＴＣＰソケットＩＤ値に対応したＴＣＰタイマを停止する（Ｓ７０３）。サブプロセッサは、さらに、Ｓ７０４において、ＴＣＰソケットＩＤ値をＩＤマネージャ２１７に返却して、処理を終了する。

ここで、図８を用いて、Ｓ７０４においてＴＣＰソケットＩＤ値が返却された場合の、ＩＤマネージャ２１７が実行するＴＣＰソケットＩＤ返却処理について説明する。ＩＤマネージャ２１７は、Ｓ８０１において、返却されたＩＤ値を、保持しているＴＣＰソケットＩＤ値に追加する。すなわち、ＩＤマネージャ２１７は、返却されたＩＤ値を、その後に新規に開始されるＴＣＰソケットによる通信に対して割り当てるための候補に追加して保持しておく。

そして、ＩＤマネージャ２１７は、返却されたＩＤ値に対応する各ハードウェアリソースのブロックについて、電源供給の停止を指示する。具体的には、Ｓ８０２においてＩＤ値に対応するＴＣＰタイマの電源停止が通信タイマ２１６に対して指示され、Ｓ８０３において、ＩＤ値に対応するＴＣＰソケット検索テーブルのエントリの電源停止が検索装置２０７に対して指示される。また、Ｓ８０４において、ＩＤ値に対応するＴＣＢコントローラ用のメモリ領域の電源停止がＴＣＢコントローラに指示され、Ｓ８０５において、ＩＤ値に対応する主メモリ１０４上のソケットバッファ領域の電源停止が主メモリ制御部１０３に指示される。そして、ＩＤマネージャ２１７は、Ｓ８０６において、ＴＣＰソケットＩＤの使用数を管理するカウンタをデクリメントして、処理を終了する。なお、上述の各ステップについても、例えば電源停止の指示の順序が変更されてもよいし、一部のステップが削除されてもよい。

（ＩＰリアセンブル開始処理）
続いて、サブプロセッサ２０４において実行される、本実施形態に係る新規のＩＰリアセンブルの開始処理について、図９及び図１０を用いて説明する。この処理は、例えば、電源制御に対応する通信プロトコルの処理の単位が、１つのデータにリアセンブルされるフラグメントの集合の通信に関するものである場合の処理である。

まず、図９のＳ９０１において、サブプロセッサ２０４は、ＩＤマネージャ２１７にＩＰリアセンブルＩＤの取得を要求し、ＩＤマネージャ２１７からＩＰリアセンブルＩＤを受け取る。このときの、ＩＤマネージャ２１７におけるＩＰリアセンブルＩＤ取得の処理の流れについて、図１０を用いて詳細に説明する。

Ｓ１００１において、ＩＤマネージャ２１７は、現在のＩＰリアセンブルカウンタが最大値に達しているかを調べる。すなわち、ＩＤマネージャ２１７は、現在並行して実行中のＩＰリアセンブルの数が、同時に取り扱える最大値に既に達しているかを判定する。そして、ＩＤマネージャ２１７は、同時のＩＰリアセンブルの数が最大値に達していた場合はエラーを出力して（Ｓ１０１３）、処理を終了し、最大値に達していなかった場合は処理をＳ１００２へ進める。

Ｓ１００２では、ＩＤマネージャ２１７は、自らが保持しているＩＰリアセンブルＩＤ値から（任意の）ＩＤ値を１つ選択する。すなわち、Ｓ１００２で、新たに実行されるＩＰリアセンブルに対してＩＤの割当処理が実行される。ＩＰリアセンブルＩＤ値は、ＴＣＰソケットＩＤ値と同様に、ＦＩＦＯを利用してＩＤ値を格納し、又はビットマップを用いて保持するなど、ＩＤ値を保持できる所定の方法で保持される。

続いて、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するＩＰリアセンブルタイマのブロックに電源が供給されているかを判定する（Ｓ１００３）。この判定の結果、処理は、ブロックに電源が供給されていない場合はＳ１００４へ進み、供給されている場合はＳ１００５へ進む。なお、ここでの「ブロック」も、上述のように、電源の供給を管理する単位であり、１つのブロックに対して個別に電源供給とその停止とを制御することができる。また、ブロックは単一のＩＤに対応付けられていてもよいし、複数のＩＤに対応付けられていてもよい点についても、上述の説明と同様である。Ｓ１００４では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するＩＰリアセンブルタイマのブロックの電源供給を通信タイマ２１６に対して指示し、処理をＳ１００５へ移す。

Ｓ１００５では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応する検索装置２０７のＩＰリアセンブル検索テーブルのエントリブロックに電源が供給されているかを調べる。そして、処理は、電源が供給されていない場合はＳ１００６へ進み、供給されている場合はＳ１００７へ進む。Ｓ１００６では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するＩＰリアセンブル検索テーブルの検索エントリブロックの電源供給を検索装置２０７に対して指示し、処理をＳ１００７へ進める。

Ｓ１００７では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するビットマップコントローラ２１９のビットマップテーブルのブロックに電源が供給されているかを調べる。処理は、電源が供給されていない場合はＳ１００８へ進み、供給されている場合はＳ１００９へ進む。Ｓ１００８では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するビットマップテーブルに対する電源供給を、ビットマップコントローラ２１９に指示し、処理をＳ１００９へ進める。

Ｓ１００９では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応するＩＰリアセンブルバッファ領域の主メモリブロックに電源が供給されているかを調べる。処理は、主メモリブロックに電源が供給されている場合はＳ１０１１へ進み、供給されていない場合はＳ１０１０へ進む。Ｓ１０１０では、ＩＤマネージャ２１７は、ＩＰリアセンブルＩＤに対応する主メモリ１０４のＩＰリアセンブルバッファ領域に対する電源供給を主メモリ制御部１０３に指示し、処理をＳ１０１１へ進める。

Ｓ１０１１では、ＩＤマネージャ２１７は、Ｓ１００２で選択した（割当処理により割り当てられた）ＩＤ値を出力し、Ｓ１０１２でＩＰリアセンブルＩＤの使用数を管理するカウンタをインクリメントして、処理を終了する。

なお、本実施形態では、上述の手順で電源の供給指示を行ったが、各ハードウェアリソースに対して電源の供給ができればどのような手順で行ってもよい。例えば、Ｓ１００３〜Ｓ１００４の処理とＳ１００５〜Ｓ１００６の順序は逆にされてもよいし、その他の処理についても順序が変更されてもよい。また、上述の各ブロックのうちの１つ以上について常に電源が供給されている場合は、そのブロックについて電源が供給されているかの判定及び電源供給指示の処理は省略されてもよい。

図９に戻ると、上述のようにして、ＩＰリアセンブルＩＤが、ＩＤマネージャ２１７からサブプロセッサ２０４へ受け渡される（Ｓ９０１）と、サブプロセッサ２０４は、Ｓ９０２において、Ｓ９０１で取得した結果を調べる。そして、ＩＤ値が取得できずエラーが出力されていた場合は、サブプロセッサ２０４は、ＩＰリアセンブルリソース獲得失敗を出力して（Ｓ９０８）、処理を終了する。一方、ＩＤ値が取得できた場合は、処理はＳ９０３へ進む。

Ｓ９０３では、サブプロセッサ２０４は、取得したＩＤ値に対応したビットマップコントローラのビットマップテーブルに、受信したフラグメントパケットの受信位置を示す情報を記録する。そして、Ｓ９０４において、サブプロセッサ２０４は、取得したＩＰリアセンブルＩＤ値に対応した主メモリ１０４のＩＰリアセンブルバッファへ、フラグメントパケットデータを転送する。続いて、Ｓ９０５において、サブプロセッサ２０４は、取得したＩＰリアセンブルＩＤ値に対応した通信タイマ２１６のＩＰリアセンブルタイマを設定し、起動する。そして、サブプロセッサ２０４は、Ｓ９０６において、取得したＩＰリアセンブルＩＤに対応した検索装置２０７のＩＰリアセンブル検索テーブルの検索エントリに、ＩＰリアセンブル検索情報を登録する。その後、サブプロセッサ２０４は、Ｓ９０７においてＩＰリアセンブルリソース獲得成功を出力して、処理を終了する。なお、これらのステップの順序等は変更されてもよい。

（ＩＰリアセンブルＩＤ初期化処理）
続いて、図１１を用いて、主プロセッサ１０１によるＩＰリアセンブルＩＤ初期化処理の流れについて説明する。なお、本実施形態では主プロセッサ１０１がＩＰリアセンブルＩＤ初期化処理を行うが、ＴＯＥ内のサブプロセッサがこの処理を実行してもよい。なお、この処理は、例えば、通信装置の電源が投入された際に実行され、この処理の後に、上述の図９及び図１０の処理が実行される。

主プロセッサ１０１は、Ｓ１１０１において、ＩＰリアセンブルＩＤの最大値をＩＤマネージャ２１７に設定する。この設定値は、システムごとに決定する同時に実行可能なＩＰリアセンブルの処理の最大数である。その後、主プロセッサ１０１は、ＩＰリアセンブルＩＤ値の最大数分のＩＰリアセンブルバッファ領域を主メモリ１０４上に確保する（Ｓ１１０２）。この領域は主メモリ制御部１０３の制御により電源制御が可能な領域に確保する。なお、本実施形態では主メモリ上にＩＰリアセンブルバッファを確保する場合について説明しているが、バッファごとに電源制御可能なメモリ領域であれば、他のメモリ上にＩＰリアセンブルバッファが確保されてもよい。

続いて、主プロセッサ１０１は、Ｓ１１０２で確保したＩＰリアセンブルバッファの位置情報をＩＤマネージャ２１７に設定する（Ｓ１１０３）。この設定情報に基づいて、１つのデータにリアセンブルされるフラグメントの集合の通信の開始または終了時（すなわち、ＩＰリアセンブルＩＤが取得され、開放された際）の、電源制御の指示を行う。主プロセッサ１０１は、その後、ＩＰリアセンブル情報検索用の検索テーブルを検索装置２０７に対して設定する（Ｓ１１０４）。そして、主プロセッサ１０１は、ＩＤマネージャ２１７に対して、ＩＰリアセンブルＩＤに関連づけられたハードウェアリソースの電源制御を開始する旨を示す指示を行い（Ｓ１１０５）、処理を終了する。なお、上述の各ステップは、順序が変更されてもよいし、一部のステップが削除されてもよい。

（ＩＰリアセンブルリソース解放処理）
続いて、サブプロセッサ２０４において実行される、本実施形態に係るＩＰリアセンブルリソース解放処理の流れについて、図１２及び図１３を用いて説明する。

まず、１つのデータにリアセンブルされるフラグメントの集合についての通信が終了した場合、サブプロセッサ２０４は、図１２のＳ１２０１において、検索装置２０７のＩＰリアセンブルＩＤ値に対応した領域のエントリを削除する。そして、サブプロセッサ２０４は、ビットマップコントローラ２１９のＩＰリアセンブルＩＤ値に対応したビットマップテーブルをクリアし（Ｓ１２０２）、ＩＰリアセンブルＩＤ値に対応したＩＰリアセンブルタイマを停止する（Ｓ１２０３）。サブプロセッサ２０４は、さらに、Ｓ１２０４において、ＩＰリアセンブルＩＤ値をＩＤマネージャ２１７に返却して、処理を終了する。

ここで、図１３を用いて、Ｓ１２０４においてＩＰリアセンブルＩＤ値が返却された場合の、ＩＤマネージャ２１７が実行するＩＰリアセンブルＩＤ返却処理について説明する。ＩＤマネージャ２１７は、Ｓ１３０１において、返却されたＩＤ値を、保持しているＩＰリアセンブルＩＤ値に追加する。すなわち、ＩＤマネージャ２１７は、返却されたＩＤ値を、その後に新規に開始されるＩＰリアセンブルに関する通信に対して割り当てるための候補に追加して保持しておく。

そして、ＩＤマネージャ２１７は、返却されたＩＰリアセンブルＩＤ値に対応する各ハードウェアリソースのブロックについて、電源供給の停止を指示する。具体的には、Ｓ１３０２では、ＩＤ値に対応するＩＰリアセンブルタイマの電源停止が通信タイマ２１６に指示され、Ｓ１３０３では、ＩＤ値に対応するＩＰリアセンブル検索テーブルのエントリの電源停止が検索装置２０７に指示される。また、ＩＤ値に対応するビットマップテーブルの電源停止がビットマップコントローラ２１９に指示され（Ｓ１３０４）、ＩＤ値に対応する主メモリ１０４上のＩＰリアセンブルバッファ領域の電源停止が主メモリ制御部１０３に指示される（Ｓ１３０５）。そして、ＩＤマネージャ２１７は、Ｓ１３０６において、ＩＰリアセンブルＩＤの使用数を管理するカウンタをデクリメントして、処理を終了する。なお、上述の各ステップについても、例えば電源停止の指示の順序が変更されてもよいし、一部のステップが削除されてもよい。

このように、本実施形態の通信装置は、ＴＣＰソケット及びＩＰリアセンブル処理をＩＤで管理するＩＤマネージャを有し、それぞれの通信プロトコルの処理に対して、管理されている複数のＩＤのうちの１つのＩＤを割り当て、又は解放する。また、本実施形態の通信装置では、各（ハードウェア）リソースを細かいブロックごとに電源制御可能な構成として、ＩＤマネージャは、これらのブロックごとに１つ以上のＩＤを対応付けて記憶しておく。そして、ＩＤマネージャは、ＩＤの割当と開放とに応じて、１つ以上のリソースについて、そのＩＤに対応するブロックに対して電源供給またはその停止、若しくはクロックの供給またはその停止を行うように、制御を行う。これにより、実際に通信処理を行っているＴＣＰソケットの数、ＩＰリアセンブルの数に応じて、ハードウェアリソースのブロック単位での詳細な電源制御を行うことが可能となる。さらに、このような構成により、同時に実行可能な通信処理の最大数を維持しながら、記憶装置及びハードウェアを、通信状況に応じて部分的に電源遮断することが可能となるため、通信状態に応じて消費電力を削減することが可能となる。またＩＤマネージャが一括で電源の制御を行うため、個別にハードウェアリソースの電源制御を行うことが不要となり、個別に電源制御を行うことにより、処理負荷が高まることを防止することが可能となる。

＜＜その他の実施形態＞＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

Claims (10)

1. 通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有する１つ以上のリソースと、
   通信に関する複数の識別子のそれぞれに対して、前記１つ以上のリソースのそれぞれについての前記複数のブロックのうちのいずれかのブロックを対応させて管理する管理手段と、
   前記通信プロトコルの処理が開始されると、処理の単位ごとに、前記複数の識別子のうちのいずれかの識別子を割り当てる割当手段と、
   前記処理の単位ごとに、処理の開始と終了とに応じて、当該処理の単位に割り当てられた識別子に対応する前記１つ以上のリソースのそれぞれについてのブロックへの、電源の供給とその供給の停止またはクロックの供給とその供給の停止を、一括して制御する制御手段と、
   を有することを特徴とする通信装置。
2. 前記管理手段は、少なくとも１つのリソースについて、１つのブロックに対して前記複数の識別子のうちの１つ以上の識別子を対応させて管理し、
   前記制御手段は、前記１つのブロックについて、当該１つのブロックに対応する１つ以上の識別子のいずれかが割り当てられた前記処理の単位のうちの、少なくとも１つに関する処理が開始した場合に、当該１つのブロックへの電源の供給を行い、当該１つのブロックに対応する１つ以上の識別子のいずれかが割り当てられた前記処理の単位の全てに関する処理が終了した場合に、当該１つのブロックへの電源の供給を停止する、
   ことを特徴とする請求項１に記載の通信装置。
3. 前記１つ以上のリソースは、前記通信プロトコルの処理のための１つ以上のハードウェアを含む、
   ことを特徴とする請求項１又は２に記載の通信装置。
4. 前記１つ以上のリソースは、前記通信プロトコルの処理のためのメモリを含む、
   ことを特徴とする請求項１から３のいずれか１項に記載の通信装置。
5. １つのＴＣＰソケットによる通信を前記処理の単位とする、
   ことを特徴とする請求項１から４のいずれか１項に記載の通信装置。
6. 前記１つ以上のリソースは、ＴＣＰによる通信処理のための情報を管理するハードウェア、ＴＣＰタイマ、ソケットバッファ、及びソケット検索テーブルの少なくともいずれかを含む、
   ことを特徴とする請求項５に記載の通信装置。
7. １つのデータにリアセンブルされるフラグメントの集合の通信を前記処理の単位とする、
   ことを特徴とする請求項１から４のいずれか１項に記載の通信装置。
8. 前記１つ以上のリソースは、受信したフラグメントをビットで管理するビットマップコントローラ、リアセンブルタイマ、リアセンブルバッファ、及びリアセンブル検索テーブルの少なくともいずれかを含む、
   ことを特徴とする請求項７に記載の通信装置。
9. 通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有する１つ以上のリソースと、通信に関する複数の識別子のそれぞれに対して、前記１つ以上のリソースのそれぞれについての前記複数のブロックのうちのいずれかのブロックを対応させて管理する管理手段と、を有する通信装置の制御方法であって、
   割当手段が、前記通信プロトコルの処理が開始されると、処理の単位ごとに、前記複数の識別子のうちのいずれかの識別子を割り当てる割当工程と、
   制御手段が、前記処理の単位ごとに、処理の開始と終了とに応じて、当該処理の単位に割り当てられた識別子に対応する前記１つ以上のリソースのそれぞれについてのブロックへの、電源の供給とその供給の停止またはクロックの供給とその供給の停止を、一括して制御する制御工程と、
   を有することを特徴とする制御方法。
10. 通信プロトコルの処理のために用いられ、個別に電源供給とその停止とを制御可能な複数のブロックをそれぞれが有する１つ以上のリソースと、通信に関する複数の識別子のそれぞれに対して、前記１つ以上のリソースのそれぞれについての前記複数のブロックのうちのいずれかのブロックを対応させて管理する管理手段と、を有する通信装置に備えられたコンピュータに、
    前記通信プロトコルの処理が開始されると、処理の単位ごとに、前記複数の識別子のうちのいずれかの識別子を割り当てる割当工程と、
    前記処理の単位ごとに、処理の開始と終了とに応じて、当該処理の単位に割り当てられた識別子に対応する前記１つ以上のリソースのそれぞれについてのブロックへの、電源の供給とその供給の停止またはクロックの供給とその供給の停止を、一括して制御する制御工程と、
    を実行させるためのプログラム。

Images