JP2004187324A - Ｒｔｐおよびｒｔｃｐプロトコルを用いる動的なデータパケット送信方法 - Google Patents

Abstract

【課題】 データパケット、特に、リアルタイムまたはほぼリアルタイムで送信されるデータを、インターネットプロトコル（ＩＰ）ネットワークを介して、メディアデータパケットに対してはリアルタイムトランスポートプロトコル（ＲＴＰ）を、制御データパケットに対してはＲＴＰコントロールプロトコル（ＲＴＣＰ）を用いて送信する方法である。各プロトコルには、利用可能な送信帯域幅の割合が割り当てられている。設定されたＲＴＰ帯域幅は、一定期間の間は円滑に機能するが、暫くするとリンク状態の変化によって送信能力及び送信効率が低下する。
【解決手段】 関連するネットワークリンクの特性を測定するステップと、この測定値から最適化されたＲＴＣＰ帯域幅を算出するステップと、最適化されたＲＴＣＰ帯域幅を用いて、制御データパケットを送信するステップとを備える。
【選択図】 図１

Description

本発明は、データパケットの送信方法に関し、特に、標準的なプロトコルを用いて、インターネットプロトコル（ＩＰ）ネットワークを介して行われる、リアルタイムまたはほぼリアルタイムで行われるデータの送信方法に関する。

リアルタイムトランスポートプロトコル（ＲＴＰ）は、ＩＰネットワークを介して、リアルタイムまたはほぼリアルタイムで行われるデータの送信に広く利用されている（例えば、非特許文献１を参照）。ＲＴＰには、ＲＴＰコントロールプロトコル（ＲＴＣＰ）というプロトコルが付随している。ＲＴＣＰは、統計値の収集や順方向への制御データの送出といった、受信側から送信側へのフィードバックとして、送信の監視に用いられる。

ＲＴＰは、通常、２つの規則によってフィードバックの量を制限する。第１に、ＲＴＰセッション帯域幅のうち特定の割合（５％推奨）がＲＴＣＰのために割り当てられる。すべての受信側は、ＲＴＣＰに割り当てられた帯域幅を共有しており、この値から、フィードバックの送出期間を算出する。第２の規則では、２つのフィードバックを送信する間隔は少なくとも５秒間（５秒間が推奨値）でなければならない、とされている。
エイチ シュルツリン（H. Schulzrinne）、他４名、ア トランスポート プロトコル フォー リアルタイム アプリケーションズ（A Transport Protocol for Real-Time Applications）、［online］、１９９６年１月、［２００３年１月３１日検索］インターネット＜ＵＲＬ：http://www.ietf.org/rfc/rfc1889.txt?number=1889＞

これらの規則によって、大規模なマルチキャストグループはＲＴＰを安定した状態で利用することができるが、ユニキャスト送信、または小規模なマルチキャスト送信にとっては最適なものではない。これらのグループでは、より多くのフィードバックをユーザ毎に行うと有用であるし、また、実際により多くのフィードバックを送出することが可能である。こうした問題点はすでに認識されており、新ＲＴＰプロトコルの拡張版では、２つのフィードバック送信間の間隔は少なくとも５秒間でなければならない、という規則は削除されている。従って、セッションパラメータに応じて、受信側はより多くのフィードバックを送出することができる。しかし、割り当てられたＲＴＣＰセッション帯域幅を超過してはならない、という規則は依然として有効である。

上述したように、制御データ送信用として、ＲＴＣＰに割り当てられるＲＴＰ帯域幅の割合は、通常、５％という推奨値に固定されているが、この割合を他の値に変更するために、ある方法の規格化が現在進められている。また、ＲＴＣＰのフィードバックをオフにするために、ビット速度をゼロに設定することもできる。

ネットワークリンクパラメータに加えて、無線リンク上のパケット喪失率なども時間の経過とともに大きく変化する。従って、設定されたＲＴＰ帯域幅は、一定期間の間は円滑に機能するかもしれないが、しばらくすると、リンク状態の変化によって送信能力および送信効率は低下してしまう。

本発明の目的は、ＲＴＰプロトコルおよびＲＴＣＰプロトコルを用いた、送信効率の高いデータパケット送信方法を提供することである。

本目的は、請求項１に記載の方法によって解決される。当該方法の好ましい実施形態は、多様な従属請求項に記載されている。

本発明は、特殊なメディアセッションにおける特定の環境が、ＲＴＣＰ帯域幅に関する柔軟性を高めるという考察に基づいている。制御データ自体がメディアストリームの質を高めることはないため、制御データの送信用に固定された量を用いるのではなく、メディアデータパケット送信用のＲＴＰ帯域幅を最適化することが必要である。その反面、メディアデータパケットを送信するためには、一定量の制御データを送出しなければならない。ＲＴＰ帯域幅の固定割合を割り当てるという従来の解決手段では、ＲＴＣＰ帯域幅は、２つの連続するＲＴＣＰパケット間の５秒間という最小間隔によって低くなりすぎるか、または必要以上になるかのいずれかであった。

例えば、ユニキャストメディアセッションにおいて、ＲＴＣＰに対してＲＴＰセッション帯域幅の５％を割り当てた場合、制御データパケット用の送信期間はわずか数ミリ秒しかないことになる。送信側のビット速度によっては、その期間が数秒間となることもある。その結果、割り当てられた帯域幅は浪費され、特に、無線リンクなどの、帯域幅が貴重な資源であるリンクの送信効率は大幅に低下する。その反面、特に無線リンクは、例えば、変化するリンク状態に合わせてコーデックを調整し、送信側にメディアデータパケット送信が必要であることを通知するために、フィードバックを速く行わなければならない。

本発明の方法は、個々のメディアセッションに対して、関連するネットワークリンクの特性を測定し、この測定結果から、最適化されたＲＴＣＰ帯域幅を算出するという考え方に焦点を当てている。関連するネットワークリンクの特性とは、送信側と受信側との間の通信の状態を示す特性である。その後、算出された帯域幅は制御データパケットの送信に用いられるが、それと同時に、メディアデータパケットは利用可能な余剰帯域幅を用いて送信される。こうすることで、最適化された帯域幅配分を行うことが可能となるため、メディアデータパケット送信の効率は最大限に高まり、制御データを適切な速度で提供するために適した方法でＲＴＣＰ帯域幅を配分することができる。従って、異なるリンクごとに最適化された帯域幅配分を多様な形で行いうるため、最も効率的な送信が実現する。

さらに、関連するネットワークリンクの特性を常時測定することで、送信経路の状態および環境を把握することが可能となり、それに応じて、ＲＴＣＰ帯域幅を動的に変更することができる。従って、制御データの量とリンク上における送信効率とを最適化された状態に保ちながら、送信システムを継続的に機能させることができる。

好ましい実施形態によれば、関連するネットワークリンクの特性を測定するステップは、時間間隔あたりに送出されるデータパケットの数の測定を含む。

さらに好ましい実施形態によれば、一定の時間内に送出されたパケットの数で、喪失したパケットの数を割った商を測定することで、リンクの質が確定する。

さらに好ましい実施形態として、サーバからクライアントにパケットを送信し、再びサーバに返送するために必要な時間を測定することで、ネットワークリンクの往復時間を測定する。さらに、ネットワークリンクの特性は、輻輳状態が判明してから測定されると好ましい。

関連する特性に対する全ての測定が、繰り返し、一定の間隔で行われると、最適化されたＲＴＣＰ帯域幅でシステムが継続的に機能しうるので好ましい。最適化されたＲＴＣＰ帯域幅が、クライアントからサーバにフィードバックとして通知されると好都合である。

好ましくは、本発明の方法は、連続する２つの制御データを送信する、フィードバックの最適な間隔を算出するステップをさらに備える。

以下、図１を参照しながら、本発明をより詳細に説明する。図１は、本発明の好ましい実施形態を処理手順として示したフローチャートである。

図１から明らかなように、メディアセッションの開始時点で、関連するネットワークリンクの特性の測定結果が存在するか否かを判断する必要がある。その時点でサンプルが使用できない場合、ステップ１００において、仮定と推測を行わなければならない。

ステップ１０１では、通知すべきフィードバックイベントが確定される。ステップ１０１では、アプリケーションによって、必要なフィードバックの種類を選択しなければならない。一般的に、新ＲＴＰプロトコルは、特定種類のフィードバックに限定されていない。例としては、定期的に行われる状態の通知、または正もしくは負の応答などが挙げられる。

定期的に行われる状態の通知は送信側が行うことが多い。この通知によって、ネットワークの状態を判断し、当該判断に基づいて、送信パラメータを調整する。例としては、輻輳制御アルゴリズムが挙げられるが、このアルゴリズムを行うには、通常、往復時間毎に少なくとも一回の割合で、ネットワークにおけるパケット喪失率に関する情報を提供しなければならない。

負の応答（ＮＡＣＫ）は、エラー回復機能を実行するために、送信側が用いるものである。エラー回復機能を実行すると、再送信、すなわち、コーディングパラメータの変更が行われるので、例えば、喪失したデータとは無関係に、新しいデータを利用することが可能となる。

正の応答（ＡＣＫ）は、通常、コーディング、すなわち、送信の効率を高めるために送られる。受信されたデータが送信側にとって既知のものである場合、送信側は、次のデータのコーディングを行うための参照用として当該受信されたデータを用いてもよい。

上述したイベントは、単独で、または、いくつかを組み合わせて用いることができるので、フィードバックも、独立して、または組み合わせて利用することができる。典型的な例としては、測定されたパケット喪失率に関する定期的なフィードバックが挙げられる。このフィードバックは、送信側の輻輳制御アルゴリズムに必要であるとともに、喪失データの再送信を実行するための、すべての喪失パケットに対するＮＡＣＫにも必要なフィードバックである。

図１における次のステップ１０２では、最適化されたＲＴＣＰ帯域幅の割合を算出するために必要な入力パラメータの測定を行わなければならない。ネットワークリンクの特性は時間の経過と共に変化するので、これらの測定は、繰り返し、定期的に行う必要がある。行うべき測定は、フィードバックの種類によって異なる。上述した種類のフィードバックを行う際、最適化されたＲＴＣＰ帯域幅が利用できるようにするために、以下に挙げる測定（ただし、全てを網羅していない）が一般的に行われる。

（パケット速度）
パケット速度とは、時間間隔あたりに送出されるパケットの数のことである。このパラメータは、推測に基づいて把握してもよいし、可変的なものであってもよい。パケット速
度の測定が行われる例としては、やはり時間とともに変化するネットワークの輻輳状態に応じて、送出するパケットの速度を調節するサーバが挙げられる。クライアントは、時間間隔あたりのパケットの数をカウントして、パケット速度を測定する。サーバからクライアントへの送信経路の途中でパケットが喪失する場合があるので、繰り返し測定を行うことによって、複数の測定値の平均を用いなければならない。この測定を行う典型的な方法は、移動平均（今までに測定されたパケット速度の平均）の算出、すなわち、ｐｒ＿ｎｅｗ＝（１／ｗ＊ｐｒ＿ｍ）＋（（ｗ−１）／ｗ＊ｐｒ＿ｏｌｄ）という計算式を用いる方法である。この計算式において、ｐｒ＿ｎｅｗは、算出された平均パケット速度、ｐｒ＿ｏｌｄは、直前のパケット平均速度、ｐｒ＿ｍは、パケット速度の現時点における測定サンプル、ｗは、今回の測定が平均に与える影響を判断する重み係数である。

（パケット喪失率）
パケット喪失率は、喪失パケットの数を、一定の時間間隔の間に送出されたパケットの数で割った商として定義される。パケット喪失率は、例えば、リンクの状態に応じて時間の経過とともに大きく変化する場合が多いため、正確なサンプルを抽出するためには、測定用に選定される時間間隔が非常に重要となる。典型的な時間間隔は、往復時間毎に一回、または往復時間毎に複数回である。

（往復時間（ＲＴＴ））
往復時間は、パケットがサーバからクライアントに送信されて、再びサーバに返送されるために必要な時間として定義される。この値も、輻輳や他の問題が生じるといったネットワークの状態に応じて、時間の経過とともに大きく変化する。典型的には、パケット速度の箇所で説明したように、往復時間の測定も移動平均に基づいて行われる。

前述したように、メディアセッションが開始されてはいないが、メディアセッションのセットアップは予定されている場合、どの測定も実行不可能なことがある。従って、仮定に基づく測定値を設定しなければならない。典型的には、これらの測定値は、正しいオーダーに依拠して推定することができる。

次のステップ１０３では、２つのフィードバックを送信する間隔が算出される。フィードバックの間隔は、上述の測定結果に左右されるが、フィードバックの種類に左右されることもある。ＲＴＴ毎に一回のような通常のフィードバックが必要な場合、最大のフィードバック間隔は、ＲＴＴに依拠して容易に推定することができる。パケットの受信やパケットの喪失などのイベントを通知する場合、これらのイベント間の平均間隔を算出しなければならない。ＡＣＫの場合、この平均間隔はパケット到着間時間であり、これはパケット速度に反比例する。ＮＡＣＫの場合、パケット到着間時間を平均パケット喪失率で割った商である。

イベント間の時間平均が長期的にかなり安定した状態である限り、ＲＴＣＰプロトコルを用いることで、送信間に生じる短期的な変化を確実に相殺することができる。

ステップ１０４では、フィードバック帯域幅が算出される。必要なＲＴＣＰ帯域幅を適切に算出するためには、フィードバックパケットの大きさを把握していることが好ましい。大半のアプリケーションにおいて、セッションの間、パケットの大きさは固定されているが、変更することも可能である。例えば、パケットの喪失時、一回のフィードバックパケットにおいて、２つ以上の喪失イベントを通知する場合がある。従って、フィードバックパケットの大きさの平均値が用いられるべきである。

フィードバックパケットの大きさｓ＿ｆｂ（単位：ビット）およびフィードバック速度ｒ＿ｆｂ（単位：パケット／秒）を用いると、必要な平均ＲＴＣＰ帯域幅（ビット／秒）
は、ｂｗ＿ｒｔｃｐ＝ｓ＿ｆｂ＊ｒ＿ｆｂとして算出することができる。

ＲＴＰセッション帯域幅ｂｗ＿ｒｔｐは、セッション期間中は固定されている。ＲＴＣＰ帯域幅の割合は、ステップ１０５において、ｆ＿ｒｔｃｐ＝ｂｗ＿ｒｔｃｐ／ｂｗ＿ｒｔｐから算出される。

次のステップ１０６において、新たに算出された帯域幅の割合は、以前の値とそれぞれ比較される。この比較から顕著な違いが判明した場合、ステップ１０７に示すように、新しい帯域幅は送信側に通知される。

新しいＲＴＣＰ帯域幅の割合の値を通知すると、ある程度のオーバーヘッドが生じうる。また、現在行われているセッションを解除し、その後、新しいＲＴＣＰ帯域幅の割合を用いて、新しいセッションを開始する必要が生じるが、そのような場合でも、セッションの変更を早急に行うことは可能である。

考慮しなければならないのは、新しい帯域幅の割合を通知すべきか否かをいつ決定するかである。以前の割合とそれほど異なっていない場合、通知しなくてもよいことがある。フィードバックによる方法は絶対的なものではない。すなわち、イベントに対するフィードバックは、所詮、保証されたものではないのである。フィードバックが時間どおりに送出される可能性は上がる。従って、利点との兼ね合いを考慮しながら、新しい値を通知する際に生じるオーバーヘッドに対して慎重に対処する必要がある。

ＲＴＣＰの割合は変更するが、現在の通知プロトコルはそのまま使う場合、以下の手順が必要となる。

どのセッションのセットアップも完了していない場合、帯域幅の割合は、セクション記述プロトコル（ＳＤＰ）を用いて通知される。セッションが既に確率されている場合、ＲＴＣＰ ＢＹＥ メッセージを送出することで、このセッションを解除し、新しいセッションをセットアップしなければならない。この新しいセッションでは、ＳＤＰによってＲＴＣＰ帯域幅が通知される。算出されたＲＴＣＰ帯域幅の割合を通知する方法は、これ以外にも考えられる。

ステップ１０１から１０７は、処理手順が一通り終了した後も、繰り返し、定期的に行われる。これらのステップを繰り返すことで、全セッションを通じて、最適化された帯域幅の割合が恒常的に利用される。帯域は可変的なものであるから、ＲＴＣＰ帯域幅の割合に対して、定期的な測定、修正、および動的な変更を行うことによって補償される。それと同時に、ＲＴＣＰ帯域幅に静的な修正を行うことも可能なので、セッションの開始時点で算出されるＲＴＣＰ帯域幅の割合は、測定結果ではなく、仮定と既知のパラメータとに基づいて導き出されている。その際、セッションの間はＲＴＣＰ帯域幅が変化しないために、値が不正確になり、送信動作が低下するという事態が生じてしまう。こうした欠点は、セッション進行中に生じる変化に応じて、動的に再計算を行うことで補償される。

本発明の好ましい実施形態を処理手順として示したフローチャートである。

Claims (11)

1. データパケットを送信する方法であって、
   インターネットプロトコル（ＩＰ）ネットワークを介して、メディアデータパケットに対してはリアルタイムトランスポートプロトコル（ＲＴＰ）を、制御データパケットに対してはＲＴＰコントロールプロトコル（ＲＴＣＰ）を用いて送信し、
   各プロトコルには利用可能な送信帯域幅の割合が割り当てられ、
   関連するネットワークリンクの特性を測定するステップと、
   測定された値から、ＲＴＣＰ帯域幅を算出するステップと、
   算出されたＲＴＣＰ帯域幅を用いて、制御データパケットを送信するステップとを備える、送信方法。
2. 関連するネットワークリンクの特性を測定するステップは、時間間隔あたりに送出されるデータパケットの数を測定するステップを含むことを特徴とする、請求項１に記載の送信方法。
3. 関連するネットワークリンクの特性を測定するステップは、送信の間に喪失したパケットの数を測定するステップを含むことを特徴とする、請求項１または２に記載の送信方法。
4. 関連するネットワークリンクの特性を測定するステップは、サーバからクライアントにパケットを送信し、再びサーバに返送するために必要な時間を測定するステップを含むことを特徴とする、請求項１から３のいずれかに記載の送信方法。
5. 関連するネットワークリンクの特性を測定するステップは、ＩＰネットワークの輻輳状態を測定するステップを含むことを特徴とする、請求項１から４のいずれかに記載の送信方法。
6. 関連するネットワークリンクの特性を測定するステップは、繰り返し、一定の間隔で行われることを特徴とする、請求項１から５のいずれかに記載の送信方法。
7. ＲＴＣＰ帯域幅は、クライアントからサーバにフィードバックとして通知されることを特徴とする、請求項１から６のいずれかに記載の送信方法。
8. 制御データパケットは、定期的に行われる状態の通知、または送信イベントの正もしくは負の応答のいずれかであることを特徴とする、請求項１から７のいずれかに記載の送信方法。
9. 連続する２つの制御データパケットを送信する、フィードバックの最適な間隔を算出するステップをさらに備えることを特徴とする、請求項１から８のいずれかに記載の送信方法。
10. ＲＴＣＰ帯域幅を算出するステップは、制御データパケットの平均速度を測定するステップを備えることを特徴とする、請求項１から９のいずれかに記載の方法。
11. ＲＴＣＰ帯域幅を算出するステップは、制御データパケットの大きさを測定するステップを備えることを特徴とする、請求項１から１０のいずれかに記載の送信方法。
    

Images