JP5393699B2 - 送信端末及び受信端末 - Google Patents

Description

本発明は、インターネット等のパケット通信を行うネットワークを介して、映像音声などのリアルタイムのストリーミングデータを伝送する送信端末、及び該送信端末から送信されたストリーミングデータを受信する受信端末に関する。

図７は、上述した送信端末と受信端末の利用状態を示す図である。同図において、送信端末１１は、ネットワーク１０を介して映像音声などのリアルタイムストリームデータをパケットに分割し、受信端末１２に伝送する。

インターネット等のネットワークの広帯域化やＶＰＮ（Virtual Private Network）ルータの高速化は、回線のトランキングや複数の暗号装置の導入で行われることがある。図８は、その一例を示す図である。同図において、送信端末１１と受信端末１２との間に、ネットワーク中に配置されるルータ（中継装置）８０１、８０２、８０３が介在する。図８では、送信端末１１とルータ８０１は回線８０４で接続され、ルータ８０１とルータ８０２は回線８０５で接続され、ルータ８０２とルータ８０３は回線８０６で接続され、受信端末１２とルータ８０３は回線８０７で接続される。このようなネットワークでは、トラフィックの増加により、例えば、回線８０５の回線容量が不足すると、複数の回線を束ねて回線容量を確保する方法が取られることがある。これは、回線のトランキングと呼ばれている。回線８０５は、複数の回線を束ねた様子を示している。

図９は、回線のトランキングが行われているルータ８０１の回線選択の様子をより詳細に示す図である。同図において、ルータ８０１には、４つの回線８０４、８０５−１、８０５−２、８０５−３が接続されている。ルータ８０１は、回線８０４、８０５−１〜８０５−３に対して出力キュー９０３、９０４、９０５を有している。ルータ８０１のスケジューラ９０２は、パケットの出力回線を決定する機能を有する。出力キュー９０３、９０４、９０５からは、長さの異なるパケット９０９、１００１、１００２が回線に出力されている。すなわち、出力キュー９０３からはパケット９０９が回線８０５−１に出力されており、出力キュー９０４からはパケット１００１が回線８０５−２に出力されている。また、出力キュー９０５からは、パケット１００２が回線８０５−３に出力されている。

図８において、ルータ８０１は、回線８０４などからパケット入力があると、経路探索を実施し、その結果の転送先が、回線８０５すなわち図９における回線８０５−１〜８０５−３のいずれかを用いてパケットを送信することを決定する。ルータ８０１のスケジューラ９０２は、回線８０５−１、８０５−２、８０５−３のうちどの回線を用いるか決定し、決定した回線に対応する出力キューにパケットを格納する。このとき、どの回線を選択するかは、ルータ８０１に設定されている値によって決定される。具体的には、順番にパケットを格納する回線を選択していくラウンドロビン（round robin）方式や、パケット中の特定領域のハッシュ値を計算し、そのハッシュ値で回線を選択する方式が知られている。それぞれの出力キュー９０３、９０４、９０５に格納されたパケットは、回線速度に応じて、順次（First In First Outで）回線を通じて相手先のルータ（図８の場合、ルータ８０２）に転送されていく。

このような回線のトランキングが行われているルータ間では、パケットの受信順序の反転が発生することがある。本稿では、パケットのリオーダ（reorder）を、送信端末が出力したパケット送信順序と受信端末が受信するパケットの受信順序が異なりながら伝送されることと定義する。図９の例では、例えばパケット９０９、１００１、１００２が、この順番で送信端末１１から送信されたにもかかわらずパケット９０９、１００２、１００１の順で受信端末１２に届くことである。これは、回線のトランキングによってリオーダが発生する代表的な例である。

この他に、ルータ８０１とルータ８０３間で暗号化を行うことによって、ネットワークの回線を盗み見られても内容が分らないようにする対策が取られていることを想定する。このような運用条件のもと、送信端末１１、受信端末１２の伝送の広帯域化に対応すると、ルータ８０１、８０３に搭載している暗号化・複合化の能力が不足することがある。このため、ルータ８０１、８０３に複数の暗号・復号のハードウェアを搭載し、これらの装置に暗号・復号処理を到着パケット毎に割り振ることによって、暗号・復号処理の高速化を行うことがある。ルータ８０１、８０３は、複数の暗号・復号のハードウェアを搭載した場合、リオーダが発生することがある。暗号・復号の処理時間は、一般にパケットの長さに応じて長くなる。つまり、ルータ８０１、８０３の暗号・復号の処理は、略同時に暗号・復号を開始した場合、短いパケットの方が長いパケットより短い時間で処理を終了することがある。このようなルータに特定の送信端末から短長パケットが届いた場合は、リオーダが発生することがある。

映像音声などリアルタイムのストリーミングデータの伝送において、リオーダが発生する受信端末では、パケットを並べ直す必要が出てくる。つまり、受信端末の映像音声のデコーダは、入力された情報の順に映像音声を再生するためにデコードしていく。受信端末は、順序が入れ替わったデータをデコーダに入力した場合、通常、映像音声のデコードが正常終了しない。具体的には、受信端末は、順序が入れ替わったデータを入力した場合、例えば、１，２，３というシーケンシャル番号がついたデータを１，３，２の順でデコーダに入力したとする。この場合、受信端末は、３を受信すると２が損失したと判定し、２が入力されると不正データが入力されたと判定し、デコードは正常に行われず、結果として映像音声の再生が一時途切れてしまう。このような事態を防止するための方法としては、「特許文献１」で開示されている受信端末でパケットを並べ直す方法が知られている。この方法による受信端末は、パケット中のシーケンシャル番号を参照し、これによりパケットの並べ直しを行うことで、正常な順序のデータとしてデコーダに入力することができる。

特開平５−０５６０７９号公報

しかしながら、受信端末でパケットを並べ直す方法では、最終的な伝送の遅延時間が増大してしまうという課題がある。映像音声などのリアルタイムストリームデータを伝送するシステムでは、最終的な伝送の遅延時間を短縮したいという要望がある。遅延時間の短縮を要望する用途としては、例えば、テレビ電話に代表されるコミュニケーション用途が挙げられる。最終的な伝送の遅延時間とは、送信端末でエンコードされた映像音声のデータが、ネットワークを介して伝送され、受信端末でデコードされ、映像音声として再生されるまでの時間である。つまり、ネットワークでリオーダが発生する場合、受信端末は、リオーダが発生する可能性がある個数分だけ、常にパケットを蓄積してから、デコーダに入力する必要が出てくる。このため、常にパケットを蓄積する方法は、パケットを蓄積する時間分だけデコーダへパケットを入力する時刻が遅くなる。

本発明は、係る事情に鑑みてなされたものであり、リオーダの発生そのものを回避することで、最終的な伝送の遅延時間を短縮したリアルタイムストリームの伝送を実現できる送信端末及び受信端末を提供することを目的とする。

本発明の送信端末は、パケットを発生させるデータ発生部と、受信端末から送信されるパディングを要求するパディング申請パケットを受け取るパディング申請受付部と、前記パディング申請受付部からのパディング要求に基づいて、パケット長が特定長以上となるように、前記データ発生部で発生されたパケットにパディングを施し、ネットワークに送信するパケットパディング部と、を備え、前記パディング申請パケットは、受信端末で算出されたリオーダが発生しない正常パケット長を含み、前記パケットパディング部は、前記正常パケット長となるように、前記データ発生部で発生されたパケットにパディングを施す。

この構成によれば、受信端末からパディング要求があると、該要求に基づき、データ発生部で発生したパケットのパケット長が特定長以上となるように該パケットに対して、パディングを施して受信端末に向けて送信する。これにより、本発明の送信端末は、リオーダの発生そのものを回避できて、最終的な伝送の遅延時間を短縮したリアルタイムストリームの伝送が可能となる。

本発明の受信端末は、ネットワークからパケットを受信し、該パケットのリオーダの発生状況を解析するリオーダ状況解析部と、前記リオーダ状況解析部で受信されたパケットを再生するデータ再生部と、前記リオーダ状況解析部での解析結果に基づいて、送信端末にパディングを要求するパディング申請パケットを生成するパディング申請部と、を備えた。

この構成によれば、送信端末から送られてきたパケットにリオーダが発生しているかどうかを解析し、リオーダが発生していれば、送信端末にパディングを要求するパディング申請パケットを送信端末に向けて送信する。これにより、送信端末は、リオーダの発生原因を取り除いた形で送信することが可能となる。また、受信端末は、受信端末側で並べ直しのためのパケットの蓄積を行う必要が無くなり、その結果、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。

上記受信端末において、前記リオーダ状況解析部は、リオーダが発生している場合、リオーダ個数と受信帯域から、予測正常パケット長を推定する。

本発明のパケット送受信方法は、送信端末が、パケットを発生させるパケット発生ステップと、送信端末が、前記パケット発生ステップで発生されたパケットにパディングを施し、ネットワークに送信するパケット送信ステップと、受信端末が、前記ネットワークからパケットを受信し、該パケットのリオーダの発生状況を解析するリオーダ状況解析ステップと、受信端末が、前記リオーダ状況解析ステップでの解析結果に基づいて、パディングを要求するパディング申請パケットを生成するパディング申請パケット生成ステップと、送信端末が、前記パディング申請パケット生成ステップで生成されたパディング申請パケットを受け取るパディング申請パケット受付ステップと、を備え、前記送信端末のパケット送信ステップは、前記パディング申請パケット受付ステップからのパディング要求に基づいて、パケット長が特定長以上となるように、前記パケット発生ステップで発生されたパケットにパディングを施す。

この方法によれば、送信の際には、リオーダの発生原因を取り除いた形で送信することができ、受信の際には、並べ直しのためのパケット蓄積の必要が無く、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。

本発明の送信端末は、パケットを発生させるデータ発生部と、前記データ発生部で発生されるパケットの送信データ量と該パケットのバースト送信個数の情報からリオーダを防止するパケット長を算出するリオーダ予測部と、前記リオーダ予測部で算出された前記パケット長に従って前記パケットにパディングを施しネットワークに送信するとともに、前記バースト送信個数の情報を生成し前記リオーダ予測部に供給するパケットパディング部と、を備えた。

この構成によれば、送信の際にリオーダの発生原因を取り除いた形で送信することができ、受信側で、並べ直しのためのパケットの蓄積を行う必要が無く、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。

本発明のパケット送信方法は、パケットを発生させるパケット発生ステップと、前記パケット発生ステップで発生されるパケットの送信データ量と該パケットのバースト送信個数の情報からリオーダを防止するパケット長を算出するパケット長算出ステップと、前記パケット長算出ステップで算出された前記パケット長に従って前記パケットにパディングを施しネットワークに送信するとともに、前記バースト送信個数の情報を生成するパケット送信ステップと、を備えた。

この方法によれば、送信の際にリオーダの発生原因を取り除いた形で送信することができ、受信側で、並べ直しのためのパケットの蓄積を行う必要が無く、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。

本発明は、リオーダの発生そのものを回避すること、受信端末で並べ直しのため、パケットを蓄積する必要が根本的に無くなり、その結果、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送を実現できる。

本発明の実施の形態１に係る送信端末及び受信端末それぞれの概略構成を示すブロック図 図１の受信端末におけるリオーダ状況解析部の処理を説明するためのフローチャート 図１の受信端末のパディング申請部で生成されるパディング申請パケットの一例を模式的に示す図 図１の送信端末におけるパディング申請受付部の処理を説明するためのフローチャート 本発明の実施の形態２に係る送信端末及び受信端末それぞれの概略構成を示すブロック図 図５の送信端末におけるリオーダ予測部の処理を説明するためのフローチャート 送信端末と受信端末の接続状況を示す図 回線のトランキングを説明するための図 回線のトランキングが行われているルータの回線選択の様子を示す図

以下、本発明を実施するための好適な実施の形態について、図面を参照して詳細に説明する。

（実施の形態１）
図１は、本発明の実施の形態１に係る送信端末及び受信端末それぞれの概略構成を示すブロック図である。
図１において、送信端末１は、データ発生部１０１と、パケットパディング部１０２と、パディング申請受付部１０３とを備えている。データ発生部１０１は、映像音声などのデータをエンコードしてパケットを発生する。パケットパディング部１０２は、特定のパケット長までパディング（padding）してパケットをネットワーク１０に送信する。パディング申請受付部１０３は、パディング申請パケットを受信し、適切な長さにパディングを行うようにパケットパディング部１０２に指示を行う。パディング申請受付部１０３は、データ保存用のメモリ１０３１を有している。

データ発生部１０１は、映像をエンコードする場合、特定のデータ単位毎にエンコード処理を実施する。具体的には、１画面単位や１画面を複数に分割したスライス単位でエンコード処理を実施する。このとき、エンコード処理は、画面の複雑さや要求される精細度に応じて処理単位あたりに発生するデータ量が異なる。このため、データ発生部１０１は、処理単位毎に発生したデータを特定長（Ｌｍａｘ）の長さに分割する。次に、データ発生部１０１は、分割したそれぞれのデータ単位毎にネットワーク１０で伝送するためのヘッダを先頭に付与した複数のパケットとして生成し、パケットパディング部１０２に引き渡す。このとき、ヘッダには、パケットの生成順序（すなわち再生順序）を示すシーケンシャル番号が付与される。このときのヘッダは、例えば、ＲＦＣ３５５０で規定されるＲＴＰ（Real-time Transport Protocol）ヘッダであってもよいし、独自に定義したヘッダでもかまわない。

パケットパディング部１０２は、パディング申請受付部１０３の指示に従って、パケットにパディングを行って、ネットワーク１０経由で受信端末２に送信する。なお、パディングとは、パケットに固定データを付加することで特定のパケット長にする処理である。パディング処理は、例えば、ＩＰｖ６（Internet Protocol Version6）で定義されているＰａｄ１,ＰａｄＮオプションヘッダで実現してもよい（参考文献：ＲＦＣ２４６０）。また、パディング処理は、ＲＴＰで定義されているパディングビットを用いて実装してもよい（参考文献：ＲＦＣ３５５０）。なお、Ｐａｄ１,ＰａｄＮオプションヘッダで実現した場合、受信端末２のアプリケーションは意識することなく、パディングの除去作業は、受信端末のＩＰスタック中で行われる。また、ＲＴＰで定義されているパディングビットで実現した場合、パディングの除去作業は、受信端末２のアプリケーションで行う必要がある。なお、パディングの実現方式は、これらに限定する必要はなく、パディングの除去が受信端末２で実施できる形態であれば、独自に定義したパケット形式で実現してもよい。

受信端末２は、リオーダ状況解析部２０１と、パディング除去部２０２と、データ再生部２０３と、パディング申請部２０４とを備えている。リオーダ状況解析部２０１は、ネットワーク１０からパケットを受信し、パケットのリオーダの発生状況を解析する。リオーダ状況解析部２０１は、パケットの受信時刻を取得するためのタイマ２０１１とデータ保存用のメモリ２０１２を有している。パディング除去部２０２は、パディングされているパケットのパディング部分を除去してデータ再生部２０３に引き渡す。パディング申請部２０４は、リオーダ状況解析部２０１からのリオーダの発生状況に基づいてパディング申請パケットを生成し、送信端末１にフィードバックする。データ再生部２０３は、入力されたパケットを順次デコードし、映像音声として再生する。

本実施の形態では、ＲＴＰで定義されているパディングビットで実現した例を想定して説明する。ネットワーク１０を介して受信端末２に届いたパケットは、受信端末２で受信後、リオーダ状況解析部２０１に引き渡される。リオーダ状況解析部２０１は、パケットのヘッダ中のシーケンシャル番号を観測することでリオーダの発生を検知する。さらに、リオーダ状況解析部２０１は、リオーダ発生時にリオーダが発生しない正常パケット長Ｌを算出し、算出した正常パケット長Ｌをパディング申請部２０４に通知する。また、リオーダ状況解析部２０１は、パディングの除去が必要なパケットはパディング除去部２０２に引渡し、パディングの除去が不要なパケットはデータ再生部２０３に引き渡す。

ここでは、図２に示すフローチャートを参照してリオーダ状況解析部２０１の処理の詳細を説明する。リオーダ状況解析部２０１は、パケットを受信する度に起動される。ステップＳ２０１の処理は、現在の受信帯域を計測し、計測結果をＲＷとしてメモリ２０１２に保存する。受信帯域は、単位時間あたりのパケット受信量で計測できる。次いで、ステップＳ２０２の処理は、最大パケット長を計測し、計測結果をＬｍａｘ１としてメモリ２０１２に保存する。最大パケット長とは、通信開始から受信するパケット長の最大長である。次いで、ステップＳ２０３の処理は、パケット到着順序が反転しているかどうか判定する。すなわち、この判定処理は、パケット中のシーケンシャル番号の反転を観測することでリオーダの発生の有無を判定する。この場合、具体的な処理は、過去受信したパケットのシーケンシャル番号の最大値より、小さいシーケンシャル番号のパケットが到着したら、パケットの到着順序が反転して到着したと判定する。なお、判定の前にシーケンシャル番号が一巡することで、大小関係が反転することはないように、ラップラウンド（lap round）処理を施した後で判定する。

ラップラウンド処理は、具体的には、例えば、比較する双方から特定の同じ値を引き算することで実現できる。リオーダ状況解析部２０１は、リオーダが発生している場合、リオーダ個数と受信帯域から、予測正常パケット長Ｌを推定し、パディング申請部２０４に通知する。この処理が図２のステップＳ２０４からステップＳ２０７である。ステップＳ２０３の処理でリオーダが発生していると判定した場合（Ｙｅｓの場合）は、ステップＳ２０４に進む。次に、ステップＳ２０４の処理は、パケット受信時刻をＴｒとし、反転前パケット番号をＳ１とし、反転検知パケット通信番号をＳ２として、それぞれをメモリ２０１２に保存する。なお、ステップＳ２０４の処理は、パケット受信時刻Ｔｒをタイマ２０１１から取得する。

次いで、ステップＳ２０５の処理は、リオーダ個数（Ｓ１-Ｓ２）Ｎｒを算出し、メモリに２０１２保存する。また、ステップＳ２０５の処理は、受信帯域ＲＷ、反転前パケット番号Ｓ１、反転検知パケット通信番号Ｓ２、パケット受信時刻Ｔｒ、リオーダ個数Ｎｒから本来の受信時刻Ｔｔを算出し、メモリ２０１２に保存する。具体的には、本来の受信時刻ＴｔをＴｔ＝Ｔｒ＋ＲＷ（Ｎｒ＊Ｌｍａｘ）／８として算出する。

次いで、ステップＳ２０６の処理は、リオーダ個数Ｎｒ、最大パケット長Ｌｍａｘ１から予測正常パケット長ＬをＬ＝Ｌｍａｘ１−α／Ｎｒに基づいて算出する。次いで、ステップＳ２０７の処理は、算出した予測正常パケット長Ｌおよびリオーダ個数Ｎｒをパディング申請部２０４に通知する。ここで、αは、正の定数としてもよいし、値域が正の値となる時間（Ｔｔ−Ｔｒ）の関数としてもよい。例えば、αは、α＝β＊（Ｔｔ−Ｔｒ）＊（Ｔｔ−Ｔｒ）（但し、β＝正の定数としてよい）と求める。

図１に戻り、パディング申請部２０４は、リオーダ状況解析部２０１から予測正常パケット長Ｌ、リオーダ個数Ｎｒを受け取ると、これらの情報を特定のパディング申請パケットに記載して送信端末１に送付する。具体的には、ＲＦＣ３５５０で規定されるＲＴＣＰのＡＰＰ（Application Defined、アプリケーション定義）形式に従ってパケットを構成してもよい。図３は、そのパケット形式の一例を示したものである。図３でフィールド３０１から３０７までは、ＲＦＣ３５５０で規定されるＡＰＰのパケット形式の通りである。ＡＡＰのパケット形式は、バージョン番号３０１、バディングビット３０２、サブタイプ３０３、パケットタイプＰＴ３０４、ＲＴＣＰパケット長３０５、送信元識別子（ＳＳＲＣ（送信元識別子）／ＣＳＲＣ（貢献送信元識別子））３０６、及び名前（４バイト）３０７を含む。サブタイプ３０３は、例えば「１」としてよいがこれに限らない。名前３０７は、例えばＲＰＡＤの４文字に対応するＡＳＣＩＩコードとしてよいがこれに限らない。フィールド３０８、３０９は、それぞれ本発明で追加したものであり、フィールド３０８にはリオーダ個数Ｎｒが格納されフィールド３０９には予測正常パケット長Ｌが格納される。

送信端末１にパディング申請パケットが到着すると、パディング申請受付部１０３がそれを受け取る。図４に示すフローチャートは、パディング申請受付部１０３の処理の詳細を示したものである。ステップＳ４０１において、パディング申請受付部１０３は、パケットパディング部１０２より、現在の通信で送信中のパケットの最大長を取得し、Ｌｍａｘ２としてメモリ１０３１に保存する。通信の単位は、ＲＦＣ３５５０で規定されるＲＴＰパケットの送信単位で規定される。具体的には、映像のＲＴＰパケットを送信する単位や音声のＲＴＰパケットを送信する単位が挙げられる。パケットパディング部１０２では、それらの通信において過去に送信したパケットの最大長を保持する。このパケットの最大長の値は、パディング申請受付部１０３の要求に基づき通知する。

次に、ステップＳ４０２において、パディング申請受付部１０３は、パディング申請パケットに記載されている予測正常パケット長Ｌおよびリオーダ個数Ｎｒをそれぞれメモリ１０３１に保存する。次いで、ステップＳ４０３において、パディング申請受付部１０３は、現在の送信帯域ＳＷおよび最大バースト送信個数Ｂｍａｘをパケットパディング部１０２より取得し、それぞれメモリ１０３１に保存する。パケットパディング部１０２では、パケットの送信量を一定時間毎に統計する。現在の送信帯域ＳＷは、パケットの送信量を観測間隔で除算したものである。また、パケットパディング部１０２では、特定時間毎にパケットを０個以上Ｎ個送信するかどうかをトークンバケツで判定する。このとき、パケットパディング部１０２は、同じ通信で、過去特定時間Ｐ以内に一度に送信した最大のパケット数を記録している。パケットパディング部１０２は、この一度に送信した最大のパケット数をＢｍａｘとして、パディング申請受付部１０３に引き渡す。

次いで、ステップＳ４０４において、パディング申請受付部１０３は、現在の送信帯域ＳＷ、最大バースト送信個数Ｂｍａｘ、リオーダ個数Ｎｒ、予測正常パケット長Ｌから、補正済み正常パケット長Ｌｍを算出する。また、パディング申請受付部１０３は、算出した補正済み正常パケット長Ｌｍをパケットパディング部１０２に通知し、処理を終了する。補正済み正常パケット長Ｌｍは、Ｌｍ＝Ｌ−β（Ｌｍａｘ２−Ｌ）／Ｉ（Ｎｒ／Ｂｍａｘ）で算出する。ここで、βは、０≦β≦１を満たす定数であり、Ｉ（ｘ）は、Ｉ（ｘ）＝１（ｘ≧１）、ｘ（０≦ｘ＜１）の値をとる関数である。

パケットパディング部１０２では、通知された補正済み正常パケット長Ｌｍに従って、送信するパケットにパディングを実施する。具体的には、送信対象のパケットの長さがＬｍに満たない場合、パケット全体の長さがＬｍになるようにパディングする。パディングの具体的な処理は、前述したＩＰｖ６のＰＡＤ１、ＰＡＤＮオプションを用いる方法やＲＴＰのパディングビットを用いてパディングの有無をパケット中に記録し、最後尾のバイトでパディング長を伝送する方法を用いてよい。

以上の実施の形態１で述べたように動作することで、送信端末１は、ネットワーク１０でリオーダが発生しない長さにパケットにパディングを施して送信するため、ネットワーク１０でリオーダが発生することは無くなる。また、受信端末２では、リオーダしたパケットを並べ直すためにパケットをバッファする必要がなくなる。この結果、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。

なお、リオーダが発生する要因として、ルータ間の回線のトランキングを挙げているがこれに限らない。例えば、リオーダの発生原因は、複数チャネルを用いて通信する無線ネットワークにおけるチャネル選択が原因となる場合がある。また、別の例としては、企業ネットワークとインターネットとの間に設置されるファイヤーウオール中に配置される複数の不正パケット検知エンジンの処理時間ずれによって発生する場合がある。これのいずれの場合でも、本実施の形態の通信端末は、有効に動作する。

（実施の形態２）
図５は、本発明の実施の形態２に係る送信端末及び受信端末それぞれの概略構成を示すブロック図である。なお、図５において前述した図１と共通する部分には同一の符号を付けている。前述した実施の形態１では、受信端末２からのパディング申請に基づいて、送信端末１がパディングの実行の要否を判定していたが、実施の形態２では、送信端末１Ａにおいてパディングの要否を判断する点が実施の形態１とは異なっている。

図５において、送信端末１Ａのリオーダ予測部５０１は、ネットワーク１０でリオーダが発生するかどうか予測する。パケットパディング部５０２は、図１のパケットパディング部１０２と同じ機能を有し、リオーダ予測部５０１に、シェイピングタイマ粒度（shaping timer granularity）を与えるという点に違いがある。受信端末２Ａのパディング除去部５０３は、図１で説明したパディング除去部２０２と同じ機能を有するが、パケットを受信し、パディング除去が不要な場合、受信したパケットをそのままデータ再生部２０３に受け渡す点に違いがある。

リオーダ予測部５０１は、送信帯域と送信データ量とパケットパディング部５０２から受け取り、シェイピングタイマ粒度からリオーダの発生を予測する。さらに、リオーダ予測部５０１は、リオーダが実際に発生するのを防止するのに必要なパケット長、すなわちパディング後のパケットの長さを示す送信予測正常パケット長を算出し、その結果をパケットパディング部５０２に通知する。リオーダ予測部５０１は、データ保存用のメモリ５０１１を有している。

ここでは、リオーダ予測部５０１の動作について、図６を参照して詳細に説明する。図６は、リオーダ予測部５０１の処理の詳細を説明するためのフローチャートである。データ発生部１０１は、一定時間毎にデータを発生させてリオーダ予測部５０１に引き渡す。例えばデータ発生部１０１は、映像のエンコーダを含む場合、画面のエンコード毎に特定量のデータを発生する。例えば、６０フレーム／秒の画面をエンコードする場合は、１／６０秒毎に数十キロバイトのデータを発生する。

データ発生部１０１が生成したデータを受け取ったリオーダ予測部５０１は、ステップＳ６０１で、パケットパディング部５０２より現在の送信帯域ＳＷを取得し、メモリ５０１１に保存する。また、データ発生部１０１が発生したデータ量Ｄをメモリ５０１１に保存する。次いで、ステップＳ６０２において、リオーダ予測部５０１は、パケットパディング部５０２から最大パケット長Ｌｍａｘ３を取得し、メモリ５０１１に保存する。最大パケット長Ｌｍａｘ３は、パケットパディング部５０２がネットワーク１０にパケットを送信する際、最大パケット長（ＭＴＵ: Max Transfer Unit）を利用してもよい。また、最大パケット長Ｌｍａｘ３は、パケットパディング部５０２が特定の最大長以下でパケットを送信するようにデータを分割パケット化する際、利用する最大パケット長でもよい。

次いで、ステップＳ６０３において、リオーダ予測部５０１は、パケットパディング部５０２よりシェイピングタイマ粒度Ｐｔを取得し、メモリ５０１１に保存する。ここで、シェイピングタイマ粒度とは、パケットパディング部５０２がネットワーク１０にパケットを送信する際、一定時間毎に一定個数のパケットを送信するように送信流量を制御する時刻間隔をさす。具体的には、このシェイピングタイマ粒度は、ソフトウエアで実装されている場合、ソフトウエアのオペレーティングシステム（ＯＳ：Operating System）が提供するタイマの粒度に下限を律速される。例えば、フリーウエアのオペレーティングシステムであるＬｉｎｕｘ（登録商標）では、オペレーティングシステムのタイマ粒度を設定する値（ＨＺ）をＨＺ＝１０００とし、最も細かく動作する場合で、タイマの粒度は、１ミリ秒である。このシステムの場合は、これ以上細かい時間間隔（例５００マイクロ秒）で動作することはできない。シェイピングタイマ粒度とは、この例の場合１ミリ秒である。

次に、ステップＳ６０４において、リオーダ予測部５０１は、現在の送信帯域ＳＷ、最大パケット長Ｌｍａｘ３、発生したデータ量Ｄ、シェイピングタイマ粒度Ｐｔより、バースト送信個数Ｂを算出する。具体的には、バースト送信個数Ｂ＝（Ｄ／Ｌｍａｘ３）＊８／ＳＷ＊Ｐｔを算出し、算出結果をメモリ５０１１に保存する。次いで、ステップＳ６０５において、リオーダ予測部５０１は、バースト送信個数Ｂが正の整数定数β以上か否かを判定し、β以上の場合はステップＳ６０７を実行し、β未満の場合はステップＳ６０６を実行するように処理を分岐する。ステップＳ６０６（すなわち、Ｂ＜βの場合）の処理では、送信パケット毎にパディングする必要がないことをパケットパディング部５０２に通知するとともに、データをパケットパディング部５０２に引き渡す。パケットパディング部５０２は、受け取ったデータを特定長のパケットに必要であれば分割して、受信端末２Ａに向けて上述した流量制御を実行しながら送信する。

一方、ステップＳ６０７（すなわち、Ｂ≧βの場合）において、リオーダ予測部５０１は、バースト送信個数Ｂとパケット長Ｌｃと最大パケット長Ｌｍａｘ３より、送信予測正常パケット長Ｌｓを算出する。さらに、リオーダ予測部５０１は、これをパケットパディング部５０２に通知するとともに、データをパケットパディング部５０２に引き渡す。ここで、送信予測正常パケット長Ｌｓは、Ｌｓ＝Ｌｃ＋（Ｌｍａｘ３−Ｌｃ）＊Ｂ／γ（但し、γはγ≧Ｂとなる定数、Ｌｃは送信する対象のパケット長さ）として算出する。なお、送信予測正常パケット長Ｌｓは、γ＝Ｂ、すなわち、Ｌｓ＝Ｌｍａｘとして運用してもかまわない。

送信予測正常パケット長Ｌｓの通知を受けたパケットパディング部５０２は、受け取ったデータを特定長のパケットに必要であれば分割して、受信端末２Ａに向けて上述した流量制御を実行しながら送信する。なお、このとき、パケットパディング部５０２は、送信する対象のパケットの長さＬｃがＬｓ以下である場合、パケット長がＬｓになるようにパディングを施しながらパケットを送信する。

以上の実施の形態２で述べたように動作することで、送信端末１Ａは、ネットワーク１０でリオーダが発生しない長さにパケットにパディングを施して送信するため、ネットワーク１０でリオーダが発生することは回避される。また、受信端末２Ａでは、リオーダしたパケットを並べ直すためにパケットをバッファする必要がなくなる。この結果、最終的な伝送の遅延時間がより短いリアルタイムストリームの伝送が可能となる。特に、実施の形態２では、送信端末１Ａがパディングの実行の要否を判定するので、受信端末２Ａに実施の形態１の受信端末２が持つリオーダ状況解析部２０１及びパディング申請部２０４を設ける必要が無い分、受信端末２Ａを安価となる。

本発明を詳細にまた特定の実施態様を参照して説明したが、本発明の精神と範囲を逸脱することなく様々な変更や修正を加えることができることは当業者にとって明らかである。

本出願は、２００８年１２月１９日出願の日本特許出願（特願２００８−３２４６０９）に基づくものであり、その内容はここに参照として取り込まれる。

本発明は、最終的な伝送の遅延時間がより短い映像音声などのリアルタイムストリームの伝送が可能になるといった効果を有し、映像音声などリアルタイムのストリーミングデータの送信を行うサーバ等の送信端末、該送信端末から送信されたストリーミングデータを受信可能なパーソナルコンピュータ、携帯電話等の受信端末への適用が可能である。

１、１Ａ 送信端末
２、２Ａ 受信端末
１０ ネットワーク
１０１ データ発生部
１０２、５０２ パケットパディング部
１０３ パディング申請受付部
２０１ リオーダ状況解析部
２０２、５０３ パディング除去部
２０３ データ再生部
２０４ パディング申請部
５０１ リオーダ予測部
１０３１、２０１２、５０１１ メモリ
２０１１ タイマ

Claims (6)

1. パケットを発生させるデータ発生部と、
   受信端末から送信されるパディングを要求するパディング申請パケットを受け取るパディング申請受付部と、
   前記パディング申請受付部からのパディング要求に基づいて、パケット長が特定長以上となるように、前記データ発生部で発生されたパケットにパディングを施し、ネットワークに送信するパケットパディング部と、
   を備え、
   前記パディング申請パケットは、受信端末で算出されたリオーダが発生しない正常パケット長を含み、
   前記パケットパディング部は、前記正常パケット長となるように、前記データ発生部で発生されたパケットにパディングを施す、
   送信端末。
2. ネットワークからパケットを受信し、該パケットのリオーダの発生状況を解析するリオーダ状況解析部と、
   前記リオーダ状況解析部で受信されたパケットを再生するデータ再生部と、
   前記リオーダ状況解析部での解析結果に基づいて、送信端末にパディングを要求するパディング申請パケットを生成するパディング申請部と、
   を備えた受信端末。
3. 前記リオーダ状況解析部は、リオーダが発生している場合、リオーダ個数と受信帯域から、予測正常パケット長を推定する、
   請求項２記載の受信端末。
4. 送信端末が、パケットを発生させるパケット発生ステップと、
   送信端末が、前記パケット発生ステップで発生されたパケットにパディングを施し、ネットワークに送信するパケット送信ステップと、
   受信端末が、前記ネットワークからパケットを受信し、該パケットのリオーダの発生状況を解析するリオーダ状況解析ステップと、
   受信端末が、前記リオーダ状況解析ステップでの解析結果に基づいて、パディングを要求するパディング申請パケットを生成するパディング申請パケット生成ステップと、
   送信端末が、前記パディング申請パケット生成ステップで生成されたパディング申請パケットを受け取るパディング申請パケット受付ステップと、を備え、
   前記送信端末のパケット送信ステップは、前記パディング申請パケット受付ステップからのパディング要求に基づいて、パケット長が特定長以上となるように、前記パケット発生ステップで発生されたパケットにパディングを施す、
   パケット送受信方法。
5. パケットを発生させるデータ発生部と、
   前記データ発生部で発生されるパケットの送信データ量と該パケットのバースト送信個数の情報からリオーダを防止するパケット長を算出するリオーダ予測部と、
   前記リオーダ予測部で算出された前記パケット長に従って前記パケットにパディングを施しネットワークに送信するとともに、前記バースト送信個数の情報を生成し、前記リオーダ予測部に供給するパケットパディング部と、
   を備えた送信端末。
6. パケットを発生させるパケット発生ステップと、
   前記パケット発生ステップで発生されるパケットの送信データ量と該パケットのバースト送信個数の情報からリオーダを防止するパケット長を算出するパケット長算出ステップと、
   前記パケット長算出ステップで算出された前記パケット長に従って前記パケットにパディングを施し、ネットワークに送信するとともに、前記バースト送信個数の情報を生成するパケット送信ステップと、
   を備えたパケット送信方法。

Images