JP2004173332A - 通信装置 - Google Patents

Abstract

【課題】複数の通信プロトコルによるデータ通信を効率よく処理する技術を提供する。
【解決手段】 インターネット電話装置１００において、ネットワークインターフェース部１３０がパケットを受信すると、プロトコル検出部１７６が、ＴＣＰパケットかＵ BR>cＰパケットかを検出する。ＴＣＰパケットの場合は、汎用回路であるＣＰＵ１１０がソフトウェアによりパケット処理を行う。ＵＤＰパケットの場合は、専用回路であるＵＤＰ処理部１７４がパケット処理を行う。ＵＤＰパケットにより送受信される音声データは、コーデック処理部１４０により復号され、スピーカ１６０に出力される。
【選択図】 図１

Description

本発明は通信技術に関し、特に複数の通信プロトコルによるデータ通信を効率的に処理する技術に関する。

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

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

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

ＴＣＰとＵＤＰの双方の通信プロトコルをサポートする装置では、パケット通信のための処理は、ＣＰＵなどの汎用プロセッサによりソフトウェア処理されるのが一般的である。また、ネットワークルータなど、高速性が要求される一部の装置では、全てのプロトコル処理をハードウェア化して実装している。
エスティー（ST）マイクロエレクトロニクス株式会社、ボイスオーバーアイピー（VoIP）デジタルプロセッサデータシート、［online］、平成１４年、［平成１４年９月３０日検索］、インターネット＜URL：http://www.st.com/stonline/books/pdf/docs/7818.pdf＞

双方の通信プロトコルをソフトウェアにより処理する方式では、処理効率が悪い速度が遅い、消費電力が大きい、などの課題がある。とくに、複数の相手と同時に通話したり、音声とともに画像を送ったりする場合には、プロトコル処理が律速となり、リアルタイム性が損なわれる恐れがある。さらに、通話中は常にＣＰＵがプロトコル処理を実行しているため、その他のアプリケーションを並行して実行させるのが困難である。処理速度を向上させるためにＣＰＵ能力を上げると、コスト、消費電力、熱発生などを増大させる結果となるため、いずれかを犠牲にして妥協点を見出す必要がある。

双方の通信プロトコルをハードウェアにより処理する方式では、高速なプロトコル処理が可能となるが、複雑な処理が必要なＴＣＰの処理もハードウェア化するため、回路規模が大きくなり、コスト、消費電力、熱の発生などの点で問題がある。

本発明は、そうした課題に鑑みてなされたものであり、その目的は、複数の通信プロトコルによるデータ通信を効率よく処理する技術を提供することにある。本発明の別の目的は、比較的簡便な回路構成により、高速でリアルタイムな通信を実現する技術を提供することにある。

本発明のある態様は、通信装置に関する。この通信装置は、ネットワークを介して受信したパケットが、リアルタイムな処理を要するデータを含むパケットであるか否かを判別する判別部と、前記パケットを一時的に保持するバッファと、前記バッファへの前記パケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記リアルタイムな処理を要するデータを含むパケットの前記バッファへの格納を許可する一方、リアルタイムな処理を要するデータを含まないパケットの前記バッファへの格納を禁止する。

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

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

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

本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットワークを介して受信したパケットの種別を判別する判別部と、前記パケットを一時的に保持するバッファと、前記バッファへのパケットの格納を制御する制御部と、を備え、前記制御部は、前記バッファへのパケットの格納の許否を判定するためのしきい値をパケットの種別に応じて複数保持し、前記バッファの空き領域がしきい値を下回ったパケット種別のパケットの前記バッファへの格納を禁止する。

リアルタイムな処理を要するパケットや、重要度の高いパケットに対するしきい値を、その他のパケットに対するしきい値よりも低く設定してもよい。これにより、バッファの空き領域が少なくなったときに、リアルタイム性を有するパケットや、重要度の高いパケットを優先的に取り込み、パケットが破棄される可能性を抑えることができる。

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

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

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

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

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

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

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

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

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

図２は、本実施の形態における通信方法の手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ１００）、ＩＰ処理部１７８が処理を行ったあと、プロトコル検出部１７６がＵＤＰパケットかＴＣＰパケットかを検出する（Ｓ１０２）。ＵＤＰパケットであった場合は（Ｓ１０２のＹ）、ＵＤＰパケットを処理するための専用回路であるＵＤＰ処理部１７４によりパケット処理が行われる（Ｓ１０４）。ＴＣＰパケットであった場合は（Ｓ１０２のＮ）、汎用回路であるＣＰＵ１１０によりパケット処理が行われる（Ｓ１０６）。その後、データの種類に応じて、必要な処理が行われる。
（第２の実施の形態）
図３は、第２の実施の形態に係る通信装置の一例としてのビデオ電話装置２００の全体構成を示す。本実施の形態のビデオ電話装置２００は、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、入力部の一例としての画像入力部１８０、および出力部の一例としての表示装置１９０を備える。その他の構成については、第１の実施の形態と同様である。同様の構成には同じ符号を付している。本実施の形態では、画像データもＵＤＰにより送受信される。

画像入力部１８０は、通話音声とともに相手に送信すべき画像を入力する。画像入力部１８０は、外部のカメラやビデオ再生装置などから画像を入力してもよいし、自身が撮像装置として画像を撮像してもよい。入力された画像は、コーデック処理部１４０に直接送られて符号化され、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。表示装置１９０は、通話音声とともに相手から受信した画像を表示する。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、コーデック処理部１４０から表示装置１９０に直接画像データが送られ、表示される。
（第３の実施の形態）
図４は、第３の実施の形態に係る通信装置の一例としてのデジタルカメラ３００の全体構成を示す。本実施の形態のデジタルカメラ３００は、電話通信機能を有しており、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、撮像部１８２および表示装置１９０を備える。その他の構成については、第１の実施の形態と同様である。同様の構成には同じ符号を付している。

撮像部１８２は、ＣＣＤなどの撮像素子と、それを制御する構成を含み、静止画または動画を撮像する。撮像された画像は、コーデック処理部１４０に直接送られて符号化され、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。表示装置１９０は、通話音声とともに相手から受信した画像を表示する。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、コーデック処理部１４０から表示装置１９０に直接画像データが送られ、表示される。
（第４の実施の形態）
図５は、第４の実施の形態に係る通信装置の一例としてのビデオ電話装置２００の全体構成を示す。本実施の形態のビデオ電話装置２００は、図３に示した第２の実施の形態のビデオ電話装置２００に比して、画像入力部１８０および表示装置１９０が、コーデック処理部１４０に直接接続されているのではなく、バス１０２に接続されている。その他の構成は図３と同様であり、同様の構成には同じ符号を付している。

画像入力部１８０が入力した画像は、メモリ１２０に保持され、適宜読み出されて、コーデック処理部１４０により符号化される。符号化された画像データは、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、バス１０２を介して表示装置１９０に送られ、表示される。
（第５の実施の形態）
図６は、第５の実施の形態に係る通信装置の一例としてのデジタルカメラ３００の全体構成を示す。本実施の形態のデジタルカメラ３００は、図４に示した第３の実施の形態のデジタルカメラ３００に比して、撮像部１８２および表示装置１９０が、コーデック処理部１４０に直接接続されているのではなく、バス１０２に接続されている。その他の構成は図４と同様であり、同様の構成には同じ符号を付している。

撮像部１８２が撮像した画像は、メモリ１２０に保持され、適宜読み出されてコーデック処理部１４０により符号化される。符号化された画像データは、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、バス１０２を介して表示装置１９０に送られ、表示される。
（第６の実施の形態）
図７は、第６の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。本実施の形態のインターネット電話装置１００は、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、ＩＰ判別部１８６およびパケット受信部１９２をさらに備え、プロトコル検出部１７６に代えてＵＤＰ判別部１８４を備える。その他の構成は図１と同様であり、同様の構成には同じ符号を付している。

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

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

ＩＰ判別部１８６は、ＩＰパケットのうち、複雑な処理を要する特殊なパケットを判別し、そのパケットをＣＰＵ１１０に送ってソフトウェアにより処理させる一方、通常のＩＰパケットはＩＰ処理部１７８に送ってハードウェアにより処理させる。これにより、ＩＰ処理部１７８のハードウェア規模の増大、複雑化、消費電力の増大を回避しつつ、専用のハードウェアにより通常のＩＰパケットを高速に処理することができる。それぞれの技術の詳細については、図を参照しつつ後述する。

図８は、パケット受信部１９２の内部構成を示す。制御部１９５は、読出し位置管理部１９６、書込み位置管理部１９７、およびバッファ飽和検出部１９８を含む。本実施の形態の受信バッファ１９３は、ＦＩＦＯ（First In First Out）メモリにより構成されており、読出し位置管理部１９６は受信バッファ１９３のリードアドレスを保持するレジスタであり、書込み位置管理部１９７は受信バッファ１９３のライトアドレスを保持するレジスタである。バッファ飽和検出部１９８は、読出し位置管理部１９６に保持されたリードアドレスと、書込み位置管理部１９７に保持されたライトアドレスとの差を算出することにより、受信バッファ１９３の使用領域の大きさを検出し、受信バッファ１９３の空き領域を把握する。

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

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

本実施の形態では、リアルタイム性を要する音声信号は、ＵＤＰを用いて送受信される。そのため、パケット判別部１９４は、受信したパケットがＴＣＰパケットであるかＵＤＰパケットであるかを判別し、ＴＣＰパケットであれば、リアルタイムな処理を要しないパケットに対しての許否判定を採用し、ＵＤＰパケットであれば、リアルタイムな処理を要するパケットに対しての許否判定を採用する。パケット判別部１９４は、格納を許可されたパケットを受信バッファ１９３に格納し、格納を拒否されたパケットを破棄する。

ＴＣＰでは、ＦＴＰ（File Transfer Protocol）によりデータファイルを転送する場合など、一時に大量のパケットを受信する可能性があるが、このとき、受信バッファ１９３がＴＣＰパケットで飽和し、ＵＤＰパケットを受信できなくなる恐れがある。音声信号を含むＵＤＰパケットは、リアルタイムに再生する必要があるので、ＵＤＰパケットが優先的に受信バッファ１９３を利用できるようにすることで、パケットの破棄によるデータの欠落を最小限に抑える。ＵＤＰは再送制御を行わないので、いったんパケットが破棄されると再び取得することができないが、ＴＣＰは、再送制御を行うので、欠落したデータを再送により補うことが可能である。

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

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

図９は、本実施の形態におけるパケットの受信手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ２００）、パケット判別部１９４がリアルタイムな処理を要するデータを含むパケットか否かを判別する（Ｓ２０２）。リアルタイム性のパケットであった場合は（Ｓ２０２のＹ）、リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ１９３への格納の許否が判定される（Ｓ２０４）。リアルタイム性のパケットでなかった場合は（Ｓ２０２のＮ）、非リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ１９３への格納の許否が判定される（Ｓ２０６）。そして、受信したパケットの受信バッファ１９３への格納が許可された場合は（Ｓ２０８のＹ）、パケットを受信バッファ１９３に格納し（Ｓ２１０）、格納が許可されなかった場合は（Ｓ２０８のＮ）、パケットは破棄される（Ｓ２１２）。

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

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

ＩＰ処理部１７８により処理されたパケットは、第２の判別部の一例としてのＵＤＰ判別部１８４に送られる。ＵＤＰ判別部１８４は、受信したパケットがＴＣＰパケットであるかＵＤＰパケットであるかを判別し、ＵＤＰパケットは第２の専用回路の一例としてのＵＤＰ処理部１７４によりハードウェア処理する一方、ＴＣＰパケットは汎用回路の一例としてのＣＰＵ１１０によりソフトウェア処理する。ここで、ＵＤＰ判別部１８４は、第１の実施の形態におけるプロトコル検出部１７６と同様の機能を有するが、本実施の形態では、通信プロトコルのうちトランスポート層の通信方式の種別を判別することを明示するために、この名称を用いている。

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

図１１は、本実施の形態におけるパケット処理手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ３００）、ＩＰ判別部１８６が通常のＩＰパケットか否かを判別する（Ｓ３０２）。通常のＩＰパケットであった場合は（Ｓ３０２のＹ）、専用回路であるＩＰ処理部１７８によりＩＰのパケット処理が行われる（Ｓ３０４）。フラグメント化されたＩＰパケットなど、複雑な処理を要する特殊なＩＰパケットであった場合は（Ｓ３０２のＮ）、汎用回路であるＣＰＵ１１０に送られ、ソフトウェアによりパケット処理が行われる（Ｓ３１０）。ＵＤＰ判別部１８４は、ＩＰ処理部１７８により処理されたパケットがＵＤＰパケットであるか否かを判別する（Ｓ３０６）。ＵＤＰパケットであった場合は（Ｓ３０６のＹ）、専用回路であるＵＤＰ処理部１７４によりＵＤＰのパケット処理が行われる。ＴＣＰパケットであった場合は（Ｓ３０６のＮ）、汎用回路であるＣＰＵ１１０に送られ、ソフトウェアによりパケット処理が行われる（Ｓ３１０）。

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

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

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

第１の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。 第１の実施の形態に係る通信方法の手順を示すフローチャートである。 第２の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。 第３の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。 第４の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。 第５の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。 第６の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。 第６の実施の形態に係るインターネット電話装置のパケット受信部の内部構成を示す図である。 第６の実施の形態におけるパケットの受信手順を示すフローチャートである。 第６の実施の形態に係るインターネット電話装置のＩＰ判別部の内部構成を示す図である。 第６の実施の形態におけるパケットのパケット処理手順を示すフローチャートである。

符号の説明

２０ インターネット、 １００ インターネット電話装置、 １３０ ネットワークインターフェース部、 １４０ コーデック処理部、 １５０ マイク、 １６０ スピーカ、 １７０ プロトコル処理部、 １７２ セキュリティ処理部、 １７４ ＵＤＰ処理部、 １７６ プロトコル検出部、 １７８ ＩＰ処理部、 １８０ 画像入力部、 １８２ 撮像部、 １８４ ＵＤＰ判別部、 １８６ ＩＰ判別部、 １９０ 表示装置、 １９２ パケット受信部、 １９３ 受信バッファ、 １９４ パケット判別部、 １９５ 制御部、 ２００ ビデオ電話装置、 ３００ デジタルカメラ。

Claims (4)

1. ネットワークを介して受信したパケットが、リアルタイムな処理を要するデータを含むパケットであるか否かを判別する判別部と、
   前記パケットを一時的に保持するバッファと、
   前記バッファへの前記パケットの格納を制御する制御部と、を備え、
   前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記リアルタイムな処理を要するデータを含むパケットの前記バッファへの格納を許可する一方、リアルタイムな処理を要するデータを含まないパケットの前記バッファへの格納を禁止することを特徴とする通信装置。
2. ネットワークを介して受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第１の通信方式により送られたパケットであるか、装置間での接続の確立を要しない第２の通信方式により送られたパケットであるかを判別する判別部と、
   前記パケットを一時的に保持するバッファと、
   前記バッファへの前記パケットの格納を制御する制御部と、を備え、
   前記制御部は、前記バッファの空き領域が所定のしきい値を下回ったとき、前記第２の通信方式により送られたパケットの前記バッファへの格納を許可する一方、前記第１の通信方式により送られたパケットの前記バッファへの格納を禁止することを特徴とする通信装置。
3. ネットワークを介して受信したパケットの種別を判別する判別部と、
   前記パケットを一時的に保持するバッファと、
   前記バッファへのパケットの格納を制御する制御部と、を備え、
   前記制御部は、前記バッファへのパケットの格納の許否を判定するためのしきい値をパケットの種別に応じて複数保持し、前記バッファの空き領域がしきい値を下回ったパケット種別のパケットの前記バッファへの格納を禁止することを特徴とする通信装置。
4. リアルタイムな処理を要するパケットの種別のしきい値を、リアルタイムな処理を要しないパケットの種別のしきい値よりも低く設定したことを特徴とする請求項３に記載の通信装置。
   

Images