JP2015220675A - 通信装置およびその制御方法 - Google Patents

Abstract

【課題】１つのプロセッサを利用して複数のプロトコルに対応するには、プロセッサが有するキャッシュサイズなどのＨ／Ｗリソースの観点で利用可能なプロセッサに制約が生じる。【解決手段】通信装置は、他の通信装置から、パケットを受信する受信手段と、受信したパケットが第１のアドレス長である場合に該パケットに対して第１のプロトコル処理を行う第１のプロセッサと、受信したパケットが第２のアドレス長である場合に該パケットに対して第２のプロトコル処理を行う第２のプロセッサと、受信したパケットのアドレス長に基づいて該パケットを第１のプロセッサもしくは第２のプロセッサに転送する転送手段と、を有する。【選択図】図１

Description

本発明は、複数のプロトコルを処理する通信技術に関するものである。

インターネット、イントラネットといった各種ネットワークにおいて、インターネットプロトコル（ＩＰ）が利用されている。現在、一般的に使用されているＩＰはＲＦＣ７９１で規定されたＩＰｖ４であるが、近年、ＲＦＣ２４６０で規定されたＩＰｖ６も使用されてきている（特許文献１）。ＩＰｖ６は、ＩＰｖ４の実績を通じて得た豊富な経験を基に開発されたプロトコルであり、ＩＰｖ４での問題点解決や拡張性や柔軟性の向上を図っている。

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

しかしながら、１つのプロセッサを利用して複数のプロトコルに対応するには、プロセッサが有するキャッシュサイズなどのＨ／Ｗリソースの観点で利用可能なプロセッサに制約が生じる。

本発明は上述の問題点に鑑みなされたものであり、通信装置において、複数のプロセッサを用いて複数のプロトコルに対応することを目的とする。

上述の問題点を解決するため、本発明に係る通信装置は以下の構成を備える。すなわち、他の通信装置から、第１のアドレス長、もしくは、第２のアドレス長のパケットを受信する受信手段と、前記受信手段が受信したパケットが前記第１のアドレス長である場合に、当該パケットに対して第１のプロトコル処理を行う第１のプロセッサと、前記受信手段が受信したパケットが前記第２のアドレス長である場合に、当該パケットに対して第２のプロトコル処理を行う第２のプロセッサと、前記受信手段が受信したパケットのアドレス長に基づいて、当該パケットを前記第１のプロセッサもしくは前記第２のプロセッサに転送する転送手段と、を有する。

本発明によれば、通信装置において、複数のプロセッサを用いて複数のプロトコルに対応することができる。

第１実施形態に係る通信装置のブロック図。 通信装置の電力モードの遷移を説明する図。 通信制御部およびプロトコル処理部におけるデータの流れを説明する図。 通信制御部およびプロトコル処理部におけるデータの流れを説明する図。 通信制御部およびプロトコル処理部におけるデータの流れを説明する図。 省電力モードへ移行する際のフローチャート。 パケットを受信する際のフローチャート。 起床する際のフローチャート。 通信装置のブロック図。 通信制御部およびプロトコル処理部におけるデータの流れを説明する図。 省電力モードへ移行する際のフローチャート。 パケットを受信する際のフローチャート。

以下に、図面を参照して、この発明の好適な実施の形態を詳しく説明する。なお、以下の実施の形態はあくまで例示であり、本発明の範囲を限定する趣旨のものではない。

（第１実施形態）
本発明に係る通信装置の第１実施形態として、ＩＰｖ４及びＩＰｖ６の両方を処理可能な通信装置を例に挙げて以下に説明する。

＜装置構成＞
図１は、第１実施形態に係る通信装置２００の構成の一例を示すブロック図である。通信装置２００は、システム部２１０、ネットワーク通信部２２０と電源制御部２３０から構成され、ネットワーク２４０を介して図示していない対向装置との通信を行う。

システム部２１０のシステムバス２１１には、入力部２１２、出力部２１３、ＣＰＵ２１４、記憶部２１５、アプリケーション機能部２１８、省電力モード移行制御部２１９、が接続される。入力部２１２は、ユーザからの各種入力を受け付ける機能部である。例えば、入力部２１２は、アプリケーションの操作や通信部に関する設定を受け付けることが出来る。出力部２１３は、ＬＣＤやＬＥＤによる表示、スピーカなどによる音声出力によって各種情報を出力する機能部である。

ＣＰＵ２１４は、ＲＡＭをワークメモリとしてＲＯＭなどに格納されたプログラムを実行し、システム部２１０の構成を実現したり制御したりする。記憶部２１５は、ＣＰＵ２１４が実行するプログラムなど各種情報を記憶するＲＯＭやワークメモリとして使用されるＲＡＭなどである。また、記憶部２１５は、ＩＰｖ４パケットの受信数やＩＰｖ６パケットの受信数といったＭＩＢ（Management Information Base）などの通信状況情報２１６を記憶する。更に、記憶部２１５は、ネットワーク通信部２２０が使用するＩＰｖ４アドレス、ＩＰｖ６アドレスなどの通信設定情報２１７を記憶する。なお、ＩＰｖ４アドレスのアドレス長は３２ビットであり、ＩＰｖ６アドレスのアドレス長は１２８ビットである。

通信状況情報２１６は、ネットワーク通信部２２０の動作によって逐次更新される。また、通信設定情報２１７は、ユーザが入力部２１０を介して、またはＤＨＣＰ（Dynamic Host Configuration Protocol）などのネットワーク通信部２２０の動作によって変更される。

アプリケーション機能部２１８は、ＣＰＵ２１４の処理によって実現される各種アプリケーションであり、ユーザへ各種機能を提供する。また必要に応じて、ソケットのオープン、バインド、クローズなどのリソース操作、ネットワーク通信部２２０を介して対向通信装置と通信を行う。

省電力モード移行制御部２１９は、予め記憶部２１５に記憶された省電力モードへの移行条件に通信装置２００が該当するかを判定する。そして、省電力モード移行制御部２１９は、移行条件を満たす場合、通信状況または／および通信設定に基づいて、後述する複数の受信パケット取得部２２７それぞれの稼働または非稼働を決定する。更に、省電力移行制御部２１９は、上述の移行条件を満たした場合に、通常電力モードで動作していたプロトコル処理部２２５の構成（図３で後述）を、省電力モードで動作するプロトコル処理部２２５の構成（図４で後述）に切り替える。

電源制御部２３０は、システム部２１０及びネットワーク通信部２２０の電力供給を制御する電源制御部である。電源制御部２３０は、システム部２１０内の各機能部に対して、電源投入の制御、ハードウェアリセット制御、さらにシステム部２１０全体が安全に起動・停止するためのシーケンス制御を行う。なお、電源制御部２３０は、省電力モード移行制御部２１９からの指示に伴い、システム部２１０への電力供給を停止する。例えば、省電力モード移行制御部２１９がプロトコル処理部２２５の構成を省電力モードの構成にした後、システム部２１０への電力供給を停止する。

ネットワーク通信部２２０のローカルバス２２１には、バスブリッジ２２２、ローカル記憶部２２３、通信制御部２２４、プロトコル制御部２２５、が接続される。バスブリッジ２２２は、システム部２１０とネットワーク通信部２２０との間でデータ転送を可能とする。即ち、システム部２１０とネットワーク通信部２２０とは、バスブリッジ２２２を介して相互に接続されており、通信データの入出力に従ってバス間転送が行われるよう構成されている。

ローカル記憶部２２３は、プロトコル処理部２２５のワークメモリとして使用されるＲＡＭである。通信制御部２２４は、ネットワーク２４０に接続してフレームの送受信を行う。例えばネットワーク２４０がイーサネット（登録商標）の場合、通信制御部２２４は、イーサネットのＭＡＣ処理や、伝送フレーム（通信フレーム）の送受信を行う。具体的には、受信時には、通信フレームからＩＰパケットを抽出し、送信時には、ＩＰパケットを通信フレームに格納する。なお、ネットワーク２４０は、例えばイーサネットのような有線ネットワークが想定できるが、無線ネットワークであってもよい。また図示されていない外部装置である対向装置とは、ネットワーク２４０を介して通信を行うものとする。

プロトコル処理部２２５は、通信プロトコル処理用向けのプロセッサである。より具体的には、プロトコル処理部２２５は、ＩＰｖ４、ＩＰｖ６、ＵＤＰ、ＴＣＰ等の通信プロトコル処理や、ＴＣＰの送信フロー制御や輻輳制御、通信エラー制御等を行う。また、第１実施形態においてはプロトコル処理部２２５は複数個（ここでは４個）存在しており、各々で各種プロトコル処理を分担して通信機能を実現する。プロトコル処理部２２５は、電源制御部２３０と制御信号線で接続されており、電源制御部２３０の動作制御を可能に構成されている。

プロトコル部２２６は、プロトコル処理を実施するプロトコル処理部２２５内の機能ブロックであり、各プロトコル処理部２２５によって処理内容が異なる（詳細は図３、図４で後述）。受信パケット取得部２２７は、通信制御部２２４から受信パケットを取得するプロトコル処理部２２５内の機能ブロックである。なお、受信パケット取得部２２７は必ずしも全てのプロトコル処理部２２５に配置する必要はない。

通信装置２００の主要な機能は、システム部２１０で実現される。アプリケーション機能部２１８はユーザに各種アプリケーション機能を提供し、必要に応じて通信を行うことが可能である。アプリケーション機能部２１８による通信は、ＴＣＰ／ＩＰプロトコルをベースとした通信である。前述のように、このＴＣＰ／ＩＰプロトコルの処理は、ネットワーク通信部２２０において実行される。

＜電力モードの遷移＞
通信装置２００は、主要機能が動作していないアイドル状態において、通常（通常電力モード）より省電力の待機状態（省電力モード）に移行可能に構成されている。すなわち、通常電力モードと省電力モードとを時分割で切り替えて動作する。

図２は、通信装置２００の電力モードの遷移を説明する図である。通信装置２００の主要機能が動作中である間は通常電力モードを維持する（遷移３２１）。通常電力モード３１０では、システム部２１０を含む通信装置２００全体に電力が供給される。

通常電力モード３１０において主要機能が実行していないアイドル状態になると、省電力モード３１１へ移行することが可能となる（遷移３２２）。省電力モード３１１においては、ネットワーク通信部２２０と電源制御部２３０にのみ電力が供給される。システム部２１０は電源がオフの状態であるため、システムバス２１１、ＣＰＵ２１４、記憶部２１５は停止しており、ユーザに各種アプリケーション機能を提供することはできない。

通信装置２００の省電力機能が動作中である間は省電力モードを維持する（遷移３２３）。ここで省電力機能とは、対向装置からＡＲＰやＩＣＭＰ（Ｐｉｎｇなど）による問合せを受信し、応答を送信するようなネットワーク通信部２２０で処理できる機能である。省電力モード３１１から通常電力モード３１０への移行は、例えば、通信装置２００がネットワークを介して対向装置からシステムの起動要求を受信した場合である（遷移３２４）。

＜装置の動作＞
以下では、４つのプロセッサ（プロトコル処理部Ａ〜Ｄ）を利用して通信機能を実現する例を説明するが、２以上の任意の個数のプロセッサであればよい。

図３は、通常電力モードで動作している際の通信制御部２２４とプロトコル処理部２２５におけるデータの流れを説明する図である。ここでプロトコル処理部２２５は、プロトコル処理部Ａ４１０、プロトコル処理部Ｂ４２０、プロトコル処理部Ｃ４３０、プロトコル処理部Ｄ４４０によって構成され、各種プロトコル処理を分担して通信機能を実現する。

プロトコル処理部Ａ４１０は、受信パケット取得部２２７、プロトコル部Ａ４１１から構成される。受信パケット取得部２２７は通信制御部２２４から受信パケットを取得する（矢印４５０）。プロトコル部Ａ４１１は受信パケット取得部２２７が取得した受信パケットに対して（矢印４５１）、ＩＰｖ４やＩＰｖ６の受信プロトコル処理を実施する。

プロトコル処理部Ｃ４３０は、プロトコル部Ｃ４３１から構成される。プロトコル部Ｃ４３１は、プロトコル部Ａ４１１がＩＰヘッダの除去などＩＰ受信処理を行った後の受信パケットに対して（矢印４５２）、ＴＣＰ受信処理を実施する。

プロトコル処理部Ｄ４４０は、プロトコル部Ｄ４４１から構成される。プロトコル部Ｄ４４１は、送信対象データに対してＴＣＰヘッダの付与や再送処理などＴＣＰ送信プロトコル処理を実施する。

プロトコル処理部Ｂ４２０はプロトコル部Ｂ４２１から構成される。プロトコル部Ｂ４２１は、例えばプロトコル部Ｄ４１１でＴＣＰ送信プロトコル処理を行った後の送信パケットに対して（矢印４５３）、ＩＰヘッダを付与するなどのＩＰｖ４やＩＰｖ６の送信プロトコル処理を実施する。そして、送信プロトコル処理が終わったパケットを通信制御部２２４に対して転送する（矢印４５４）ことで、パケット送信を実現する。

なお、プロトコルによって処理を行うプロトコル処理部が異なっていても良い。例えば、ＵＤＰ送信などの場合は、プロトコル処理部Ｄ４４０で処理を行わず、送信データをプロトコル処理部Ｂ４２０でのみ送信プロトコル処理を実施するように構成しても良い。同様に、ＵＤＰ受信などの場合は、プロトコル処理部Ａ４１０でのみ受信プロトコル処理を実施し、プロトコル処理部Ｃ４３０では処理を行わないように構成しても良い。

以上のように、通常電力モード３１０における通信制御部２２４とプロトコル処理部２２５は、主要機能を動作させるのに十分なプロトコルに関する機能や性能を実現するために、各プロトコル処理部でプロトコル処理を分担する。

図４は、省電力モードで動作している際の通信制御部２２４とプロトコル処理部２２５におけるデータの流れを説明する図である。ここでプロトコル処理部２２５は、通常電力モードの時と同様に、プロトコル処理部Ａ５１０、プロトコル処理部Ｂ５２０、プロトコル処理部Ｃ５３０、プロトコル処理部Ｄ５４０によって構成される。

プロトコル処理部Ａ５１０は受信パケット取得部５１２、プロトコル部Ａ５１１から構成される。受信パケット取得部５１２は、通信制御部２２４から受信パケットを取得する（矢印５５０）。なお、受信パケット取得部は、１つしかない場合は動作を行う「有効」に設定されるが、複数存在する場合は、後述するアルゴリズム（図６）によって、各々、「有効」または動作を行わない「無効」に設定される。

受信パケット取得部５１２が取得した受信パケットがＩＰｖ４パケットだった場合、プロトコル部Ａ５１１は、そのパケットに対し（矢印５５１）、ＩＰｖ４プロトコル処理を実施する。具体的には、ＩＣＭＰｖ４のＥｃｈｏ＿Ｒｅｑｕｅｓｔメッセージの受信処理、Ｅｃｈｏ＿Ｒｅｐｌｙメッセージの送信処理などを行う。一方、受信パケット取得部５１２が取得した受信パケットがＩＰｖ６パケットだった場合、プロトコル処理部Ｂ５２０へ処理要求が行われる。なお、図示していないが送信処理を行う時、プロトコル部Ａ５１１は通信制御部２２４に対してパケットを転送する。また、プロトコル部Ａ５１１は対向装置から起動要求パケットを認識し、通常電力モードへの遷移をトリガする。そのために必要であれば、機能を限定したＴＣＰプロトコル処理など必要なプロトコル処理を行えるようにプロトコル部Ａ５１１を構成しても良い。

プロトコル処理部Ｂ５２０は、プロトコル部Ｂ５２１、受信パケット取得部５２２から構成される。受信パケット取得部５２２は後述するアルゴリズム（図６）によって無効化された受信パケット取得部であり、動作を行わない。

上述のように、受信パケット取得部５１２が取得した受信パケットがＩＰｖ６パケットだった場合、プロトコル処理部Ｂ５２０へ処理要求が行われる。処理要求を受けたプロトコル処理部Ｂ５２０のプロトコル部Ｂ５２１は、受信パケット取得部５１２が受信したパケットに対し（矢印５５２）、ＩＰｖ６プロトコル処理を実施する。具体的には、ＩＣＭＰｖ６のＥｃｈｏ＿Ｒｅｑｕｅｓｔメッセージの受信処理、Ｅｃｈｏ＿Ｒｅｐｌｙメッセージの送信処理などを行う。なお、図示していないが送信処理を行う時、プロトコル部Ｂ５２１は、通信制御部２２４に対してパケットを転送する。また、ＩＰｖ４プロトコル部Ａ５１１と同様に、対向装置から起動要求パケットを認識し、通常電力モードへの遷移をトリガする。そのために必要であれば、機能を限定したＴＣＰプロトコル処理など必要なプロトコル処理を行えるようにプロトコル部Ｂ５２１を構成しても良い。

プロトコル処理部Ｃ５３０、プロトコル処理部Ｄ５４０に関しては、特に特定のプロトコル処理を割当てずに、動作を行わないストール状態にしておくことで、電力消費を抑える。

また、プロトコル処理部Ａ５１０は、受信パケットがない場合はストール状態に遷移し、通信制御部２２４が受信パケットを受信した際に、プロトコル処理部Ａ５１０のストール状態を解除するように構成しても良い。同様に、プロトコル処理部Ｂ５２０は、プロトコル処理部Ａ５１０からの処理要求がない場合はストール状態に遷移し、受信パケット取得部５１２が取得した受信パケットがＩＰｖ６パケットだった場合、プロトコル処理部Ｂ５２０のストール状態を解除するように構成しても良い。

なお、図４では、プロトコル部Ａ５１１が搭載されたプロトコル処理部Ａ５１０の受信パケット取得部が有効であり、プロトコル部Ｂ５２１が搭載されたプロトコル処理部Ｂ５２０の受信パケット取得部が無効であった。ただし、受信パケット取得部が複数存在する場合は、後述するアルゴリズム（図６）によって、受信パケット取得部の有効、無効が決定される。

図５は、省電力モードで動作している際の通信制御部２２４とプロトコル処理部２２５におけるデータの流れを説明する他の図である。具体的には、プロトコル処理部Ａ５１０の受信パケット取得部が無効であり、プロトコル部Ｂ５２１が搭載されたプロトコル処理部Ｂ５２０の受信パケット取得部が有効となる場合を説明する図である。なお、同一の動作を行うものに関しては図４と同じ参照番号を付与し、説明を省略する。

プロトコル処理部Ｂ５２０の受信パケット取得部５２２は、通信制御部２２４から受信パケットを取得する（矢印６３０）。プロトコル部Ｂ５２１は、受信パケット取得部５２２が取得した受信パケットがＩＰｖ６パケットだった場合にそのパケットに対し（矢印６３１）、ＩＰｖ６プロトコル処理を実施する。受信パケット取得部５２２が取得した受信パケットがＩＰｖ４パケットだった場合、プロトコル処理部Ａ５１０へ処理要求が行われる。

処理要求を受けたプロトコル処理部Ａ５１０のプロトコル部Ａ５１１は、受信パケット取得部５２２が受信したパケットに対し（矢印６３２）、ＩＰｖ４プロトコル処理を実施する。なお、プロトコル処理部Ｂ５２０は、受信パケットがない場合はストール状態に遷移し、通信制御部２２４が受信パケットを受信した際に、プロトコル処理部Ｂ５２０のストール状態を解除するように構成しても良い。同様に、プロトコル処理部Ａ５１０は、プロトコル処理部Ｂ５２０からの処理要求がない場合はストール状態に遷移し、受信パケット取得部５２２が取得した受信パケットがＩＰｖ４パケットだった場合、プロトコル処理部Ａ５１０のストール状態を解除するように構成しても良い。なお受信パケット取得部が１つしかない場合の動作は、受信パケット取得部５１２が存在しない場合と同じである。

以上のように、省電力モード３１１におけるプロトコル処理部２２５は、省電力機能を動作させるのに必要なプロトコル処理部以外はストール状態にすることで電力消費を削減する。また、プロトコル処理部Ａ５１０、プロトコル処理部Ｂ５２０にプロトコルの種別単位でプロトコル処理を割当てる。

当該構成により、図４の構成においては、ＩＰｖ６パケットを受信しない限りはプロトコル処理部Ｂ５２０をストール状態にしておくことが可能となり、消費電力を削減することができる。同様に、図５の構成においては、ＩＰｖ４パケットを受信しない限りはプロトコル処理部Ａ５１０をストール状態にしておくことが可能となり、消費電力を削減することができる。

さらに、通信装置２００がＩＰｖ４とＩＰｖ６のどちらを多く受信するか判断し、複数の受信パケット取得部の何れを有効にするかを制御することで、より消費電力を削減することができる。すなわち、受信するパケットが多いプロトコルを処理するプロトコル部を有するプロトコル処理部内の受信パケット取得部を有効にすることで、他のプロトコル処理部をストール状態にする機会を増やすことが可能である。

図６は、通信装置２００が通常電力モード３１０から省電力モード３１１へ移行する際のフローチャートである。当該処理は、通常電力モード３１０から省電力モード３１１への移行を判断する毎に実施される。

ステップＳ７０１では、省電力モード移行制御部２１９は、記憶部２１５に予め記憶された省電力モードへの移行条件に通信装置２００が該当するかを判定する。省電力モードへの移行条件は、例えば、通常電力モード３１０の通信装置２００が主要機能を実行していないアイドル状態であることである。省電力モードへ移行すべきことを検知した場合（Ｓ７０１でＹｅｓ）、Ｓ７０２に進む。一方、省電力モードへ移行すべきことを検知しなかった場合（Ｓ７０１でＮｏ）、処理を終了する。

ステップＳ７０２では、省電力モード移行制御部２１９は、通信状況情報２１６や通信設定情報２１７を参照する。そして、ステップＳ７０３では、ＩＰｖ４またはＩＰｖ６のいずれかをメインとするプロトコルに決定する。

ここでは、通信状況情報２１６は、ＭＩＢに格納された受信パケットの統計情報である。例えば、通信装置２００のＩＰｖ４パケット受信数とＩＰｖ６パケット受信数とを比較し、受信数が多い方をメインのプロトコルとして決定する。

通信設定情報２１７は、端末に設定しているＩＰアドレス等のインタフェース識別アドレスのことである。例えば、通信装置２００にＩＰｖ４アドレスは設定しているが、ＩＰｖ６アドレスを設定していない場合、ＩＰｖ４アドレスをメインのプロトコルとして決定する。

ステップＳ７０４では、省電力モード移行制御部２１９は、プロトコル処理部２２５に複数の受信パケット取得部２２７が存在する場合、各受信パケット取得部２２７の有効／無効を設定する。有効として設定するのは、Ｓ７０３においてメインとしたプロトコルを処理するプロトコル部を含むプロトコル処理部の受信パケット取得部である。他の受信パケット取得部は無効として設定を行う。なお、もともと受信パケット取得部２２７が１つしかない存在しない場合、Ｓ７０４は実施しなくて良い。

ステップＳ７０５では、電源制御部２３０は、プロトコル処理部２２５の構成を省電力モードの構成にした後、省電力モード移行制御部２１９からの指示に伴い、システム部２１０全体を停止する。このようにして、通信装置２００は、通常電力モードから省電力モード省電力モードへ移行することになる。

図７は、省電力モード３１１の通信装置２００がパケットを受信する際のフローチャートである。図７は、省電力構成が図４または図５のどちらの場合でも対応している。以下の説明では図４の構成を前提として説明を行うが、図５の構成を前提としたケースについても同様である。当該処理は、プロトコル処理部Ａ５１０において、受信パケット取得部５１２が、受信パケットが存在するか確認を行う毎に実施される。

ステップＳ８０１では、受信パケット取得部５１２は、ポーリング、割込みなどにより、通信制御部２２４に受信パケットがあるかチェックを行う。なお、所定の期間／所定の回数の間、通信処理が行われていない場合、つまり処理すべきパケットが所定時間存在しなかった場合、プロトコル処理部Ａ５１０及びプロトコル処理部Ｂ５２０についても動作を行わないストール状態に遷移させても良い。

ここでプロトコル処理部Ａ５１０をストール状態へ遷移可能とする場合、パケット受信などをトリガに通信制御部２２４がプロトコル処理部Ａ５１０を起床させた後、Ｓ８０１が実施される。つまり、Ｓ８０１に先行して起床処理が実行される。

受信パケットが存在しない場合（Ｓ８０１でＮｏ）、処理を終了する。受信パケットが存在する場合（Ｓ８０１でＹｅｓ）、ステップＳ８０２において、受信パケット取得部５１２は、受信パケットがＩＰｖ４かＩＰｖ６かを解析する。受信パケットがＩＰｖ４かＩＰｖ６かの判定は、例えば、ＤＩＸやＩＥＥＥ８０２．３といったＭＡＣヘッダの「タイプ」フィールド（ヘッダ情報）を参照することで行われる。

受信パケットがＩＰｖ４だった場合（Ｓ８０２でＩＰｖ４）、ステップＳ８０３において、プロトコル部Ａ５１１は、受信パケットに対してＩＰｖ４や機能を限定したＴＣＰプロトコル処理など必要なプロトコル処理を実施する。一方、受信パケットがＩＰｖ６だった場合（Ｓ８０２でＩＰｖ６）、ステップＳ８０４において、受信パケット取得部５１２は、プロトコル処理部Ｂ５２０に対して、プロトコル処理要求を発行する。そして、ステップＳ８０５において、受信パケット取得部５１２は、プロトコル処理部Ｂ５２０がストール状態になっており動作していない可能性があるため、プロトコル処理部Ｂ５２０に対して起床要求を発行する。すなわち、ＩＰｖ４かＩＰｖ６かの判定結果に応じて、受信パケットの転送先を制御する。

なお、Ｓ８０４とＳ８０５の処理順序は、プロトコル処理部Ｂ５２０がプロトコル処理要求を処理できれば良く、逆の順序でもよい。

図８は、省電力モード３１１の通信装置２００が、プロトコル処理部Ｂ５２０において起床要求を受信する時のフローチャートである。なお、図８は、省電力構成が図４または図５のどちらの場合でも対応している。以下の説明では図４の構成を前提として説明を行うが、図５の構成を前提としたケースについても同様である。ここでは、プロトコル処理部Ａ５１０の受信パケット取得部５１２がＩＰｖ６パケットを受信した場合について説明する。すなわち、図８の処理は、省電力モード移行時、またはプロトコル処理部Ｂ５２０が、プロトコル処理部Ａ５１０からストール状態からの起床要求をされる（Ｓ８０５）時に実施される。

ステップＳ９０１では、プロトコル処理部Ｂ５２０は、受信パケット取得部５１２から受信した起床要求により、起床を行い各種処理が行える状態に移行する。なお、省電力モード移行する場合など既にプロトコル処理部Ｂ５２０が起床している場合は、Ｓ９０１は実施しなくとも良い。

ステップＳ９０２では、プロトコル部Ｂ５２１は、受信パケット取得部５１２からのプロトコル処理要求があるか確認を行う。処理要求を伝える方式は、特定のものに限定していない。例えば、共有メモリ上でメッセージ交換を行う共有メモリ通信方式やメッセージパッシング通信方式を用いて実現を行う。

プロトコル処理要求がある場合（Ｓ９０２でＹｅｓ）、ステップＳ９０３において、プロトコル部Ｂ５２１は、受信パケットに対してＩＰｖ６や機能を限定したＴＣＰプロトコル処理など必要なプロトコル処理を実施する。一方、プロトコル処理要求がない場合（Ｓ９０２でＮｏ）、ステップＳ９０４において、プロトコル部Ｂ５２１は、特定期間の間受信パケット取得部５１２からのプロトコル処理要求がない、または特定回数受信パケット取得部５１２からのプロトコル処理要求がないかを確認する。

特定期間または特定回数に渡り受信パケット取得部５１２からのプロトコル処理要求がない場合（Ｓ９０４でＹｅｓ）、ステップＳ９０５において、プロトコル処理部Ｂ５２０は、ストール状態に移行する。

以上説明したとおり第１実施形態によれば、省電力モードで動作している際に、複数の受信パケット取得部の１つのみを有効にし、他の受信パケット取得部は無効にする。特に、使用頻度が高いプロトコルを処理するプロトコル部を有するプロトコル処理部に含まれる受信パケット取得部を有効にする。このように構成することにより、使用頻度が低いプロトコルを処理するプロトコル部を有するプロトコル処理部をストール状態にしておくことが可能となる。

これにより、複数のプロセッサ／キャッシュにより複数のプロトコルへの対応を実現している場合、性能要求が低い期間に利用される省電力モードにおい利用されるプロセッサ／キャッシュの数を減らすことができる。従って、電力消費を抑えることができる。

また、省電力モードにおいても、複数のプロセッサ／キャッシュを利用することで、１つのプロセッサ／キャッシュを利用して複数のプロトコルに対応する場合と比較して、１つあたりのキャッシュサイズを減らすことができる。

（第２実施形態）
第２実施形態では、通信制御部２２４内に受信パケットの種別を判断する受信パケット種別判断部１００１を配置する形態について説明する。

＜装置構成＞
図９は、第２実施形態に係る通信装置１０００の構成の一例を示すブロック図である。第１実施形態の通信装置２００（図１）に対して、通信制御部２２４に受信パケット種別判断部１００１を追加する。また、プロトコル処理部２２５の受信パケット取得部１００２の機能が多少異なる。なお、図９においては、図１と同一構成である部分に関しては同一の参照番号を付してその説明を省略する。

受信パケット種別判断部１００１は、通信制御部２２４がネットワーク２２４から受信したパケットを解析して、どのプロトコル処理部２２５が受信パケットのプロトコル処理をすべきかを判断する。具体的には、受信したパケットが、ＩＰｖ４パケットであるかＩＰｖ６パケットであるかを判断する。受信パケットがＩＰｖ４かＩＰｖ６かの判断は、例えば、ＤＩＸやＩＥＥＥ８０２．３といったＭＡＣヘッダの「タイプ」フィールドを参照することで行われる。そして、それぞれの受信パケットを処理可能なプロトコル部を有するプロトコル処理部に受信パケットを送信する。

受信パケット取得部１００２は、通信制御部２２４から受信パケットを取得する。なお、第２実施形態ではＩＰｖ４やＩＰｖ６を用いた例を記載するが、特定のプロトコルに限定するわけではない。

図１０は、省電力モードで動作している際の通信制御部２２４とプロトコル処理部２２５におけるデータの流れを説明する図である。ここでプロトコル処理部２２５は、図５および図６と同様に、プロトコル処理部Ａ５１０、プロトコル処理部Ｂ５２０、プロトコル処理部Ｃ５３０、プロトコル処理部Ｄ５４０によって構成される。なお、図１０においては、図４または図５と同一構成の部分に関しては同一の参照番号を付してその説明を省略する。

プロトコル処理部Ａ５１０の受信パケット取得部１００２ａは、通信制御部２２４から受信パケットを取得する（矢印５５０）。なお、受信パケット取得部１００２ａが受信パケットを取得するのは、通信制御部２２４の受信パケット種別判断部１００１がプロトコル処理部Ａ５１０で処理すべきと判断した場合である。受信パケット取得部１００２ａは、ＩＰｖ４受信パケットをプロトコル部Ａへ渡す（矢印５５１）。

同様に、プロトコル処理部Ｂ５２０の受信パケット取得部１００２ｂは、通信制御部２２４から受信パケットを取得する（矢印６３０）。なお、受信パケット取得部１００２ｂが受信パケットを取得するのは、通信制御部２２４の受信パケット種別判断部１００１がプロトコル処理部Ｂ５２０で処理すべきと判断した場合である。受信パケット取得部１００２ｂは、ＩＰｖ６受信パケットをプロトコル部Ｂへ渡す（矢印６３１）。

＜装置の動作＞
図１１は、通信装置１０００が通常電力モード３１０から省電力モード３１１へ移行する際のフローチャートである。当該処理は、通常電力モード３１０から省電力モード３１１への移行を判断する毎に実施される。なお、図１１の処理は、図６のＳ７０１、Ｓ７０５と同様の処理であるため説明を省略する。

図１２は、省電力モード３１１の通信装置１０００がパケットを受信する際のフローチャートである。図１０のプロトコル処理部Ａ５１０における受信処理、プロトコル処理部Ｂ５２０における受信処理は同様であるため、ここではプロトコル処理部Ａ５１０における受信処理を前提として説明を行い、プロトコル処理部Ｂ５２０における受信処理を前提としたケースについては記載を省略する。当該処理は、受信パケット取得部１００２が、受信パケットが存在するか確認を行う毎に実施される。図１２においては、図８と同様の処理であるＳ９０４、Ｓ９０５に関しては同一の参照番号を付してその説明を省略する。

ステップＳ１３０１では、プロトコル処理部Ａ５１０の受信パケット取得部１００２ａは、ポーリング、割込みなどにより、受信パケット種別判断部１００１を参照して、プロトコル処理部Ａ５１０が処理すべき受信パケットが存在するかを確認する。

なお、プロトコル処理部Ａ５１０やプロトコル処理部Ｂ５２０は、所定の期間／所定の回数処理がない場合、動作を行わないストール状態に遷移する。そのため、受信パケット種別判断部１００１は、受信パケットの判断が終わると、処理すべきプロトコル処理部のストール状態を解除し、動作可能な状態へ遷移させる。処理対象の受信パケットが存在する場合（Ｓ１３０１でＹｅｓ）、Ｓ１３０２に進む。

ステップＳ１３０２では、受信パケット取得部１００２ａは、通信制御部２２４から受信パケットを取得する。そして、プロトコル部Ａ５１１は、受信パケットに対してＩＰｖ４や機能を限定したＴＣＰプロトコル処理など必要なプロトコル処理を実施する。

以上説明したとおり第２実施形態によれば、省電力モードで動作している際に、通信制御部の受信パケット種別判断部が受信パケットを解析する。そして、受信パケットのプロトコル種別に応じて対応するプロトコル処理部を判断する。つまり、処理を行うべきプロトコル処理部のみストール状態から解除して受信処理を行う。これにより、プロトコル処理部がストール状態に遷移できる機会が更に増え、電力消費をさらに低減させることが可能となる。

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

２１０ システム部；２１９ 省電力モード移行制御部；２２０ ネットワーク通信部；２２５ プロトコル処理部；２２６ プロトコル部；２２７ 受信パケット取得部；２３０ 電源制御部

Claims (14)

1. 通信装置であって、
   他の通信装置から、第１のアドレス長、もしくは、第２のアドレス長のパケットを受信する受信手段と、
   前記受信手段が受信したパケットが前記第１のアドレス長である場合に、該パケットに対して第１のプロトコル処理を行う第１のプロセッサと、
   前記受信手段が受信したパケットが前記第２のアドレス長である場合に、該パケットに対して第２のプロトコル処理を行う第２のプロセッサと、
   前記受信手段が受信したパケットのアドレス長が前記第１のアドレス長である場合には該パケットを前記第１のプロセッサに転送し、該パケットのアドレス長が前記第２のアドレス長である場合には該パケットを前記第２のプロセッサに転送する転送手段と、
   を有することを特徴とする通信装置。
2. 前記通信装置は、第１の電力モードと該第１の電力モードよりも前記通信装置の消費電力が低い第２の電力モード とで動作可能であり、
   前記転送手段は、前記通信装置が前記第２の電力モードで動作している場合に、前記受信手段が受信したパケットのアドレス長に基づいて、該パケットを前記第１のプロセッサもしくは前記第２のプロセッサに転送することを特徴とする請求項１に記載の通信装置。
3. 前記第１のプロセッサは、前記受信手段が受信したパケットを取得する第１の取得手段を有し、
   前記第２のプロセッサは、前記受信手段が受信したパケットを取得する第２の取得手段を有し、
   前記通信装置は、前記通信装置が前記第２の電力モードで動作している場合、前記第１の取得手段、もしくは、前記第２の取得手段のいずれか一方が無効となるように制御する制御手段を更に有することを特徴とする請求項２に記載の通信装置。
4. 前記受信手段が受信するパケットのうち、前記第１のアドレス長のパケットの方が前記第２のアドレス長のパケットよりも多い場合に、前記制御手段は、前記第２の取得手段が無効として動作するように制御することを特徴とする請求項３に記載の通信装置。
5. 前記制御手段は、前記通信装置に設定されているアドレス長に基づいて、前記第１の取得手段、もしくは、前記第２の取得手段のいずれか一方が無効として動作するように制御することを特徴とする請求項３に記載の通信装置。
6. 前記通信装置が前記第２の電力モードで動作している場合であって、前記転送手段が前記パケットを前記第１のプロセッサに転送する場合、前記転送手段は該パケットを前記第２のプロセッサを介すことなく、前記第１のプロセッサに転送することを特徴とする請求項３から５のいずれか１項に記載の通信装置。
7. 前記受信手段が受信したパケットのアドレス長が前記第２のアドレス長である場合、前記第１のプロセッサが前記転送手段を制御して、該パケットを前記第１のプロセッサから前記第２のプロセッサに転送することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
8. 前記受信手段が受信したパケットを前記転送手段が前記第１のプロセッサに転送する際に、前記第１のプロセッサがストール状態である場合、該転送に先行して前記第１のプロセッサのストール状態を解除するための起床要求を送信する送信手段を更に有することを特徴とする請求項１から５のいずれか１項に記載の通信装置。
9. 前記第１のプロセッサが前記送信手段を制御して前記起床要求を送信させることを特徴とする請求項８に記載の通信装置。
10. 前記第１のプロセッサは、所定時間、前記受信手段が受信したパケットに対して前記第１のプロトコル処理を行わなかった場合に、ストール状態に移行することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
11. 前記第１のプロトコル処理は、ＩＰｖ４パケットの処理であり、
    前記第２のプロトコル処理は、ＩＰｖ６パケットの処理であることを特徴とする請求項１から７のいずれか１項に記載の通信装置。
12. 前記受信手段が受信したパケットに含まれるヘッダ情報に基づいて、該パケットのアドレス長が前記第１のアドレス長であるか前記第２のアドレス長であるかを判定する判定手段を更に有し、
    前記転送手段は、前記判定手段の判定結果に基づいて、前記パケットを転送することを特徴とする請求項１から１１のいずれか１項に記載の通信装置。
13. 受信したパケットが第１のアドレス長である場合に、該パケットに対して第１のプロトコル処理を行う第１のプロセッサと、受信したパケットが第２のアドレス長である場合に、該パケットに対して第２のプロトコル処理を行う第２のプロセッサと、を有する通信装置の制御方法であって、
    他の通信装置から、前記第１のアドレス長、もしくは、前記第２のアドレス長のパケットを受信する受信工程と、
    前記受信工程において受信されたパケットのアドレス長に基づいて、該パケットを前記第１のプロセッサもしくは前記第２のプロセッサに転送する転送工程と、
    を有することを特徴とする制御方法。
14. コンピュータを、請求項１から１２のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。

Images