JP3557202B2

JP3557202B2 - 通信装置、通信方法、およびその方法を利用可能な電話装置、ビデオ電話装置、撮像装置

Info

Publication number: JP3557202B2
Application number: JP2003005101A
Authority: JP
Inventors: 一晃岡本; 英雄廣野
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2002-09-30
Filing date: 2003-01-10
Publication date: 2004-08-25
Anticipated expiration: 2023-01-10
Also published as: JP2004180253A

Description

【０００１】
【発明の属する技術分野】
本発明は通信技術に関し、特に複数の通信プロトコルによるデータ通信を効率的に処理する技術に関する。
【０００２】
【従来の技術】
インターネットが広く普及し、ネットワークのインフラの整備も進みつつある現在、通話音声信号を符号化したデータをパケット化し、インターネットなどのネットワークを介して送受信するインターネット電話装置が注目を集めている。通話音声と同時にビデオ映像を送ることにより、ビデオ電話装置として利用することも可能であり、従来の電話装置に取って代わる次世代の電話装置として期待されている。
【０００３】
現在、パケット通信のための通信プロトコルとして、ＴＣＰ／ＩＰ（ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）が広く利用されている。ＴＣＰは、装置間で接続を確立してからデータを送受信するなど、正確性を重視した通信プロトコルである。しかしながら、処理が複雑で、相手側がパケットを受信したことを確認するまで次のパケットを送ることができないなどの時間的制約があり、リアルタイム性に欠けるため、通話音声の送受信には不向きである。
【０００４】
ＴＣＰよりも簡便な通信プロトコルに、ＵＤＰ／ＩＰ（ＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌ／ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌ）がある。ＵＤＰでは、データの送受信に先立って装置間で接続を確立する必要がなく、パケットの受信確認を待たずに次のパケットを送ることが許されるので、送信側は次々にパケットを送出することができる。そのため、データの正確性よりもリアルタイム性が重視される、通話音声の送受信に適している。
【０００５】
ＴＣＰとＵＤＰの双方の通信プロトコルをサポートする装置では、パケット通信のための処理は、ＣＰＵなどの汎用プロセッサによりソフトウェア処理されるのが一般的である。また、ネットワークルータなど、高速性が要求される一部の装置では、全てのプロトコル処理をハードウェア化して実装している。
【０００６】
【非特許文献１】
エスティー（ＳＴ）マイクロエレクトロニクス株式会社、ボイスオーバーアイピー（ＶｏＩＰ）デジタルプロセッサデータシート、［ｏｎｌｉｎｅ］、平成１４年、［平成１４年９月３０日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｓｔ．ｃｏｍ／ｓｔｏｎｌｉｎｅ／ｂｏｏｋｓ／ｐｄｆ／ｄｏｃｓ／７８１８．ｐｄｆ＞
【０００７】
【発明が解決しようとする課題】
双方の通信プロトコルをソフトウェアにより処理する方式では、処理効率が悪い、速度が遅い、消費電力が大きい、などの課題がある。とくに、複数の相手と同時に通話したり、音声とともに画像を送ったりする場合には、プロトコル処理が律速となり、リアルタイム性が損なわれる恐れがある。さらに、通話中は常にＣＰＵがプロトコル処理を実行しているため、その他のアプリケーションを並行して実行させるのが困難である。処理速度を向上させるためにＣＰＵ能力を上げると、コスト、消費電力、熱発生などを増大させる結果となるため、いずれかを犠牲にして妥協点を見出す必要がある。
【０００８】
双方の通信プロトコルをハードウェアにより処理する方式では、高速なプロトコル処理が可能となるが、複雑な処理が必要なＴＣＰの処理もハードウェア化するため、回路規模が大きくなり、コスト、消費電力、熱の発生などの点で問題がある。
【０００９】
本発明は、そうした課題に鑑みてなされたものであり、その目的は、複数の通信プロトコルによるデータ通信を効率よく処理する技術を提供することにある。本発明の別の目的は、比較的簡便な回路構成により、高速でリアルタイムな通信を実現する技術を提供することにある。
【００１０】
【課題を解決するための手段】
本発明のある態様は通信装置に関する。この通信装置は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第１の通信方式により送られたパケットであったとき、そのパケットをソフトウェアにより処理するための汎用回路と、受信したパケットが、装置間での接続の確立を要しない第２の通信方式により送られたパケットであったとき、そのパケットを処理するための専用回路と、を備える。
【００１１】
本発明の別の態様も、通信装置に関する。この通信装置は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットが、送信パケットの到着確認を行う第１の通信方式により送られたパケットであったとき、そのパケットをソフトウェアにより処理するための汎用回路と、受信したパケットが、送信パケットの到着確認を行わない第２の通信方式により送られたパケットであったとき、そのパケットを処理するための専用回路と、を備える。
【００１２】
汎用回路は、ＣＰＵ、ＤＳＰなどであってもよい。第１の通信方式は、たとえば、ＴＣＰであってもよい。第２の通信方式は、たとえば、ＵＤＰであってもよい。ＵＤＰの処理のみをハードウェア化することにより、回路規模の増大を抑えつつ、ＵＤＰの処理を高速化することができる。
【００１３】
この通信装置は、ネットワークを介してパケットを送信する送信部をさらに備え、送信するパケットが、前記第１の通信方式により送られるとき、そのパケットを前記汎用回路により処理し、送信するパケットが、前記第２の通信方式により送られるとき、そのパケットを前記専用回路により処理してもよい。
【００１４】
この通信装置は、受信したパケットが、どの通信方式により送られたかを検出する検出部をさらに備えてもよい。検出部は、パケットのヘッダを参照して、通信方式を検出してもよい。この検出部も、専用の回路により構成されてもよい。
【００１５】
前記検出部により、前記第１の通信方式により送られたパケットが検出されたとき、前記検出部は、そのパケットを、前記汎用回路を介さずに、直接前記専用回路へ送ってもよい。ソフトウェア処理を介さず、専用回路により処理することで、高速な処理が実現する。また、ＣＰＵなどの汎用回路の処理負担を軽減することができる。
【００１６】
この通信装置は、パケットを構成するデータを暗号化または復号化するセキュリティ処理部をさらに備えてもよい。このセキュリティ処理部も、専用の回路により構成されてもよい。
【００１７】
本発明のさらに別の態様も、通信装置に関する。この通信装置は、ネットワークを介して送られたパケットを受信する受信部と、受信したパケットがフラグメント化されたパケットであったとき、そのパケットをソフトウェアにより処理するために汎用回路へ送り、受信したパケットがフラグメント化されていないパケットであったとき、そのパケットをハードウェアにより処理するために第１の専用回路へ送る第１の判別部と、を備える。
【００１８】
ＩＰパケットのうち、オプション付きのＩＰパケットや、フラグメント化されたＩＰパケットなどは、複雑な処理を必要とするので、これらのＩＰパケットも専用回路で処理しようとすると、回路規模が増大し、消費電力やコストの増大を招く。そのため、通常のＩＰパケットは専用回路で高速に処理しつつ、通常のＩＰパケットよりも複雑な処理を必要とする特殊なＩＰパケットは、ＣＰＵなどの汎用回路でソフトウェアにより処理することで、専用回路の回路規模を抑え、消費電力およびコストを低減することができる。
【００１９】
この通信装置は、前記第１の専用回路により処理したパケットが、データの送受信に先立って装置間で接続を確立することを要する第１の通信方式により送られたパケットであったとき、そのパケットを前記汎用回路に送り、前記第１の専用回路により処理したパケットが、装置間での接続の確立を要しない第２の通信方式により送られたパケットであったとき、そのパケットをハードウェアにより処理するための第２の専用回路へ送る第２の判別部をさらに備えてもよい。通常のＩＰパケットのＩＰ処理をＩＰ処理回路で行った後、パケットがＵＤＰであるかＴＣＰであるかを判断し、ＵＤＰパケットのみをＵＤＰ処理回路で処理し、ＴＣＰパケットはＣＰＵなどの汎用回路によりソフトウェア処理してもよい。
【００２９】
本発明のさらに別の態様は、通信方法に関する。この方法は、パケットを受信したときに、そのパケットの通信方式を検出する工程と、前記通信方式に応じて、そのパケットを処理すべき回路にパケットのデータを送る工程と、を含む。
【００３０】
前記検出する工程は、パケットのヘッダを解析することにより、データの送受信に先立って装置間での接続の確立を要する第１の通信方式によるパケットであるか、装置間での接続の確立を要しない第２の通信方式によるパケットであるかを検出し、前記データを送る工程は、前記第１の通信方式によるパケットを、ソフトウェア処理するための汎用回路に送り、前記第２の通信方式によるパケットを、そのパケットを処理するための専用回路に送ってもよい。
【００３４】
なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、などの間で変換したものもまた、本発明の態様として有効である。
【００３５】
【発明の実施の形態】
（第１の実施の形態）
図１は、本発明の第１の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。インターネット電話装置１００は、インターネット２０を介して、他のインターネット電話装置１００との間で通話を行うための装置である。インターネット電話装置１００は、主に、ソフトウェア処理を実行するための汎用回路であるＣＰＵ１１０、プログラムエリアまたはワークエリアとして利用されるメモリ１２０、インターネット２０を介してパケットを送受信するネットワークインターフェース部１３０、音声信号を入力するマイク１５０、音声信号を出力するスピーカ１６０、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部１４０、通信プロトコルに応じた各種処理を行うプロトコル処理部１７０、およびこれらの構成を電気的に接続するバス１０２を備える。
【００３６】
本実施の形態のインターネット電話装置１００では、トランスポート層の通信プロトコルとして、ＵＤＰを利用して音声信号を送受信する。ＵＤＰは、接続の確立を要さず、パケットを次々に送出することが可能な通信方式であるため、プロトコル処理が簡単で、かつ高速な通信が可能であり、通話音声を送るなどのリアルタイムな通信に適している。本実施の形態のインターネット電話装置１００では、ＵＤＰにより送られたパケットの処理を、専用の回路であるプロトコル処理部１７０に実行させることで、さらに処理速度を向上させ、通話音声のリアルタイムな送受信を実現する。
【００３７】
インターネット電話装置１００が送受信するパケットのうち、ＴＣＰにより送受信されるパケットは、ＣＰＵ１１０を利用してソフトウェアにより処理される。リアルタイム性を要しないＴＣＰについては、専用の回路を設けず、汎用回路によるソフトウェア処理を行うことで、回路規模の増大を抑え、コスト、消費電力、熱発生の増大を最小限に抑えることができる。本発明者の試算によれば、ＴＣＰとＵＤＰの双方を専用回路により処理する場合に比べて、回路の面積および消費電力が約１／３で済むことが分かっている。
【００３８】
ネットワークインターフェース部１３０が受信したパケットは、プロトコル処理部１７０のＩＰ処理部１７８に送られる。ＩＰ処理部１７８は、パケットが自装置に割り当てられたＩＰアドレスに宛てられたものであるか否かを判断し、自装置宛てのパケットのみをプロトコル検出部１７６に送る。プロトコル検出部１７６は、パケットに付されたＩＰヘッダ内のプロトコル種別を示すＰＲＯＴを参照して、または、ＴＣＰヘッダまたはＵＤＰヘッダを参照して、プロトコルの種別を検出する。パケットがＴＣＰにより送られたパケットであった場合は、そのパケットのデータをバス１０２上に送り、ＣＰＵ１１０によりソフトウェア処理させる。パケットがＵＤＰのパケットであった場合は、そのパケットのデータをＵＤＰ処理部１７４に送り、ＵＤＰデータの処理のために専用に設けられた回路により処理させる。
【００３９】
ＵＤＰ処理部１７４は、ＵＤＰパケットを処理するための専用回路であり、ＵＤＰパケットを受け取って、そのヘッダを解析し、必要な処理を実行する。セキュリティ処理部１７２は、データに対して暗号化処理などのセキュリティ対策が施されていた場合に、暗号を復号するなどの処理を行う。復号されたデータは、コーデック処理部１４０に送られる。コーデック処理部１４０は、圧縮符号化されていた通話音声信号を復号し、スピーカ１６０に出力する。
【００４０】
このように、本実施の形態のインターネット電話装置１００では、正確性よりもリアルタイム性が重視され、通話中、常時処理が必要となる通話音声データは、ＵＤＰにより送受信を行い、専用回路であるＵＤＰ処理部１７４によりハードウェア処理を行う一方、リアルタイム性よりも正確性が重視されるデータは、ＴＣＰにより送受信を行い、ＣＰＵ１１０によりソフトウェア処理を行う。これにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えつつ、通話音声データを高速に処理することが可能となる。このような利点は、複数の相手と同時に通話したり、通話音声とともに画像を送信するなど、大量のデータを同時に処理することが必要な場合に、より顕著となる。また、プロトコル検出部１７６によりパケットの種別を検出し、パケットの処理主体を高速かつ適切に選択することができる。さらに、ＣＰＵ１１０の処理負担を軽減し、低コスト化、低消費電力化が実現できるほか、ＣＰＵ１１０に余力ができるため、通話中に他のアプリケーションを実行することが可能となり、新たなサービスを提供することもできる。
【００４１】
以上、パケットを受信したときの動作について説明したが、つづいて、マイク１５０から入力された音声信号をパケット化して送信するときの動作について説明する。マイク１５０から入力された音声信号は、コーデック処理部１４０に送られ、符号化される。符号化された信号は、必要であれば、セキュリティ処理部１７２により暗号化されたあと、ＵＤＰ処理部１７４に送られ、ＵＤＰヘッダが付され、パケット化される。このＵＤＰパケットは、ネットワークインターフェース部１３０を介して、インターネット２０に送出される。
【００４２】
図２は、本実施の形態における通信方法の手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ１００）、ＩＰ処理部１７８が処理を行ったあと、プロトコル検出部１７６がＵＤＰパケットかＴＣＰパケットかを検出する（Ｓ１０２）。ＵＤＰパケットであった場合は（Ｓ１０２のＹ）、ＵＤＰパケットを処理するための専用回路であるＵＤＰ処理部１７４によりパケット処理が行われる（Ｓ１０４）。ＴＣＰパケットであった場合は（Ｓ１０２のＮ）、汎用回路であるＣＰＵ１１０によりパケット処理が行われる（Ｓ１０６）。その後、データの種類に応じて、必要な処理が行われる。
【００４３】
（第２の実施の形態）
図３は、第２の実施の形態に係る通信装置の一例としてのビデオ電話装置２００の全体構成を示す。本実施の形態のビデオ電話装置２００は、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、入力部の一例としての画像入力部１８０、および出力部の一例としての表示装置１９０を備える。その他の構成については、第１の実施の形態と同様である。同様の構成には同じ符号を付している。本実施の形態では、画像データもＵＤＰにより送受信される。
【００４４】
画像入力部１８０は、通話音声とともに相手に送信すべき画像を入力する。画像入力部１８０は、外部のカメラやビデオ再生装置などから画像を入力してもよいし、自身が撮像装置として画像を撮像してもよい。入力された画像は、コーデック処理部１４０に直接送られて符号化され、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。表示装置１９０は、通話音声とともに相手から受信した画像を表示する。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、コーデック処理部１４０から表示装置１９０に直接画像データが送られ、表示される。
【００４５】
（第３の実施の形態）
図４は、第３の実施の形態に係る通信装置の一例としてのデジタルカメラ３００の全体構成を示す。本実施の形態のデジタルカメラ３００は、電話通信機能を有しており、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、撮像部１８２および表示装置１９０を備える。その他の構成については、第１の実施の形態と同様である。同様の構成には同じ符号を付している。
【００４６】
撮像部１８２は、ＣＣＤなどの撮像素子と、それを制御する構成を含み、静止画または動画を撮像する。撮像された画像は、コーデック処理部１４０に直接送られて符号化され、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。表示装置１９０は、通話音声とともに相手から受信した画像を表示する。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、コーデック処理部１４０から表示装置１９０に直接画像データが送られ、表示される。
【００４７】
（第４の実施の形態）
図５は、第４の実施の形態に係る通信装置の一例としてのビデオ電話装置２００の全体構成を示す。本実施の形態のビデオ電話装置２００は、図３に示した第２の実施の形態のビデオ電話装置２００に比して、画像入力部１８０および表示装置１９０が、コーデック処理部１４０に直接接続されているのではなく、バス１０２に接続されている。その他の構成は図３と同様であり、同様の構成には同じ符号を付している。
【００４８】
画像入力部１８０が入力した画像は、メモリ１２０に保持され、適宜読み出されて、コーデック処理部１４０により符号化される。符号化された画像データは、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、バス１０２を介して表示装置１９０に送られ、表示される。
【００４９】
（第５の実施の形態）
図６は、第５の実施の形態に係る通信装置の一例としてのデジタルカメラ３００の全体構成を示す。本実施の形態のデジタルカメラ３００は、図４に示した第３の実施の形態のデジタルカメラ３００に比して、撮像部１８２および表示装置１９０が、コーデック処理部１４０に直接接続されているのではなく、バス１０２に接続されている。その他の構成は図４と同様であり、同様の構成には同じ符号を付している。
【００５０】
撮像部１８２が撮像した画像は、メモリ１２０に保持され、適宜読み出されて、コーデック処理部１４０により符号化される。符号化された画像データは、ＵＤＰ処理部１７４によりＵＤＰパケットに整形されて、ネットワークインターフェース部１３０によりインターネット２０へ送出される。ネットワークインターフェース部１３０が受信したＵＤＰパケットに含まれる画像データは、ＵＤＰ処理部１７４、セキュリティ処理部１７２、およびコーデック処理部１４０により処理され、バス１０２を介して表示装置１９０に送られ、表示される。
【００５１】
（第６の実施の形態）
図７は、第６の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。本実施の形態のインターネット電話装置１００は、図１に示した第１の実施の形態のインターネット電話装置１００の構成に加えて、ＩＰ判別部１８６およびパケット受信部１９２をさらに備え、プロトコル検出部１７６に代えてＵＤＰ判別部１８４を備える。その他の構成は図１と同様であり、同様の構成には同じ符号を付している。
【００５２】
本実施の形態のインターネット電話装置１００でも、第１の実施の形態と同様に、音声信号を含むＵＤＰパケットを専用のハードウェアで処理することで、処理速度を向上させ、通話音声のリアルタイムな送受信を実現するが、本実施の形態では、さらにリアルタイム性を向上させるための技術を提案する。
【００５３】
パケット受信部１９２は、リアルタイム性を要するデータを含むパケットを、リアルタイム性を要しないパケットに優先して受信バッファ１９３に格納するために、リアルタイム性を要しないパケットについては、受信バッファ１９３の空き領域が所定のしきい値を下回ると受信バッファ１９３への格納を禁止し、リアルタイム性を要するパケットのみを格納可能とする。これにより、リアルタイム性を要するパケットの受信が遅延したり、パケットが破棄されてデータが欠落する可能性を抑えることができる。
【００５４】
ＩＰ判別部１８６は、ＩＰパケットのうち、複雑な処理を要する特殊なパケットを判別し、そのパケットをＣＰＵ１１０に送ってソフトウェアにより処理させる一方、通常のＩＰパケットはＩＰ処理部１７８に送ってハードウェアにより処理させる。これにより、ＩＰ処理部１７８のハードウェア規模の増大、複雑化、消費電力の増大を回避しつつ、専用のハードウェアにより通常のＩＰパケットを高速に処理することができる。それぞれの技術の詳細については、図を参照しつつ後述する。
【００５５】
図８は、パケット受信部１９２の内部構成を示す。制御部１９５は、読出し位置管理部１９６、書込み位置管理部１９７、およびバッファ飽和検出部１９８を含む。本実施の形態の受信バッファ１９３は、ＦＩＦＯ（ＦｉｒｓｔＩｎＦｉｒｓｔＯｕｔ）メモリにより構成されており、読出し位置管理部１９６は受信バッファ１９３のリードアドレスを保持するレジスタであり、書込み位置管理部１９７は受信バッファ１９３のライトアドレスを保持するレジスタである。バッファ飽和検出部１９８は、読出し位置管理部１９６に保持されたリードアドレスと、書込み位置管理部１９７に保持されたライトアドレスとの差を算出することにより、受信バッファ１９３の使用領域の大きさを検出し、受信バッファ１９３の空き領域を把握する。
【００５６】
バッファ飽和検出部１９８は、受信バッファ１９３への書込みの許否を判定するための複数のしきい値を保持している。しきい値は、パケットの種別に応じて設定されており、受信バッファ１９３の空き領域が、あるパケット種別に対するしきい値を下回ると、その種別のパケットの受信バッファ１９３への書込みを禁止し、受信したパケットを破棄する。
【００５７】
本実施の形態では、リアルタイムな処理を要するデータを含むパケットを優先的に受信バッファ１９３に格納するために、リアルタイムな処理を要するパケットに対する許否判定のしきい値を、リアルタイムな処理を要しないパケットに対する許否判定のしきい値よりも低く設定する。たとえば、リアルタイムな処理を要するパケットに対するしきい値を０とし、リアルタイムな処理を要しないパケットに対するしきい値をバッファサイズの５０％としたとき、バッファ飽和検出部１９８は、受信バッファ１９３の空き領域が５０％を下回ると、リアルタイムな処理を要しないパケットに対してはバッファが飽和したと判定して書込みを禁止する一方、リアルタイムな処理を要するパケットに対しては空き領域があると判定して書込みを許可する。すなわち、受信バッファ１９３の空き領域が５０％以上のときは、リアルタイムな処理を要するパケットもリアルタイムな処理を要しないパケットも受信バッファ１９３に格納可能とするが、空き領域が５０％を下回ると、リアルタイムな処理を要するパケットのみの格納を許可する。
【００５８】
本実施の形態では、リアルタイム性を要する音声信号は、ＵＤＰを用いて送受信される。そのため、パケット判別部１９４は、受信したパケットがＴＣＰパケットであるかＵＤＰパケットであるかを判別し、ＴＣＰパケットであれば、リアルタイムな処理を要しないパケットに対しての許否判定を採用し、ＵＤＰパケットであれば、リアルタイムな処理を要するパケットに対しての許否判定を採用する。パケット判別部１９４は、格納を許可されたパケットを受信バッファ１９３に格納し、格納を拒否されたパケットを破棄する。
【００５９】
ＴＣＰでは、ＦＴＰ（ＦｉｌｅＴｒａｎｓｆｅｒＰｒｏｔｏｃｏｌ）によりデータファイルを転送する場合など、一時に大量のパケットを受信する可能性があるが、このとき、受信バッファ１９３がＴＣＰパケットで飽和し、ＵＤＰパケットを受信できなくなる恐れがある。音声信号を含むＵＤＰパケットは、リアルタイムに再生する必要があるので、ＵＤＰパケットが優先的に受信バッファ１９３を利用できるようにすることで、パケットの破棄によるデータの欠落を最小限に抑える。ＵＤＰは再送制御を行わないので、いったんパケットが破棄されると再び取得することができないが、ＴＣＰは、再送制御を行うので、欠落したデータを再送により補うことが可能である。
【００６０】
受信バッファ１９３を２つ設け、一方にリアルタイム性を要するパケットを格納し、他方にリアルタイム性を要しないパケットを格納するように構成してもよいが、上述の技術を用いることにより、１つの受信バッファ１９３でリアルタイムな処理を要するパケットを優先的に受信することができるので、２つの受信バッファ１９３を設ける場合に比べて、ハードウェア規模を抑え、消費電力を低減することができる。
【００６１】
リアルタイムな処理を要するデータを含むか否かを示す情報をパケットのヘッダ情報に格納しておき、その情報を参照してパケットの種別を取得し、受信バッファ１９３への格納の許否を判定してもよい。リアルタイム性の有無だけでなく、他の観点に基づいてしきい値を設定し、受信バッファ１９３への格納の優先度を決定してもよい。たとえば、重要度が高く、データの欠落が許されないパケットのしきい値を他のパケットのしきい値よりも低く設定し、優先的に取り込むようにしてもよい。パケット判別部１９４がしきい値を保持し、バッファ飽和検出部１９８から受信バッファ１９３の残量を取得して、受信バッファ１９３への書込みの許否を判定してもよい。
【００６２】
図９は、本実施の形態におけるパケットの受信手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ２００）、パケット判別部１９４がリアルタイムな処理を要するデータを含むパケットか否かを判別する（Ｓ２０２）。リアルタイム性のパケットであった場合は（Ｓ２０２のＹ）、リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ１９３への格納の許否が判定される（Ｓ２０４）。リアルタイム性のパケットでなかった場合は（Ｓ２０２のＮ）、非リアルタイム性のパケットに対して設定されたしきい値を用いて受信バッファ１９３への格納の許否が判定される（Ｓ２０６）。そして、受信したパケットの受信バッファ１９３への格納が許可された場合は（Ｓ２０８のＹ）、パケットを受信バッファ１９３に格納し（Ｓ２１０）、格納が許可されなかった場合は（Ｓ２０８のＮ）、パケットは破棄される（Ｓ２１２）。
【００６３】
図１０は、ＩＰ判別部１８６の内部構成を示す。第１の判別部の一例としてのＩＰ判別部１８６は、ＩＰヘッダ検出部１８７、ＩＰヘッダ判定部１８８、およびパケット出力切替部１８９を含む。ＩＰヘッダ検出部１８７は、パケット受信部１９２から取得したパケットのＩＰヘッダを検出し、ＩＰヘッダ判定部１８８に送る。ＩＰヘッダ判定部１８８は、ＩＰヘッダなどを参照して、そのパケットが通常のＩＰパケットであるか、複雑な処理を要する特殊なＩＰパケットであるかを判定し、判定結果をパケット出力切替部１８９に通知する。特殊なＩＰパケットは、たとえば、オプション付きＩＰパケット、フラグメント化されたＩＰパケットなどであってもよい。パケット出力切替部１８９は、ＩＰヘッダ判定部１８８の判定結果に基づいて、ＩＰヘッダ検出部１８７が取得したＩＰパケットの出力先を切り替える。パケット出力切替部１８９は、通常のＩＰパケットをハードウェアにより処理させるために第１の専用回路の一例としてのＩＰ処理部１７８へ出力し、複雑な処理を要する特殊なＩＰパケットをソフトウェアにより処理させるためにバスインターフェースを介して汎用回路の一例としてのＣＰＵ１１０へ出力する。
【００６４】
フラグメント化されたＩＰパケットは、パケットの順序の管理や、欠落や重複があったときの処理など、通常のＩＰ処理よりも複雑な処理が必要となる。また、オプション付きＩＰパケットは、付されたオプションに応じた処理が必要となる。このような例外的な処理もハードウェアにより実現しようとすると、回路規模が増大し、コストや消費電力の増大を招く。そのため、通常のＩＰパケットのみを処理可能なハードウェアのみを設けることで、コストや消費電力を抑える。
【００６５】
ＩＰ処理部１７８により処理されたパケットは、第２の判別部の一例としてのＵＤＰ判別部１８４に送られる。ＵＤＰ判別部１８４は、受信したパケットがＴＣＰパケットであるかＵＤＰパケットであるかを判別し、ＵＤＰパケットは第２の専用回路の一例としてのＵＤＰ処理部１７４によりハードウェア処理する一方、ＴＣＰパケットは汎用回路の一例としてのＣＰＵ１１０によりソフトウェア処理する。ここで、ＵＤＰ判別部１８４は、第１の実施の形態におけるプロトコル検出部１７６と同様の機能を有するが、本実施の形態では、通信プロトコルのうちトランスポート層の通信方式の種別を判別することを明示するために、この名称を用いている。
【００６６】
このように、本実施の形態のインターネット電話装置１００では、ＩＰ判別部１８６によりＩＰパケットの種別を検出し、パケットの処理主体を高速かつ適切に選択することができる。また、通話音声などのリアルタイムな処理を要するデータを含む通常のＩＰパケットは専用回路であるＩＰ処理部１７８により高速に処理を行いつつ、複雑な処理を要する特殊なＩＰパケットはＣＰＵ１１０によりソフトウェア処理を行うことにより、回路の複雑化、回路規模、コスト、消費電力、熱発生などの増大を抑えることができる。
【００６７】
図１１は、本実施の形態におけるパケット処理手順を示すフローチャートである。ネットワークインターフェース部１３０がパケットを受信すると（Ｓ３００）、ＩＰ判別部１８６が通常のＩＰパケットか否かを判別する（Ｓ３０２）。通常のＩＰパケットであった場合は（Ｓ３０２のＹ）、専用回路であるＩＰ処理部１７８によりＩＰのパケット処理が行われる（Ｓ３０４）。フラグメント化されたＩＰパケットなど、複雑な処理を要する特殊なＩＰパケットであった場合は（Ｓ３０２のＮ）、汎用回路であるＣＰＵ１１０に送られ、ソフトウェアによりパケット処理が行われる（Ｓ３１０）。ＵＤＰ判別部１８４は、ＩＰ処理部１７８により処理されたパケットがＵＤＰパケットであるか否かを判別する（Ｓ３０６）。ＵＤＰパケットであった場合は（Ｓ３０６のＹ）、専用回路であるＵＤＰ処理部１７４によりＵＤＰのパケット処理が行われる。ＴＣＰパケットであった場合は（Ｓ３０６のＮ）、汎用回路であるＣＰＵ１１０に送られ、ソフトウェアによりパケット処理が行われる（Ｓ３１０）。
【００６８】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下、そうした例を述べる。
【００６９】
実施の形態では、電話装置を例にとって説明したが、本発明の技術は、コンピュータや携帯電話など、ストリームデータを送受信する通信装置全般に利用可能である。
【００７０】
ＩＰ処理部１７８、プロトコル検出部１７６、ＵＤＰ処理部１７４の機能を有する回路を、一つの半導体基板上に搭載してもよい。さらに、セキュリティ処理部１７２、コーデック処理部１４０、ＣＰＵ１１０などの回路を搭載してもよい。これにより、通信装置の小型化、軽量化、高速化を図ることができる。
【００７１】
【発明の効果】
本発明によれば、複数の通信プロトコルによるデータ通信を効率よく処理することができる。また、比較的簡便な回路構成により、高速でリアルタイムな通信を実現することができる。
【図面の簡単な説明】
【図１】第１の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。
【図２】第１の実施の形態に係る通信方法の手順を示すフローチャートである。
【図３】第２の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。
【図４】第３の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。
【図５】第４の実施の形態に係る通信装置の一例としてのビデオ電話装置の全体構成を示す図である。
【図６】第５の実施の形態に係る通信装置の一例としてのデジタルカメラの全体構成を示す図である。
【図７】第６の実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。
【図８】第６の実施の形態に係るインターネット電話装置のパケット受信部の内部構成を示す図である。
【図９】第６の実施の形態におけるパケットの受信手順を示すフローチャートである。
【図１０】第６の実施の形態に係るインターネット電話装置のＩＰ判別部の内部構成を示す図である。
【図１１】第６の実施の形態におけるパケットのパケット処理手順を示すフローチャートである。
【符号の説明】
２０インターネット、１００インターネット電話装置、１３０ネットワークインターフェース部、１４０コーデック処理部、１５０マイク、１６０スピーカ、１７０プロトコル処理部、１７２セキュリティ処理部、１７４ＵＤＰ処理部、１７６プロトコル検出部、１７８ＩＰ処理部、１８０画像入力部、１８２撮像部、１８４ＵＤＰ判別部、１８６ＩＰ判別部、１９０表示装置、１９２パケット受信部、１９３受信バッファ、１９４パケット判別部、１９５制御部、２００ビデオ電話装置、３００デジタルカメラ。

Claims

ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットが、データの送受信に先立って装置間で接続を確立することを要する第１の通信方式により送られたパケットであったとき、そのパケットをソフトウェアにより処理するための汎用回路と、
受信したパケットが、装置間での接続の確立を要しない第２の通信方式により送られたパケットであったとき、そのパケットを処理するための専用回路と、
受信したパケットが、どの通信方式により送られたかを検出する検出部と、を備え、
前記検出部により、前記第１の通信方式により送られたパケットが検出されたとき、前記検出部は、そのパケットを、前記汎用回路を介さずに、直接前記専用回路へ送ることを特徴とする通信装置。
ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットが、送信パケットの到着確認を行う第１の通信方式により送られたパケットであったとき、そのパケットをソフトウェアにより処理するための汎用回路と、
受信したパケットが、送信パケットの到着確認を行わない第２の通信方式により送られたパケットであったとき、そのパケットを処理するための専用回路と、
受信したパケットが、どの通信方式により送られたかを検出する検出部と、を備え、
前記検出部により、前記第１の通信方式により送られたパケットが検出されたとき、前記検出部は、そのパケットを、前記汎用回路を介さずに、直接前記専用回路へ送ることを特徴とする通信装置。
ネットワークを介してパケットを送信する送信部をさらに備え、
送信するパケットが、前記第１の通信方式により送られるとき、そのパケットを前記汎用回路により処理し、
送信するパケットが、前記第２の通信方式により送られるとき、そのパケットを前記専用回路により処理することを特徴とする請求項１または２に記載の通信装置。
ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットがフラグメント化されたパケットであったとき、そのパケットをソフトウェアにより処理するために汎用回路へ送り、受信したパケットがフラグメント化されていないパケットであったとき、そのパケットをハードウェアにより処理するために専用回路へ送る判別部と、
を備えることを特徴とする通信装置。
ネットワークを介して送られたパケットを受信する受信部と、
受信したパケットがフラグメント化されたパケットであったとき、そのパケットをソフトウェアにより処理するために汎用回路へ送り、受信したパケットがフラグメント化されていないパケットであったとき、そのパケットをハードウェアにより処理するために第１の専用回路へ送る第１の判別部と、
前記第１の専用回路により処理したパケットが、データの送受信に先立って装置間で接続を確立することを要する第１の通信方式により送ら
れたパケットであったとき、そのパケットを前記汎用回路に送り、前記第１の専用回路により処理したパケットが、装置間での接続の確立を要しない第２の通信方式により送られたパケットであったとき、そのパケットをハードウェアにより処理するための第２の専用回路へ送る第２の判別部と、
を備えることを特徴とする通信装置。
パケットを受信したときに、そのパケットの通信方式を検出する工程と、
前記通信方式に応じて、そのパケットを処理すべき回路にパケットのデータを送る工程と、を含み、
前記検出する工程は、パケットのヘッダを解析することにより、フラグメント化されたパケットであるか、フラグメント化されていないパケットであるかを検出し、
前記データを送る工程は、前記フラグメント化されたパケットを、ソフトウェア処理するための汎用回路に送り、前記フラグメント化されていないパケットを、そのパケットを処理するための専用回路に送ることを特徴とする通信方法。