WO2004036865A1

WO2004036865A1 - 通信装置及びその応用

Info

Publication number: WO2004036865A1
Application number: PCT/JP2003/012166
Authority: WO
Inventors: Kazuaki Okamoto; Hideo Hirono
Original assignee: Sanyo Electric Co.,Ltd.
Priority date: 2002-09-30
Filing date: 2003-09-24
Publication date: 2004-04-29
Also published as: KR20070045338A; KR100790673B1; AU2003266582A1; KR20070091232A; CN1656767A; KR100753734B1; CN1656767B; KR20040091769A; KR100899923B1

Description

明細書. 通信装置及びその応用技術分野

本発明は通信技術に関し、特に、パケットを効率的に処理する技術、複数の通ィ 1 プロトコルによるデータ通信を効率的に処理する技術、ネットワークを介して送受信されるバケツトのチェックサムを算出する技術に関する。背景技術

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

現在、パケット通信のための通信プロトコルとして、 T C P / I P

(Transmission Control Protocol I Internet Protocol) 力ムく禾 IJ用さている。 T C Pは、装置間で接続を確立してからデータを送受信するなど、正確性を重視した通信プロトコルである。しかしながら、処理が複雑で、相手側がパケットを受信したことを確認するまで次のパケットを送ることができないなどの時間的制約があり、リアルタイム性に欠けるため、通話音声の送受信には不向きである。

T C Pよりも簡便な通信プロトコルに、 U D P / I P (User Datagram

Protocol / Internet Protocol) がある。 U D Pでは、データの送受信に先立って装置間で接続を確立する必要がなく、バケツトの受信確認を待たずに次のバケツトを送ることが許されるので、送信側は次々にパケットを送出することができる。そのため、データの正確性よりもリアルタイム性が重視される、通話音声の送受信に適している。 TC Pと UD Pの双方の通信プロトコルをサポートする装置では、バケツト処理は、 C PUなどの汎用プロセッサによりソフトウエア処理されるのが一般的である。すなわち、ネットワークインタフェースデバイスがパケットを受信すると、自装置以外の MAC (Media Access Control) アドレス宛てのパケットがフィルタリングされ、 CRC (Cyclic Redundancy Check) による誤りチェックが行われた後、それらを通過した全てのパケットが CPUに送られて処理される。

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

また、ネットワークルータなど、高速性が要求される一部の装置では、全てのプロトコル処理をハードゥヱァ化して実装している。双方の通信プロトコルをノヽ一ドウエアにより処理する方式では、高速なプロトコル処理が可能となるが、複雑な処理が必要な TCPの処理もハードウエア化するため、回路規模が大きくなり、コスト、消費電力、熱の発生などの点で問題がある。

また、 TCPおよび UDPでは、データをパケット化して送受信するが、受信したデータの信頼性をチェックするために、それぞれのバケツトにはチェックサムが与えられる。チェックサムは、パケットの全データを 1の補数カ卩算したものであり、パケットのヘッダ内に格納される。送信側は、パケットの送信に先立つて、そのパケットの全データを加算してチェックサムを算出し、ヘッダに格納して送信する。受信側は、パケットを受信すると、そのパケットの全データを加算し、その結果が、ヘッダ内に格納されたチェックサム値と一致するか否かをチェックする。一致していれば、パケットの受信に成功したと判断し、一致していなければ、受信したパケット内のデータに誤りがあると判断して、そのパケットを廃棄する。

T C Pの場合、 1回に送信可能なデータの量は、ネットワークの状況や、受信側のバッファの状況などにより変動し、送信の直前に決定される。そのため、送信側では、一般に、次に送信するパケットのサイズが確定した後に、そのパケットのデータを読み出してチェックサムを算出している。そして、そのチェックサムをパケットのヘッダに格納し、ヘッダ情報を送信した後、再びデータを読み出して送信する。

特開 2 0 0 1— 2 6 8 1 5 9号公報は、 T C Pバケツトを生成する方法を開示する。この方法では、 T C Pにより送信すべきデータをいつたん T Xバッファに貯蔵し、次に送信するパケットのサイズが確定すると、そのサイズのデータを T Xバッファから読み出してチェックサムを算出するとともに、そのデータを臨時バッファに格納する。そして、チェックサムを含むヘッダを送信した後、臨時バッファからデータを読み出して送信する。このように、メモリを 2つ用意することにより、チェックサム算出のための T Xバッファからのデータ読み出しと、データ送信のための臨時バッファからのデータ読み出しを並行してパイプライン的に行うことができるので、オーバーへッドを改善することができる。

しかしながら、この方法によっても、次に送信するパケットのサイズが確定してからチェックサムを算出することに変わりはなく、バケツト送出までの遅延時間が長いという問題がある。また、物理的に分割された 2種類のメモリを用意する必要があるので、ハードウェア規模が大きくなり、コストがかかるという問題がある。発明の開示

本発明は、そうした課題に鑑みてなされたものであり、その目的は、データ通信に伴うパケット処理を効率よく行う技術を提供することにある。

本発明のある態様は、通信装置に関する。この通信装置は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式により送られたバケツトであったとき、そのバケツトをソフトウエアにより処理するための汎用回路と、'受信したバケツトが、装置間での接続の確立を要しない第 2の通信方式により送られたバケツトであったとき、そのバケツトを処理するための専用回路と、を備える。

本発明の別の態様も、通信装置に関する。この通信装置は、ネットワークを介して送られたバケツトを受信する受信部と、受信したバケツトが、送信バケツトの到着確認を行う第 1の通信方式により送られたバケツトであったとき、そのパケットをソフトウエアにより処理するための汎用回路と、受信したバケツトが、送信パケットの到着確認を行わない第 2の通信方式により送られたバケツトであつたとき、そのパケットを処理するための専用回路と、を備える。

汎用回路は、 C P U、 D S Pなどであってもよい。第 1の通信方式は、たとえば、 T C Pであってもよい。第 2の通信方式は、たとえば、 U D Pであってもよい。 U D Pの処理のみをハードウェア化することにより、回路規模の増大を抑えつつ、 U D Pの処理を高速化することができる。

この通信装置は、ネットワークを介してバケツトを送信する送信部をさらに備え、送信するパケットが、前記第 1の通信方式により送られるとき、そのバケツトを前記汎用回路により処理し、送信するパケットが、前記第 2の通信方式により送られるとき、そのバケツトを前記専用回路により処理してもよい。

この通信装置は、受信したパケットが、どの通信方式により送られたかを検出する検出部をさらに備えてもよい。検出部は、パケットのヘッダを参照して、通信方式を検出してもよい。この検出部も、専用の回路により構成されてもよい。前記検出部により、前記第 1の通信方式により送られたパケットが検出されたとき、前記検出部は、そのパケットを、前記汎用回路を介さずに、直接前記専用回路へ送ってもよい。ソフトゥヱァ処理を介さず、専用回路により処理することで、高速な処理が実現する。また、 C P Uなどの汎用回路の処理負担を軽減することができる。

この通信装置は、パケットを構成するデータを暗号化または復号化するセキュリティ処理部をさらに備えてもよい。このセキュリティ処理部も、専用の回路により構成されてもよレ、。

本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットヮークを介して送られたバケツトを受信する受信部と、受信したバケツトがフラグメント化されたパケットであったとき、そのパケットをソフトウェアにより処理するために汎用回路へ送り、受信したバケツトがフラグメント化されていないパケットであったとき、そのバケツトをハードウエアにより処理するために第 1の専用回路へ送る第 1の判別部と、を備える。

I Pパケットのうち、オプション付きの I Pパケットや、フラグメント化された I Pパケットなどは、複雑な処理を必要とするので、これらの I Pパケットも専用回路で処理しょうとすると、回路規模が増大し、消費電力やコストの増大を招く。そのため、通常の I Pパケットは専用回路で高速に処理しつつ、通常の I Pバケツトよりも複雑な処理を必要とする特殊な I Pバケツトは、 C P Uなどの汎用回路でソフトウェアにより処理することで、専用回路の回路規模を抑え、消費電力およびコストを低減することができる。

この通信装置は、前記第 1の専用回路により処理したパケットが、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式により送られたパケットであったとき、そのパケットを前記汎用回路に送り、前記第 1の専用回路により処理したバケツトが、装置間での接続の確立を要しない第 2の通信方式により送られたバケツトであったとき、そのパケットをハードウェアにより処理するための第 2の専用回路へ送る第 2の判別部をさらに備えてもよい。通常の I Pパケットの I P処理を I P処理回路で行った後、バケツトが U D Pであるか T C Pであるかを判断し、 U D Pパケットのみを U D P処理回路で処理し、 τ C Pバケツトは C P Uなどの汎用回路によりソフトウエア処理してもよレ、。本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットヮークを介して受信したバケツトが、リアルタイムな処理を要するデータを含むパケットであるか否かを判別する判別部と、前記パケットを一時的に保持するバッファと、前記バッファへの前記パケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記リアルタイムな処理を要するデータを含むパケットの前記パッファへの格納を許可する一方、リアルタイムな処理を要するデータを含まないバケツトの前記バッファへの格納を禁止する。

リアルタイムな処理を要するバケツトを優先的に受信バッファに取り込んで処理することで、バッファが飽和してリアルタイムな処理を要するパケットが破棄される可能性を抑えることができる。

本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットヮークを介して受信したバケツトが、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式により送られたパケットであるか、装置間での接続の確立を要しない第 2の通信方式により送られたパケットであるかを判別する判別部と、前記パケットを一時的に保持するバッファと、前記バッファへの前記パケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記第 2の通信方式により送られたパケットの前記バッファへの格納を許可する一方、前記第 1の通信方式により送られたパケットの前記バッファへの格納を禁止する。

電話装置における通話音声信号や、ビデオ電話装置における映像信号などを U D Pにより送受信する場合、 U D Pバケツトを T C Pバケツトより優先して選択的に取り込むことにより、 U D Pバケツトが破棄されて通話音声信号などのデータが欠落する可能性を抑えることができる。

本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットヮークを介して受信したバケツトの種別を判別する判別部と、前記バケツトを一時的に保持するバッファと、前記バッファへのバケツトの格納を制御する制御部と、を備え、前記制御部は、前記バッファへのパケットの格納の許否を判定するためのしきい値をバケツトの種別に応じて複数保持し、前記バッファの空き領域がしきい値を下回ったバケツト種別のバケツトの前記バッファへの格納を禁止する。リアルタイムな処理を要するバケツトゃ、重要度の高いバケツトに対するしきい値を、その他のパケットに対するしきい値よりも低く設定してもよい。これにより、バッファの空き領域が少なくなつたときに、リアルタイム性を有するパケットや、重要度の高いパケットを優先的に取り込み、パケットが破棄される可能性を抑えることができる。

本発明のさらに別の態様は、電話装置に関する。この電話装置は、音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、他の装置から受信した音声を出力する出力部と、を備え、前記通信部は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットの通信方式を検出する検出部と、前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であつたとき、そのパケットをソフトウェアにより処理するための汎用回路と、前記通信方式が、装置間での接続の確立を要しない第 2の通信方式であったとき、そのパケットを処理するための専用回路と、を含み、前記音声を前記第 2の通信方式により送受信する。出力部はスピーカであってもよく、入力部はマイクロホンであってもよい。

本発明のさらに別の態様は、ビデオ電話装置に関する。このビデオ電話装置は、画像および音声を入力する入力部と、前記入力部により入力された画像および音声を他の装置へ送信し、他の装置から画像および音声を受信する通信部と、他の装置から受信した画像および音声を出力する出力部と、を備え、前記通信部は、ネットワークを介して送られたバケツトを受信する受信部と、受信したバケツトの通信方式を検出する検出部と、前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であったとき、そのバケツトをソフトウェアにより処理するための汎用回路と、前記通信方式が、装置間での接続の確立を要しない第 2の通信方式であったとき、そのバケツトを処理するための専用回路と、を含み、前記画像おょぴ音声を前記第 2の通信方式により送受信する。

本発明のさらに別の態様は、撮像装置に関する。この撮像装置は、画像を撮像する撮像部と、前記撮像部により撮像された画像を他の装置へ送信し、他の装置から画像を受信する通信部と、を備え、前記通信部は、ネットワークを介して送られたバケツトを受信する受信部と、受信したバケツトの通信方式を検出する検出部と、前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であったとき、そのバケツトをソフトウェアにより処理するための汎用回路と、前記通信方式が、装置間での接続の確立を要しない第 2の通信方式であったとき、そのパケットを処理するための専用回路と、を含み、前記画像を前記第 2の通信方式により送受信する。

本発明のさらに別の態様は、通信方法に関する。この方法は、パケットを受信したときに、そのパケットの通信方式を検出する工程と、前記通信方式に応じて、そのバケツトを処理すべき回路にバケツトのデータを送る工程と、を含む。

前記検出する工程は、パケットのヘッダを解析することにより、データの送受信に先立って装置間での接続の確立を要する第 1の通信方式によるバケツトであるか、装置間での接続の確立を要しない第 2の通信方式によるバケツトであるかを検出し、前記データを送る工程は、前記第 1の通信方式によるパケットを、ソフトウエア処理するための汎用回路に送り、前記第 2の通信方式によるバケツトを、そのパケットを処理するための専用回路に送ってもよい。

前記検出する工程は、パケットのヘッダを解析することにより、フラグメント化されたパケットであるか、フラグメント化されていないパケットであるかを検出し、前記データを送る工程は、前記フラグメント化されたパケットを、ソフトウェア処理するための汎用回路に送り、前記フラグメント化されていないパケットを、そのパケットを処理するための専用回路に送ってもよい。

リアルタイム性を要しないデータは、前記第 1の通信方式により送受信する一方、リアルタイム性を要するストリームデータは、前記第 2の通信方式により送受信してもよい。リアルタイムな処理を要するデータとは、時間制約を受けるデータをいい、また、リアルタイム性を要しないデータとは、時間制約を受けないデータをいう。ストリームデータは、たとえば、通話音声データ、動画データ、などであってもよい。

本発明のさらに別の態様は、通信方法に関する。この方法は、パケットを受信したときに、そのパケットの種別を検出する工程と、前記種別ごとに設定された条件に基づいて、バケツトを一時的に保持するバッファへのそのバケツトの格納の許否を判断する工程と、格納が許可されたときに、そのパケットを前記バッファへ格納する工程と、格納が許可されなかったときに、そのパケットを破棄する工程と、を含む。

本発明のさらに別の態様は、パケット処理装置に関する。このパケット処理装置は、ネットワークを介して取得したバケツ小を一時的に保持するバッファと、前記パケットの前記バッファへの格納を制御する書き込み制御部と、を備え、前記書き込み制御部は、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納する。

パケットの MA Cヘッダに格納されている送信先 MA Cァドレスは、バケツトを受信すると以降のバケツト処理には不要であるので、これを破棄することにより、バッファの使用効率を向上させることができる。

前記書き込み制御部は、前記送信先アドレス情報に代えて、そのパケットがュ二キャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を格納してもよい。前記管理情報は、パケットの種別を示すバケツト種別情報、および次のバケツトの格納位置を示すァドレス情報をさらに含んでもよい。前記書き込み制御部は、前記管理情報を 1ワードにおさめ、後続のデータをヮード単位で整形して前記バッファに格納してもよい。

MA Cヘッダは、 3 2ビットヮードで 3 · 5ヮードであり、半端なサイズであるから、そのままバッファに格納すると、後続のデータが全て半ワードずつずれることになる。そのため、 1 . 5ワード分の送信先 MA Cアドレスを破棄してバッファに格納することにより、後続のデータをヮード単位でァライメントすることができる。このとき、パケット処理に必要な管理情報を 1ワード分追加してもよい。これにより、ハードウェア的にもソフトウェア的にも扱いが容易になる。本発明のさらに別の態様も、パケット処理装置に関する。このパケット処理装置は、ネットワークを介して取得したパケットを一時的に保持するバッファと、前記パケットの前記バッファからの読み出しを制御する読み出し制御部と、を備え、前記バケツトのヘッダ部分にはそれぞれ独立したレジスタを割り当ててランダムアクセスを可能とする一方、前記バケツトのデータ部分はアクセスポートレジスタを介して読み出しを行うように構成する。

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

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

前記バケツトを前記バッファに格納する前に、そのヘッダ情報を解析することにより不要なパケットを破棄するヘッダ解析部と、前記バケツトを前記バッファに格納する前に、そのチェックサムを算出して、ヘッダに格納されたチヱックサム値と一致するか否かを検証するチェックサム算出部と、をさらに備えてもよい。これにより、 C P Uは、バッファに保持されたパケットが有効なパケットであることを前提に処理を行うことができる。

本発明のさらに別の態様は、電話装置に関する。この電話装置は、音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、他の装置から受信した音声を出力する出力部と、を備え、前記通信部は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットを処理するパケット処理部と、を含み、前記パケットタ几理部は、前記パケットを一時的に保持するバッファと、前記パケットの前記バッファへの格納を制御する書き込み制御部と、を含み、前記書き込み制御部は、前記パケットのへッダ情報のうち、送信先ァドレス情報を破棄して前記受信バッファに格納する。

本発明のさらに別の態様も、電話装置に関する。この電話装置は、音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、他の装置から受信した音声を出力する出力部と、を備え、前記通信部は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットを処理するパケット処理部と、を含み、前記パケット処理部は、前記パケットを一時的に保持するバッファと、前記バケツトの前記バッファからの読み出しを制御する読み出し制御部と、を含み、前記パケットのへッダ部分にはそれぞれ独立したレジスタを割り当ててランダムアクセスを可能とする一方、前記バケツトのデータ部分はァクセスポートレジスタを介して読み出しを行うように構成する。

本発明のさらに別の態様は、パケット処理方法に関する。この方法は、バケツトを受信したときに、そのパケットをバッファに一時的に格納する工程と、前記格納する工程に先立って、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄する工程と、を含む。

本発明のさらに別の態様は、チェックサム算出方法に関する。この方法は、所定のタイミングでデ一タ長が確定するデータブ口ックにチェックサムを与えるために、前記タイミングに先立って、前記データブロックを含むデータユエットの所定長ごとに、前記データュニットの先頭からのチェックサムの累積値を算出して記憶装置に保持する。

データプロックは、たとえば、 T C Pにおけるペイロードであってもよい。 τ C Pパケットは送信直前にデータ長が確定するが、予め所定長ごとにチェックサムの累積値を格納しておくことで、データ長が確定したときに、そのデータプロックの前後の累積値を利用して、短時間でパケットのチェックサムを算出することができる。前記データブロックのデータ長が確定したあと、そのデータプロックの前後の前記累積値を前記記憶装置から読み出して、そのデータプロックのチェックサムを算出してもよい。前記データブロックの直前のデータまでのチェックサムの累積値と、前記データプロックの最後のデータまでのチェックサム累積値とを前記記憶装置から読み出し、それらの差を算出して、そのデータプロックのチェックサムとしてもよい。

本発明のさらに別の態様も、チェックサム算出方法に関する。この方法は、所定のタイミングでデ一タ長が確定するデータブ口ックにチェックサムを与えるために、前記タイミングに先立って、前記データプロックを含むデータユニットを所定長に分割し、その各部分ごとにチェックサム値を算出して記憶装置に保持する。

前記データブロックのデータ長は、前記所定長の整数倍になるよう制限されてもよい。

本発明のさらに別の態様は、チェックサム記録方法に関する。この方法は、あるデータユニットの複数の箇所について、データュュットの先頭からその箇所までのチェックサム値を算出して保持する。データュニットのサイズが大きい場合であっても、途中の複数の箇所について、チェックサムの途中結果を記録しておくことで、データユニットの先頭に近いデータに誤りがあつたときに、データュニット全体のチヱックサムを計算するまでもなく、誤りを検出することができる。本発明のさらに別の態様は、通信装置に関する。この通信装置は、データュニットの入力を受け付ける入力部と、前記データュ-ットの先頭からのチヱックサムの累積値を算出する算出部と、前記データユニットの所定長ごとに、前記累積値を保持する保持部と、を備える。

前記データュニットを複数のデータブロックに分割し、ネットワークを介して送出する出力部と、次に送出するデータプロックのサイズを制御するサイズ制御部と、次に送出するデータプロックのサイズを取得して、そのデータブロックの前後の前記累積値を前記保持部から読み出し、そのデータプロックのチェックサムを算出する第 2算出部と、をさらに備えてもよい。；前記保持部は、送出するデータブロックのサイズが予め定まっていない通信方式でデータユニットを送出する場合は、所定長ごとに、そのデータユニットの先頭からのチェックサムの累積値を保持し、送出するデータプロックのサイズが予め定まっている通信方式でデータュニットを送出する場合は、そのデータュ-ット全体のチェックサムを保持してもよい。送出するデータプロックのサイズが予め定まっていない通信方式は、たとえば T C Pであってもよく、送出するデータプロックのサイズが予め定まっている通信方式は、たとえば U D Pであってもよ ' い。

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

上述した目的、およびその他の目的、特徴および利点は、以下に述べる好適な実施の形態、およびそれに付随する以下の図面によってさらに明らかになる。

図 1は、第 1の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。

図 2は、第 1の実施の形態に係る通信方法の手順を示すフローチャートである。図 3は、第 2の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。

図 4は、'第 3の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。

図 5は、第 4の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。

図 6は、第 5の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。

図 7は、第 6の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。

図 8は、第 6の実施の形態に係るインターネット電話装置のバケツト受信部の内部構成を示す図である。

図 9は、第 6の実施の形態におけるバケツトの受信手順を示すフローチャートでめる。

図 1 0は、第 6の実施の形態に係るインターネット電話装置の I P判別部の内部構成を示す図である。

図 1 1は、第 6の実施の形態におけるパケット処理手順を示すフローチャートである。

図 1 2は、第 7の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。

図 1 3は、第 7の実施の形態に係るプロトコルエンジンの内部構成を示す図である。

図 1 4は、第 7の実施の形態に係るホストテーブルの内部データを示す図である。

図 1 5は、第 7の実施の形態に係る書き込み制御部および読み出し制御部の内部構成を示す図である。

図 1 6は、書き込み制御部によりバケツトのデータが整形される様子を示す図である。

図 1 7は、第 8の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。

図 1 8は、図 1 7の T C P ZU D P処理部の内部構成を示す図である。

図 1 9は、データ格納部とチェックサム格納部の内部データの例を示す図である。

図 2 0は、第 8の実施の形態に係るチェックサム算出方法の手順を示すフローチヤ一トである。発明を実施するための最良の形態

(第 1の実施の形態）

図 1は、本発明の第 1の実施の形態に係る通信装置の一例としてのインターネット電話装置 1 0 0の全体構成を示す。ィンターネット電話装置 1 0 0は、インターネット 2 0を介して、他のインターネット電話装置 1 0 0との間で通話を行うための装置である。インターネット電話装置 1 0 0は、主に、ソフトウエア処理を実行するための汎用回路である C P U 1 1 0、プログラムエリアまたはヮークエリアとして利用されるメモリ 1 2 0、インターネット 2 0を介してバケツトを送受信するネットワークインタフェース部 1 3 0、音声信号を入力するマイク 1 5 0、音声信号を出力するスピーカ 1 6 0、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部 1 4 0、通信プロトコルに応じた各種処理を行うプロトコル処理部 1 7 0、およびこれらの構成を電気的に接続するパス 1 0 2 を備える。

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

インターネット電話装置 1 0 0が送受信するバケツトのうち、 T C Pにより送受信されるパケットは、 C P U 1 1 0を利用してソフトウェアにより処理される。リアルタイム性を要しない T C Pについては、専用の回路を設けず、汎用回路によるソフトウェア処理を行うことで、回路規模の増大を抑え、コスト、消費電力、熱発生の増大を最小限に抑えることができる。本発明者の試算によれば、 T C P と U D Pの双方を専用回路により処理する場合に比べて、回路の面積および消費電力が約 1 3で済むことが分かっている。

ネットワークインタフェース部 1 3 0が受信したバケツトは、プロトコル処理部 1 7 0の I' P処理部 1 7 8に送られる。 I P処理部 1 7 8は、バケツトカ S自装置に割り当てられた I Pアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみをプロトコル検出部 1 76に送る。プロトコル検出部 1 7 6は、パケットに付された I Pヘッダ内のプロトコル種別を示す P ROTを参照して、または、 TC Pヘッダまたは UDPヘッダを参照して、プロトコルの種別を検出する。パケットが TC Pにより送られたパケットであった場合は、そのパケットのデータをバス 1 02上に送り、 C PU 1 1 0によりソフトウェア処理させる。パケットが UD Pのパケットであった場合は、そのパケットのデータを U DP処理部 1 74に送り、 UDPデータの処理のために専用に設けられた回路により処理させる。

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

このように、本実施の形態のインターネット電話装置 100では、正確性よりもリアルタイム性が重視され、通話中、常時処理が必要となる通話音声データは、 UDPにより送受信を行い、専用回路である UDP処理部 1 74によりハードウヱァ処理を行う一方、リアルタイム性よりも正確性が重視されるデータは、 TC Pにより送受信を行い、 CPU 1 1 0によりソフトウェア処理を行う。これにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えつつ、通話音声データを高速に処理することが可能となる。このような利点は、複数の相手と同時に通話したり、通話音声とともに画像を送信するなど、大量のデータを同時に処理することが必要な場合に、より顕著となる。また、プロトコル検出部 1 76によりバケツトの種別を検出し、バケツトの処理主体を高速かつ適切に選択することができる。さらに、 CPU 1 1 0の処理負担を軽減し、低コスト化、低消費電力化が実現できるほか、 CPU 1 1 0に余力ができるため、通話中に他のアプリケーションを実行することが可能となり、新たなサービスを提供することもできる。以上、パケットを受信したときの動作について説明したが、つづいて、マイク 1 50から入力された音声信号をバケツト化して送信するときの動作について説明する。マイク 1 50から入力された音声信号は、コーデック処理部 140に送られ、符号化される。符号化された信号は、必要であれば、セキュリティ処理部 1 72により暗号化されたあと、 UDP処理部 1 74に送られ、 UDPヘッダが付され、パケット化される。この UDPパケットは、ネットワークインタフエ一ス部 1 30を介して、インターネット 20に送出される。

図 2は、本実施の形態における通信方法の手順を示すフローチャートである。ネットワークインタフェース部 1 30がパケットを受信すると（S 100) 、 I P処理部 1 78が処理を行ったあと、プロトコル検出部 1 76が UDPパケットか TC Pパケットかを検出する（S 1 02) 。 UDPパケットであった場合は

(31 02の丫）、 UDPパケットを処理するための専用回路である UDP処理部 1 74によりパケット処理が行われる（S 1 04) 。 TCPパケットであった場合は（S 1 02の N) 、汎用回路である CPU 1 1 0によりパケット処理が行われる（S 106) 。その後、データの種類に応じて、必要な処理が行われる。実施の形態では、電話装置を例にとって説明したが、本実施の形態の技術は、コンピュータや携帯電話など、ストリームデータを送受信する通信装置全般に利用可能である。

I P処理部 1 78、プロトコル検出部 1 76、 UD P処理部 1 74の機能を有する回路を、一つの半導体基板上に搭載してもよい。さらに、セキュリティ処理部 1 72、コーデック処理部 140、 CPU 1 1 0などの回路を搭載してもよい。これにより、通信装置の小型化、軽量化、高速化を図ることができる。

本実施の形態によれば、複数の通信プロトコルによるデータ通信を効率よく処理することができる。また、比較的簡便な回路構成により、高速でリアルタイムな通信を実現することができる。

(第 2の実施の形態）

図 3は、第 2の実施の形態に係る通信装置の一例としてのビデオ電話装置 20 0の全体構成を示す。本実施の形態のビデオ電話装置 200は、図 1に示した第 1の実施の形態のィンターネット電話装置 1 0 0の構成に加えて、入力部の一例としての画像入力部 1 8 0、および出力部の一例としての表示装置 1 9 0を備える。その他の構成については、第 1の実施の形態と同様である。同様の構成には同じ符号を付している。本実施の形態では、画像データも U D Pにより送受信される。

画像入力部 1 8 0は、通話音声とともに相手に送信すべき画像を入力する。画像入力部 1 8 0は、外部のカメラやビデオ再生装置などから画像を入力してもよいし、自身が撮像装置として画像を撮像してもよい。入力された画像は、コーデック処理部 1 4 0に直接送られて符号化され、 U D P処理部 1 7 4により U D P パケットに整形されて、ネットワークインタフェース部 1 3 0によりインターネット 2 0へ送出される。表示装置 1 9 0は、通話音声とともに相手から受信した画像を表示する。ネットワークインタフェース部 1 3 0が受信した U D Pバケツトに含まれる画像データは、 110卩処理部1 7 4、セキュリティ処理部 1 7 2、およびコーデック処理部 1 4 0により処理され、コーデック処理部 1 4 0から表示装置 1 9 0に直接画像データが送られ、表示される。

(第 3の実施の形態）

図 4は、第 3の実施の形態に係る通信装置の一例としてのデジタルカメラ 3 0 0の全体構成を示す。本実施の形態のデジタルカメラ 3 0 0は、電話通信機能を有しており、図 1に示した第 1の実施の形態のインターネット電話装置 1 0 0の構成に加えて、撮像部 1 8 2および表示装置 1 9 0を備える。その他の構成については、第 1の実施の形態と同様である。同様の構成には同じ符号を付している。撮像部 1 8 2は、 C C Dなどの撮像素子と、それを制御する構成を含み、静止画または動画を撮像する。撮像された画像は、コーデック処理部 1 4 0に直接送られて符号化され、 U D P処理部 1 7 4により U D Pパケットに整形されて、ネットワークインタフェース部 1 3 0によりインターネット 2 0へ送出される。表示装置 1 9 0は、通話音声とともに相手から受信した画像を表示する。ネットヮ一クインタフエース部 1 3 0が受信した U D Pバケツトに含まれる画像データは、 U D P処理部 1 7 4、セキュリティ処理部 1 7 2、およびコーデック処理部 1 4 0により処理され、コーデック処理部 1 4 0カゝら表示装置 1 9 0に直接画像データが送られ、表示される。

(第 4の実施の形態）

図 5は、第 4の実施の形態に係る通信装置の一例としてのビデオ電話装置 2 0 0の全体構成を示す。本実施の形態のビデオ電話装置 2 0 0は、図 3に示した第 2の実施の形態のビデオ電話装置 2 0 0に比して、画像入力部 1 8 0および表示装置 1 9 0力コーデック処理部 1 4 0に直接接続されているのではなく、バス 1 0 2に接続されている。その他の構成は図 3と同様であり、同様の構成には同じ符号を付している。

画像入力部 1 8 0が入力した画像は、メモリ 1 2 0に保持され、適宜読み出されて、コーデック処理部 1 4 0により符号化される。符号化された画像データは、 U D P処理部 1 7 4により U D Pバケツトに整形されて、ネットワークインタフエース部 1 3 0によりインターネット 2 0へ送出される。ネットワークインタフエース部 1 3 0が受信した U D Pパケットに含まれる画像データは、 U D P処理部 1 7 4、セキュリティ処理部 1 7 2、およぴコーデック処理部 1 4 0により処理され、バス 1 0 2を介して表示装置 1 9 0に送られ、表示される。

(第 5の実施の形態）

図 6は、第 5の実施の形態に係る通信装置の一例としてのデジタルカメラ 3 0 0の全体構成を示す。本実施の形態のデジタルカメラ 3 0 0は、図 4に示した第 3の実施の形態のデジタルカメラ 3 0 0に比して、撮像部 1 8 2および表示装置 1 9 0力コーデック処理部 1 4 0に直接接続されているのではなく、パス 1 0 2に接続されている。その他の構成は図 4と同様であり、同様の構成には同じ符号を付している。

撮像部 1 8 2が撮像した画像は、メモリ 1 2 0に保持され、適宜読み出されて、コーデック処理部 1 4 0により符号化される。符号化された画像データは、 U D P処理部 1 7 4により U D Pバケツトに整形されて、ネットワークインタフエ一ス部 1 3 0によりインターネット 2 0へ送出される。ネットワークインタフエ一ス部 1 3 0が受信した U D Pバケツトに含まれる画像データは、 U D P処理部 1 7 4、セキュリティ処理部 1 7 2、およびコーデック処理部 1 4 0により処理され、バス 1 0 2を介して表示装置 1 9 0に送られ、表示される。

(第 6の実施の形態）

図 7は、第 6の実施の形態に係る通信装置の一例としてのインターネット電話装置 1 0 0の全体構成を示す。本実施の形態のィンターネット電話装置 1 0 0は、図 1に示した第 1の実施の形態のインターネット電話装置 1 0 0の構成に加えて、 I P判別部 1 8 6およびパケット受信部 1 9 2をさらに備え、プロトコル検出部 1 7 6に代えて U D P判別部 1 8 4を備える。その他の構成は図 1と同様であり、同様の構成には同じ符号を付している。

本実施の形態のインターネット電話装置 1 0 0でも、第 1の実施の形態と同様に、音声信号を含む U D Pパケットを専用のハードウェアで処理することで、処理速度を向上させ、通話音声のリアルタイムな送受信を実現するが、本実施の形態では、さらにリ.アルタイム性を向上させるための技術を提案する。

バケツト受信部 1 9 2は、リアルタイム性を要するデータを含むバケツトを、リアルタイム性を要しないバケツトに優先して受信バッファ 1 9 3に格納するために、リアルタイム性を要しないパケットについては、受信バッファ 1 9 3の空き領域が所定のしきい値を下回ると受信バッファ 1 9 3への格納を禁止し、リアルタイム性を要するパケットのみを格納可能とする。これにより、リアルタイム性を要するバケツトの受信が遅延したり、バケツトが破棄されてデータが欠落する可能性を抑えることができる。

I P判別部 1 8 6は、 I Pパケットのうち、複雑な処理を要する特殊なパケットを判別し、そのバケツ 1、を C P U 1 1 0に送ってソフトウエアにより処理させる一方、通常の I Pバケツトは I P処理部 1 7 8に送ってハードウエアにより処理させる。これにより、 I P処理部 1 7 8のハードウェア規模の増大、複雑化、消費電力の増大を回避しつつ、専用のハードウェアにより通常の I Pパケットを高速に処理することができる。それぞれの技術の詳細については、図を参照しつつ後述する。

図 8は、バケツト受信部 1 9 2の内部構成を示す。制御部 1 9 5は、読出し位置管理部 1 9 6、書込み位置管理部 1 9 7、およびバッファ飽和検出部 1 9 8を含む。本実施の形態の受信バッファ 1 9 3は、 F I F O (First In First Out) メモリにより構成されており、読出し位置管理部 1 9 6は受信バッファ 1 9 3のリ一ドアドレスを保持するレジスタであり、書込み位置管理部 1 9 7は受信パッファ 1 9 3のライトアドレスを保持するレジスタである。バッファ飽和検出部 1

9 8は、読出し位置管理部 1 9 6に保持されたリードアドレスと、書込み位置管理部 1 9 7に保持されたライトァドレスとの差を算出することにより、受信バッファ 1 9 3の使用領域の大きさを検出し、受信バッファ 1 9 3の空き領域を把握する。

バッファ飽和検出部 1 9 8は、受信バッファ 1 9 3への書込みの許否を判定するための複数のしきい値を保持している。しきい値は、パケットの種別に応じて設定されており、受信バッファ 1 9 3の空き領域が、あるバケツト種別に対するしきい値を下回ると、その種別のバケツトの受信バッファ 1 9 3への書込みを禁止し、受信したパケットを破棄する。

本実施の形態では、リアルタイムな処理を要するデータを含むパケットを優先的に受信バッファ 1' 9 3に格納するために、リアルタイムな処理を要するバケツトに対する許否判定のしきい値を、リアルタイムな処理を要しないバケツトに対する許否判定のしきい値よりも低く設定する。たとえば、リアルタイムな処理を要するバケツトに対するしきい値を 0とし、リアルタイムな処理を要しないパケットに対するしきい値をバッファサイズの 5 0 %としたとき、バッファ飽和検出咅 1 9 8は、受信バッファ 1 9 3の空き領域が 5 0 %を下回ると、リアルタイムな処理を要しないパケットに対してはバッファが飽和したと判定して書込みを禁止する一方、リアルタイムな処理を要するバケツトに対しては空き領域があると判定して書込みを許可する。すなわち、受信バッファ 1 9 3の空き領域が 5 0 % 以上のときは、リアルタイムな処理を要するパケットもリアルタイムな処理を要しないバケツトも受信バッファ 1 9 3に格納可能とするが、空き領域が 5 0 %を下回ると、リアルタイムな処理を要するバケツトのみの格納を許可する。

本実施の形態では、リアルタイム性を要する音声信号は、 U D Pを用いて送受信される。そのため、パケット判別部 1 94は、受信したパケットが TCPパケットであるか UD Pパケットであるかを判別し、 TCPパケットであれば、リアルタイムな処理を要しないバケツトに対しての許否判定を採用し、 UDPバケツトであれば、リアルタイムな処理を要するバケツトに対しての許否判定を採用する。バケツト判別部 1 94は、格納を許可されたパケットを受信バッファ 1 93 に格納し、格納を拒否されたパケットを破棄する。

T C Pでは、 FTP (File Transfer Protocol) によりデータフアイルを転送する場合など、一時に大量のパケットを受信する可能性があるが、このとき、受信バッファ 1 93が TCPパケットで飽和し、 UDPパケットを受信できなくなる恐れがある。音声信号を含む UDPパケットは、リアルタイムに再生する必要があるので、 UDPバケツトが優先的に受信バッファ 1 9 3を利用できるようにすることで、パケットの破棄によるデータの欠落を最小限に抑える。 UDPは再送制御を行わないので、いったんパケットが破棄されると再び取得することができないが、 TCPは、再送制御を行うので、欠落したデータを再送により補うことが可能である。

受信バッファ 1 93を 2つ設け、一方にリアルタイム性を要するバケツトを格納し、他方にリアルタイム性を要しないバケツトを格納するように構成してもよいが、上述の技術を用いることにより、 1つの受信バッファ 1 93でリアルタイムな処理を要するバケツトを優先的に受信することができるので、 2つの受信バッファ 1 93を設ける場合に比べて、ハードゥヱァ規模を抑え、消費電力を低減することができる。

リアルタイムな処理を要するデータを含むか否かを示す情報をバケツトのへッダ情報に格納しておき、その情報を参照してパケットの種別を取得し、受信バッファ 1 93への格納の許否を判定してもよい。リアルタイム性の有無だけでなく、他の観点に基づいてしきい値を設定し、受信バッファ 1 93への格納の優先度を決定してもよい。たとえば、重要度が高く、'データの欠落が許されないパケットのしきい値を他のバケツトのしきい値よりも低く設定し、優先的に取り込むようにしてもよい。パケット判別部 1 94がしきい値を保持し、バッファ飽和検出部 1 9 8から受信バッファ 1 9 3の残量を取得して、受信バッファ 1 9 3への書込みの許否を判定してもよい。

図 9は、本実施の形態におけるバケツトの受信手順を示すフローチャートである。ネットワークインタフェース部 1 3 0がパケットを受信すると（S 2 0 0 ) 、バケツト判別部 1 9 4がリアルタイムな処理を要するデータを含むバケツトか否かを判別する（S 2 0 2 ) 。リアルタイム性のパケットであった場合は（S 2 0 2の Y) 、リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ 1 9 3への格納の許否が判定される（S 2 0 4 ) 。リアルタイム性のパケットでなかった場合は（3 2 0 2の1^) 、非リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ 1 9 3への格納の許否が判定される ( S 2 0 6 ) 。そして、受信したバケツトの受信バッファ 1 9 3への格納が許可された場合は（3 2 0 8の丫）、パケットを受信バッファ 1 9 3に格納し（S 2 1 0 ) 、格納が許可されなかった場合は（S 2 0 8のN) 、パケットは破棄される（S 2 1 2 ) 。

図 1 0は、 I P判別部 1 8 6の内部構成を示す。第 1の判別部の一例としての I P判別部 1 8 6は、 I Pへッダ検出部 1 8 7、 I Pへッダ判定部 1 8 8、およぴバケツト出力切替部 1 8 9を含む。 I Pヘッダ検出部 1 8 7は、バケツト受信部 1 9 2から取得したバケツトの I Pヘッダを検出し、 I Pヘッダ判定部 1 8 8 に送る。 I Pヘッダ判定部 1 8 8は、 I Pヘッダなどを参照して、そのパケットが通常の I Pバケツトである力、、複雑な処理を要する特殊な I Pパケットであるかを判定し、判定結果をバケツト出力切替部 1 8 9に通知する。特殊な I Pパケットは、たとえば、オプション付き I Pパケット、フラグメント化された I Pパケットなどであってもよレ、。パケット出力切替部 1 8 9は、 I Pへッダ判定部 1 8 8の判定結果に基づいて、 I Pヘッダ検出部 1 8 7が取得した I Pバケツトの出力先を切り替える。パケット出力切替部 1 8 9は、通常の I Pパケットをハードウエアにより処理させるために第 1の専用回路の一例としての I P処理部 1 7 8へ出力し、複雑な処理を要する特殊な I Pバケツトをソフトウェアにより処理させるためにバスインタフェースを介して汎用回路の一例としての C P U 1 1 0 へ出力する。

フラグメント化された I Pバケツトは、バケツトの順序の管理や、欠落や重複があったときの処理など、通常の I P処理よりも複雑な処理が必要となる。また、オプション付き I Pバケツトは、付されたオプションに応じた処理が必要となる。このような例外的な処理もハードウェアにより実現しょうとすると、回路規模が増大し、コストや消費電力の増大を招く。そのため、通常の I Pパケットのみを処理可能なハードウェアのみを設けることで、コストゃ消費電力を抑える。

I P処理部 1 78により処理されたバケツトは、第 2の判別部の一例としての UDP判別部 1 84に送られる。 UDP判別部 1 84は、受信したパケットが T C Pパケットであるか UD Pパケットであるかを判別し、 UDPパケットは第 2 の専用回路の一例としての UDP処理部 1 74によりハードウヱァ処理する一方、 TCPバケツトは汎用回路の一例としての CPU 1 1 0によりソフトウエア処理する。ここで、 UDP判別部 1 84は、第 1の実施の形態におけるプロトコル検出部 1 76と同様の機能を有するが、本実施の形態では、通信プロトコルのうちトランスポート層の通信方式の種別を判別することを明示するために、この名称を用いている。

このように、本実施の形態のインターネット電話装置 100では、 I P判別部 1 86により I Pバケツトの種別を検出し、バケツトの処理主体を高速かつ適切に選択することができる。また、通話音声などのリアルタイムな処理を要するデータを含む通常の I Pバケツトは専用回路である I P処理部 1 78により高速に処理を行いつつ、複雑な処理を要する特殊な I Pバケツトは C PU 1 1 0によりソフトウェア処理を行うことにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えることができる。

図 1 1は、本実施の形態におけるパケット処理手順を示すフローチャートである。ネットワークインタフェース部 1 30がパケットを受信すると（S 300) 、 I P判別部 1 86が通常の I Pバケツトか否かを判別する（S 302) 。通常の I Pバケツトであった場合は（S 302の Y) 、専用回路である I P処理部 1 7 8により I Pのパケット処理が行われる（S 304) 。フラグメント化された I Pパケットなど、複雑な処理を要する特殊な I Pパケットであった場合は（S 3 02のN) 、汎用回路である CPU1 1 0に送られ、ソフトウェアによりバケツト処理が行われる（S 3 10) 。 110卩判別部1 84は、 I P処理部 1 78により処理されたパケットが UDPパケットであるか否かを判別する（S 306) 。 UDPパケットであった場合は（3306の）、専用回路である UD P処理部 1 74により UD Pのバケツト処理が行われる。 T C Pパケットであった場合は (S 306の N) 、汎用回路である CPU 1 10に送られ、ソフトウエアによりバケツト処理が行われる（S 3 1 0) 。

本実施の形態によっても、複数の通信プロトコルによるデータ通信を効率よく処理することができる。また、比較的簡便な回路構成により、高速でリアルタイムな通信を実現することができる。

(第 7の実施の形態）

図 1 2は、本発明の第 7の実施の形態に係る通信装置の一例としてのインターネット電話装置 1 00の全体構成を示す。インターネット電話装置 1 00は、ィンターネット 20を介して、他のインターネット電話装置 100との間で通話を行うための装置である。インターネット電話装置 100は、主に、ソフトウェア処理を実行するための汎用回路である C PU 1 1 0、プログラムエリアまたはヮークエリアとして利用されるメモリ 1 20、インターネット 20を介してバケツトを送受信するネットワークインタフェース部 1 30、音声信号を入力するマイク 1 50、音声信号を出力するスピーカ 1 60、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部 140、通信データの暗号化処理または復号処理などを行うセキュリティ処理部 1 72、 UDPバケツトを処理するための専用回路である UDP処理部 1 74、通信プロトコルに応じた各種処理を行うプロトコルエンジン 50、およびこれらの構成を電気的に接続するバス 102を備える。

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

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

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

ネットワークインタフェース部 1 30が受信したバケツトは、プロトコルェンジン 50に送られる。プロトコルエンジン 50は、パケットが自装置に割り当てられた I Pアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみを通し、その他のパケットを破棄する。また、パケットに付されたへッダ情報を参照してプロトコルの種別を検出し、パケットが TCPにより送られたパケットであった場合は、そのパケットのデータをバス 102上に送り、 CPU 1 10によりソフトウェア処理させる。パケットが UDPのパケットであった場合は、そのパケットのデータを UD P処理部 1 74に送り、 UDPパケットの処理のために専用に設けられた回路により処理させる。

110?処理部1 74は、 UD Pパケットを処理するための専用回路であり、 U D Pパケットを受け取って、そのヘッダを解析し、必要な処理を実行する。セキユリティ処理部 1 7 2は、データに対して暗号化処理などのセキュリティ対策が施されていた場合に、暗号を復号するなどの処理を行う。復号されたデータは、コーデック処理部 1 4 0に送られる。コーデック処理部 1 4 0は、圧縮符号化されていた通話音声信号を復号し、スピーカ 1 6 0に出力する。

このように、本実施の形態のインターネット電話装置 1 0 0では、正確性よりもリアルタイム性が重視され、通話中、常時処理が必要となる通話音声データは、

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

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

図 1 3は、プロトコルエンジン 5 0の内部構成を示す。 1 ?制御部2 0 2は、ネットワークインタフェース部 1 30が自装置の I Pァドレスに宛てた ARP

(Address Resolution Protocol) パケットを受信したときに、自動的に自装置のデータリンク層のアドレス（MACアドレス）情報をセットして応答パケットを生成し、 ARPパケットの送信元へ送信する。従来は、 ARPパケットも CPU 1 1 0によりソフトウエア処理していたが、本実施の形態では、 ARP制御部 2 02が CPU 1 10を介さずに自動応答することにより、 CPU 1 1 0の負担を大幅に軽減するとともに、割り込みによるタスクスィツチを減少させることができる。

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

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

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

チェックサム生成部 2 8 0は、送信パケットのチェックサムを算出する。 U D Pパケットは、送信キューに投入する時点でパケットサイズが確定しているので、チェックサム生成部 2 8 0により予めデータ部のチェックサムを算出して保持しておき、バケツト送出時にヘッダ合成部 2 5 0によりヘッダにチェックサム値をセットする。 T C Pパケットは、パケット送出時にパケットサイズが確定するので、予めデータ部のチェックサム値を算出しておくことはできないが、所定の区間ごとにチェックサム累積値を算出して保持しておくことで、パケット送出時のチェックサム算出処理を簡略化することができる。 T C Pバケツトのバケツトサィズを、チヱックサム累積値の算出区間の整数倍に限定すれば、データ部のチヱックサム値はデータ部の区間前後のチェックサム累積値を減算するだけで得られる。

第 1送信バッファ 2 7 0は、送信バケツトのうち、送信先の MA Cアドレスが未解決のものを格納する。第 2送信バッファ 2 7 2は、送信パケットのうち、送信先の MA Cァドレスが分かっているものを格納する。 A R Pインタフェース 2 6 0は、第 1送信バッファ 2 7 0に格納された、送信先の MA Cアドレスが不明なパケットについて、その MACアドレスを解決すべく、 ARPパケットを生成してネットワークにプロ一ドキャストする。 ARPパケットの応答が戻ってくるまでの間はそのバケツトを送出できないので、ァドレス解決が不要なバケツトのキューとは別に第 1送信バッファ 270を設けて待機させておき、その間は第 2 送信バッファ 272にて待機中のァドレス解決が不要な送信バケツトを送出する。 ARPの応答が戻ってくると、解決された MACァドレスをセットして第 1送信バッファ 270のパケットを送出し、次に待機中のパケットについて ARPパケットを送出する。そして、応答が戻るまでの間は再び第 2送信バッファ 272のパケットを送出する。これにより、全体の送信待ち時間を減少させ、効率良くパケットを送出することができる。また、送信先の MACアドレスが未解決のパケットであっても、第 1送信バッファ 270に投入しておけば自動的に MACァドレスを解決しつつバケツトを送出してくれるので、 CPU1 1 0側の処理が単純になり、処理負荷を軽減することができる。

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

ホストテーブル 204は、他装置の MACァドレスおよび I Pァドレスを対応付けて保持する。図 14は、ホストテーブル 204の内部データの例を示す。ホストテーブル 204には、ホスト I D欄 205、 MACァドレス欄 206、および I Pアドレス欄 207が設けられている。ホストテーブル 204の内容は、 C PU 1 10が予め頻繁に通信を行う可能性のあるホスト装置の情報を登録してもよいし、通信中に C PU 1 10などが登録してもよい。 MACアドレスが不明なホスト装置であっても、まず I Pアドレスのみを格納しておき、 A R Pインタフヱース 2 6 0により A R Pバケツトを送出し、その応答を取得したときに MA C アドレスを登録してもよレ、。ホストテーブル 2 0 4を設けてあるので、 C P U 1 1 0は、パケットの送信先を指定するときに、ホスト I D、 MA Cアドレス、 I Pアドレスのいずれを用いて指定してもよい。ヘッダ合成部 2 5 0は、ホストテ一ブル 2 0 4を参照して、へッダ生成に必要な情報を取得することができる。ホストインタフェース部 2 9 0は、プロトコノレエンジン 5 0の構成要素と C P U 1 1 0との間でデータや指示の入出力を制御する。

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

図 1 6は、書き込み制御部 2 2 0によりパケットのデータが整形される様子を示す。通常の I Pパケットは、先頭の MA Cヘッダが 1 4バイトを占めているが、 3 2ビットワードでは 3 . 5ワードと半端になるため、以降のデータが 1 6ビットずつずれた形となる。このまま受信バッファ 2 3 0に格納すると、アクセスするときに不便であるから、本実施の形態では、 MA Cヘッダが 3ワードとなるようにデータを整形してから受信バッファ 2 3 0に格納する。すなわち、 MA Cへッダを 1 6 ビット分減らせばよい。 MA Cヘッダのうち、宛先 MA Cアドレスは、自装置の MA Cァドレスと同じであり、既にバケツトを受信しているので不要である。 MA Cアドレスは 4 8ビットであるから、これを破棄すると、 3 2ビット分余裕が残る。アプリケーションによっては、このパケットがュニキャスト、マルチキャスト、ブロードキャストのいずれで送信されたのかという情報が必要な場合があるので、これをフラグとして宛先 MA Cァドレスの代わりに格納する。このフラグは 2ビットで十分であるから、まだ 3 0ビット分余裕がある。そこで、パケット種別を示すフラグや、次のバケツトの格納位置を示すァドレス情報などを管理情報として格納する。以上により、 MA Cヘッダが 3ワードにおさまるので、以降のデータをワード単位で整列させることができ、アクセスが容易になる。図 1 5に戻り、受信したバケツトを書き込む手順と読み出す手順について説明する。管理情報生成部 2 2 2は、上述した管理情報を生成する。管理情報として、たとえば、このパケットがュニキャスト、マノレチキャスト、ブロードキャストのいずれで送信されたのかを示す送信種別情報、このパケットが T C Pパケットか U D Pバケツトカ \ フラグメント化された I Pバケツトまたはォプション付きの I Pパケットなど複雑な処理を要する特殊な I Pバケツトであるか否か、などを示すバケツト種別情報、次のバケツトの格納位置を示すァドレス情報、などを生成してもよい。次バケツトのァドレス情報を格納する場合は、自バケツトのデ一タの格納が終了してから、書き込みアドレス生成部 2 2 6から次パケットのアドレス情報を取得するので、管理情報の受信バッファ 2 3 0への書き込みはバケツトのデータの格納が完了した後になる。これらの管理情報は、全体で 1ワードとなるように整形され、セレクタ 2 2 9を介して受信バッファ 2 3 0に格納される。データ入れ替え部 2 2 4は、受信したパケットのデータのうち、 MA Cァドレスを除いたデータを 3 2ビットワードで整列させるために、上位 1 6ビットと下位 1 6ビットを入れ替える。データ入れ替え部 2 2 4の出力のうち、上位 1 6ビットを遅延回路 2 2 8により 1クロック遅延させて合成することにより、 1 6ビットずつずれていたデータを整列させることができる。整形されたデータは、セレクタ 2 2 9を介して受信バッファ 2 3 0に格納される。

書き込みアドレス生成部 2 2 6は、まず、書き込み位置の先頭にポインタを移動するが、 1ワード目の管理情報は最後に格納されるので、ポインタをインクリメントし、 MA Cヘッダのうち宛先 MA Cァドレスを除いた 2ヮード、 I Pへッダ 5ワード、 I Pデータを、ポインタをインクリメントしつつ次々に書き込んでいく。データ部分の書き込みが終了すると、次の書き込み開始位置を管理情報生成部 2 2 2に通知し、書き込み位置の先頭にポインタを戻して、管理情報を書き込む。

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

受信バッファの読み出しァドレスは上位ァドレスと下位ァドレスから構成される。 C P U 1 1 0は、受信パッファ 2 3 0に格納されたパケットのへッダ情報にアクセスするときは、上位ァドレスと下位ァドレスの双方を指定する。上位アドレスについては、どのパケットのどのヘッダにアクセスしたいかを読み出しアドレス生成部 2 4 2に指定すれば、読み出しァドレス生成部 2 4 2が自動的に上位アドレスを生成してポインタを移動する。下位アドレスについては、 C P U 1 1 0が出力する下位ァドレスをそのまま受信バッファの下位ァドレスとし、 C P U 1 10が自由に読み出せるようにする。 CPU1 1 0は、バケツトのデータ部分にアクセスするときは、読み出しァドレス生成部 242に、どのパケットのデータにアクセスしたいかを指定すればよレ、。読み出しアドレス生成部 242は、自動的に上位ァドレスと下位ァドレスを生成してポィンタを移動し、データを次々に読み出す。

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

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

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

(第 8の実施の形態）

図 1 7は、本発明の第 8の実施の形態に係る通信装置の一例としてのインターネット電話装置 1 00の全体構成を示す。インターネット電話装置 100は、ィンターネット 20を介して、他のインターネット電話装置 1 00との間で通話を行うための装置である。インターネット電話装置 100は、主に、ソフトゥヱァ処理を実行するための汎用回路である CPU 1 1 0、プログラムエリアまたはヮークエリアとして利用されるメモリ 1 20、ィンターネット 20を介してバケツトを送受信するネットワークインタフヱース部 1 30、音声信号を入力するマイク 1 50、音声信号を出力するスピーカ 1 60、音声信号の圧縮符号化処理およぴ復号処理を行うコーデック処理部 140、 I Pによる通信のための各種処理を行う I P処理部 1 78、 TCPまたは UDPによる通信のための各種処理を行う TCP/UDP処理部 400、およびこれらの構成を電気的に接続するバス 10 2を備える。

本実施の形態のインターネット電話装置 100では、音声信号などのデータを TCP/ I Pにより送信するために TC Pバケツトを生成するにあたって、送信するデータが入力されたときに、予め所定長ごとにチェックサムの累積値を算出して保持しておく。そして、 TCPパケットのサイズが確定したときに、その累積値を利用して、そのパケットのチェックサムを算出する。これにより、従来の、送信サイズが確定してからデータを読み出してチェックサムを算出する方式に比ベて、チヱックサムの算出に要する時間を大幅に短縮することができる。この点については、図 1 8以降の説明部分で詳述する。

まず、インターネット電話装置 1 00がパケットを受信したときの動作の概要について説明する。ネットワークインタフェース部 1 30が受信したバケツトは、 I P処理部 1 78に送られる。 I P処理部 1 78は、パケットが自装置に割り当てられた I Pアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみを TC P/UD P処理部 400に送る。 TCPZUDP処理部 400 は、ヘッダ情報などからパケットが TCPパケットであるか UDPパケットであるかを判断し、それぞれのパケットに対して必要な処理を実行する。受信したパケットが音声信号であった場合、そのデータはコーデック処理部 140に送られる。コーデック処理部 140は、圧縮符号化されていた通話音声信号を復号し、スピーカ 1 60に出力する。

つづいて、インターネット電話装置 100が音声信号を含むデータを送信するときの動作の概要について説明する。マイク 1 50から入力された音声信号は、コーデック処理部 140に送られ、符号化される。符号化された信号は、必要であれば、図示しないセキュリティ処理部により暗号化された後、 TCP/UDP 処理部 400に送られバケツトイヒされる。生成された TC Pまたは UDPバケツトは、ネットワークインタフェース部 1 30を介して、ィンターネット 20に送出される。

I P処理部 1 78、 TCPZUDP処理部 400、およびコーデック処理部 1 40の機能は、ハードウエア的には CPU 1 10やメモリ 1 20などの構成で実現でき、ソフトウエア的にはプロトコル処理機能またはコーデック処理機能のあるプログラムなどによって実現できるが、本図ではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウェアの組合せによっていろいろなかたちで実現できる。これらの構成を、専用の回路により実現してもよい。本図では、 I P処理部 1 78、 TC ?/110 処理部400、およぴコーデック処理部 140は、それぞれバス 1 0

2に接続されているが、これらを専用の回路により実現する場合、それぞれの回路を専用バスにより接続してもよい。 .

図 1 8は、図 1 7の TCP/UDP処理部 400の内部構成のうち、本実施の形態において特徴的なパケット生成機能を実現するための構成を示す。 TCP/ UDP処理部 400は、 CPU 1 1 0などにより用意された送信データの入力を受け付けるデータ入力部 410、送信データのチェックサムの累積値を算出するチックサム算出部 420、送信データを保持するデータ格納部 430、送信デ一タの所定長の区間ごとにチェックサムの累積値を保持するチェックサム格納部 432、データ格納部 430に残っている未送信のデータのサイズを格納するデータサイズ格納部 434、 TCPバケツトの送信サイズを制御する送信サイズ制御部 440、 TCPおよび UDPパケットのヘッダ情報を生成する、第 2算出部の一例としてのヘッダ生成部 450、および TCPおよび UDPバケツトを出力するバケツト出力部 460を含む。

まず、 TCPパケットが生成される手順について説明する。 CPU 1 1 0などからデータ入力部 4 10を介して入力された送信データは、データ格納部 430 に格納されるとともに、チェックサム算出部 420に送られる。チェックサム算出部 420は、入力されたデータの先頭からのチェックサムの累積値を算出し、所定長ごとに、算出された累積値を出力してチェックサム格納部 432に保持しておく。チェックサムは、 1 6ビット（1ワード）ごとに一まとめにしたデータを順次加算することにより算出されるが、ここで、加算とは 1の補数加算を指し、加算結果が 1 6ビットに収まらずに桁あふれした場合は、加算結果に 1を加える。

1 9は、データ格納部 430およびチェックサム格納部 432の内部データの例を示す。本図では、 2 8 8ヮードの送信データがデータ格納部 4 3 0に格納されている。チェックサム格納部 4 3 2には、 6 4ワードごとにチェックサムの累積値が格納されている。たとえば、送信データの先頭から 6 4ワード目までのチェックサム累積値は 1 6進数で 3 2 1 0であり、先頭から 1 2 8ワード目までのチェックサム累積値は 1 6進数で 5 3 3 2である。

図 1 8に戻り、 T C Pパケットの生成手順の説明を続ける。送信サイズ制御部 4 4 0は、受信側のバッファの状況や、バケツト消失等のネットワークの状況を考慮して、次に送信すべき T C Pパケットのサイズを決定する。このとき、 T C Pバケツトのサイズは、チェックサム累積値を記録した区間の単位長の整数倍に制限される。すなわち、本実施の形態では、 T C Pパケットのサイズは、 6 4ヮ一ドの整数倍に制限される。この理由については後で詳述する。

へッダ生成部 4 5 0は、送信サイズ制御部 4 4 0から、次に送信すベき T C P バケツトのサイズを取得すると、そのサイズをもとに送信すべきデータの区間を決定し、その区間の直前の区間の最後のチヱックサム累積値と、その区間の最後のチェックサム累積値とを、チェックサム格納部 4 3 2から読み出す。そして、それらの差を算出し、当該区間のチェックサム値を得る。 1の捕数演算においては、負数を絶対値のビット反転で表現し、 a— b = a + ' b (ただし、 ~ bは b のビット反転を表す）として減算を行う。ヘッダ生成部 4 5 0は、このチェックサム値をヘッダ情報に格納し、その他のヘッダ情報とともに出力する。パケット出力部 4 6 0は、ヘッダ生成部 4 5 0から取得したヘッダ情報を出力した後、データ格納部 4 3 0から送信サイズ分のデータを読み出して出力する。

図 1 9の例において、たとえば、最初に送信する T C Pパケットのサイズが 6 4ワードであったとすると、そのパケットのチェックサム値は、 3 2 1 O hである。つづいて、 1 4 4ワードのデータ長のパケットを送信可能であったとする。このとき、送信サイズ制御部 4 4 0は、チヱックサム累積値を記録した区間の単位長の整数倍で、かつ、送信可能なパケットのサイズを超えないサイズを、次に送信する T C Pパケットのサイズとする。ここでは、 1 4 4を超えない最大の 6 4の倍数、すなわち 1 2 8ワードとなる。次に送信すべきデータ 4 3 0 bおよび 4 3 0 cのチェックサム値は、その区間の最後のチェックサム累積値である 7 6

5 4 hから、その区間の直前の区間 4 3 0 aの最後のチェックサム累積値である 3 2 1 0 hを減じた値、すなわち 4 4 4 4 hとなる。

データを送信すると、データサイズ格納部 4 3 4に保持している未送信データサイズの値から、送信したデータのサイズを減じる。送信サイズ制御部 4 4 0が決定した T C Pバケツトのデータサイズが、未送信データのサイズよりも大きい場合は、データサイズ格納部 4 3 4に保持されたデータサイズがヘッダ生成部 4

5 0に出力される。このとき、ヘッダ-生成部 4 5 0は、データ全体のチェックサム累積値から、直前に送信'したデータ区間の最後のチェックサム累積値を減じて、送信パケットのチェックサム値を得る。

このように、予め所定長ごとにチェックサム累積値を算出して保持しておき、その累積値を利用してバケツトのチェックサムを算出するので、チェックサムの算出に要する時間を大幅に短縮することができ、バケツトサイズが確定してからパケットを送出するまでの遅延時間を削減することができる。これは、通話音声などリアルタイム性が要求されるデータを送受信する際に、とくに有効である。チェックサム累積値を記録する単位区間のサイズは、送信側および受信側の装置の性能や、ネットワークの性能などを考慮して設計すればよい。ネットワーク上の通信がある程度の不確実性を伴うのは不可避であり、また、必要以上に小さいサイズのバケツトで通信を行うことは非効率的であるから、送信するバケツトのサイズを、たとえば 6 4ワードの整数倍に制限したとしても支障はない。 6 4 ヮードごとにチェックサム累積値を格納する場合、チェックサム格納部 4 3 2の容量は、全てのデータについてチェックサム累積値を保持しておく場合に比べて、

6 4分の 1ですむ。また、パケットのチェックサムを算出するためにメモリから読み出すデータは、バケツトデータの前後のチヱックサム累積値に対応する 2ヮ —ドですむため、データ格納部 4 3 0とチェックサム格納部 4 3 2とを物理的に分割された 2種類のメモリにより実現する必要はなく、 1つにまとめてもよレ、。すなわち、メモリに対する制約が小さい。

上述の方法は、ソフトウェアによっても実現できるが、より高速化を図るために TCPおよび UDPのための処理を専用のハードウエアにより実現する場合に、本方法を適用すれば、メモリアクセスのオーバーヘッドが改善され、より有効に処理の高速化に寄与することができる。

次に、 UD Pパケットを生成する手順について説明する。 CPU1 10など力、らデータ入力部 4 1 0を介して入力されたデータは、データ格納部 430に格納されるとともに、チェックサム算出部 420に送られる。 UDPの場合は、送信するバケツトのサイズが予め指定されるので、所定の区間ごとにチェックサム累積値を保持しておく必要はなく、バケツト全体のチェックサムを算出してチエツクサム格納部 432に保持する。ヘッダ生成部 450は、次に送信すべき UDP バケツトのチェックサム値をチヱックサム格納部 432から読み出してヘッダ情報に格納し、その他のヘッダ情報とともに出力する。パケット出力部 460は、ヘッダ生成部 450から取得したヘッダ情報を出力した後、データ格納部 430 からデータを読み出して出力する。

このように、本実施の形態によれば、 TC Pと UD Pのパケット生成処理のための構成を別個に設ける必要はなく、同じ構成により双方のパケットを生成して送信することができる。

TCPによりデータを送信する場合であっても、最初に送信すべきバケツトのサイズがデータサイズよりも大きい場合には、一度に全てのデータを送信可能であるから、減算によりチェックサム値を算出する必要はなく、データ全体のチェックサム値がパケットのチェックサム値となる。

図 20は、本実施の形態におけるチェックサム算出方法の手順を示すフローチヤートである。 CPU 1 1 0などからデータ入力部 41 0を介して送信データが入力されると（S 400) 、チヱックサム算出部 420は、入力されたデータの先頭からのチェックサムの累積値を算出し、所定長ごとに、算出された累積値を出力してチェックサム格納部 432に保持する（S 402) 。ヘッダ生成部 45 0は、送信サイズ制御部 440から、次に送信すべき TCPパケットのサイズを取得すると（S 404) 、そのサイズをもとに送信すべきデータの区間を決定し、その区間の直前のデータまでのチェックサム累積値と、その区間の最後のデータまでのチェックサム累積値とを、チェックサム格納部 432から読み出す（S 4 06) 。そして、それらの差を算出し、当該区間のチェックサム値を得る（S 4 08) 。パケット出力部 460は、ヘッダ生成部 450から取得したチヱックサムを含むヘッダ情報を送信し（S 41 0) 、さらにデータ格納部 430から送信サイズ分のデータを読み出して送信する（S 412) 。送信データが残っている場合は（3414の1^) 、 S 404に戻り、パケットを生成して送信する手順を繰り返す。全てのデータを送信すると（341 4の丫）、処理を終了する。

実施の形態では、インターネット電話装置を例にとって説明したが、本実施の形態の技術は、コンピュータ、携帯電話、デジタルカメラ、ビデオ装置など、データを送受信する通信装置全般に利用可能である。また、一連のデータ列について、先頭からのチェックサム累積値を複数箇所に埋め込む技術は、通信に限らず、データを記録する装置全般に利用可能である。

TCPZUDP処理部 400を実現するための回路およびメモリを、一つの半導体基板上に搭載してもよい。さらに、 I P処理部 1 78、コーデック処理部 1 40、 CPU 1 1 0、セキュリティ処理部などの回路を搭載してもよい。これにより、通信装置の小型化、軽量化、高速化を図ることができる。

本実施の形態によれば、データのチェックサムの算出に要する時間を短縮する技術を提供することができる。また、高速なチェックサム算出に要するハードウエアの規模を削減する技術を提供することができる。

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

上述の説明では、主に電話装置を例にとって説明したが、実施の形態において説明した技術は、コンピュータや携帯電話など、ストリームデータを送受信する通信装置全般に利用可能である。産業上の利用可能性 . 以上のように、本発明は、通信装置、電話装置、パケット処理装置などに利用可能である。

Claims

請求の範囲

1 . ネットワークを介して送られたパケットを受信する受信部と、

受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式により送られたパケットであったとき、そのパケットをソフトウエアにより処理するための汎用回路と、

受信したバケツトが、装置間での接続の確立を要しない第 2の通信方式により送られたバケツトであったとき、そのバケツトを処理するための専用回路と、を備えることを特徴とする通信装置。

2 . ネットワークを介して送られたバケツトを受信する受信部と、

受信したパケットが、送信パケットの到着確認を行う第 1の通信方式により送られたパケットであったとき、そのバケツトをソフトウエアにより処理するための汎用回路と、

受信したバケツトが、送信バケツトの到着確認を行わない第 2の通信方式により送られたバケツトであったとき、そのバケツトを処理するための専用回路と、を備えることを特徴とする通信装置。

3 . ネットワークを介してバケツトを送信する送信部をさらに備え、

送信するパケットが、前記第 1の通信方式により送られるとき、そのパケットを前記汎用回路により処理し、

送信するパケットが、前記第 2の通信方式により送られるとき、そのパケットを前記専用回路により処理することを特徴とする請求の範囲 1または 2に記載の通信装置。

4 . 受信したパケットが、どの通信方式により送られたかを検出する検出部をさらに備えることを特徴とする請求の範囲 1カゝら 3のいずれかに記載の通信装置 _c

5 . 前記検出部により、前記第 1の通信方式により送られたパケットが検出されたとき、前記検出部は、そのパケットを、前記汎用回路を介さずに、直接前記専用回路へ送ることを特徴とする請求の範囲 4に記載の通信装置。

6 . パケットを構成するデータを暗号化または復号化するセキュリティ処理部をさらに備えることを特徴とする請求の範囲 1から 5のいずれかに記載の通信装

7 . ネットワークを介して送られたバケツトを受信する受信部と、

受信したバケツトがフラグメント化されたバケツトであったとき、そのバケツトをソフトウエアにより処理するために汎用回路へ送り、受信したバケツトがフラグメント化されていないバケツトであったとき、そのバケツトをハードウエアにより処理するために第 1の専用回路へ送る第 1の判別部と、

を備えることを特徴とする通信装置。

8 . 前記第 1の専用回路により処理したパケットが、データの送受信に先立つて装置間で接続を確立することを要する第 1の通信方式により送られたバケツトであったとき、そのパケットを前記汎用回路に送り、前記第 1の専用回路により処理したバケツトが、装置間での接続の確立を要しない第 2の通信方式により送られたパケットであったとき、そのパケットをハードウェアにより処理するための第 2の専用回路へ送る第 2の判別部をさらに備えることを特徴とする請求の範囲 7に記載の通信装置。

9 . ネットワークを介して受信したパケットが、リアルタイムな処理を要するデータを含むパケットであるか否かを判別する判別部と、

前記パケットを一時的に保持するバッファと、

前記バッファへの前記パケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記リアルタイムな処理を要するデータを含むバケツトの前記バッファへの格納を許可する一方、リアルタイムな処理を要するデータを含まないバケツトの前記バッファへの格納を禁止することを特徴とする通信装置。

1 0 . ネットワークを介して受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式により送られたパケットである力、装置間での接続の確立を要しない第 2の通信方式により送られたパケットであるかを判別する判別部と、

前記バケツトを一時的に保持するバッファと、

前記バッファへの前記パケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記第 2の通信方式により送られたパケットの前記バッファへの格納を許可する一方、前記第 1の通信方式により送られたバケツトの前記バッファへの格納を禁止することを特徴とする通信装置。

1 1 . ネットワークを介して受信したバケツトの種別を判別する判別部と、前記バケツトを一時的に保持するバッファと、

前記バッファへのパケットの格納を制御する制御部と、を備え、

前記制御部は、前記バッファへのバケツトの格納の許否を判定するためのしきい値をパケットの種別に応じて複数保持し、前記バッファの空き領域がしきい値を下回ったバケツト種別のバケツトの前記バッファへの格納を禁止することを特徴とする通信装置。

1 2 . リアルタイムな処理を要するパケットの種別のしきい値を、リアルタイムな処理を要しないバケツトの種別のしきい値よりも低く設定したことを特徴とする請求の範囲 1 1に記載の通信装置。

1 3 . 音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、

他の装置から受信した音声を出力する出力部と、を備え、

前記通信部は、

ネットワークを介して送られたバケツトを受信する受信部と、

受信したバケツトの通信方式を検出する検出部と、

前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であったとき、そのパケットをソフトウエアにより処理するための汎用回路と、

前記通信方式が、装置間での接続の確立を要しない第 2の通信方式であつたとき、そのパケットを処理するための専用回路と、を含み、

前記音声を前記第 2の通信方式により送受信することを特徴とする電話装置。

1 4 . 画像および音声を入力する入力部と、

前記入力部により入力された画像および音声を他の装置へ送信し、他の装置から画像および音声を受信する通信部と、

他の装置から受信した画像および音声を出力する出力部と、を備え、前記通信部は、

受信したパケットの通信方式を検出する検出部と、

前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であったとき、そのバケツトをソフトウエアにより処理するための汎用回路と、

前記画像おょぴ音声を前記第 2の通信方式により送受信することを特徴とするビデオ電話装置。

1 5 . 画像を撮像する撮像部と、

前記撮像部により撮像された画像を他の装置へ送信し、他の装置から画像を受信する通信部と、を備え、

前記通信部は、

受信したパケットの通信方式を検出する検出部と、

前記通信方式が、データの送受信に先立って装置間で接続を確立することを要する第 1の通信方式であったとき、そのバケツトをソフトウエアにより処理するための汎用回路と、，

前記画像を前記第 2の通信方式により送受信することを特徴とする撮像装置。

1 6 . パケットを受信したときに、そのパケットの通信方式を検出する工程と, 前記通信方式に応じて、そのパケットを処理すべき回路にパケットのデータを送る工程と、

を含むことを特徴とする通信方法。

1 7 . 前記検出する工程は、パケットのヘッダを解析することにより、フラグメント化されたパケットであるか、フラグメント化されていないパケットであるかを検出し、

前記データを送る工程は、前記フラグメント化されたバケツトを、ソフトゥェァ処理するための汎用回路に送り、前記フラグメント化されていないバケツトを、そのバケツトを処理するための専用回路に送ることを特徴とする請求の範囲 1 6 に記載の通信方法。

1 8 . 前記検出する工程は、パケットのヘッダを解析することにより、データの送受信に先立って装置間での接続の確立を要する第 1の通信方式によるバケツトであるか、装置間での接続の確立を要しない第 2の通信方式によるバケツトであるかを検出し、

前記データを送る工程は、前記第 1の通信方式によるパケットを、ソフトゥェァ処理するための汎用回路に送り、前記第 2の通信方式によるパケットを、そのパケットを処理するための専用回路に送ることを特徵とする請求の範囲 1 6に記載の通信方法。

1 9 . リアルタイム性を要しないデータは、前記第 1の通信方式により送受信する一方、リアルタイム性を要するストリームデータは、前記第 2の通信方式により送受信することを特徴とする請求の範囲 1 6から 1 8のいずれかに記載の通信方法。

2 0 . パケットを受信したときに、そのパケットの種別を検出する工程と、前記種別ごとに設定された条件に基づいて、バケツトを一時的に保持するバッファへのそのバケツトの格納の許否を判断する工程と、

格納が許可されたときに、そのバケツトを前記バッファへ格納する工程と、格納が許可されなかったときに、そのパケットを破棄する工程と、

を含むことを特徴とする通信方法。

2 1 . ネットワークを介して取得したパケットを一時的に保持するバッファと、前記バケツトの前記バッファへの格納を制御する書き込み制御部と、を備え、前記書き込み制御部は、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納することを特徴とするバケツト処理装置。

2 2 . 前記書き込み制御部は、前記送信先アドレス情報に代えて、そのバケツトがュ二キャスト、マルチキャスト、ブロードキャストのいずれで送信されたかを示す送信種別情報を含む管理情報を格納することを特徴とする請求の範囲 2 1 に記載のバケツト処理装置。

2 3 . 前記管理情報は、パケットの種別を示すパケット種別情報、および次のパケットの格納位置を示すァドレス情報をさらに含むことを特徴とする請求の範囲 2 2に記載のパケット処理装置。

2 4 . 前記書き込み制御部は、前記管理情報を 1ヮードにおさめ、後続のデータをヮ一ド単位で整形して前記バッファに格納することを特徴とする請求の範囲 2 2または 2 3に記載のバケツト処理装置。

2 5 . ネットワークを介して取得したパケットを一時的に保持するバッファと、前記バケツトの前記バッファからの読み出しを制御する読み出し制御部と、を備え、

前記パケットのへッダ部分にはそれぞれ独立したレジスタを割り当ててランダムアクセスを可能とする一方、前記バケツトのデータ部分はアクセスポートレジスタを介して読み出しを行うように構成したことを特徴とするパケット処理装置 _c

2 6 . 前記読み出し制御部は、読み出すパケットの種別に応じて、前記ァクセスポートレジスタが読み出しを開始する位置を設定することを特徴とする請求の範囲 2 5に記載のパケット処理装置。

2 7 . 前記パケットを前記バッファに格納する前に、そのヘッダ情報を解析することにより不要なパケットを破棄するへッダ解析部と、 . 前記バケツトを前記バッファに格納する前に、そのチヱックサムを算出して、へッダに格納されたチェックサム値と一致するか否かを検証するチェックサム算出部と、をさらに備えることを特徴とする請求の範囲 2 5または 2 6に記載のパケット処理装置。

2 8 . 音声を入力する入力部と、前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、

他の装置から受信した音声を出力する出力部と、を備え、

前記通信部は、

受信したバケツトを処理するバケツト処理部と、を含み、

前記バケツト処理部は、

前記バケツトを一時的に保持するバッファと、

前記パケットの前記バッファへの格納を制御する書き込み制御部と、を含み、前記書き込み制御部は、前記パケットのへッダ情報のうち、送信先アドレス情報を破棄して前記受信バッファに格納することを特徴とする電話装置。

2 9 . 音声を入力する入力部と、

前記入力部により入力された音声を他の装置へ送信し、他の装置から音声を受信する通信部と、

他の装置から受信した音声を出力する出力部と、を備え、

前記通信部ほ、

受信したバケツトを処理するバケツト処理部と、を含み、

前記パケット処理部は、

前記パケットを一時的に保持するバッファと、

前記バケツトの前記バッファからの読み出しを制御する読み出し制御部と、を含み、

前記パケットのへッダ部分にはそれぞれ独立したレジスタを割り当ててランダムアクセスを可能とする一方、前記パケットのデータ部分はアクセスポートレジスタを介して読み出しを行うように構成したことを特徴とする電話装置。

3 0 . パケットを受信したときに、そのパケットをバッファに一時的に格納する工程と、

前記格納する工程に先立って、前記パケットのヘッダ情報のうち、送信先アドレス情報を破棄する工程と、

を含むことを特徴とするバケツト処理方法。

3 1 . 所定のタイミングでデータ長が確定するデータプロックにチェックサムを与えるために、前記タイミングに先立って、前記データブロックを含むデータュニットの所定長ごとに、前記データュニットの先頭からのチェックサムの累積値を算出して記憶装置に保持することを特徴とするチェックサム算出方法。

3 2 . 前記データブロックのデータ長が確定したあと、そのデータブロックの前後の前記累積値を前記記憶装置から読み出して、そのデータプロックのチェックサムを算出することを特徴とする請求の範囲 3 1に記載のチェックサム算出方法。

3 3 . 前記データブロックの直前のデータまでのチェックサムの累積値と、前記データブロックの最後のデータまでのチェックサム累積値とを前記記憶装置から読み出し、それらの差を算出して、そのデータブロックのチェックサムとすることを特徴とする請求の範囲 3 2に記載のチェックサム算出方法。

3 4 . 所定のタイミングでデ一タ長が確定するデータブ口ックにチェックサムを与えるために、前記タイミングに先立って、前記データブロックを含むデータュ-ットを所定長に分割し、その各部分ごとにチェックサム値を算出して記憶装置に保持することを特徴とするチックサム算出方法。

3 5 . 前記データブロックのデータ長は、前記所定長の整数倍になるよう制限されることを特徴とする請求の範囲 3 1から 3 4のいずれかに記載のチヱックサム算出方法。

3 6 . あるデータユニットの複数の箇所について、データユニットの先頭からその箇所までのチェックサム値を算出して保持することを特徴とするチヱックサム記録方法。

3 7 . データユニットの入力を受け付ける入力部と、

前記データュニットの先頭からのチェックサムの累積値を算出する算出部と、前記データュニットの所定長ごとに、前記累積値を保持する保持部と、を備えることを特徴とする通信装置。

3 8 . 前記データュニットを複数のデータプロックに分割し、ネットワークを介して送出する出力部と、

次に送出するデータプロックのサイズを制御するサイズ制御部と、

次に送出するデータブロックのサイズを取得して、そのデータプロックの前後の前記累積値を前記保持部から読み出し、そのデータブロックのチェックサムを算出する第 2算出部と、

をさらに備えることを特徴とする請求の範囲 3 7に記載の通信装置。

3 9 . 前記保持部は、送出するデータブロックのサイズが予め定まっていない通信方式でデータユニットを送出する場合は、所定長ごとに、そのデータュニットの先頭からのチヱックサムの累積値を保持し、送出するデータプロックのサイズが予め定まっている通信方式でデータュニットを送出する場合は、そのデータュニット全体のチヱックサムを保持することを特徴とする請求の範囲 3 8に記載