(57)【特許請求の範囲】
【請求項１】
ネットワークを介して取得したパケットを一時的に保持するバッファと、
前記パケットの前記バッファへの格納を制御する書き込み制御部と、を備え、
前記書き込み制御部は、
前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納し、
前記破棄した送信先アドレス情報に代えて、そのパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を前記受信バッファに格納することを特徴とする、パケット処理装置。
【請求項２】
前記管理情報は、パケットの種別を示すパケット種別情報、および次のパケットの格納位置を示すアドレス情報をさらに含むことを特徴とする、請求項１に記載のパケット処理装置。
【請求項３】
前記書き込み制御部は、前記管理情報を１ワードにおさめ、後続のデータをワード単位で整形して前記バッファに格納することを特徴とする、請求項１または２に記載のパケット処理装置。
【請求項４】
音声を入力する入力部と、
前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、
他の装置から受信した音声を出力する出力部と、を備え、
前記通信部は、
ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットを処理するパケット処理部と、を含み、
前記パケット処理部は、
前記パケットを一時的に保持するバッファと、
前記パケットの前記バッファへの格納を制御する書き込み制御部と、を含み、
前記書き込み制御部は、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納し、
前記破棄した送信先アドレス情報に代えて、そのパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を前記受信バッファに格納することを特徴とする電話装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は通信技術に関し、とくにパケットを効率的に処理する技術に関する。
【０００２】
【従来の技術】
インターネットが広く普及し、ネットワークのインフラの整備も進みつつある現在、通話音声信号を符号化したデータをパケット化し、インターネットなどのネットワークを介して送受信するインターネット電話装置が注目を集めている。通話音声と同時にビデオ映像を送ることにより、ビデオ電話装置として利用することも可能であり、従来の電話装置に取って代わる次世代の電話装置として期待されている。
【０００３】
現在、パケット通信のための通信プロトコルとして、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ  ／  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）が広く利用されている。ＴＣＰは、装置間で接続を確立してからデータを送受信するなど、正確性を重視した通信プロトコルである。しかしながら、処理が複雑で、相手側がパケットを受信したことを確認するまで次のパケットを送ることができないなどの時間的制約があり、リアルタイム性に欠けるため、通話音声の送受信には不向きである。
【０００４】
ＴＣＰよりも簡便な通信プロトコルに、ＵＤＰ／ＩＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ  ／  Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）がある。ＵＤＰでは、データの送受信に先立って装置間で接続を確立する必要がなく、パケットの受信確認を待たずに次のパケットを送ることが許されるので、送信側は次々にパケットを送出することができる。そのため、データの正確性よりもリアルタイム性が重視される、通話音声の送受信に適している。
【０００５】
ＴＣＰとＵＤＰの双方の通信プロトコルをサポートする装置では、パケット処理は、ＣＰＵなどの汎用プロセッサによりソフトウェア処理されるのが一般的である。すなわち、ネットワークインタフェースデバイスがパケットを受信すると、自装置以外のＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレス宛てのパケットがフィルタリングされ、ＣＲＣ（Ｃｙｃｌｉｃ  Ｒｅｄｕｎｄａｎｃｙ  Ｃｈｅｃｋ）による誤りチェックが行われた後、それらを通過した全てのパケットがＣＰＵに送られて処理される。
【０００６】
【非特許文献１】
エスティー（ＳＴ）マイクロエレクトロニクス株式会社、ボイスオーバーアイピー（ＶｏＩＰ）デジタルプロセッサデータシート、［ｏｎｌｉｎｅ］、平成１４年、［平成１４年９月３０日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｓｔ．ｃｏｍ／ｓｔｏｎｌｉｎｅ／ｂｏｏｋｓ／ｐｄｆ／ｄｏｃｓ／７８１８．ｐｄｆ＞
【０００７】
【発明が解決しようとする課題】
しかしながら、全てのパケットをＣＰＵによりソフトウェア処理する方式では、処理効率が悪い、速度が遅い、消費電力が大きい、などの課題がある。とくに、複数の相手と同時に通話したり、音声とともに画像を送ったりする場合には、プロトコル処理が律速となり、リアルタイム性が損なわれる恐れがある。また、通話中は常にＣＰＵがプロトコル処理を実行しているため、その他のアプリケーションを並行して実行させるのが困難である。たとえば、パーソナルコンピュータなどのように高性能のＣＰＵを搭載した装置により通信を行う場合は、ＣＰＵに全てのパケット処理を担わせても、それに見合う十分な能力を有しているので問題はないが、インターネット電話のための専用装置を開発する場合、装置の小型化、低価格化、低消費電力化を実現するためには、比較的性能の低いＣＰＵを搭載せざるを得ないので、いかにＣＰＵの処理負荷を軽減するかが課題となる。
【０００８】
本発明は、そうした課題に鑑みてなされたものであり、その目的は、データ通信に伴うパケット処理を効率よく行う技術を提供することにある。本発明の別の目的は、パケット処理におけるＣＰＵの処理負荷を軽減し、高速でリアルタイムな通信を実現する技術を提供することにある。
【０００９】
【課題を解決するための手段】
本発明のある態様は、パケット処理装置に関する。このパケット処理装置は、ネットワークを介して取得したパケットを一時的に保持するバッファと、前記パケットの前記バッファへの格納を制御する書き込み制御部と、を備え、前記書き込み制御部は、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納する。
【００１０】
パケットのＭＡＣヘッダに格納されている送信先ＭＡＣアドレスは、パケットを受信すると以降のパケット処理には不要であるので、これを破棄することにより、バッファの使用効率を向上させることができる。
【００１１】
前記書き込み制御部は、前記送信先アドレス情報に代えて、そのパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を格納してもよい。前記管理情報は、パケットの種別を示すパケット種別情報、および次のパケットの格納位置を示すアドレス情報をさらに含んでもよい。前記書き込み制御部は、前記管理情報を１ワードにおさめ、後続のデータをワード単位で整形して前記バッファに格納してもよい。
【００１２】
ＭＡＣヘッダは、３２ビットワードで３．５ワードであり、半端なサイズであるから、そのままバッファに格納すると、後続のデータが全て半ワードずつずれることになる。そのため、１．５ワード分の送信先ＭＡＣアドレスを破棄してバッファに格納することにより、後続のデータをワード単位でアライメントすることができる。このとき、パケット処理に必要な管理情報を１ワード分追加してもよい。これにより、ハードウェア的にもソフトウェア的にも扱いが容易になる。
【００１７】
本発明のさらに別の態様は、電話装置に関する。この電話装置は、音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、他の装置から受信した音声を出力する出力部と、を備え、前記通信部は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットを処理するパケット処理部と、を含み、前記パケット処理部は、前記パケットを一時的に保持するバッファと、前記パケットの前記バッファへの格納を制御する書き込み制御部と、を含み、前記書き込み制御部は、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納する。更に前記書き込み制御部は、前記破棄した送信先アドレス情報に代えて、そのパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を前記受信バッファに格納する。
【００２０】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、などの間で変換したものもまた、本発明の態様として有効である。
【００２１】
【発明の実施の形態】
図１は、本発明の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。インターネット電話装置１００は、インターネット２０を介して、他のインターネット電話装置１００との間で通話を行うための装置である。インターネット電話装置１００は、主に、ソフトウェア処理を実行するための汎用回路であるＣＰＵ１１０、プログラムエリアまたはワークエリアとして利用されるメモリ１２０、インターネット２０を介してパケットを送受信するネットワークインタフェース部１３０、音声信号を入力するマイク１５０、音声信号を出力するスピーカ１６０、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部１４０、通信データの暗号化処理または復号処理などを行うセキュリティ処理部１７２、ＵＤＰパケットを処理するための専用回路であるＵＤＰ処理部１７４、通信プロトコルに応じた各種処理を行うプロトコルエンジン２００、およびこれらの構成を電気的に接続するバス１０２を備える。
【００２２】
本実施の形態のインターネット電話装置１００は、受信したパケットの処理をＣＰＵ１１０のみに任せるのではなく、ＣＰＵ１１０へパケットを転送する前に、専用のハードウェアにより構成されたプロトコルエンジン２００が、ヘッダ解析、エラーチェック、データのアライメントなどの処理を行うので、ＣＰＵ１１０が無駄なパケット処理を行う必要がなく、処理負荷が大幅に軽減される。
【００２３】
本実施の形態のインターネット電話装置１００では、ＵＤＰを利用して音声信号を送受信する。ＵＤＰは、接続の確立を要さず、パケットを次々に送出することが可能な通信方式であるため、プロトコル処理が簡単で、かつ高速な通信が可能であり、通話音声を送るなどのリアルタイムな通信に適している。本実施の形態のインターネット電話装置１００では、ＵＤＰパケットの処理を、専用の回路であるＵＤＰ処理部１７４に実行させることで、さらに処理速度を向上させ、通話音声のリアルタイムな送受信を実現する。
【００２４】
インターネット電話装置１００が送受信するパケットのうち、ＴＣＰにより送受信されるパケットは、ＣＰＵ１１０を利用してソフトウェアにより処理される。リアルタイム性を要しないＴＣＰパケットについては、専用の回路を設けず、汎用回路によるソフトウェア処理を行うことで、回路規模の増大を抑え、コスト、消費電力、熱発生の増大を最小限に抑えることができる。本発明者の試算によれば、ＴＣＰとＵＤＰの双方を専用回路により処理する場合に比べて、回路の面積および消費電力が約１／３で済むことが分かっている。このように、本実施の形態では、専用のハードウェアと汎用のソフトウェアとにより協調処理することで、処理の高速化と回路規模の削減という二律背反的な要望に応える。
【００２５】
ネットワークインタフェース部１３０が受信したパケットは、プロトコルエンジン２００に送られる。プロトコルエンジン２００は、パケットが自装置に割り当てられたＩＰアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみを通し、その他のパケットを破棄する。また、パケットに付されたヘッダ情報を参照してプロトコルの種別を検出し、パケットがＴＣＰにより送られたパケットであった場合は、そのパケットのデータをバス１０２上に送り、ＣＰＵ１１０によりソフトウェア処理させる。パケットがＵＤＰのパケットであった場合は、そのパケットのデータをＵＤＰ処理部１７４に送り、ＵＤＰパケットの処理のために専用に設けられた回路により処理させる。
【００２６】
ＵＤＰ処理部１７４は、ＵＤＰパケットを処理するための専用回路であり、ＵＤＰパケットを受け取って、そのヘッダを解析し、必要な処理を実行する。セキュリティ処理部１７２は、データに対して暗号化処理などのセキュリティ対策が施されていた場合に、暗号を復号するなどの処理を行う。復号されたデータは、コーデック処理部１４０に送られる。コーデック処理部１４０は、圧縮符号化されていた通話音声信号を復号し、スピーカ１６０に出力する。
【００２７】
このように、本実施の形態のインターネット電話装置１００では、正確性よりもリアルタイム性が重視され、通話中、常時処理が必要となる通話音声データは、ＵＤＰにより送受信を行い、専用回路であるＵＤＰ処理部１７４によりハードウェア処理を行う一方、リアルタイム性よりも正確性が重視されるデータは、ＴＣＰにより送受信を行い、ＣＰＵ１１０によりソフトウェア処理を行う。これにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えつつ、通話音声データを高速に処理することが可能となる。このような利点は、複数の相手と同時に通話したり、通話音声とともに画像を送信するなど、大量のデータを同時に処理することが必要な場合に、より顕著となる。また、プロトコルエンジン２００によりパケットの種別を検出し、パケットの処理主体を高速かつ適切に選択することができる。さらに、ＣＰＵ１１０の処理負担を軽減し、低コスト化、低消費電力化が実現できるほか、ＣＰＵ１１０に余力ができるため、通話中に他のアプリケーションを実行することが可能となり、新たなサービスを提供することもできる。
【００２８】
以上、パケットを受信したときの動作について説明したが、つづいて、マイク１５０から入力された音声信号をパケット化して送信するときの動作について説明する。マイク１５０から入力された音声信号は、コーデック処理部１４０に送られ、符号化される。符号化された信号は、必要であれば、セキュリティ処理部１７２により暗号化されたあと、ＵＤＰ処理部１７４に送られ、ＵＤＰヘッダが付され、パケット化される。このＵＤＰパケットは、プロトコルエンジン２００によりチェックサム値などのヘッダ情報が付され、ネットワークインタフェース部１３０を介して、インターネット２０に送出される。
【００２９】
図２は、プロトコルエンジン２００の内部構成を示す。ＡＲＰ制御部２０２は、ネットワークインタフェース部１３０が自装置のＩＰアドレスに宛てたＡＲＰ（Ａｄｄｒｅｓｓ  Ｒｅｓｏｌｕｔｉｏｎ  Ｐｒｏｔｏｃｏｌ）パケットを受信したときに、自動的に自装置のデータリンク層のアドレス（ＭＡＣアドレス）情報をセットして応答パケットを生成し、ＡＲＰパケットの送信元へ送信する。従来は、ＡＲＰパケットもＣＰＵ１１０によりソフトウェア処理していたが、本実施の形態では、ＡＲＰ制御部２０２がＣＰＵ１１０を介さずに自動応答することにより、ＣＰＵ１１０の負担を大幅に軽減するとともに、割り込みによるタスクスイッチを減少させることができる。
【００３０】
ヘッダ解析部２１０は、パケットのヘッダ情報を解析して、不要なパケットを破棄し、必要なパケットのみを通す処理を行う。たとえば、自装置のＩＰアドレスに宛てたパケットのみを通し、その他のＩＰアドレス宛てのパケットは破棄する。ＩＰパケットのみを送受信する装置に本実施の形態のプロトコルエンジン２００を搭載する場合、ＩＰ以外の通信方式のパケットを破棄してもよい。また、特定のパケットを検出して、そのパケットを処理する専用回路へ送ってもよい。本実施の形態では、ＵＤＰパケットを専用回路であるＵＤＰ処理部１７４により処理するので、ヘッダ解析部２１０は、ヘッダ情報を解析することによりＵＤＰパケットを検出すると、そのＵＤＰパケットをＣＰＵ１１０を介さずに直接ＵＤＰ処理部１７４に転送する。このとき、ヘッダ情報を破棄してデータ部分のみを送ってもよい。これにより、ソフトウェア処理が必要なパケットのみをＣＰＵ１１０に処理させることができるので、ＣＰＵ１１０の処理負担を軽減することができる。また、適宜専用のハードウェアによりパケットを処理することにより、処理の高速化を図ることができる。
【００３１】
チェックサム算出部２１２は、パケットのチェックサムを算出し、ヘッダに格納されたチェックサム値と一致するか否かを検証する。一致した場合は、そのパケットを通し、一致しなかった場合は、そのパケットを破棄する。従来は、ＣＰＵ１１０がチェックサムの検証を行っていたが、本実施の形態のように、ＣＰＵ１１０に送る前の段階で専用回路にてチェックサムの検証を行うことで、ＣＰＵ１１０に無用なパケットを処理させることを防ぎ、ＣＰＵ１１０の処理負担を軽減することができる。
【００３２】
書き込み制御部２２０は、ヘッダ解析部２１０を通過したパケットを受信バッファ２３０に格納する。チェックサム算出部２１２によりエラーが検出されたパケットは受信バッファ２３０に格納せずに破棄するが、チェックサム算出部２１２がチェックサムを算出している間、受信バッファ２３０への書き込みを待機しているよりも、並行して受信バッファ２３０へ書き込んでいくほうが効率がよい。そのため、書き込み制御部２２０は、ヘッダ解析部２１０を通過したパケットを、チェックサム算出部２１２による検証の結果を待たずに受信バッファ２３０に書き込んでいき、チェックサム算出部２１２による検証でエラーが検出された場合は、書き込んだパケットを消去し、ライトポインタを元に戻す。読み出し制御部２４０は、受信バッファ２３０に格納された受信パケットの読み出しを制御する。書き込み制御部２２０、受信バッファ２３０、および読み出し制御部２４０の構成および動作の詳細については、図４において詳述する。
【００３３】
チェックサム生成部２８０は、送信パケットのチェックサムを算出する。ＵＤＰパケットは、送信キューに投入する時点でパケットサイズが確定しているので、チェックサム生成部２８０により予めデータ部のチェックサムを算出して保持しておき、パケット送出時にヘッダ合成部２５０によりヘッダにチェックサム値をセットする。ＴＣＰパケットは、パケット送出時にパケットサイズが確定するので、予めデータ部のチェックサム値を算出しておくことはできないが、所定の区間ごとにチェックサム累積値を算出して保持しておくことで、パケット送出時のチェックサム算出処理を簡略化することができる。ＴＣＰパケットのパケットサイズを、チェックサム累積値の算出区間の整数倍に限定すれば、データ部のチェックサム値はデータ部の区間前後のチェックサム累積値を減算するだけで得られる。
【００３４】
第１送信バッファ２７０は、送信パケットのうち、送信先のＭＡＣアドレスが未解決のものを格納する。第２送信バッファ２７２は、送信パケットのうち、送信先のＭＡＣアドレスが分かっているものを格納する。ＡＲＰインタフェース２６０は、第１送信バッファ２７０に格納された、送信先のＭＡＣアドレスが不明なパケットについて、そのＭＡＣアドレスを解決すべく、ＡＲＰパケットを生成してネットワークにブロードキャストする。ＡＲＰパケットの応答が戻ってくるまでの間はそのパケットを送出できないので、アドレス解決が不要なパケットのキューとは別に第１送信バッファ２７０を設けて待機させておき、その間は第２送信バッファ２７２にて待機中のアドレス解決が不要な送信パケットを送出する。ＡＲＰの応答が戻ってくると、解決されたＭＡＣアドレスをセットして第１送信バッファ２７０のパケットを送出し、次に待機中のパケットについてＡＲＰパケットを送出する。そして、応答が戻るまでの間は再び第２送信バッファ２７２のパケットを送出する。これにより、全体の送信待ち時間を減少させ、効率良くパケットを送出することができる。また、送信先のＭＡＣアドレスが未解決のパケットであっても、第１送信バッファ２７０に投入しておけば自動的にＭＡＣアドレスを解決しつつパケットを送出してくれるので、ＣＰＵ１１０側の処理が単純になり、処理負荷を軽減することができる。
【００３５】
ヘッダ合成部２５０は、第１送信バッファ２７０または第２送信バッファ２７２に保持された送信待機中の送信パケットを、ネットワークインタフェース部１３０を介して送出すべく、そのパケットのヘッダ情報を生成する。ヘッダ合成部２５０は、頻繁に変更されないパラメータや容易に推測可能なパラメータを自動的に生成してヘッダ情報を生成する。たとえば、ＩＰヘッダの識別子は、ＣＰＵ１１０が指定しなくともヘッダ合成部２５０が自動的にインクリメントしてヘッダにセットする。ＣＰＵ１１０は、データ以外には、送信先とパケットサイズのみを指定すればよい。これにより、ＣＰＵ１１０のバッファ管理を単純化し、処理負荷を軽減することができる。
【００３６】
ホストテーブル２０４は、他装置のＭＡＣアドレスおよびＩＰアドレスを対応付けて保持する。図３は、ホストテーブル２０４の内部データの例を示す。ホストテーブル２０４には、ホストＩＤ欄２０５、ＭＡＣアドレス欄２０６、およびＩＰアドレス欄２０７が設けられている。ホストテーブル２０４の内容は、ＣＰＵ１１０が予め頻繁に通信を行う可能性のあるホスト装置の情報を登録してもよいし、通信中にＣＰＵ１１０などが登録してもよい。ＭＡＣアドレスが不明なホスト装置であっても、まずＩＰアドレスのみを格納しておき、ＡＲＰインタフェース２６０によりＡＲＰパケットを送出し、その応答を取得したときにＭＡＣアドレスを登録してもよい。ホストテーブル２０４を設けてあるので、ＣＰＵ１１０は、パケットの送信先を指定するときに、ホストＩＤ、ＭＡＣアドレス、ＩＰアドレスのいずれを用いて指定してもよい。ヘッダ合成部２５０は、ホストテーブル２０４を参照して、ヘッダ生成に必要な情報を取得することができる。
【００３７】
ホストインタフェース部２９０は、プロトコルエンジン２００の構成要素とＣＰＵ１１０との間でデータや指示の入出力を制御する。
【００３８】
図４は、書き込み制御部２２０および読み出し制御部２４０の内部構成を示す。書き込み制御部２２０は、管理情報生成部２２２、データ入れ替え部２２４、書き込みアドレス生成部２２６、遅延回路２２８、およびセレクタ２２９を備える。ヘッダ解析部２１０によるパケットフィルタリングを通過したパケットは、管理情報生成部２２２およびデータ入れ替え部２２４により整形されて受信バッファ２３０に格納される。パケットのデータが整形される様子は、図５を参照しつつ後述することにする。書き込みアドレス生成部２２６は、受信バッファ２３０のライトポインタを管理する。前述したように、チェックサム算出部２１２によるチェックサムの検証に並行して受信バッファ２３０にパケットのデータを格納していくが、チェックサムエラーが検出されたときは、書き込みアドレス生成部２２６は、ライトポインタを元の位置に戻す。チェックサムエラーが検出されず、受信バッファ２３０への格納が正常に終了すると、書き込みアドレス生成部２２６は、管理情報生成部２２２に次のパケットのアドレスを通知する。読み出し制御部２４０は、読み出しアドレス生成部２４２およびセレクタ２４４を備える。
【００３９】
図５は、書き込み制御部２２０によりパケットのデータが整形される様子を示す。通常のＩＰパケットは、先頭のＭＡＣヘッダが１４バイトを占めているが、３２ビットワードでは３．５ワードと半端になるため、以降のデータが１６ビットずつずれた形となる。このまま受信バッファ２３０に格納すると、アクセスするときに不便であるから、本実施の形態では、ＭＡＣヘッダが３ワードとなるようにデータを整形してから受信バッファ２３０に格納する。すなわち、ＭＡＣヘッダを１６ビット分減らせばよい。ＭＡＣヘッダのうち、宛先ＭＡＣアドレスは、自装置のＭＡＣアドレスと同じであり、既にパケットを受信しているので不要である。ＭＡＣアドレスは４８ビットであるから、これを破棄すると、３２ビット分余裕が残る。アプリケーションによっては、このパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたのかという情報が必要な場合があるので、これをフラグとして宛先ＭＡＣアドレスの代わりに格納する。このフラグは２ビットで十分であるから、まだ３０ビット分余裕がある。そこで、パケット種別を示すフラグや、次のパケットの格納位置を示すアドレス情報などを管理情報として格納する。以上により、ＭＡＣヘッダが３ワードにおさまるので、以降のデータをワード単位で整列させることができ、アクセスが容易になる。
【００４０】
図４に戻り、受信したパケットを書き込む手順と読み出す手順について説明する。管理情報生成部２２２は、上述した管理情報を生成する。管理情報として、たとえば、このパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたのかを示す送信種別情報、このパケットがＴＣＰパケットかＵＤＰパケットか、フラグメント化されたＩＰパケットまたはオプション付きのＩＰパケットなど複雑な処理を要する特殊なＩＰパケットであるか否か、などを示すパケット種別情報、次のパケットの格納位置を示すアドレス情報、などを生成してもよい。次パケットのアドレス情報を格納する場合は、自パケットのデータの格納が終了してから、書き込みアドレス生成部２２６から次パケットのアドレス情報を取得するので、管理情報の受信バッファ２３０への書き込みはパケットのデータの格納が完了した後になる。これらの管理情報は、全体で１ワードとなるように整形され、セレクタ２２９を介して受信バッファ２３０に格納される。
【００４１】
データ入れ替え部２２４は、受信したパケットのデータのうち、ＭＡＣアドレスを除いたデータを３２ビットワードで整列させるために、上位１６ビットと下位１６ビットを入れ替える。データ入れ替え部２２４の出力のうち、上位１６ビットを遅延回路２２８により１クロック遅延させて合成することにより、１６ビットずつずれていたデータを整列させることができる。整形されたデータは、セレクタ２２９を介して受信バッファ２３０に格納される。
【００４２】
書き込みアドレス生成部２２６は、まず、書き込み位置の先頭にポインタを移動するが、１ワード目の管理情報は最後に格納されるので、ポインタをインクリメントし、ＭＡＣヘッダのうち宛先ＭＡＣアドレスを除いた２ワード、ＩＰヘッダ５ワード、ＩＰデータを、ポインタをインクリメントしつつ次々に書き込んでいく。データ部分の書き込みが終了すると、次の書き込み開始位置を管理情報生成部２２２に通知し、書き込み位置の先頭にポインタを戻して、管理情報を書き込む。
【００４３】
管理情報を含むヘッダ情報は、それぞれ独立したレジスタを割り当て、ＣＰＵ１１０がランダムに何度でもアクセスできるようにする。受信バッファ２３０に格納されたパケットは、既にヘッダ解析部２１０およびチェックサム算出部２１２により有効性が検証されたものであるから、ＣＰＵ１１０が直接ヘッダ情報にアクセスしてデータを渡すべきアプリケーションを判断できるようにする。他方、データ部分は、１つのアクセスポートレジスタから読み出すようにする。すなわち、アクセスポートレジスタへの最初の読み出しでは、データ部分の最初のデータが読み出され、以降、同じレジスタを連続してアクセスすることにより、データが次々に読み出される。データの転送先が決定されれば、あとはデータをコピーするだけであるから、ランダムアクセスを可能とする必要はない。したがって、アクセスポート方式を採用することにより、ポインタ管理が必要なメモリマップ方式よりも簡便で処理負担を軽減することができる。また、ＣＰＵ１１０を持たないハードウェアと組み合わせて利用することもできる。
【００４４】
受信バッファの読み出しアドレスは上位アドレスと下位アドレスから構成される。ＣＰＵ１１０は、受信バッファ２３０に格納されたパケットのヘッダ情報にアクセスするときは、上位アドレスと下位アドレスの双方を指定する。上位アドレスについては、どのパケットのどのヘッダにアクセスしたいかを読み出しアドレス生成部２４２に指定すれば、読み出しアドレス生成部２４２が自動的に上位アドレスを生成してポインタを移動する。下位アドレスについては、ＣＰＵ１１０が出力する下位アドレスをそのまま受信バッファの下位アドレスとし、ＣＰＵ１１０が自由に読み出せるようにする。ＣＰＵ１１０は、パケットのデータ部分にアクセスするときは、読み出しアドレス生成部２４２に、どのパケットのデータにアクセスしたいかを指定すればよい。読み出しアドレス生成部２４２は、自動的に上位アドレスと下位アドレスを生成してポインタを移動し、データを次々に読み出す。
【００４５】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、そうした例を述べる。
【００４６】
実施の形態では、電話装置を例にとって説明したが、本発明の技術は、コンピュータや携帯電話など、ストリームデータを送受信する通信装置全般に利用可能である。
【００４７】
プロトコルエンジン２００の機能を有する回路を、一つの半導体基板上に搭載してもよい。さらに、セキュリティ処理部１７２、コーデック処理部１４０、ＣＰＵ１１０などの回路を搭載してもよい。これにより、通信装置の小型化、軽量化、高速化を図ることができる。
【００４８】
【発明の効果】
本発明によれば、データ通信に伴うパケット処理を効率よく行う技術を提供することができる。また、本発明によれば、パケット処理におけるＣＰＵの処理負荷を軽減し、高速でリアルタイムな通信を実現する技術を提供することができる。
【図面の簡単な説明】
【図１】実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。
【図２】実施の形態に係るプロトコルエンジンの内部構成を示す図である。
【図３】実施の形態に係るホストテーブルの内部データを示す図である。
【図４】実施の形態に係る書き込み制御部および読み出し制御部の内部構成を示す図である。
【図５】書き込み制御部によりパケットのデータが整形される様子を示す図である。
【符号の説明】
１００  インターネット電話装置、  １３０  ネットワークインタフェース部、  １４０  コーデック処理部、  １５０  マイク、  １６０  スピーカ、  １７４  ＵＤＰ処理部、  ２００  プロトコルエンジン、  ２０２  ＡＲＰ制御部、  ２０４  ホストテーブル、  ２１０  ヘッダ解析部、  ２１２  チェックサム算出部、  ２２０  書き込み制御部、  ２２２  管理情報生成部、  ２２４  データ入れ替え部、  ２２６  書き込みアドレス生成部、  ２３０  受信バッファ、  ２４０  読み出し制御部、  ２４２  読み出しアドレス生成部、  ２５０ヘッダ合成部、  ２６０  ＡＲＰインタフェース、  ２７０  第１送信バッファ、  ２７２  第２送信バッファ、  ２８０  チェックサム生成部。
【図１】
0003557201.tif 000002
【図２】
0003557201.tif 000003
【図３】
0003557201.tif 000004
【図４】
0003557201.tif 000005
【図５】
0003557201.tif 000006