JP7616111B2 - 通信装置、通信方法、及び通信プログラム - Google Patents

Description

本発明は、受信したパケットを格納するバッファを有する通信装置、通信方法、及び通信プログラムに関する。

通信装置でパケットを受信する場合、バッファに受信したパケットを格納するとともに、送信時にバッファからパケットを読み出して送信する。もっとも、バッファの容量との関係で、受信したパケットのバッファへの格納やバッファからのパケットの破棄を制御する必要がある。

特許文献１には、伝送されたパケットを一時的に保管するキューを有し、キューに入るパケット長の和であるキュー長があらかじめ定められた閾値よりも小さい場合はパケットを順次キューに入れ、予め定められた閾値よりも大きい場合はパケットの廃棄レベルによって格納されるキューの位置を変えることが開示されている。

特許文献２には、キュー長が最大キュー長よりも大きい場合はパケットを破棄することが記載されている。

特開２００３－１７９６３３号公報 特開２００６－１１５１９７号公報

ここで、本発明者は、以下の課題を見出した。
特許文献１や特許文献２のように、パケット単位でバッファへの格納やバッファからの破棄を行う場合、上位レイヤで必要とするデータに欠損が生じる可能性がある。その場合、送信したデータが利用できない場合があり、効率的なデータ送信を阻害する。

そこで、本発明は、データの欠損発生の可能性を低減することにより、効率的なデータ送信を行うことができる通信装置等を実現することを目的とする。

本開示の通信装置（１００）は、
第１の装置（１０）からパケットを受信する受信部（１０１）と、
前記パケットが属する、上位レイヤにおけるデータ単位であるチャンクを識別するパケット識別部（１０２）と、
前記パケットを格納するバッファ（１０４）と、
前記チャンクを単位として、前記パケットの前記バッファへの格納及び前記パケットの前記バッファからの破棄を制御するバッファ制御部（１０５）と、
前記バッファから前記パケットを読み出し、第２の装置（２０）に送信する送信部（１０６）と、を有する。

なお、特許請求の範囲、及び本項に記載した発明の構成要件に付した括弧内の番号は、本発明と後述の実施形態との対応関係を示すものであり、本発明を限定する趣旨ではない。

上述のような構成により、本開示の通信装置等は、データの欠損発生の可能性を低減し、効率的なデータ送信を行うことができる。

実施形態１の通信装置の構成を示す構成図 実施形態１の通信装置のパケット情報保存部に保存されているパケット情報を示す説明図 実施形態１の通信装置のパケット識別部の具体的な動作例１を示す説明図 実施形態１の通信装置のパケット識別部の具体的な動作例２を示す説明図 実施形態１の通信装置のパケット識別部の具体的な動作例３を示す説明図 実施形態１の通信装置のバッファ制御部の具体的な動作例１を示す説明図 実施形態１の通信装置のバッファ制御部の具体的な動作例２を示す説明図 実施形態１の通信装置のバッファ制御部の具体的な動作例３を示す説明図 実施形態１の通信装置の動作を示すフロー図 実施形態２の通信装置の構成を示す構成図 実施形態２の通信装置のパケット識別部の具体的な動作例を示す説明図 実施形態２の通信装置のパケット情報保存部に保存されているパケット情報を示す説明図 送信元端末装置、実施形態１又は２の通信装置、及び宛先端末装置の組み合わせの具体例を示す説明図

以下、本発明の実施形態について、図面を参照して説明する。

なお、本発明とは、特許請求の範囲又は課題を解決するための手段の項に記載された発明を意味するものであり、以下の実施形態に限定されるものではない。また、少なくともかぎ括弧内の語句は、特許請求の範囲又は課題を解決するための手段の項に記載された語句を意味し、同じく以下の実施形態に限定されるものではない。

特許請求の範囲の従属項に記載の構成及び方法は、特許請求の範囲の独立項に記載の発明において任意の構成及び方法である。従属項に記載の構成及び方法に対応する実施形態の構成及び方法、並びに特許請求の範囲に記載がなく実施形態のみに記載の構成及び方法は、本発明において任意の構成及び方法である。特許請求の範囲の記載が実施形態の記載よりも広い場合における実施形態に記載の構成及び方法も、本発明の構成及び方法の例示であるという意味で、本発明において任意の構成及び方法である。いずれの場合も、特許請求の範囲の独立項に記載することで、本発明の必須の構成及び方法となる。

実施形態に記載した効果は、本発明の例示としての実施形態の構成を有する場合の効果であり、必ずしも本発明が有する効果ではない。

複数の実施形態がある場合、各実施形態に開示の構成は各実施形態のみで閉じるものではなく、実施形態をまたいで組み合わせることが可能である。例えば一の実施形態に開示の構成を、他の実施形態に組み合わせてもよい。また、複数の実施形態それぞれに開示の構成を集めて組み合わせてもよい。

発明が解決しようとする課題に記載した課題は公知の課題ではなく、本発明者が独自に知見したものであり、本発明の構成及び方法と共に発明の進歩性を肯定する事実である。

１．実施形態１
（１）本実施形態の通信装置１００の全体構成
図１を用いて、実施形態１の通信装置１００の構成を説明する。通信装置１００は、受信部１０１、パケット識別部１０２、パケット情報保存部１０３、バッファ１０４、バッファ制御部１０５、送信部１０６を有する。

通信装置１００は、汎用のＣＰＵ（Central Processing Unit）、ＲＡＭ等の揮発性メモリ、ＲＯＭ、フラッシュメモリ、又はハードディスク等の不揮発性メモリ、各種インターフェース、及びこれらを接続する内部バスで構成することができる。そして、これらのハードウェア上でソフトウェアを実行することにより、図１に記載の各機能ブロックの機能を発揮させるように構成することができる。
もちろん、通信装置１００を、ＬＳＩ等の専用のハードウェアで実現してもよい。
以上は、他の実施形態の通信装置においても同様である。

通信装置１００は、本実施形態では半完成品としての電子制御装置（ＥＣＵ（Electric Control Unit）、以下ＥＣＵと略する。）の形態を想定しているが、これに限らない。例えば、部品の形態としては、半導体回路や半導体モジュール、半完成品の形態としては、電子制御装置、電子制御ユニット、システムボード、完成品の形態としては、サーバ、ワークステーション、パーソナルコンピュータ（ＰＣ）、タブレット、モバイルルータ、スマートフォン、携帯電話、ナビゲーションシステムが挙げられる。
なお、通信装置１００は、単一のＥＣＵの他、複数のＥＣＵで構成されてもよい。
以上は、他の実施形態の通信装置においても同様である。

受信部１０１は、送信元端末装置１０（「第１の装置」に相当）から、送信元端末装置１０で生成された「パケット」を受信する。パケットは、例えば送信元端末装置１０で実行している送信元アプリケーションで生成されたデータを、送信元端末装置１０の図示しない制御部等で実行されるパケタイズやフラグメントにより、複数のパケットに分割されて送信されたものである。
ここで、「パケット」とは、情報通信における伝送単位のデータのかたまりをいい、狭義のパケットの他、フレーム、セグメント等、その名称を問わない。

送信元アプリケーションはデータを生成する任意のアプリケーションである。例えば送信元端末装置１０に接続されたカメラで撮像された画像データを例えばＨ．２６４／ＭＰＥＧ４ ＡＶＣ規格に基づき、Ｉフレーム、Ｐフレーム、及びＢフレームデータに圧縮して、宛先端末装置２０の宛先アプリケーションに送信する映像伝送アプリケーションが挙げられる。このとき、圧縮された各フレームデータは、送信元端末装置１０のネットワークカード（ＮＩＣ：Network Interface Card）でフラグメントされることにより、ＮＩＣのＭＴＵ（Maximum Transmission Unit）サイズのパケットに分割されて送信される。

送信元端末装置１０と通信装置１００とは、通信回線を介して接続されている。
通信回線は、無線通信回線、有線通信回線のいずれであってもよい。
無線通信回線の例として、移動通信システムに基づく通信回線が挙げられ、例えば、Ｗ－ＣＤＭＡ（Wideband Code Division Multiple Access）、ＨＳＰＡ（High Speed Packet Access）、ＬＴＥ（Long Term Evolution）、ＬＴＥ－Ａ（Long Term Evolution Advanced）、４Ｇ、又は５Ｇ等の無線通信方式からなる通信回線を用いることができる。この他、例えば、ＩＥＥＥ８０２．１１（Ｗｉ―Ｆｉ（登録商標））、ＩＥＥＥ８０２．１６（ＷｉＭＡＸ（登録商標））、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＵＷＢ（Ultra Wide Band）、又はＤＳＲＣ（Dedicated Short Range Communication）等の無線通信方式からなる通信回線を用いることもできる。
有線通信回線の例として、イーサネット（登録商標）等のＬＡＮ（Local Area Network）、光回線、又は固定電話回線を用いることができる。車載装置の場合は、例えば車載ネットワークであるＣＡＮ（Controller Area Network）、又はＬＩＮ（Local Interconnect Network）を用いることができる。
この他、無線通信回線と有線通信回線とを組み合わせた通信回線であってもよい。

送信元端末装置１０も、通信装置１００と同様、その形態は部品、半完成品、完成品のいずれであってもよい。送信元端末装置１０の具体的な態様は後述する。

パケット識別部１０２は、受信部１０１で受信したパケットを分析することによりパケットに関する情報であるパケット情報を収集し、収集したパケット情報をパケット情報保存部１０３に保存する。
特に本実施形態においては、パケット識別部１０２は、受信部１０１で受信したパケットが属するチャンクを識別する。チャンクとは、上位レイヤにおけるデータ単位をいう。上位レイヤとは、例えばパケットがＯＳＩ参照モデルのネットワーク層（レイヤ３）の通信で使われる場合、トランスポート層（レイヤ４）以上をいう。
チャンクの例として、送信元端末装置１０の送信元アプリケーションが映像伝送アプリケーションである場合、圧縮されたフレームデータ（Ｉフレーム、Ｐフレーム、又はＢフレーム）が挙げられる。

この他、本実施形態では、パケット識別部１０２は、パケットを分析することにより、受信したパケットのパケットサイズ、チャンクサイズ、及び重要度情報、を収集する。
パケット識別部１０２で実行される具体的なチャンクの識別方法、及びチャンク番号の付与方法は後述する。

パケット情報保存部１０３は、パケット識別部１０２で収集したパケット情報を保存する。具体的には、パケット識別部１０２から入力されたパケット情報を入力順に保存している。パケット情報保存部１０３は、不揮発性メモリ又は揮発性メモリのいずれで構成してもよい。

図２は、パケット情報保存部１０３で保存されているパケット情報を示している。
パケット番号は、受信部１０１で受信するパケット毎に、受信部１０１で受信した順にパケット識別部１０２が付与したシリアル番号である。

チャンク番号は、受信部１０１で受信した各パケットを分析することで、パケット識別部１０２が付与する各パケットが属するチャンクを識別するためのシリアル番号である。

パケットサイズは、受信部１０１で受信するパケット毎に、パケット識別部１０２がパケットのサイズを収集したものである。パケットサイズは、ＩＰヘッダ等の識別情報に記載されている場合はその識別情報を記録すればよい。固定長のパケットの場合は、予め定まった固定長のパケットサイズを記録すればよい。

チャンクサイズは、パケット識別部１０２で識別したチャンクのサイズである。チャンクサイズは、例えば同一のチャンク番号が付与されたパケットのパケットサイズを合計することにより求めることができる。具体的には、以下のように求めている。

図２の例では、パケット＃１（チャンク番号＃１）が入力された時点では、チャンク番号＃１が付与されたパケットはまだ１つだけなので、パケットサイズと同じ１５００Ｂがパケット＃１のチャンクサイズに記録される。
次にパケット＃２（チャンク番号＃１）が入力された時点では、チャンク番号＃１が付与されたパケットは２つになるので、先のチャンクサイズ１５００Ｂにパケット＃２のパケットサイズ１５００Ｂを加えた３０００Ｂがパケット＃１及びパケット＃２のチャンクサイズに記録される。
さらにパケット＃３（チャンク番号＃１）が入力された時点では、チャンク番号＃１が付与されたパケットは３つになるので、先のチャンクサイズ３０００Ｂにパケット＃３のパケットサイズ１１５０Ｂを加えた４１５０Ｂがパケット＃１乃至パケット＃３のチャンクサイズに記録される。
パケット＃４（チャンク番号＃２）が入力された時点では、パケット＃４のチャンク番号は先に受信したパケット＃１乃至パケット＃３のチャンク番号と異なるので、パケットサイズと同じ１５００Ｂがパケット＃４のチャンクサイズに記録される。
以下、同様の計算でパケットが入力される毎にチャンクサイズが記録される。

重要度情報は、パケットの重要度を示す情報である。具体的には、送信元端末装置１０でパケット毎に付与された情報や、パケットのペイロードデータの内容に基づきパケット識別部１０２がパケットの分析の結果付与した情報である。パケットの重要度は、送信元アプリケーションの目的や通信装置１００の設置目的に応じて定義することができる。例えば、パケットが動画の画像データの場合、Ｉフレームが欠損するとＰフレームやＢフレームの復号ができなくなるので、Ｉフレームを構成するパケットの重要度を他の種類のフレームを構成するパケットの重要度よりも上げるようにしてもよい。あるいは、通信装置１００が自動車に搭載される車載装置を構成する場合、速度や加速度のような走行状態を直接示す情報の重要度を他の情報の重要度よりも上げるようにしてもよい。図２の場合は、重要度情報を２値、すなわちフラグで示しているが、３段階以上で定義してもよい。

パケット情報保存部１０３に保存されるパケット情報は、後述のバッファ１０４に格納しているパケットに合わせて更新される。例えば、バッファ１０４にパケットが格納された場合は、格納されたパケットのパケット情報がパケット情報保存部１０３に記録される。バッファ１０４からパケットが破棄された場合は、破棄されたパケットのパケット情報がパケット情報保存部１０３から削除される。送信部１０６がバッファ１０４からパケットを読み出して送信した場合は、読み出されたパケットのパケット情報がパケット情報保存部１０３から削除される。

バッファ１０４は、受信部１０１で受信し、パケット識別部１０２でチャンクが識別されたパケットを格納する「バッファ」である。具体的には、受信部１０１で受信したパケットを、破棄されるものを除き受信順に格納する。バッファ１０４も、パケット情報保存部１０３と同様、不揮発性メモリ又は揮発性メモリのいずれで構成してもよい。
ここで、「バッファ」とは、パケットを格納する領域をいい、格納順や読み出し順は任意である。また、バッファには、キューやスタックも含まれる。

本実施形態では、バッファ１０４は入力順に格納し入力順に出力するＦＩＦＯ（First In First Out）の動作をベースとしており、キューとも呼ばれる。もっとも、本実施形態では、出力順は必ずしも入力順とはならない場合もある。

バッファ制御部１０５は、パケットのバッファ１０４への格納や、パケットのバッファ１０４からの破棄を制御する。具体的には、パケット情報保存部１０３に保存されたパケット情報に基づき、「チャンクを単位として」、パケットの格納及び破棄を制御する。
ここで、「チャンクを単位として」とは、バッファへの格納やバッファからの破棄が結果としてチャンク単位であればよく、バッファへ格納する時に同一のチャンクに属する全てのパケットを同時に格納する必要はなく、またバッファから破棄するときに同一チャンクに属する全てのパケットを同時に破棄する必要はない。

バッファ制御部１０５で実行される具体的なパケットの格納方法及び破棄方法は後述する。

送信部１０６は、バッファ１０４からパケットを読み出し、宛先端末装置２０（「第２の装置」に相当）に送信する。パケットの読み出し順はバッファ１０４の入力順と原則同じであるが、本実施形態では必ずしも入力順とはならない場合もある。送信されたパケットは、宛先端末装置２０の宛先アプリケーションで利用される。

宛先アプリケーションは、パケットに格納されたデータを利用するアプリケーションである。例えば、圧縮された画像データを復号して再生する画像再生ソフトが挙げられる。

通信装置１００と宛先端末装置２０とは、通信回線を介して接続されている。
通信回線は、無線通信回線、有線通信回線のいずれであってもよい。無線通信回線の例及び有線通信回線の例は、送信元端末装置１０と通信装置１００との間の通信回線の例として説明した内容と同様である。また、無線通信回線と有線通信回線とを組み合わせた通信回線であってもよいことも同様である。例えば、宛先端末装置２０がインターネットに接続されたサーバ装置である場合、通信装置１００と基地局装置との間は４Ｇや５Ｇの無線通信方式、基地局装置と宛先端末装置２０との間は光回線からなる有線通信方式、を用いることができる。

宛先端末装置２０も、通信装置１００と同様、その形態は部品、半完成品、完成品のいずれであってもよい。宛先端末装置２０の具体的な態様は後述する。

（２）本実施形態の通信装置１００のパケット識別部１０２の詳細
パケット識別部１０２で実行される具体的なチャンク識別方法、及びチャンク番号の付与方法の例を、図３～図５を用いて説明する。

（ａ）パケットの受信間隔に基づきチャンクを識別する例
図３を用いて、パケットの受信間隔に基づきチャンクを識別する例を説明する。
パケット識別部１０２は、受信部１０１で受信するパケットの受信間隔に基づき、チャンクを識別する。

例えば、送信元端末装置１０の映像伝送アプリケーションで画像を圧縮してフレームを送信する場合、図３のようにフレーム毎に単数又は複数個のパケットに分割して送信する。フレームレートが３０ＦＰＳ（Frames per second）であれば各フレームは１／３０ｓ＝３３ｍｓ毎に複数のパケットに分割されて送信される。１つのフレーム中のパケットは連続してバースト的に送信されるので、パケット間の送信間隔は極めて小さい。これに対して、フレームをまたがる場合は、先のフレームの最後のパケットが送信されてから次のフレームの最初のパケットが送信されるまでの時間（Δｘ）はある程度の送信間隔が生じる。Ｉフレームのデータ量はＰフレームやＢフレームのデータ量よりも大きいので、Ｉフレームと他のフレームとの送信間隔やＩフレームが連続する場合の送信間隔はより小さくなる。

そこで、Ｉフレームが連続する場合にも正しい判定ができるようにするため、例えば５ｍｓを基準として、Δｘが５ｍｓより小さければ同一フレームに属するパケット、Δｘが５ｍｓ以上であれば異なるフレームに属するパケットであると判定できる。そして、各フレームを１つのチャンクと識別し、フレーム毎にチャンク番号をインクリメントして付与する。図３の例では、受信順にチャンク番号として＃１、＃２、・・・＃ｍを付与している。このチャンク番号により、パケットがどのチャンクに属するかを識別することができる。

ここでは、Ｈ．２６４／ＭＰＥＧ４ ＡＶＣ規格を用いた動画圧縮を例として挙げたが、静止画圧縮（例えばＪＰＥＧ規格）を用いる場合も同様である。

（ｂ）パケットのＩＰヘッダに基づきチャンクを識別する例
図４を用いて、パケットのＩＰヘッダに基づきチャンクを識別する例を説明する。
パケット識別部１０２は、パケットのＩＰヘッダに含まれる識別子に基づき、チャンクを識別する。

図４で示すＩＰヘッダには、パケットに関する情報が格納されている。ここでは、ＩＰヘッダの識別子に着目する。例えば送信元端末装置１０がフレームデータを１パケットで送信しようとした場合、ＮＩＣでフラグメントが発生しフレームデータは複数のパケットに分割される。このとき、同じフレームに由来する各パケットには同じ内容の識別子が付与されることになる。
すなわち、送信元端末装置１０で送信されるフレームをチャンクと定義した場合、ＩＰヘッダの識別子に基づけば、パケットがどのチャンクに属しているかを識別することができる。本実施形態では、ＩＰヘッダの識別子毎にチャンク番号をインクリメントして付与している。

（ｃ）パケットのペイロードデータに基づきチャンクを識別する例
図５を用いて、パケットのＴＣＰ／ＵＤＰペイロードに基づきチャンクを識別する例を説明する。
パケット識別部１０２は、パケットのＴＣＰ／ＵＤＰペイロードに含まれる識別情報に基づき、チャンクを識別する。

大きなサイズのデータを送信元アプリケーションで小サイズのパケットにパケタイズした場合、送信元アプリケーションはＴＣＰ／ＵＤＰペイロードの先頭に、分割前のデータを示す識別情報を格納する。
すなわち、送信元端末装置１０で送信されるデータをチャンクと定義した場合、ＴＣＰ／ＵＤＰペイロードの識別情報に基づけば、パケットがどのチャンクに属しているかを識別することができる。本実施形態では、ＴＣＰ／ＵＤＰペイロードの識別情報毎にチャンク番号をインクリメントして付与している。

（ｄ）その他のチャンクを識別する例
これらの他、バッファ１０４に格納された際のタイムスタンプからチャンクを識別するようにしてもよい。
あるいは、動画圧縮の場合であって、Ｉフレーム、Ｐフレーム、Ｂフレームの情報がパケットに記録されている場合は、これらの情報に基づきチャンクを識別するようにしてもよい。

（３）本実施形態の通信装置１００のバッファ制御部１０５の詳細
バッファ制御部１０５で実行される具体的なパケットの格納方法及び破棄方法の例を図６～８を用いて説明する。

（ａ）新しいチャンクを格納し、古いチャンクを破棄する例（実施例１）
図６を用いて、新しいチャンクに属するパケットをバッファ１０４に格納し、古いチャンクに属するパケットをバッファ１０４から破棄する例を説明する。
本実施例では、バッファ制御部１０５は、バッファ１０４の容量を超えることを原因としてパケットをバッファ１０４に格納できない場合、このパケットが属するチャンクと異なる他のチャンクに属し、このパケットよりも先にバッファ１０４に格納された格納済パケットをバッファ１０４から破棄する。

図６（ａ）は、従来例のパケットの格納及び破棄の例である。なお、従来はチャンクの視点でもってパケットの格納及び破棄はしていないが、本実施形態との比較で本実施形態における効果を説明するために、従来の例においてもチャンクという語を使用している。

時刻ｔ１において、バッファ１０４にはチャンク１（図面においてはＣ１：以下同様）及びチャンク２に対応するパケットが既に格納されている。そして、新たにチャンク３に対応する５つのパケットがバッファ１０４に格納される場合を想定する。

時刻ｔ２、ｔ３において、チャンク３に対応するパケットが、順次バッファ１０４の空き領域に格納される。しかし、時刻ｔ４においてバッファ１０４の容量が飽和し、チャンク３の３番目のパケットはバッファ１０４に格納することができず、廃棄されてしまう。時刻ｔ５、ｔ６においても同様、４番目及び５番目のパケットは廃棄されてしまう。

結局、時刻ｔ６において、チャンク３に対応するパケットは一部が廃棄されてしまい、チャンク３に対応するすべてのパケットがそろわなくなってしまう。この結果、バッファ１０４に残ったチャンク３に対応するパケットが宛先端末装置２０に送信されたとしても、宛先端末装置２０の宛先アプリケーションで利用することができず、チャンク３に属するパケットの送信が無駄になってしまい、効率的なデータ送信を行うことができない。

図６（ｂ）は、本実施例のパケットの格納及び破棄の例である。
本実施例では、時刻ｔ１～ｔ３までは従来例と同じ処理であるが、時刻ｔ４においてバッファ１０４の容量を超えることを原因としてパケットをバッファ１０４に格納できない場合、チャンク３と異なるチャンクであるチャンク１又はチャンク２に属するパケットであって既にバッファ１０４に格納されたパケット（「格納済パケット」に相当）をバッファ１０４から破棄する。図６（ｂ）の場合、最も時間的に早くバッファ１０４に格納されたチャンク１に属するパケットを破棄している。これにより、チャンク３の３番目のパケットもバッファ１０４に格納される。時刻ｔ５、ｔ６においても同様、４番目及び５番目のパケットもバッファ１０４に格納される。

時刻ｔ６において、チャンク１に属するパケットの全数は破棄されているものの、チャンク２及びチャンク３に属するパケットは欠けることなく格納されている。この結果、宛先端末装置２０の宛先アプリケーションで利用することができないパケットが送信されることがなく、効率的なデータ送信を行うことができる。しかも、結果的に宛先端末装置２０に送信しなかったパケットは、本実施例の方が従来例よりも時間的に古いチャンクに属するパケットであることから、より現在に近いデータを利用することができる。特に、宛先アプリケーションが、リアルタイム性を重視するアプリケーションである場合に有効である。

なお、図６において、時刻ｔ４において既にチャンク１に属するパケットの一部が送信部１０６から読み出され、既に送信されている場合は、バッファ制御部１０５は、チャンク１に属するパケットは破棄せず、チャンク２に属するパケットを破棄するようにしてもよい。この処理によれば、既に送信されたパケットが無駄になることはない。また、チャンク１の重要度がチャンク２の重要度よりも高い場合についても同様に、チャンク１に属するパケットは破棄せず、チャンク２に属するパケットを破棄するようにしてもよい。後述の実施例２においても同様である。

あるいは、時刻ｔ４においてバッファ１０４に残っているチャンク１に属するパケット（「格納済パケット」に相当）が、既に送信されたチャンク１に属するパケットを含めチャンク１に属する全てのパケットに対して「所定の割合」を「超える」場合、バッファ１０４残っているチャンク１に属するパケットをバッファ１０４から破棄するようにしてもよい。所定の割合は、例えば１／２、２／３、又は３／４と設定することができる。この処理によれば、通信リソースの無駄を最小限に抑えることができるとともに、最低限のリアルタイム性を維持することができる。後述の実施例２においても同様である。
ここで、
「所定の割合」とは、予め定まった固定値の他、条件に応じて変動する変動値であってもよい。
「超える」とは、所定の割合を含む場合、すなわち所定の割合以上であってもよい。

後者の例のように、チャンクに属する一部のパケットがバッファ１０４から破棄された場合、破棄されたパケットは当然送信部１０６から送信されないが、既にバッファ１０４から読み出されたにもかかわらず未だ送信されていない場合は、送信部１０６は送信を中止するようにしてもよい。

なお、本実施例の時刻ｔ４においては、最も時間的に早くバッファ１０４に格納されたチャンク１に属するパケットを破棄したが、バッファ制御部１０５は、チャンク１に属するパケットが「所定の重要度」を「超える」場合、チャンク１に属するパケットをバッファ１０４から破棄しないようにしてもよい。その場合は、次に時間的に早くバッファ１０４に格納されたチャンク２に属するパケットを破棄するようにしてもよい。重要度が所定の重要度を超えているかどうかは、図２に示す通り、パケット情報保存部１０３に記録した重要度情報に基づき判断することができる。後述の実施例２においても同様である。
もっとも、バッファ制御部１０５は、新たに格納されるチャンク３に属するパケットが所定の重要度を超える場合は、チャンク１に属するパケットが所定の重要度を超える場合であっても、チャンク１に属するパケットをバッファ１０４から破棄するようにしてもよい。
ここで、
「所定の重要度」とは、重要度が予め定まっている場合の他、重要度が条件に応じて変動する場合であってもよい。
「超える」とは、所定の重要度を含む場合、すなわち所定の重要度以上であってもよい。

（ｂ）新しいチャンクを格納し、古いチャンクを破棄する例（実施例２）
図７を用いて、新しいチャンクに属するパケットをバッファ１０４に格納し、古いチャンクに属するパケットをバッファ１０４から破棄する別の例を説明する。
実施例１では、バッファ１０４の容量を超えることを原因として、古いチャンクに属する格納済パケットをバッファ１０４から破棄した。本実施例では、新しいチャンクがバッファ１０４に格納されることを原因として、古いチャンクに属する格納済パケットをバッファ１０４から破棄する。

本実施例では、バッファ制御部１０５は、パケットがバッファ１０４に格納された場合、このパケットが属するチャンクと異なる他のチャンクに属しこのパケットよりも先にバッファ１０４に格納された格納済パケットをバッファ１０４から破棄する。

図７は、本実施例のパケットの格納及び破棄の例である。
時刻ｔ１において、バッファ１０４にはチャンク１及びチャンク２に属するパケットが既に格納されており、チャンク１については一部のパケットが送信済みの状態である。そして、新たにチャンク３に属する５つのパケットがバッファ１０４に格納される場合を想定する。

時刻ｔ２において、チャンク３に属するパケットがバッファ１０４の空き領域に格納される。この場合、チャンク３と異なるチャンクであるチャンク１又はチャンク２に属するパケットであってバッファ１０４に格納されたパケット（「格納済パケット」に相当）をバッファ１０４から破棄する。図７の場合、所定の割合以上のパケットがバッファ１０４に残っており、かつ最も時間的に早くバッファ１０４に格納されたチャンク２に属するパケットを破棄している。

時刻ｔ３～ｔ６において、２番目～５番目のパケットが順次バッファ１０４に格納される。

時刻ｔ６において、チャンク２に属するパケットの全数は破棄されているものの、チャンク１の未送信パケット及びチャンク３に属するパケットは欠けることなく格納されている。この結果、宛先端末装置２０の宛先アプリケーションで利用することができないパケットが送信されることがなく、効率的なデータ送信を行うことができる。しかも、結果的に宛先端末装置２０に送信しなかったパケットは、本実施例の方が従来例よりも時間的に古いチャンクに属するパケットであることから、より現在に近いデータを利用することができる。特に、宛先アプリケーションが、リアルタイム性を重視するアプリケーションである場合に有効である。

（ｃ）新しいチャンクを破棄し、古いチャンクを維持する例（実施例３）
図８を用いて、新しいチャンクに属するパケットをバッファ１０４から破棄し、古いチャンクに属するパケットをバッファ１０４に残す例を説明する。
実施例１では、バッファ１０４の容量を超えることを原因として、古いチャンクに属する格納済パケットをバッファ１０４から破棄した。本実施例では、バッファ１０４の容量を超えることを原因として、新しいチャンクに属する格納済パケットをバッファ１０４から破棄する。

本実施例では、バッファ制御部１０５は、バッファ１０４の容量を超えることを原因としてパケットをバッファ１０４に格納できない場合、このパケットと同じチャンクに属しこのパケットよりも先にバッファ１０４に格納された格納済パケットをバッファ１０４から破棄する。

図８は、本実施例のパケットの格納及び破棄の例である。
時刻ｔ１において、バッファ１０４にはチャンク１及びチャンク２に属するパケットが既に格納されている。そして、新たにチャンク３に属する５つのパケットがバッファ１０４に格納される場合を想定する。

時刻ｔ２、ｔ３において、チャンク３に属するパケットが、順次バッファ１０４の空き領域に格納される。しかし、時刻ｔ４においてバッファ１０４の容量が飽和し、チャンク３の３番目のパケットはバッファ１０４に格納することができず、廃棄されてしまう。この場合、チャンク３と同じチャンクであるチャンク３に属するパケットであって既にバッファ１０４に格納されたパケット（「格納済パケット」に相当）をバッファ１０４から破棄する。図７の場合、時刻ｔ４において、チャンク３に属する１番目及び２番目に格納されたパケットを破棄している。

時刻ｔ５、ｔ６においても、チャンク３に属するパケットは、バッファ１０４に格納されることなく破棄される。

時刻ｔ６において、チャンク３に属するパケットの全数は破棄されているものの、チャンク１及びチャンク２に属するパケットは欠けることなく格納されている。この結果、宛先端末装置２０の宛先アプリケーションで利用することができないパケットが送信されることがなく、効率的なデータ送信を行うことができる。しかも、結果的に宛先端末装置２０に送信しなかったパケットは、新しいチャンクに属するパケットであるから、時系列を維持したデータを利用することができる。特に、宛先アプリケーションが、映像コンテンツの視聴等、時系列のデータが順に再生される必要があるアプリケーションである場合に有効である。

なお、チャンク３に属するパケットは一旦破棄されるが、チャンク１及びチャンク２に属するパケットが順次宛先端末装置２０に送信されてバッファ１０４に余裕ができた場合、通信装置１００から送信元端末装置１０に再送要求を行うことにより、チャンク３に属するパケットを送信元端末装置１０から改めて受信することができ、これを宛先端末装置２０に送信することができる。

（４）本実施形態の通信装置１００の動作
図９を用いて本実施形態の通信装置１００の動作について説明する。
なお、以下の動作は、通信装置１００における通信方法を示すだけでなく、通信装置１００で実行される通信プログラムの処理手順を示すものである。そして、これらの処理は、図９で示した順序には限定されない。すなわち、あるステップでその前段のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。
以上、本実施形態だけでなく、他の実施形態においても同様である。

通信装置１００の受信部１０１は、送信元端末装置１０（「第１の装置」に相当）から、送信元端末装置１０で生成された「パケット」を受信する（Ｓ１０１）。
通信装置１００のパケット識別部１０２は、受信部１０１で受信したパケットが属するチャンクを識別する（Ｓ１０２）。
通信装置１００のバッファ制御部１０５は、パケット情報保存部１０３に保存されたパケット情報に基づき、「チャンクを単位として」、パケットの格納及び破棄を制御する（Ｓ１０３）。
通信装置１００のバッファ１０４は、バッファ制御部１０５の制御の結果に応じ、受信部１０１で受信したパケットを格納する（Ｓ１０４）。
通信装置１００の送信部１０６は、バッファ１０４からパケットを読み出し、宛先端末装置２０（「第２の装置」に相当）に送信する（Ｓ１０５）。

以上、本実施形態によれば、上位レイヤにおけるデータ単位であるチャンクを単位としてパケットのバッファへの格納及び破棄を制御するので、データの欠損発生の可能性を低減することができ、ひいては効率的なデータ送信を行うことができる。

２．実施形態２
（１）本実施形態の通信装置２００の全体構成
実施形態１では、接続されている送信元端末装置１０や宛先端末装置２０の区別、あるいはそれぞれの装置に搭載されている送信元アプリケーションや宛先アプリケーションの区別をすることなくチャンクの識別を行った。しかし、送信元端末装置１０や宛先端末装置２０が複数台接続されているような場合は、同じソフトウェアを使用している場合でもそれぞれのチャンク同士は異なるチャンクとして扱う必要がある。また、送信元端末装置１０や宛先端末装置２０に、複数の送信元アプリケーションや複数の宛先アプリケーションが実行されている場合も、アプリケーション毎にチャンクを区別する必要がある。
そこで、本実施形態では、接続されている送信元端末装置１０や宛先端末装置２０が複数台の場合、あるいはそれぞれの装置に搭載されている送信元アプリケーションや宛先アプリケーションが複数の場合について、図１０を用いて説明する。
なお、実施形態１と同様の機能の場合は図１と同じ図番を用い、実施形態１の説明を引用する。

図１０を用いて、実施形態２の通信装置２００の構成を説明する。通信装置２００は、受信部１０１、パケット識別部２０２、パケット情報保存部２０３、バッファ１０４、バッファ制御部２０５、送信部１０６を有する。

通信装置２００には、複数の送信元端末装置である送信元端末装置Ａ及び送信元端末装置Ｂが接続されている。また、複数の宛先端末装置である宛先端末装置Ｐ及び宛先端末装置Ｑが接続されている。
送信元端末装置Ａには、送信元アプリケーションａが搭載され実行されている。送信元端末装置Ｂには、送信元アプリケーションｂ及び送信元アプリケーションｃが搭載され実行されている。宛先端末装置Ｐには、宛先アプリケーションｐ及び宛先アプリケーションｑが搭載され実行されている。宛先端末装置Ｑには、宛先アプリケーションｒが搭載され実行されている。
なお、送信元端末装置や宛先端末装置は３台以上接続されていてもよい。また、送信元アプリケーションや宛先アプリケーションも一つの装置に３つ以上搭載され実行されていてもよい。

パケット識別部２０２は、実施形態１で説明したチャンクを識別することに加え、さらにパケットの送信元又は／及び宛先に基づき、パケットが属する通信フローを識別する。

通信フローは、例えば送信元を特定する情報と宛先を特定する情報で示すことができる。例えば、送信元端末装置Ａの送信元アプリケーションａから宛先端末装置Ｐの宛先アプリケーションｑにパケットが送信される場合、通信フローはＡａＰｑと表現することができる。

通信装置２００に接続されている送信元端末装置又は宛先端末装置のうちいずれかが１台の場合は、送信元端末装置又は宛先端末装置を特定する情報は省略することができる。例えば、通信装置２００に接続されている送信元端末装置が送信元端末装置Ｂのみであれば、送信元端末装置Ｂの送信元アプリケーションｂから宛先端末装置Ｐの宛先アプリケーションｑにパケットが送信される場合、通信フローはｂＰｑと表現することができる。
送信元端末装置に搭載されている送信元アプリケーションや宛先端末装置に搭載されている宛先アプリケーションのうちいずれかが１つの場合は、送信元アプリケーション又は宛先アプリケーションを特定する情報は省略することができる。例えば、通信装置２００に接続されている送信元端末装置が送信元端末装置Ａのみであり、送信端末装置Ａに搭載されている送信元アプリケーションが送信元アプリケーションａのみであれば、送信元端末装置Ａの送信元アプリケーションａから宛先端末装置Ｐの宛先アプリケーションｑにパケットが送信される場合、通信フローはＰｑと表現することができる。

送信元や宛先を特定するためには、ＩＰヘッダやＴＣＰ／ＵＤＰヘッダに格納された情報を利用することができる。

図４に示す通り、ＩＰヘッダには、送信元アドレスや宛先アドレスが格納されているので、これらに基づき送信元端末装置や宛先端末装置を特定することができる。また、ＩＰヘッダには、プロトコルが格納されているので、これに基づき送信元アプリケーションや宛先アプリケーションを特定することができる。

図１１に示す通り、ＴＣＰヘッダやＵＤＰヘッダには、送信先ポートや宛先ポートが格納されているので、これらに基づき送信元アプリケーションや宛先アプリケーションを特定することができる。

図１２は、パケット情報保存部２０３で保存されているパケット情報を示している。
パケット情報保存部２０３は、図１２に示す通り、実施形態１で説明したパケット情報に加え、通信フロー情報を保存する。通信フローの表現方法は上述の通りである。

パケット情報保存部２０３は、図１２に示す情報に加え、さらにパケットの受信間隔に基づいて各フローのチャンクを識別する場合のために、フロー毎にパケットの最終受信時刻を保存するようにしてもよい。

バッファ制御部２０５は、通信フロー毎にチャンクを単位として、パケットのバッファ１０４への格納及びパケットのバッファ１０４からの破棄を制御する。例えば、図１２において、通信フローＡａＰｑと通信フローＢｂＱｒは、同じチャンク番号＃１であっても異なるチャンクとしてパケットの格納や破棄が独立して制御される。本実施形態においては、実施形態１の実施例１や実施例２で説明した制御を行う際、削除対象とするチャンクは同一のフローから選択される。

以上、本実施形態によれば、実施形態１の構成に加え、通信フロー毎にチャンクを単位としてパケットのバッファへの格納及び破棄を制御するので、通信装置に複数の送信元端末装置や宛先端末装置、あるいは複数の送信元アプリケーションや宛先アプリケーションが実行されている場合であっても、それぞれの装置やアプリケーションで用いるデータの欠損発生の可能性を低減することができ、ひいては効率的なデータ送信を行うことができる。

３．送信元端末装置、通信装置、及び宛先端末装置の組み合わせの具体例
送信元端末装置１０、通信装置１００（２００）、及び宛先端末装置２０の具体的な組み合わせとして、いくつかの例を挙げる。

図１３（ａ）のように、スマートフォンで撮影した動画をＷｉ－Ｆｉでルータに送信し、ルータから４Ｇ／５Ｇ回線を用いてサーバ装置にアップロードする場合は、スマートフォンが送信元端末装置１０（「第１の装置」に相当）、ルータが通信装置１００（２００）、サーバ装置が宛先端末装置２０（「第２の装置」に相当）となる。
逆に、サーバ装置から動画を４Ｇ／５Ｇ回線を用いてルータを経由してダウンロードする場合は、サーバ装置が送信元端末装置１０（「第１の装置」に相当）、ルータが通信装置１００（２００）、スマートフォンが宛先端末装置２０（「第２の装置」に相当）となる。

通信装置１００（２００）は「移動体」に「搭載」されてもよい。
図１３（ｂ）のように、車載ネットワークに接続されたＥＣＵや各種センサからのデータが通信ＥＣＵを介して無線通信方式でデータセンタに送信される場合、ナビＥＣＵ、車載ＥＣＵ、及び各種センサが送信元端末装置１０（「第１の装置」に相当）、通信ＥＣＵが通信装置１００（２００）、データセンタが宛先端末装置２０（「第２の装置」に相当）となる。
あるいは、図１３（ｃ）のように、車載ネットワークに接続された各種センサからのデータが統合ＥＣＵの通信機能を介して無線通信方式でデータセンタに送信される場合、各種センサが送信元端末装置１０（「第１の装置」に相当）、統合ＥＣＵが通信装置１００（２００）、データセンタが宛先端末装置２０（「第２の装置」に相当）となる。
ここで、
「移動体」とは、移動可能な物体をいい、移動速度は任意である。また移動体が停止している場合も当然含む。例えば、自動車、自動二輪車、自転車、歩行者、船舶、航空機、及びこれらに搭載される物を含み、またこれらに限らない。
「搭載」される、とは、移動体に直接固定されている場合の他、移動体に固定されていないが移動体と共に移動する場合も含む。例えば、移動体に乗った人が所持している場合、移動体に載置された積荷に搭載されている場合、が挙げられる。

４．総括
以上、本発明の各実施形態における通信装置等の特徴について説明した。
各実施形態で使用した用語は例示であるので、同義の用語、あるいは同義の機能を含む用語に置き換えてもよい。

実施形態の説明に用いたブロック図は、装置の構成を機能毎に分類及び整理したものである。それぞれの機能を示すブロックは、ハードウェア又はソフトウェアの任意の組み合わせで実現される。また、機能を示したものであることから、かかるブロック図は方法の発明、及び当該方法を実現するプログラムの発明の開示としても把握できるものである。

各実施形態に記載した処理、フロー、及び方法として把握できるブロック、については、一のステップでその前段の他のステップの結果を利用する関係にある等の制約がない限り、順序を入れ替えてもよい。

本発明の通信装置は、特許請求の範囲で特に限定する場合を除き、車両用途でもよいし、車両用途以外の専用又は汎用の通信装置も含むものである。

また、本発明の通信装置の形態の例として、半導体素子、電子回路、モジュール、マイクロコンピュータが挙げられる。
半完成品の形態として、電子制御装置（ＥＣＵ（Electric Control Unit））、システムボードが挙げられる。
完成品の形態として、モバイルルータ、携帯電話、スマートフォン、タブレット、パーソナルコンピュータ（ＰＣ）、ワークステーション、サーバが挙げられる。
その他、通信機能を有するデバイス等を含み、例えば、カーナビゲーションシステムが挙げられる。

本発明の通信装置は、各種サービスの提供を目的とするために用いられることが想定される。かかるサービスの提供に伴い、本発明の通信装置が使用され、本発明の方法が使用され、又は／及び本発明のプログラムが実行されることになる。

加えて、本発明は、各実施形態で説明した構成及び機能を有する専用のハードウェアで実現できるだけでなく、メモリやハードディスク等の記録媒体に記録した本発明を実現するためのプログラム、及びこれを実行可能な専用又は汎用ＣＰＵ及びメモリ等を有する汎用のハードウェアとの組み合わせとしても実現できる。

本発明の通信装置のためのプログラムであって、専用や汎用のハードウェアの非遷移的実体的記録媒体（例えば、外部記憶装置（ハードディスク、ＵＳＢメモリ、ＣＤ／ＢＤ等）、又は内部記憶装置（ＲＡＭ、ＲＯＭ等））に格納されるプログラムは、記録媒体を介して、あるいは記録媒体を介さずにサーバから通信回線を経由して、専用又は汎用のハードウェアに提供することもできる。これにより、プログラムのアップグレードを通じて常に最新の機能を提供することができる。

本発明の通信装置は、車載用途にも車載用途以外にも用いることができる。さらに、中継装置にも適用が可能である。

１００ 通信装置、１０１ 受信部、１０２ パケット識別部、１０３ パケット情報保存部、１０４ バッファ、１０５ バッファ制御部、１０６ 送信部、１０ 送信元端末装置（「第１の装置」に相当）、２０ 宛先端末装置（「第２の装置」に相当）

Claims (18)

1. 第１の装置（１０）からパケットを受信する受信部（１０１）と、
   前記パケットが属する、上位レイヤにおけるデータ単位であるチャンクを識別するパケット識別部（１０２）と、
   前記パケットを格納するバッファ（１０４）と、
   前記チャンクを単位として、前記パケットの前記バッファへの格納及び前記パケットの前記バッファからの破棄を制御するバッファ制御部（１０５）と、
   前記バッファから前記パケットを読み出し、第２の装置（２０）に送信する送信部（１０６）と、を有する、通信装置であって、
   前記バッファ制御部は、受信した第１のパケットが前記バッファに格納できるか否か、及び前記第１のパケットが属する第１のチャンクに基づき、前記第１のパケットよりも先に前記バッファに格納された格納済パケットである第２のパケットを、前記第２のパケットが属する前記第１のチャンク又は前記第２のパケットが属する第２のチャンクの単位で前記バッファから破棄する、
   通信装置（１００）。
2. 前記パケット識別部は、前記受信部で受信する前記パケットの受信間隔に基づき、前記チャンクを識別する、
   請求項１記載の通信装置。
3. 前記チャンクは、動画の圧縮により生成されたフレームである、
   請求項２記載の通信装置。
4. 前記パケット識別部は、前記パケットのＩＰヘッダに含まれる識別子に基づき、前記チャンクを識別する、
   請求項１記載の通信装置。
5. 前記パケット識別部は、前記パケットのＴＣＰ／ＵＤＰペイロードに含まれる識別情報に基づき、前記チャンクを識別する、
   請求項１記載の通信装置。
6. 前記バッファ制御部は、前記バッファの容量を超えることを原因として前記第１のパケットを前記バッファに格納できない場合、前記第１のパケットが属する前記第１のチャンクと異なる前記第２のチャンクに属し前記第１のパケットよりも先に前記バッファに格納された格納済パケットである前記第２のパケットを前記バッファから破棄する、
   請求項１記載の通信装置。
7. 前記バッファ制御部は、前記バッファの容量を超えることを原因として前記第１のパケットを前記バッファに格納できない場合、前記第１のパケットが属する前記第１のチャンクと異なる前記第２のチャンクに属し最も時間的に早く前記バッファに格納された格納済パケットである前記第２のパケットを前記バッファから破棄する、
   請求項１記載の通信装置。
8. 前記バッファ制御部は、前記第１のパケットが前記バッファに格納された場合、前記第１のパケットが属する前記第１のチャンクと異なる前記第２のチャンクに属し前記第１のパケットよりも先に前記バッファに格納された格納済パケットである前記第２のパケットを前記バッファから破棄する、
   請求項１記載の通信装置。
9. 前記バッファ制御部は、前記第１のパケットが前記バッファに格納された場合、前記第１のパケットが属する前記第１のチャンクと異なる前記第２のチャンクに属し最も時間的に早く前記バッファに格納された格納済パケットである前記第２のパケットを前記バッファから破棄する、
   請求項１記載の通信装置。
10. 前記バッファ制御部は、前記第２のチャンクに属する前記格納済パケットである前記第２のパケットが、前記第２のチャンクに属する全てのパケットに対して所定の割合を超える場合、前記格納済パケットである前記第２のパケットを前記バッファから破棄する、
    請求項６～９のいずれかに記載の通信装置。
11. 前記送信部は、前記格納済パケットである前記第２のパケットの送信を中止する、
    請求項１０記載の通信装置。
12. 前記バッファ制御部は、前記第２のチャンクに属する前記格納済パケットである前記第２のパケットが所定の重要度を超える場合、前記格納済パケットである前記第２のパケットを前記バッファから破棄しない、
    請求項６～９のいずれかに記載の通信装置。
13. 前記バッファ制御部は、前記第１のチャンクに属する前記第１のパケットが所定の重要度を超える場合、前記第２のチャンクに属する前記格納済パケットである前記第２のパケットを前記バッファから破棄する、
    請求項１２記載の通信装置。
14. 前記バッファ制御部は、前記バッファの容量を超えることを原因として前記第１のパケットを前記バッファに格納できない場合、前記第１のパケットと同じ前記第１のチャンクに属し前記第１のパケットよりも先に前記バッファに格納された格納済パケットである前記第２のパケットを前記バッファから破棄する、
    請求項１記載の通信装置。
15. 前記パケット識別部は、さらに前記パケットの送信元又は／及び宛先に基づき、前記パケットが属する通信フローを識別し、
    前記バッファ制御部は、前記通信フロー毎に前記チャンクを単位として、前記パケットの前記バッファへの格納及び前記パケットの前記バッファからの破棄を制御する、
    請求項２、４、５のいずれかに記載の通信装置（２００）。
16. 当該通信装置は、移動体に搭載されている、
    請求項１～１５記載の通信装置。
17. 通信装置で実行する通信方法であって、
    第１の装置からパケットを受信し（Ｓ１０１）、
    前記パケットが属する、上位レイヤにおけるデータ単位であるチャンクを識別し（Ｓ１０２）、
    前記チャンクを単位として、前記パケットのバッファへの格納及び前記パケットの前記バッファからの破棄を制御し（Ｓ１０３）、
    前記パケットを前記バッファに格納し（Ｓ１０４）、
    前記バッファから前記パケットを読み出し、第２の装置に送信する（Ｓ１０５）、通信方法であって、
    受信した第１のパケットが前記バッファに格納できるか否か、及び前記第１のパケットが属する第１のチャンクに基づき、前記第１のパケットよりも先に前記バッファに格納された格納済パケットである第２のパケットを、前記第２のパケットが属する前記第１のチャンク又は前記第２のパケットが属する第２のチャンクの単位で前記バッファから破棄する、
    通信方法。
18. 通信装置で実行可能な通信プログラムであって、
    第１の装置からパケットを受信し（Ｓ１０１）、
    前記パケットが属する、上位レイヤにおけるデータ単位であるチャンクを識別し（Ｓ１０２）、
    前記チャンクを単位として、前記パケットのバッファへの格納及び前記パケットの前記バッファからの破棄を制御し（Ｓ１０３）、
    前記パケットを前記バッファに格納し（Ｓ１０４）、
    前記バッファから前記パケットを読み出し、第２の装置に送信する（Ｓ１０５）、通信プログラムであって、
    受信した第１のパケットが前記バッファに格納できるか否か、及び前記第１のパケットが属する第１のチャンクに基づき、前記第１のパケットよりも先に前記バッファに格納された格納済パケットである第２のパケットを、前記第２のパケットが属する前記第１のチャンク又は前記第２のパケットが属する第２のチャンクの単位で前記バッファから破棄する、
    通信プログラム。