JP4514487B2

JP4514487B2 - パケット処理装置

Info

Publication number: JP4514487B2
Application number: JP2004088462A
Authority: JP
Inventors: 英雄廣野; 一晃岡本
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2004-03-25
Filing date: 2004-03-25
Publication date: 2010-07-28
Anticipated expiration: 2023-01-10
Also published as: JP2004252995A

Description

本発明は通信技術に関し、とくにパケットを効率的に処理する技術に関する。

インターネットが広く普及し、ネットワークのインフラの整備も進みつつある現在、通話音声信号を符号化したデータをパケット化し、インターネットなどのネットワークを介して送受信するインターネット電話装置が注目を集めている。通話音声と同時にビデオ映像を送ることにより、ビデオ電話装置として利用することも可能であり、従来の電話装置に取って代わる次世代の電話装置として期待されている。

現在、パケット通信のための通信プロトコルとして、ＴＣＰ／ＩＰ（Transmission Control Protocol / Internet Protocol）が広く利用されている。ＴＣＰは、装置間で接続を確立してからデータを送受信するなど、正確性を重視した通信プロトコルである。しかしながら、処理が複雑で、相手側がパケットを受信したことを確認するまで次のパケットを送ることができないなどの時間的制約があり、リアルタイム性に欠けるため、通話音声の送受信には不向きである。

ＴＣＰよりも簡便な通信プロトコルに、ＵＤＰ／ＩＰ（User Datagram Protocol / Internet Protocol）がある。ＵＤＰでは、データの送受信に先立って装置間で接続を確立する必要がなく、パケットの受信確認を待たずに次のパケットを送ることが許されるので、送信側は次々にパケットを送出することができる。そのため、データの正確性よりもリアルタイム性が重視される、通話音声の送受信に適している。

ＴＣＰとＵＤＰの双方の通信プロトコルをサポートする装置では、パケット処理は、ＣＰＵなどの汎用プロセッサによりソフトウェア処理されるのが一般的である。すなわち、ネットワークインタフェースデバイスがパケットを受信すると、自装置以外のＭＡＣ（Media Access Control）アドレス宛てのパケットがフィルタリングされ、ＣＲＣ（Cyclic Redundancy Check）による誤りチェックが行われた後、それらを通過した全てのパケットがＣＰＵに送られて処理される。
エスティー（ST）マイクロエレクトロニクス株式会社、ボイスオーバーアイピー（VoIP）デジタルプロセッサデータシート、［online］、平成１４年、［平成１４年９月３０日検索］、インターネット＜URL：http://www.st.com/stonline/books/pdf/docs/7818.pdf＞

しかしながら、全てのパケットをＣＰＵによりソフトウェア処理する方式では、処理効率が悪い、速度が遅い、消費電力が大きい、などの課題がある。とくに、複数の相手と同時に通話したり、音声とともに画像を送ったりする場合には、プロトコル処理が律速となり、リアルタイム性が損なわれる恐れがある。また、通話中は常にＣＰＵがプロトコル処理を実行しているため、その他のアプリケーションを並行して実行させるのが困難である。たとえば、パーソナルコンピュータなどのように高性能のＣＰＵを搭載した装置により通信を行う場合は、ＣＰＵに全てのパケット処理を担わせても、それに見合う十分な能力を有しているので問題はないが、インターネット電話のための専用装置を開発する場合、装置の小型化、低価格化、低消費電力化を実現するためには、比較的性能の低いＣＰＵを搭載せざるを得ないので、いかにＣＰＵの処理負荷を軽減するかが課題となる。

本発明は、そうした課題に鑑みてなされたものであり、その目的は、データ通信に伴うパケット処理を効率よく行う技術を提供することにある。本発明の別の目的は、パケット処理におけるＣＰＵの処理負荷を軽減し、高速でリアルタイムな通信を実現する技術を提供することにある。

本発明のある態様は、パケット処理装置に関する。このパケット処理装置は、リアルタイム性が重視されるパケット処理を行うハードウエア処理と、リアルタイム性が重視されないパケット処理を行うソフトウエア処理と、前記パケット処理の際のリアルタイム性の重要度によりハードウエア処理とソフトウエア処理とにパケットを振り分けて処理するプロトコル制御部と、を備えるパケット処理装置において、前記プロトコル制御部は、ネットワークを介して取得したパケットを一時的に保持するバッファと、前記パケットの前記バッファからの読み出しを制御する読み出し制御部と、を備え、前記読み出し制御部は、前記バッファに直接アクセスして、前記バッファに保持されたパケットのヘッダ部分を読み出すヘッダ読み出し手段と、単一のアクセスポートレジスタへのアクセスを介して前記バッファに保持されたパケットのデータ部分を読み出すデータ読み出し手段を備えており、前記データ読み出し手段は、読み出すパケットの種別に応じて、前記アクセスポートレジスタが読み出しを開始する前記バッファの読み出し開始位置を設定することを特徴とする。

ヘッダ情報は、ＣＰＵがパケットの転送先を決定するために読み出す必要があるので、独立したレジスタを割り当てて容易にアクセスすることができるようにする。データ部分は、転送先さえ決まれば、転送先にコピーすればよいだけであるから、アクセスポートレジスタにより、ポインタを管理することなくアクセスできるようにする。

前記読み出し制御部は、読み出すパケットの種別に応じて、前記アクセスポートレジスタが読み出しを開始する位置を設定してもよい。たとえば、ＭＡＣパケットではＭＡＣデータの先頭位置に、ＩＰパケットではＩＰデータの先頭位置に、読み出し開始位置を自動的に設定する。これにより、さらにＣＰＵの処理負荷を軽減することができる。

前記パケットを前記バッファに格納する前に、そのヘッダ情報を解析することにより不要なパケットを破棄するヘッダ解析部と、前記パケットを前記バッファに格納する前に、そのチェックサムを算出して、ヘッダに格納されたチェックサム値と一致するか否かを検証するチェックサム算出部と、前記チェックサム算出部が前記パケットのチェックサムの算出中、前記バッファに前記パケットを書き込み、チェックサムエラーが検出されたとき、ライトポインタを書き込み前の値に戻す書き込み処理部と、をさらに備えてもよい。これにより、ＣＰＵは、バッファに保持されたパケットが有効なパケットであることを前提に処理を行うことができる。

本発明の別の態様は、電話装置に関する。この電話装置は、リアルタイム性が重視されるパケット処理を行うハードウエア処理部と、リアルタイム性が重視されないパケット処理を行うソフトウエア処理部と、前記パケット処理の際のリアルタイム性の重視度によりハードウエア処理とソフトウエア処理とにパケット処理を振り分けて処理するプロトコル処理部と、音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、他の装置から受信した音声を出力する出力部と、を備える電話装置において、前記通信部は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットを処理するパケット処理部と、を含み、前記パケット処理部は、前記パケットを一時的に保持するバッファと、前記パケットの前記バッファからの読み出しを制御する読み出し制御部と、を含み、前記読み出し制御部は、前記パケットのヘッダ部分をランダムにアクセスするヘッダ読み出し手段と、単一のアクセスポートレジスタをアクセスすることにより前記パケットのデータ部分を読み出すデータ読み出し手段と、を備えることを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、データ通信に伴うパケット処理を効率よく行う技術を提供することができる。また、本発明によれば、パケット処理におけるＣＰＵの処理負荷を軽減し、高速でリアルタイムな通信を実現する技術を提供することができる。

図１は、本発明の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。インターネット電話装置１００は、インターネット２０を介して、他のインターネット電話装置１００との間で通話を行うための装置である。インターネット電話装置１００は、主に、ソフトウェア処理を実行するための汎用回路であるＣＰＵ１１０、プログラムエリアまたはワークエリアとして利用されるメモリ１２０、インターネット２０を介してパケットを送受信するネットワークインタフェース部１３０、音声信号を入力するマイク１５０、音声信号を出力するスピーカ１６０、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部１４０、通信データの暗号化処理または復号処理などを行うセキュリティ処理部１７２、ＵＤＰパケットを処理するための専用回路であるＵＤＰ処理部１７４、通信プロトコルに応じた各種処理を行うプロトコルエンジン２００、およびこれらの構成を電気的に接続するバス１０２を備える。

本実施の形態のインターネット電話装置１００は、受信したパケットの処理をＣＰＵ１１０のみに任せるのではなく、ＣＰＵ１１０へパケットを転送する前に、専用のハードウェアにより構成されたプロトコルエンジン２００が、ヘッダ解析、エラーチェック、データのアライメントなどの処理を行うので、ＣＰＵ１１０が無駄なパケット処理を行う必要がなく、処理負荷が大幅に軽減される。

本実施の形態のインターネット電話装置１００では、ＵＤＰを利用して音声信号を送受信する。ＵＤＰは、接続の確立を要さず、パケットを次々に送出することが可能な通信方式であるため、プロトコル処理が簡単で、かつ高速な通信が可能であり、通話音声を送るなどのリアルタイムな通信に適している。本実施の形態のインターネット電話装置１００では、ＵＤＰパケットの処理を、専用の回路であるＵＤＰ処理部１７４に実行させることで、さらに処理速度を向上させ、通話音声のリアルタイムな送受信を実現する。

インターネット電話装置１００が送受信するパケットのうち、ＴＣＰにより送受信されるパケットは、ＣＰＵ１１０を利用してソフトウェアにより処理される。リアルタイム性を要しないＴＣＰパケットについては、専用の回路を設けず、汎用回路によるソフトウェア処理を行うことで、回路規模の増大を抑え、コスト、消費電力、熱発生の増大を最小限に抑えることができる。本発明者の試算によれば、ＴＣＰとＵＤＰの双方を専用回路により処理する場合に比べて、回路の面積および消費電力が約１／３で済むことが分かっている。このように、本実施の形態では、専用のハードウェアと汎用のソフトウェアとにより協調処理することで、処理の高速化と回路規模の削減という二律背反的な要望に応える。

ネットワークインタフェース部１３０が受信したパケットは、プロトコルエンジン２００に送られる。プロトコルエンジン２００は、パケットが自装置に割り当てられたＩＰアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみを通し、その他のパケットを破棄する。また、パケットに付されたヘッダ情報を参照してプロトコルの種別を検出し、パケットがＴＣＰにより送られたパケットであった場合は、そのパケットのデータをバス１０２上に送り、ＣＰＵ１１０によりソフトウェア処理させる。パケットがＵＤＰのパケットであった場合は、そのパケットのデータをＵＤＰ処理部１７４に送り、ＵＤＰパケットの処理のために専用に設けられた回路により処理させる。

ＵＤＰ処理部１７４は、ＵＤＰパケットを処理するための専用回路であり、ＵＤＰパケットを受け取って、そのヘッダを解析し、必要な処理を実行する。セキュリティ処理部１７２は、データに対して暗号化処理などのセキュリティ対策が施されていた場合に、暗号を復号するなどの処理を行う。復号されたデータは、コーデック処理部１４０に送られる。コーデック処理部１４０は、圧縮符号化されていた通話音声信号を復号し、スピーカ１６０に出力する。

このように、本実施の形態のインターネット電話装置１００では、正確性よりもリアルタイム性が重視され、通話中、常時処理が必要となる通話音声データは、ＵＤＰにより送受信を行い、専用回路であるＵＤＰ処理部１７４によりハードウェア処理を行う一方、リアルタイム性よりも正確性が重視されるデータは、ＴＣＰにより送受信を行い、ＣＰＵ１１０によりソフトウェア処理を行う。これにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えつつ、通話音声データを高速に処理することが可能となる。このような利点は、複数の相手と同時に通話したり、通話音声とともに画像を送信するなど、大量のデータを同時に処理することが必要な場合に、より顕著となる。また、プロトコルエンジン２００によりパケットの種別を検出し、パケットの処理主体を高速かつ適切に選択することができる。さらに、ＣＰＵ１１０の処理負担を軽減し、低コスト化、低消費電力化が実現できるほか、ＣＰＵ１１０に余力ができるため、通話中に他のアプリケーションを実行することが可能となり、新たなサービスを提供することもできる。

以上、パケットを受信したときの動作について説明したが、つづいて、マイク１５０から入力された音声信号をパケット化して送信するときの動作について説明する。マイク１５０から入力された音声信号は、コーデック処理部１４０に送られ符号化される。符号化された信号は、必要であれば、セキュリティ処理部１７２により暗号化されたあと、ＵＤＰ処理部１７４に送られ、ＵＤＰヘッダが付され、パケット化される。このＵＤＰパケットは、プロトコルエンジン２００によりチェックサム値などのヘッダ情報が付され、ネットワークインタフェース部１３０を介して、インターネット２０に送出される。

図２は、プロトコルエンジン２００の内部構成を示す。ＡＲＰ制御部２０２は、ネットワークインタフェース部１３０が自装置のＩＰアドレスに宛てたＡＲＰ（Address Resolution Protocol）パケットを受信したときに、自動的に自装置のデータリンク層のアドレス（ＭＡＣアドレス）情報をセットして応答パケットを生成し、ＡＲＰパケットの送信元へ送信する。従来は、ＡＲＰパケットもＣＰＵ１１０によりソフトウェア処理していたが、本実施の形態では、ＡＲＰ制御部２０２がＣＰＵ１１０を介さずに自動応答することにより、ＣＰＵ１１０の負担を大幅に軽減するとともに、割り込みによるタスクスイッチを減少させることができる。

ヘッダ解析部２１０は、パケットのヘッダ情報を解析して、不要なパケットを破棄し、必要なパケットのみを通す処理を行う。たとえば、自装置のＩＰアドレスに宛てたパケットのみを通し、その他のＩＰアドレス宛てのパケットは破棄する。ＩＰパケットのみを送受信する装置に本実施の形態のプロトコルエンジン２００を搭載する場合、ＩＰ以外の通信方式のパケットを破棄してもよい。また、特定のパケットを検出して、そのパケットを処理する専用回路へ送ってもよい。本実施の形態では、ＵＤＰパケットを専用回路であるＵＤＰ処理部１７４により処理するので、ヘッダ解析部２１０は、ヘッダ情報を解析することによりＵＤＰパケットを検出すると、そのＵＤＰパケットをＣＰＵ１１０を介さずに直接ＵＤＰ処理部１７４に転送する。このとき、ヘッダ情報を破棄してデータ部分のみを送ってもよい。これにより、ソフトウェア処理が必要なパケットのみをＣＰＵ１１０に処理させることができるので、ＣＰＵ１１０の処理負担を軽減することができる。また、適宜専用のハードウェアによりパケットを処理することにより、処理の高速化を図ることができる。

チェックサム算出部２１２は、パケットのチェックサムを算出し、ヘッダに格納されたチェックサム値と一致するか否かを検証する。一致した場合は、そのパケットを通し、一致しなかった場合は、そのパケットを破棄する。従来は、ＣＰＵ１１０がチェックサムの検証を行っていたが、本実施の形態のように、ＣＰＵ１１０に送る前の段階で専用回路にてチェックサムの検証を行うことで、ＣＰＵ１１０に無用なパケットを処理させることを防ぎ、ＣＰＵ１１０の処理負担を軽減することができる。

書き込み制御部２２０は、ヘッダ解析部２１０を通過したパケットを受信バッファ２３０に格納する。チェックサム算出部２１２によりエラーが検出されたパケットは受信バッファ２３０に格納せずに破棄するが、チェックサム算出部２１２がチェックサムを算出している間、受信バッファ２３０への書き込みを待機しているよりも、並行して受信バッファ２３０へ書き込んでいくほうが効率がよい。そのため、書き込み制御部２２０は、ヘッダ解析部２１０を通過したパケットを、チェックサム算出部２１２による検証の結果を待たずに受信バッファ２３０に書き込んでいき、チェックサム算出部２１２による検証でエラーが検出された場合は、書き込んだパケットを消去し、ライトポインタを元に戻す。読み出し制御部２４０は、受信バッファ２３０に格納された受信パケットの読み出しを制御する。書き込み制御部２２０、受信バッファ２３０、および読み出し制御部２４０の構成および動作の詳細については、図４において詳述する。

チェックサム生成部２８０は、送信パケットのチェックサムを算出する。ＵＤＰパケットは、送信キューに投入する時点でパケットサイズが確定しているので、チェックサム生成部２８０により予めデータ部のチェックサムを算出して保持しておき、パケット送出時にヘッダ合成部２５０によりヘッダにチェックサム値をセットする。ＴＣＰパケットは、パケット送出時にパケットサイズが確定するので、予めデータ部のチェックサム値を算出しておくことはできないが、所定の区間ごとにチェックサム累積値を算出して保持しておくことで、パケット送出時のチェックサム算出処理を簡略化することができる。ＴＣＰパケットのパケットサイズを、チェックサム累積値の算出区間の整数倍に限定すれば、データ部のチェックサム値はデータ部の区間前後のチェックサム累積値を減算するだけで得られる。

第１送信バッファ２７０は、送信パケットのうち、送信先のＭＡＣアドレスが未解決のものを格納する。第２送信バッファ２７２は、送信パケットのうち、送信先のＭＡＣアドレスが分かっているものを格納する。ＡＲＰインタフェース２６０は、第１送信バッファ２７０に格納された、送信先のＭＡＣアドレスが不明なパケットについて、そのＭＡＣアドレスを解決すべく、ＡＲＰパケットを生成してネットワークにブロードキャストする。ＡＲＰパケットの応答が戻ってくるまでの間はそのパケットを送出できないので、アドレス解決が不要なパケットのキューとは別に第１送信バッファ２７０を設けて待機させておき、その間は第２送信バッファ２７２にて待機中のアドレス解決が不要な送信パケットを送出する。ＡＲＰの応答が戻ってくると、解決されたＭＡＣアドレスをセットして第１送信バッファ２７０のパケットを送出し、次に待機中のパケットについてＡＲＰパケットを送出する。そして、応答が戻るまでの間は再び第２送信バッファ２７２のパケットを送出する。これにより、全体の送信待ち時間を減少させ、効率良くパケットを送出することができる。また、送信先のＭＡＣアドレスが未解決のパケットであっても、第１送信バッファ２７０に投入しておけば自動的にＭＡＣアドレスを解決しつつパケットを送出してくれるので、ＣＰＵ１１０側の処理が単純になり、処理負荷を軽減することができる。

ヘッダ合成部２５０は、第１送信バッファ２７０または第２送信バッファ２７２に保持された送信待機中の送信パケットを、ネットワークインタフェース部１３０を介して送出すべく、そのパケットのヘッダ情報を生成する。ヘッダ合成部２５０は、頻繁に変更されないパラメータや容易に推測可能なパラメータを自動的に生成してヘッダ情報を生成する。たとえば、ＩＰヘッダの識別子は、ＣＰＵ１１０が指定しなくともヘッダ合成部２５０が自動的にインクリメントしてヘッダにセットする。ＣＰＵ１１０は、データ以外には、送信先とパケットサイズのみを指定すればよい。これにより、ＣＰＵ１１０のバッファ管理を単純化し、処理負荷を軽減することができる。

ホストテーブル２０４は、他装置のＭＡＣアドレスおよびＩＰアドレスを対応付けて保持する。図３は、ホストテーブル２０４の内部データの例を示す。ホストテーブル２０４には、ホストＩＤ欄２０５、ＭＡＣアドレス欄２０６、およびＩＰアドレス欄２０７が設けられている。ホストテーブル２０４の内容は、ＣＰＵ１１０が予め頻繁に通信を行う可能性のあるホスト装置の情報を登録してもよいし、通信中にＣＰＵ１１０などが登録してもよい。ＭＡＣアドレスが不明なホスト装置であっても、まずＩＰアドレスのみを格納しておき、ＡＲＰインタフェース２６０によりＡＲＰパケットを送出し、その応答を取得したときにＭＡＣアドレスを登録してもよい。ホストテーブル２０４を設けてあるので、ＣＰＵ１１０は、パケットの送信先を指定するときに、ホストＩＤ、ＭＡＣアドレス、ＩＰアドレスのいずれを用いて指定してもよい。ヘッダ合成部２５０は、ホストテーブル２０４を参照して、ヘッダ生成に必要な情報を取得することができる。

ホストインタフェース部２９０は、プロトコルエンジン２００の構成要素とＣＰＵ１１０との間でデータや指示の入出力を制御する。

図４は、書き込み制御部２２０および読み出し制御部２４０の内部構成を示す。書き込み制御部２２０は、管理情報生成部２２２、データ入れ替え部２２４、書き込みアドレス生成部２２６、遅延回路２２８、およびセレクタ２２９を備える。ヘッダ解析部２１０によるパケットフィルタリングを通過したパケットは、管理情報生成部２２２およびデータ入れ替え部２２４により整形されて受信バッファ２３０に格納される。パケットのデータが整形される様子は、図５を参照しつつ後述することにする。書き込みアドレス生成部２２６は、受信バッファ２３０のライトポインタを管理する。前述したように、チェックサム算出部２１２によるチェックサムの検証に並行して受信バッファ２３０にパケットのデータを格納していくが、チェックサムエラーが検出されたときは、書き込みアドレス生成部２２６は、ライトポインタを元の位置に戻す。チェックサムエラーが検出されず、受信バッファ２３０への格納が正常に終了すると、書き込みアドレス生成部２２６は、管理情報生成部２２２に次のパケットのアドレスを通知する。読み出し制御部２４０は、読み出しアドレス生成部２４２およびセレクタ２４４を備える。

図５は、書き込み制御部２２０によりパケットのデータが整形される様子を示す。通常のＩＰパケットは、先頭のＭＡＣヘッダが１４バイトを占めているが、３２ビットワードでは３．５ワードと半端になるため、以降のデータが１６ビットずつずれた形となる。このまま受信バッファ２３０に格納すると、アクセスするときに不便であるから、本実施の形態では、ＭＡＣヘッダが３ワードとなるようにデータを整形してから受信バッファ２３０に格納する。すなわち、ＭＡＣヘッダを１６ビット分減らせばよい。ＭＡＣヘッダのうち、宛先ＭＡＣアドレスは、自装置のＭＡＣアドレスと同じであり、既にパケットを受信しているので不要である。ＭＡＣアドレスは４８ビットであるから、これを破棄すると、３２ビット分余裕が残る。アプリケーションによっては、このパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたのかという情報が必要な場合があるので、これをフラグとして宛先ＭＡＣアドレスの代わりに格納する。このフラグは２ビットで十分であるから、まだ３０ビット分余裕がある。そこで、パケット種別を示すフラグや、次のパケットの格納位置を示すアドレス情報などを管理情報として格納する。以上により、ＭＡＣヘッダが３ワードにおさまるので、以降のデータをワード単位で整列させることができ、アクセスが容易になる。

図４に戻り、受信したパケットを書き込む手順と読み出す手順について説明する。管理情報生成部２２２は、上述した管理情報を生成する。管理情報として、たとえば、このパケットがユニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたのかを示す送信種別情報、このパケットがＴＣＰパケットかＵＤＰパケットか、フラグメント化されたＩＰパケットまたはオプション付きのＩＰパケットなど複雑な処理を要する特殊なＩＰパケットであるか否か、などを示すパケット種別情報、次のパケットの格納位置を示すアドレス情報、などを生成してもよい。次パケットのアドレス情報を格納する場合は、自パケットのデータの格納が終了してから、書き込みアドレス生成部２２６から次パケットのアドレス情報を取得するので、管理情報の受信バッファ２３０への書き込みはパケットのデータの格納が完了した後になる。これらの管理情報は、全体で１ワードとなるように整形され、セレクタ２２９を介して受信バッファ２３０に格納される。

データ入れ替え部２２４は、受信したパケットのデータのうち、ＭＡＣアドレ
スを除いたデータを３２ビットワードで整列させるために、上位１６ビットと下位１６ビットを入れ替える。データ入れ替え部２２４の出力のうち、上位１６ビットを遅延回路２２８により１クロック遅延させて合成することにより、１６ビットずつずれていたデータを整列させることができる。整形されたデータは、セレクタ２２９を介して受信バッファ２３０に格納される。

書き込みアドレス生成部２２６は、まず、書き込み位置の先頭にポインタを移動するが、１ワード目の管理情報は最後に格納されるので、ポインタをインクリメントし、ＭＡＣヘッダのうち宛先ＭＡＣアドレスを除いた２ワード、ＩＰヘッダ５ワード、ＩＰデータを、ポインタをインクリメントしつつ次々に書き込んでいく。データ部分の書き込みが終了すると、次の書き込み開始位置を管理情報生成部２２２に通知し、書き込み位置の先頭にポインタを戻して、管理情報を書き込む。

管理情報を含むヘッダ情報は、それぞれ独立したレジスタを割り当て、ＣＰＵ１１０がランダムに何度でもアクセスできるようにする。受信バッファ２３０に格納されたパケットは、既にヘッダ解析部２１０およびチェックサム算出部２１２により有効性が検証されたものであるから、ＣＰＵ１１０が直接ヘッダ情報にアクセスしてデータを渡すべきアプリケーションを判断できるようにする。他方、データ部分は、１つのアクセスポートレジスタから読み出すようにする。すなわち、アクセスポートレジスタへの最初の読み出しでは、データ部分の最初のデータが読み出され、以降、同じレジスタを連続してアクセスすることにより、データが次々に読み出される。データの転送先が決定されれば、あとはデータをコピーするだけであるから、ランダムアクセスを可能とする必要はない。したがって、アクセスポート方式を採用することにより、ポインタ管理が必要なメモリマップ方式よりも簡便で処理負担を軽減することができる。また、ＣＰＵ１１０を持たないハードウェアと組み合わせて利用することもできる。

受信バッファの読み出しアドレスは上位アドレスと下位アドレスから構成される。ＣＰＵ１１０は、受信バッファ２３０に格納されたパケットのヘッダ情報にアクセスするときは、上位アドレスと下位アドレスの双方を指定する。上位アドレスについては、どのパケットのどのヘッダにアクセスしたいかを読み出しアドレス生成部２４２に指定すれば、読み出しアドレス生成部２４２が自動的に上位アドレスを生成してポインタを移動する。下位アドレスについては、ＣＰＵ１１０が出力する下位アドレスをそのまま受信バッファの下位アドレスとし、ＣＰＵ１１０が自由に読み出せるようにする。ＣＰＵ１１０は、パケットのデータ部分にアクセスするときは、読み出しアドレス生成部２４２に、どのパケットのデータにアクセスしたいかを指定すればよい。読み出しアドレス生成部２４２は、自動的に上位アドレスと下位アドレスを生成してポインタを移動し、データを次々に読み出す。

以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、そうした例を述べる。

実施の形態では、電話装置を例にとって説明したが、本発明の技術は、コンピュータや携帯電話など、ストリームデータを送受信する通信装置全般に利用可能である。

プロトコルエンジン２００の機能を有する回路を、一つの半導体基板上に搭載してもよい。さらに、セキュリティ処理部１７２、コーデック処理部１４０、ＣＰＵ１１０などの回路を搭載してもよい。これにより、通信装置の小型化、軽量化、高速化を図ることができる。

実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。実施の形態に係るプロトコルエンジンの内部構成を示す図である。実施の形態に係るホストテーブルの内部データを示す図である。実施の形態に係る書き込み制御部および読み出し制御部の内部構成を示す図である。書き込み制御部によりパケットのデータが整形される様子を示す図である。

符号の説明

１００インターネット電話装置、１３０ネットワークインタフェース部、１４０コーデック処理部、１５０マイク、１６０スピーカ、１７４ＵＤＰ処理部、２００プロトコルエンジン、２０２ＡＲＰ制御部、２０４ホストテーブル、２１０ヘッダ解析部、２１２チェックサム算出部、２２０書き込み制御部、２２２管理情報生成部、２２４データ入れ替え部、２２６書き込みアドレス生成部、２３０受信バッファ、２４０読み出し制御部、２４２読み出しアドレス生成部、２５０ヘッダ合成部、２６０ＡＲＰインタフェース、２７０第１送信バッファ、２７２第２送信バッファ、２８０チェックサム生成部。

Claims

リアルタイム性が重視されるパケット処理を行うハードウエア処理と、
リアルタイム性が重視されないパケット処理を行うソフトウエア処理と、
前記パケット処理の際のリアルタイム性の重要度によりハードウエア処理とソフトウエア処理とにパケットを振り分けて処理するプロトコル制御部と、を備えるパケット処理装置において、
前記プロトコル制御部は、ネットワークを介して取得したパケットを一時的に保持するバッファと、
前記パケットの前記バッファからの読み出しを制御する読み出し制御部と、を備え、
前記読み出し制御部は、
前記バッファに直接アクセスして、前記バッファに保持されたパケットのヘッダ部分を読み出すヘッダ読み出し手段と、
単一のアクセスポートレジスタへのアクセスを介して前記バッファに保持されたパケットのデータ部分を読み出すデータ読み出し手段を備えており、
前記データ読み出し手段は、読み出すパケットの種別に応じて、前記アクセスポートレジスタが読み出しを開始する前記バッファの読み出し開始位置を設定することを特徴とするパケット処理装置。
前記パケットを前記バッファに格納する前に、そのヘッダ情報を解析することにより不要なパケットを破棄するヘッダ解析部と、
前記パケットを前記バッファに格納する前に、そのチェックサムを算出して、ヘッダに格納されたチェックサム値と一致するか否かを検証するチェックサム算出部と、
前記チェックサム算出部が前記パケットのチェックサムの算出中、前記バッファに前記パケットを書き込み、チェックサムエラーが検出されたとき、ライトポインタを書き込み前の位置に戻す書き込み処理部と、をさらに備えることを特徴とする請求項１に記載のパケット処理装置。
音声を入力する入力部と、
前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、
他の装置から受信した音声を出力する出力部と、を備え、
前記通信部は、
ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットを処理する、請求項１又は２に記載のパケット処理装置を含むように構成したことを特徴とする電話装置。