JP4201719B2

JP4201719B2 - 通信装置

Info

Publication number: JP4201719B2
Application number: JP2004027403A
Authority: JP
Inventors: 一晃岡本; 英雄廣野
Original assignee: Sanyo Electric Co Ltd
Current assignee: Sanyo Electric Co Ltd
Priority date: 2004-02-03
Filing date: 2004-02-03
Publication date: 2008-12-24
Anticipated expiration: 2024-02-03
Also published as: JP2005223459A

Description

本発明は、通信技術に関し、特に、順序を有する一連のパケット群を受信する通信装置及び通信方法に関する。

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

音声や映像などの大量のストリームデータをネットワーク経由で伝送する場合、通常、データを分割し、パケット化して伝送する。このとき、インターネット電話や映像配信サービスなどのように、リアルタイム性が重要となる用途においては、リアルタイム性を確保するために、送信先への到着確認を省略するＵＤＰ（User Datagram Protocol）などのプロトコルが用いられている。図４は、インターネット電話におけるデータパケットであるＩＰ（Internet Protocol）パケットの構成を示す図である。ＩＰパケットは、ＩＰヘッダ、ＵＤＰヘッダ、ＲＴＰヘッダ、ＲＴＰデータを含む。ＲＴＰパケットは、前記のＲＴＰヘッダとＲＴＰデータからなる。ＵＤＰパケットは、前記のＵＤＰヘッダとＲＴＰパケットからなる。ＵＤＰは、接続の確立を要さず、パケットを次々に送出することが可能であるため、通話音声を送るなどのリアルタイムな通信に適している。
特開２００１−２２３７４８号公報

しかしながら、送信元の装置から次々に送出されるＵＤＰパケットは、送出された順に送信先のインターネット電話装置に到着するとは限らず、途中の通信経路の状況により、順番が入れ替わったり、消失したりすることがある。このような場合であっても、データの品質をできる限り損なわず、かつ、リアルタイムな再生を可能とする技術が求められる。

本発明はこうした状況に鑑みてなされたものであり、その目的は、順序を有する一連のパケット群を受信し、適切かつ効率的に処理する技術を提供することにある。

本発明のある態様は、通信装置に関する。この通信装置は、順序を有する一連のパケット群を受信する受信手段と、前記順序に関する情報を取得する取得手段と、前記パケット群のデータをメモリに格納する際に、前記パケットのデータが前記メモリにおいて順序通りに配列するように、前記順序を反映した書込みアドレスを生成する書込みアドレス生成手段と、を備えることを特徴とする。

このような構成によれば、音声や映像などのストリーミングデータを、順次を有する一連のパケット群として伝送するときに、受信したパケットの順番が入れ替わっている場合であっても、メモリ上で順序通りに再配列させることができるので、読み出し時のメモリアクセスを高速化することができる。また、パケットの順序を入れ替える処理の負荷を低減することができる。

前記メモリは、前記順序に関する情報をタグとしてアクセスする連想メモリにより構成されてもよい。前記取得手段は、前記パケットのヘッダ情報を参照して、前記順序に関する情報を取得してもよい。

通信装置は、前記メモリから前記パケットのデータを読み出す際に、順序通りに配列されたパケットのデータを読み出すために、読出しアドレスを順次インクリメントする読出しアドレス生成手段を更に備えてもよい。

通信装置は、所定の時点よりも過去の順序のパケットを受信したときに、前記メモリに格納せずに破棄してもよい。通信装置は、既に読み出されたパケットよりも過去の順序のパケットを受信したときに、前記メモリに格納せずに破棄してもよい。これにより、メモリを効率良く利用することができる。

前記メモリは、前記パケットのデータの書込み及び読出しの状況を示すフラグ情報を格納する領域を含んでもよい。このフラグ情報により、書込み処理と読出し処理の対応が実現され、同期メモリ方式のアクセスが可能となる。前記パケットのデータが前記メモリに正常に書き込まれたときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されてもよい。前記メモリは、前記パケットのデータを読み出すときに、そのパケットのデータが前記メモリに格納されていない場合に、そのデータを補完するための補完データのアドレスを格納する領域を含んでもよい。前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記補完データを読み出してもよい。これにより、データが欠落している場合であっても、データの品質を向上させることができる。

前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記フラグ情報として、読み出しエラーを示す情報が格納されてもよい。前記パケットのデータを書き込むときに、前記フラグ情報として、読み出しエラーを示す情報が格納されている場合は、そのパケットのデータを前記メモリに格納せずに破棄してもよい。

通信装置は、前記メモリから前記パケットのデータを読み出すときに、そのパケットのデータが前記メモリに格納されていない場合に、そのデータを補完するための補完データを予め生成する補完データ生成部を更に備えてもよい。前記補完データ生成部は、既に受信したパケットのデータに基づいて、前記補完データを生成してもよい。これにより、補完データの品質を向上させることができる。

通信装置は、前記補完データ生成部が生成した補完データを格納する補完データ格納部を更に備え、前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記補完データ格納部に格納された補完データを読み出してもよい。

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

本発明によれば、順序を有する一連のパケット群を受信し、適切かつ効率的に処理する技術を提供することができる。

図１は、本発明の実施の形態に係る通信装置の一例としてのインターネット電話装置１００の全体構成を示す。インターネット電話装置１００は、インターネット２０を介して、他のインターネット電話装置１００との間で通話を行うための装置である。インターネット電話装置１００は、主に、ソフトウェア処理を実行するための汎用回路であるＣＰＵ１１０、プログラムエリアまたはワークエリアとして利用されるメモリ１２０、インターネット２０を介してパケットを送受信する受信手段の一例であるネットワークインタフェース１３０、ネットワークインタフェース１３０が受信したパケットを一時的に格納する受信ユニット２００、音声信号を入力するマイク１５０、音声信号を出力するスピーカ１６０、及びこれらの構成を電気的に接続するバス１０２を備える。

本実施の形態のインターネット電話装置１００では、ＲＴＰ（Real-time Transport Protocol）を利用して音声信号を送受信する。ＲＴＰは、オーディオやビデオなどのデータストリームをリアルタイムに配送することを目的として定められたデータ転送プロトコルである。ＲＴＰは、接続の確立を要さず、パケットを次々に送出することが可能なＵＤＰタイプのデータ転送プロトコルであるため、プロトコル処理が簡単で、かつ高速な通信が可能であり、通話音声を送るなどのリアルタイムな通信に適している。しかしながら、送信元の装置から次々に送出されるＲＴＰパケットは、送出された順にインターネット電話装置１００に到着するとは限らず、途中の通信経路の状況により、順番が入れ替わったり、消失したりすることがある。

従来、受信側の装置では、データの順番を整列させたり、欠落したデータを補完したりするために、一定時間分のデータを保持するための十分な大きさを有する受信バッファを設ける必要があった。また、データの整列や補完などの処理を、ＣＰＵ又はＤＳＰなどにより実行されるソフトウェアにより実現する場合、ＣＰＵやＤＳＰなどの処理負荷が大きくなるという問題があった。このような処理をリアルタイムに実行するために、処理能力の高いＣＰＵ又はＤＳＰを搭載すると、装置のコストが増大するという問題があり、コストを抑えるために比較的処理能力の低いＣＰＵ又はＤＳＰを搭載すると、処理が追随できずにリアルタイム性が損なわれるという問題がある。また、後者の場合に、リアルタイム性を確保するために、データの入れ替わりや欠落を無視して処理すると、データの品質が低下するという問題がある。

本実施の形態では、受信したＲＴＰパケットを適切かつ効率的に処理するために、受信ユニット２００への格納時にパケットの順番を入れ替えて順序通りに整列させたり、消失したデータを補完したりするための技術を提案する。

まず、インターネット電話装置１００がパケットを受信したときの動作の概要について説明する。ネットワークインタフェース１３０が受信したパケットは、受信ユニット２００に一時的に格納される。受信ユニット２００に待避されたパケットは、ＣＰＵ１１０により順次読み出されて処理される。具体的には、ＣＰＵ１１０は、パケットが自装置に割り当てられたＩＰアドレスに宛てられたものであるか否かを判断して、他装置宛のパケットを破棄し、自装置宛てのパケットのみを次の処理へ移す。つづいて、ＣＰＵ１１０は、ヘッダ情報などからパケットの種別を判断して、それぞれのパケットに対して必要な処理を実行する。受信したパケットが音声信号を含むＲＴＰパケットであった場合、ＣＰＵ１１０は、圧縮符号化されていた通話音声信号を復号し、スピーカ１６０に出力する。

上述の例では、ネットワークインタフェース１３０が受信したパケットを、まず受信ユニット２００に待避した後、ＣＰＵ１１０により読み出して処理したが、別の例では、ＣＰＵ１１０又はネットワークインタフェース１３０が、受信したパケットのヘッダなどをチェックして必要な処理を行ってから、パケットを受信ユニット２００に待避してもよい。この場合、ＲＴＰパケットのみを受信ユニット２００に格納するようにしてもよい。

つづいて、インターネット電話装置１００が音声信号を含むデータを送信するときの動作の概要について説明する。マイク１５０から入力された音声信号は、ＣＰＵ１１０により符号化され、必要に応じて暗号化された後、パケット化される。生成されたＲＴＰパケットは、ネットワークインタフェース１３０を介して、インターネット２０に送出される。

上述した例では、パケットの処理をＣＰＵ１１０が行ったが、別の例では、専用のハードウェアによりパケットを処理してもよい。例えば、インターネット電話装置１００は、ＩＰによる通信のための各種処理を行うＩＰ処理部、ＵＤＰによる通信のための各種処理を行うＵＤＰ処理部、音声信号の圧縮符号化処理および復号処理を行うコーデック処理部、暗号化された受信データの復号処理又は送信データの暗号化処理を行う暗号処理部などを備えてもよく、これらの機能ブロックは、専用のハードウェア回路により実現されてもよい。これにより、データの処理を高速化し、リアルタイム性を向上させることができる。

図２は、受信ユニット２００の内部構成を示す。受信ユニット２００は、受信したパケットを一時的に格納する受信バッファ２０４と、受信バッファ２０４に対するデータの書き込み及び読み出しを制御する制御部２０２を含む。制御部２０２は、取得手段の一例であるヘッダ抽出部２１０及び識別子抽出部２２０と、書込みアドレス生成部２３０と、読出しアドレス生成部２４０と、読出しアドレス更新部２５０とを含む。制御部２０２は、受信バッファ２０４と同じチップ上に構成された回路により実現されてもよい。これにより、ＣＰＵ１１０を介さずに、受信したＲＴＰパケットを順序通りに再配列させて受信バッファ２０４に格納することができるので、ＣＰＵ１１０の負荷を大幅に軽減することができる。

図３は、受信バッファ２０４のデータ構造を示す。受信バッファ２０４は、識別子抽出部２２０により抽出された順序に関する情報をタグとしてアクセスする連想メモリにより構成されており、タグ部３００、データ格納部３０２、及びポインタ部３０４を含む。タグ部３００には、順序に関する情報３０８とフラグ３０６が格納される。フラグ３０６は、データの書き込み状況を示し、受信したパケットのデータがデータ格納部３０２に正常に格納されると書込みフラグがセットされ、データが正常に読み出されると書込みフラグがクリアされる。また、後述するように、データ格納部３０２にデータが格納されていないときに読出しが行われると、読出しエラーフラグがセットされる。ポインタ部３０４は、パケットが通信途中で破棄されていたり、遅延しているなどの理由により、読出し時にデータ格納部３０２にデータが格納されていないときに、代わりに挿入される代替データのアドレスを保持する。

図２に戻り、受信ユニット２００の他の構成の説明を続ける。ヘッダ抽出部２１０は、受信したＲＴＰパケットからヘッダ情報を抽出する。図４に示すように、ＲＴＰパケットは、ＵＤＰパケットのデータ部に格納されており、その先頭にＲＴＰヘッダが格納されている。図５に、ＲＦＣ１８８９において規定されたＲＴＰヘッダの構成を示す。ＲＴＰヘッダは、ＲＴＰのバージョン番号Ｖ（ＲＦＣ１８８９では「２」）、調整用ビット（パディング）Ｐ、拡張ビットＸ、貢献ソース識別子の数ＣＣ、マーカＭ、ペイロードタイプＰＴ、シーケンスナンバー、タイムスタンプ、同期ソース（ＳＳＲＣ）識別子、及び貢献ソース（ＣＳＲＣ）識別子を含む。ヘッダ抽出部２１０は、このＲＴＰヘッダを抽出する。識別子抽出部２２０は、ＲＴＰヘッダ中のシーケンスナンバー又はタイムスタンプを抽出する。シーケンスナンバーは、データを順番通りに再構成するために、又は、パケットの損失を検出するために、ＲＴＰヘッダに格納される情報である。タイムスタンプは、ＲＴＰパケットに含まれるデータの時間情報を示す。

書込みアドレス生成部２３０は、識別子抽出部２２０が抽出したシーケンスナンバー又はタイムスタンプ情報を参照して、受信バッファ２０４においてＲＴＰパケットがデータの順序通りに配列して格納されるように、受信バッファ２０４に対するデータの書込みアドレスを生成する。したがって、ＲＴＰパケットが順序通りに到着しなかった場合であっても、受信バッファ２０４には、ＲＴＰパケットが順序通りに配列されて格納される。これにより、受信バッファ２０４からデータを読み出す時に、メモリアクセスのオーバーヘッドを低減し、読み出しに要する時間を短縮することができるので、データの読出しを高速化することができ、ひいてはストリームデータの再生のリアルタイム性を向上させることができる。書込みアドレス生成部２３０により生成された書込みアドレスに、パケットのデータが正常に格納されると、正常に書込みが行われたことを示す書込みフラグがフラグ３０６に格納される。

ストリームデータをリアルタイムに再生するために、ストリームデータの全てを格納可能なサイズの受信バッファ２０４を用意するのは効率的ではない。本実施の形態では、受信バッファ２０４をサイクリックに利用することにより、比較的小容量の受信バッファ２０４を利用してリアルタイムな再生を可能とする。すなわち、既に再生が終わったデータの格納領域は所定のタイミングでリフレッシュし、後続のパケットのデータの格納領域として利用する。

この場合、あるパケットを受信してデータを受信バッファ２０４に格納した後に、そのアドレスに過去に格納されるはずであったパケットが、いわゆる「周回遅れ」で到着した場合、遅延して到着したパケットが上書きされる恐れがある。このような事態を避けるために、書込みアドレス生成部２３０は、所定の時点よりも過去の順序のパケットを受信したときに、そのパケットを受信バッファ２０４に格納せずに破棄してもよい。「所定の時点」は、現在再生中のデータの順序（時間）であってもよい。ストリームデータを再生しているとき、現在再生中のデータよりも過去のデータを含むパケットが遅延して到着した場合、そのデータは再生されないので破棄してもよい。これにより、これから再生されるデータが、遅延して到着した過去のデータに上書きされて失われてしまう事態を回避することができる。ストリームデータが、例えばＭＰＥＧ４などでエンコードされている場合、現在再生中のフレーム（ピクチャ）よりも過去のデータであっても、復号時に参照されるフレームであれば、破棄せずに受信バッファ２０４に格納してもよい。この場合、「所定の時点」は、現在再生中のデータの順序を基点として、１又は数ＧＯＰ分過去の時点であってもよい。書込みアドレス生成部２３０は、データを読み出し中の読出しアドレスを取得して、その読出しアドレスに格納されたパケットよりも過去の順序のパケットを破棄してもよい。また、書込みアドレス生成部２３０は、所定時間以上遅延して到着したパケットを破棄してもよい。

書込みアドレス生成部２３０は、所定のサイズの書込みウィンドウを設定し、その書込みウィンドウ内に格納されるべきパケット以外のパケットを受信したときには、そのパケットを受信バッファ２０４に格納せずに破棄してもよい。書込みウィンドウは、例えば、既に読み出されて再生が終わったパケットのアドレスを開始アドレスとして、パケットのサイズ、受信レート、再生レート、受信バッファ２０４のサイズなどに基づいて決定されたサイズの領域に設定されてもよい。ストリームデータをリアルタイムに再生しているとき、既に再生が終わったデータを含むパケットが遅延して到着しても、そのパケットは再生されないので、受信バッファ２０４に格納せずに破棄してもよい。これにより、インターネット電話装置１００の処理負荷が低減されるとともに、受信バッファ２０４を効率良く利用することができる。

読出しアドレス生成部２４０は、データの読出し要求を受け付けると、データの先頭のアドレスを生成する。読出しアドレス更新部２５０は、読出しアドレスを１データ分インクリメントするよう読出しアドレス生成部２４０に指示してもよい。読出しアドレス生成部２４０は、以降、読出しアドレス更新部２５０からの指示に従い、順次読出しアドレスを１データ分ずつインクリメントしてもよい。これにより、受信バッファ２０４に順序通りに格納されたデータを順次読み出すことができる。データがデータ格納部３０２から正常に読み出されると、フラグ３０６の書込みフラグがクリアされる。

インターネット電話装置１００は、パーソナルコンピュータなどとは異なり、比較的処理性能の低いＣＰＵを搭載してコストを抑える場合が多いが、本実施の形態の技術によれば、処理性能の低いＣＰＵであっても、通話音声データを含むパケットを効率よく処理し、リアルタイムに再生することが可能となる。また、ＣＰＵ１１０に余力ができるため、通話中に他のアプリケーションを実行することが可能となり、新たなサービスを提供することもできる。

制御部２０２の構成は、ハードウエア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウエア的にはメモリにロードされたプログラムなどで実現できる。図２では、それらの連携によって実現される機能ブロックを描いているので、これらの機能ブロックがハードウエアのみ、ソフトウエアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

図６は、受信バッファ２０４のポインタ部３０４の設定例を示す。ポインタ部３０４は、前述したように、ＲＴＰパケットが通信途中で遅延したり、破棄されたり、破壊されたりして、正しいデータが受信できなかった場合、その部分のデータを補完する他のデータへのポインタを格納する。データを読み出すときに、そのデータが未受信であったり、破壊されていた場合は、ポインタ部３０４に格納されたアドレスに存在する補完データが代わりに読み出される。これにより、パケットが遅延したり、通信経路で廃棄されたりして、データが正しく受信できなかった場合であっても、適切にデータを補完することができ、データの品質を向上させることができる。

補完データとしては、例えば、１つ前のデータであってもよいし、所定位置のデータであってもよいし、補間データ生成部２６０により生成された補間データであってもよい。ここで、「補完」は、欠落したデータを補って完全にすることをいい、固定的に定められたデータで補ってもよいし、計算により導かれたデータで補ってもよい。所定の規則にしたがって算出されたデータで補う場合は、「補間」といってもよく、ここでは、その意味で、「補間データ生成部２６０」と呼んでいる。補間データ生成部２６０は、過去に受信したデータに基づいて、所定のアルゴリズムにより補間データを算出する。補間データ生成部２６０は、例えば、過去に受信したデータの平均値を算出して補間データを生成してもよいし、過去に受信したデータの最大値、最小値、中央値、最頻値、などにの統計値に基づいて補間データを生成してもよい。補間データ生成部２６０が生成した補間データは、補間データ格納部２７０に格納される。補間データ生成部２６０は、ＣＰＵ１１０などにより実現されてもよい。補間データ格納部２７０は、メモリ１２０に設けられてもよいし、受信ユニット２００内に設けられてもよい。

補完データが読み出されたとき、そのデータの格納領域のフラグ３０６に読出しエラーフラグがセットされる。書込みアドレス生成部２３０は、エラーフラグが既にセットされているデータを含むパケットを受信したとき、そのデータは既に補完データにより補完されて再生されているので、そのパケットを受信バッファ２０４に格納せずに破棄する。これにより、無用な処理を省き、処理負荷を低減することができる。エラーフラグは、受信バッファ２０４の格納領域をリフレッシュするときにクリアされる。このとき、ポインタ部３０４には、デフォルト値として、所定のアドレス、例えば補間データ格納部２７０のアドレスが格納されてもよい。

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

実施の形態では、通信装置の一例としてインターネット電話装置について説明したが、本実施の形態の技術は、ルータ、パーソナルコンピュータ、テレビジョン受信装置など、順序を有する一連のパケット群を受信可能な任意の装置に適用可能である。

実施の形態に係る通信装置の一例としてのインターネット電話装置の全体構成を示す図である。受信ユニットの内部構成を示す図である。受信バッファのデータ構造を示す図である。ＩＰパケットの構成を示す図である。ＲＴＰヘッダの構成を示す図である。受信バッファのポインタ部を示す図である。

符号の説明

１００インターネット電話装置、１１０ＣＰＵ、１２０メモリ、１３０ネットワークインタフェース、２００受信ユニット、２０２制御部、２０４受信バッファ、２１０ヘッダ抽出部、２２０識別子抽出部、２３０書込みアドレス生成部、２４０読出しアドレス生成部、２５０読出しアドレス更新部、２６０補間データ生成部、２７０補間データ格納部、３００タグ部、３０２データ格納部、３０４ポインタ部、３０６フラグ、３０８アドレス。

Claims

順序を有する一連のパケット群を受信する受信手段と、
前記順序に関する情報を取得する取得手段と、
前記パケット群のデータをメモリに格納する際に、前記パケットのデータが前記メモリにおいて順序通りに配列するように、前記順序を反映した書込みアドレスを生成する書込みアドレス生成手段と、
を備えることを特徴とする通信装置。
前記メモリは、前記順序に関する情報をタグとしてアクセスする連想メモリにより構成されることを特徴とする請求項１に記載の通信装置。
前記取得手段は、前記パケットのヘッダ情報を参照して、前記順序に関する情報を取得することを特徴とする請求項１又は２に記載の通信装置。
前記メモリから前記パケットのデータを読み出す際に、順序通りに配列されたパケットのデータを読み出すために、読出しアドレスを順次インクリメントする読出しアドレス生成手段を更に備えることを特徴とする請求項１から３のいずれかに記載の通信装置。
所定の時点よりも過去の順序のパケットを受信したときに、前記メモリに格納せずに破棄することを特徴とする請求項１から４のいずれかに記載の通信装置。
既に読み出されたパケットよりも過去の順序のパケットを受信したときに、前記メモリに格納せずに破棄することを特徴とする請求項５に記載の通信装置。
前記メモリは、前記パケットのデータの書込み及び読出しの状況を示すフラグ情報を格納する領域を含むことを特徴とする請求項１から６のいずれかに記載の通信装置。
前記パケットのデータが前記メモリに正常に書き込まれたときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されることを特徴とする請求項７に記載の通信装置。
前記メモリは、前記パケットのデータを読み出すときに、そのパケットのデータが前記メモリに格納されていない場合に、そのデータを補完するための補完データのアドレスを格納する領域を含むことを特徴とする請求項１から８のいずれかに記載の通信装置。
前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記補完データを読み出すことを特徴とする請求項９に記載の通信装置。
前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記フラグ情報として、読み出しエラーを示す情報が格納されることを特徴とする請求項８から１０のいずれかに記載の通信装置。
前記パケットのデータを書き込むときに、前記フラグ情報として、読み出しエラーを示す情報が格納されている場合は、そのパケットのデータを前記メモリに格納せずに破棄することを特徴とする請求項１１に記載の通信装置。
前記メモリから前記パケットのデータを読み出すときに、そのパケットのデータが前記メモリに格納されていない場合に、そのデータを補完するための補完データを予め生成する補完データ生成部を更に備えることを特徴とする請求項１から１２のいずれかに記載の通信装置。
前記補完データ生成部は、既に受信したパケットのデータに基づいて、前記補完データを生成することを特徴とする請求項１３に記載の通信装置。
前記補完データ生成部が生成した補完データを格納する補完データ格納部を更に備え、
前記パケットのデータを読み出すときに、前記フラグ情報として、正常に書き込まれた旨の情報が格納されていない場合は、前記補完データ格納部に格納された補完データを読み出すことを特徴とする請求項１３又は１４に記載の通信装置。