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

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. 制御データパケットは、一定の間隔よりも早いタイミングで送信され、定められたＲＴＣＰ帯域幅を平均で超えることがないように、次に予定された制御データパケットは延期される、請求項１から１０のいずれかに記載の方法。