JP4299275B2 - マルチメディアデータ転送率の適応的推定方法 - Google Patents

Description

本発明は、有線ＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）網におけるリアルタイム転送プロトコル（以下、「ＲＴＰ」と称す）／リアルタイム転送制御プロトコル（以下、「ＲＴＣＰ」と称す）ベースのマルチメディアデータ転送システムに関し、特に、ＲＴＣＰ網の状態をモニタリングする機能を使用してマルチメディアデータ転送率を適応的に推定するための方法に関する。

一般に、インターネットなどの有線ＩＰ網でマルチメディアデータを転送するためには、チャネルの十分な帯域幅、少ない遅延、及び少ないパケット損失などの条件が保障されなければならない。しかしながら、現在の有線ＩＰ網におけるネットワーク層は、ビデオ転送に必要なサービス品質（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ；以下、ＱｏＳと称す）を満たすための適切な機能を提供することができない。従って、ＱｏＳの保障は、ネットワーク層の上位層により行われなければならない。このために提案されたのが、トランスポート層上で動作するＲＴＰとＲＴＣＰである。

前記ＲＴＰは、リアルタイムに生成されるオーディオ及びビデオのようなリアルタイムマルチメディアデータを転送するためのインターネットプロトコルである。ＲＴＰ自体がデータのリアルタイム転送を保障することはないが、ＲＴＰを使用すると、リアルタイムマルチメディアデータ転送システムにおける送受信のための応用プログラムがストリーミングデータを支援することができる。一般に、ＲＴＰは、ＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）上で実行される。また、前記ＲＴＣＰは、ＲＴＰのＱｏＳを維持するために共に使用されるプロトコルである。ＲＴＰはデータ転送のみに関わるが、ＲＴＣＰはデータ転送の監視及びセッション関連情報の転送に関わる。各ＲＴＰノードは、ネットワークの状態を分析し、周期的にネットワークの渋滞の有無を報告するためにＲＴＣＰパケットを互いに送受信する。ＲＴＰとＲＴＣＰの使用により、マルチメディアデータ転送時、時間の制約による特性が考慮され、ネットワーク内で発生する損失に対処することができる。

一般的なリアルタイムマルチメディアデータ転送システムにおいて、マルチメディアアプリケーションプログラム（アプリケーション層）は、前記ＲＴＣＰによりネットワークの状態を感知して、転送するリアルタイムマルチメディアデータの符号化率を制御する。前記リアルタイムマルチメディアデータの符号化率の制御は転送率の制御によりなされ、ＲＴＣＰによるネットワークの状態情報を使用して有効転送率を推定する一般的な方法は次の数式１による。

式中、Ｒ（ｔ）は有効転送率を示し、ｐ（ｔ）はパケット損失率を示すもので受信側から受信されたＲＴＣＰにより得られる値である。ＲＴＴ（ｔ）は往復遅延時間を示し、ｓはパケットサイズを示す。

前記数式１によれば、往復遅延時間（ＲＴＴ（ｔ））とパケット損失率（ｐ（ｔ））が与えられると、一般的な有効転送率（Ｒ（ｔ））が推定される。即ち、数式１を用いる一般的な転送率の推定方法によれば、パケットサイズ（ｓ）が固定されている場合、往復遅延時間（ＲＴＴ（ｔ））とパケット損失率（ｐ（ｔ））によって推定転送率が変化する。

図４は、パケット損失率（ｐ（ｔ））とパケットサイズ（ｓ）を固定し、往復遅延時間（ＲＴＴ（ｔ））を線形的に変化させた場合、数式１により推定された有効転送率の変化を示す。パケット損失率（ｐ（ｔ））≡０．０１５、パケットサイズ（ｓ）≡６２５に固定し、往復遅延時間（ＲＴＴ（ｔ））を８０ｍｓ〜３８０ｍｓの範囲内で線形的に増加させ、このとき、使用者の最小転送率は５０ｋｂｐｓであり、最大転送率は５００ｋｂｐｓである。図４に示すように、往復遅延時間（ＲＴＴ（ｔ））が増加するにつれて推定される有効転送率が適当に減少する。

図５は、往復遅延時間（ＲＴＴ（ｔ））とパケットサイズ（ｓ）を固定し、パケット損失率（ｐ（ｔ））を線形的に変化させた場合、数式１により推定された有効転送率の変化を示す。往復遅延時間（ＲＴＴ（ｔ））≡１００ｍｓ、パケットサイズ（ｓ）≡６２５に固定し、パケット損失率（ｐ（ｔ））を０．１％〜２０％の範囲内で線形的に増加させ、このとき、使用者の最小転送率は５０ｋｂｐｓであり、最大転送率は５００ｋｂｐｓである。

図５に示すように、数式１による一般的な有効転送率の推定方法においては、パケット損失が多いためタイムアウトのような現象が発生することは考慮されていなかった。従って、パケット損失率が低い場合は有効転送率が適切な値に推定されるが、パケット損失率が高い場合は有効転送率が過大評価されて推定される。即ち、一般的な転送率の推定方法においては、例えば、パケット損失率が１０％のように相当高い値である場合も、有効転送率が２００ｋｂｐｓくらいの高い値に推定されるという問題があった。

また、このような一般的な転送率の推定方法においては、パケット損失率が高いとき有効転送率が高く推定されるため、ネットワークの渋滞を速やかに解消することができず、マルチメディアデータの受信品質が低下するという問題があった。
韓国特許出願公開第２００４−００２０６３９号 日本国公開特許公報２００２−２０４２７８号 米国特許出願公開第２００２０１３６１６２号 国際公開第ＷＯ０３／０９８８８４号

本発明は、このような従来技術の問題を解決するためになされたもので、受信側から受信されたＲＴＣＰ ＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケットからパケット損失率を検出し、前記パケット損失率によって有効転送率の推定方法を変化させることにより、有効転送率における推定値の正確性を高めることができるマルチメディアデータ転送率の適応的推定方法を提供することを目的とする。

このような目的を達成するために、本発明によるマルチメディアデータ転送率の適応的推定方法は、マルチメディアデータ受信部からＲＴＣＰ ＲＲパケットを受信する過程と、前記ＲＴＣＰ ＲＲパケットからパケット損失率を検出する過程と、前記パケット損失率が属する範囲によって有効転送率を適応的に推定する過程とを含むことを特徴とする。

上記目的を達成するために、本発明は、例えば、以下の手段を提供する。
（項目１）
マルチメディアデータ受信部からＲＴＣＰ ＲＲパケットを受信する過程と、
前記ＲＴＣＰ ＲＲパケットからパケット損失率を検出する過程と、
前記パケット損失率が属する範囲によって有効転送率を適応的に推定する過程と、
を含むことを特徴とするマルチメディアデータ転送率の適応的推定方法。
（項目２）
前記有効転送率を推定する過程は、
前記パケット損失率が属する範囲によって異なる演算方法で有効転送率を推定することを特徴とする項目１に記載のマルチメディアデータ転送率の適応的推定方法。
（項目３）
前記有効転送率を推定する過程は、
前記パケット損失率が第１の範囲に属する場合、第１の数式により有効転送率を推定する過程と、
前記パケット損失率が第２の範囲に属する場合、第２の数式により有効転送率を推定する過程と、
前記パケット損失率が第３の範囲に属する場合、第３の数式により有効転送率を推定する過程と、
を含むことを特徴とする項目１に記載のマルチメディアデータ転送率の適応的推定方法。
（項目４）
前記第１の数式は、

を含むことを特徴とする項目３に記載のマルチメディアデータ転送率の適応的推定方法。

ｓ：パケットサイズ
ＲＴＴ（ｔ_ｎ）：往復遅延時間
ｐ（ｔ_ｎ）：ｎ番目のＲＴＣＰ ＲＲパケットから検出されたパケット損失率
（項目５）
前記第２の数式は、
Ｒ_２（ｐ（ｔ_ｎ））＝

を含むことを特徴とする項目３に記載のマルチメディアデータ転送率の適応的推定方法。

ｓ：パケットサイズ
ｐ（ｔ_ｎ）：ｎ番目のＲＴＣＰＲＲパケットから検出されたパケット損失率
ＬＳＲ（ｔ_ｎ）：ｎ番目のＲＴＣＰＳＲパケットの送信時間
α、β：加重値
（項目６）
前記第３の数式は、
使用者により設定された最小転送率を含むことを特徴とする項目３に記載のマルチメディアデータ転送率の適応的推定方法。
（項目７）
前記第１の範囲、前記第２の範囲、及び前記第３の範囲は、
それぞれ５％以下、５％超過１０％未満、及び１０％以上の範囲を示すことを特徴とする項目３に記載のマルチメディアデータ転送率の適応的推定方法。
（項目８）
ＲＴＰパケットが所定の個数送信されるごとに、ＲＴＣＰ ＳＲパケットが１つ送信され、前記ＲＴＣＰ ＲＲパケットが１つ受信されることを特徴とする項目１に記載のマルチメディアデータ転送率の適応的推定方法。
（項目９）
前記所定の個数が２０を含むことを特徴とする項目８に記載のマルチメディアデータ転送率の適応的推定方法。
（項目１０）
前記ＲＴＣＰ ＲＲパケットは、マルチメディアデータ送信部から受信されたＲＴＰパケットの統計情報を該マルチメディアデータ送信部にフィードバックするための受信報告ブロックを含み、
前記受信報告ブロックは、パケット損失率と、最後のＲＴＣＰ ＳＲパケットの送信時間（ＬＳＲ）とを含むことを特徴とする項目８に記載のマルチメディアデータ転送率の適応的推定方法。

本発明によるマルチメディアデータ転送率の適応的推定方法においては、受信部から受信されたＲＴＣＰ ＲＲパケットからパケット損失率を検出し、検出されたパケット損失率が属する範囲によって有効転送率の推定方法を適応的に選択することにより、パケット損失が大きい場合は有効転送率をさらに低い値に推定してネットワークの渋滞を速やかに解消することができ、パケット損失を減らしてマルチメディアデータの受信品質を向上させることができるという効果がある。

以下、本発明によるマルチメディアデータ転送率の適応的推定方法の好ましい実施形態を説明する。

図１は、ＲＴＰとＲＴＣＰが適用された、一般的なリアルタイムマルチメディアデータ転送システムの構成を示すブロック図である。

図１に示すように、一般的なリアルタイムマルチメディアデータ転送システムの送信部及び受信部は、それぞれ転送ドメイン（ｔｒａｎｓｐｏｒｔ ｄｏｍａｉｎ）と圧縮ドメイン（ｃｏｍｐｒｅｓｓｉｏｎ ｄｏｍａｉｎ；アプリケーション層に含まれる）とに分けられる。

前記送信部の圧縮ドメインは、マルチメディアデータを推定された転送率によって符号化するビデオエンコーダと、前記符号化されたマルチメディアデータを圧縮するビデオ圧縮部とを含む。

前記送信部の転送ドメインは、前記ビデオ圧縮部から転送されたマルチメディアデータを転送制御するＲＴＰ層と、前記ＲＴＰ層から転送されたマルチメディアデータを受信部に送信するためのＵＤＰ層及びＩＰ層と、前記ＲＴＰ層と連結され、前記受信部から受信されたＲＴＣＰ ＲＲパケットからパケット損失率を検出し、前記ＲＴＣＰ ＲＲパケットを用いて往復遅延時間（ＲＴＴ）を測定し、前記パケット損失率及び前記往復遅延時間を用いて転送率を推定し、前記推定された転送率を前記ビデオエンコーダに提供する転送率制御部とを含む。

前記受信部の転送ドメインは、ＩＰ層及びＵＤＰ層と、前記ＵＤＰ層から受信されたマルチメディアデータを転送制御するＲＴＰ層と、前記ＲＴＰ層のＲＴＰパケットのヘッダーに含まれている情報によって、マルチメディアデータのＱｏＳをモニタリングするＱｏＳモニタリング部と、前記モニタリングされたＱｏＳに基づいたチャネル情報を前記送信部に報告するためのチャネル報告部とを含む。前記チャネル報告部は、前記チャネル情報をＲＴＣＰ ＲＲパケットにより前記送信部に送信する。

前記ＲＴＣＰ ＲＲパケットは、前記送信部から受信されたＲＴＰパケットの統計情報を前記送信部にフィードバックするための受信報告ブロックを含む。前記受信報告ブロックは、パケット損失率、ＬＳＲ（Ｌａｓｔ Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ ｔｉｍｅｓｔａｍｐ）を含む。前記ＬＳＲは、最後のＲＴＣＰ ＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）パケットの送信時間を示す。

前記受信部の圧縮ドメインは、前記ＲＴＰ層から受信されたマルチメディアデータを復号化するビデオデコーダを含む。

このように構成された一般的なマルチメディアデータ転送システムの送信部により送信されるマルチメディアデータパケットは、インターネットにおいて損失するか、又は時間遅延の超過が原因で受信部により廃棄することができ、その他、時間内に受信部に受信されたパケットは、受信部のＩＰ／ＵＤＰ／ＲＴＰ層を経てビデオデコーダに転送された後に復号化される。

前記受信部は、前記マルチメディアデータパケットを受信した後、前記マルチメディアデータパケットのＲＴＰヘッダーに含まれている各種情報によって、パケット損失率と遅延などネットワークの状態に関する情報を計算して、ＱｏＳをモニタリングする。前記モニタリングされた情報は、チャネル報告部のＲＴＣＰにより送信部にフィードバックされる。前記送信部は、前記フィードバックされた情報を用いて現在のチャネルの可用帯域幅を予測し、前記予測された可用帯域幅、即ち、有効転送率は、ビデオエンコーダに転送される。前記予測された有効転送率を受信したビデオエンコーダは、前記予測された転送率に合わせて、マルチメディアデータビットストリームの出力符号化率を調節する。

本発明は、マルチメディアデータ転送システムにおいて、送信部が受信部からＲＴＣＰ ＲＲパケットを受信したとき、ＲＲパケットに含まれている情報から転送率を推定し、ＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）の親和的な転送率の推定に関する基本理念に反しない新しい転送率の推定方法を提案する。

本発明が適用されるマルチメディアデータ転送システムは、ＲＴＰパケット形態のマルチメディアデータパケットを所定の個数転送するごとに、ＲＴＣＰパケットを１個送信する。前記所定の個数とは、例えば２０個であり得る。

図２は、本発明によるマルチメディアデータ転送率の適応的推定方法を示すフローチャートである。

図２に示すように、マルチメディアデータ転送システムにおいて、送信部がＲＴＰパケット形態のマルチメディアデータを受信部に送信する（Ｓ１１）。このとき、ＲＴＰパケットが所定の個数、例えば、２０個送信されるごとにＲＴＣＰパケットが１個送信される。従って、送信部は、ＲＴＰパケットを２０個送信するごとに、ＲＴＣＰ ＳＲパケットを１個受信部に送信する。前記ＲＴＣＰ ＳＲパケットは、ＳＲパケットの送信時間に関連した情報、即ち、ＳＲパケットが送信される際のＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）タイムスタンプの値を含む。

受信部は、ＲＴＣＰ ＳＲパケットが受信されると、ＲＴＣＰ ＳＲパケットのＮＴＰタイムスタンプの値に基づいて、前記ＳＲパケットの送信時間を得て、前記得られたＳＲパケットの送信時間をＲＴＣＰ ＲＲパケットのＬＳＲフィールドに記録してＲＴＣＰ ＲＲパケットを生成した後、前記生成されたＲＴＣＰ ＲＲパケットを送信部に送信する（Ｓ１３）。前記ＲＴＣＰ ＲＲパケットは、パケット損失率を含む。

前記ＲＴＣＰ ＲＲパケットを受信した送信部は、前記ＲＴＣＰ ＲＲパケットからパケット損失率を検出し（Ｓ１５）、数式２に示すように、前記検出されたパケット損失率によってそれぞれ異なる演算方法で有効転送率（Ｒ（ｔ_ｎ））を推定する（Ｓ１７）。

即ち、送信部は、前記検出されたパケット損失率が５％以下（ｐ（ｔ_ｎ）≦０．０５）である場合、有効転送率（Ｒ_１（ｐ（ｔ_ｎ）））を推定し、前記パケット損失率が５％超過１０％未満（０．０５＜ｐ（ｔ_ｎ）＜０．１）である場合、有効転送率（Ｒ_２（ｐ（ｔ_ｎ）））を推定し、前記パケット損失率が１０％以上（ｐ（ｔ_ｎ）≧０．１）である場合、有効転送率（Ｒ_３（ｐ（ｔ_ｎ）））を推定する。

より詳しくは、前記検出されたパケット損失率が５％以下（ｐ（ｔ_ｎ）≦０．０５）であると、送信部は、数式１による一般的な推定方法により有効転送率（Ｒ_１（ｐ（ｔ_ｎ）））を推定する。

また、前記検出されたパケット損失率が５％超過１０％未満（０．０５＜ｐ（ｔ_ｎ）＜０．１）である場合、送信部は、２０個のＲＴＰパケットのうち正常に受信部に受信された総データサイズを、２０個のＲＴＰパケットの転送に要する時間で除算して、有効転送率（Ｒ_２（ｐ（ｔ_ｎ）））を推定する。

前記の転送に要する時間は、ＲＴＣＰ ＲＲパケットに含まれているＬＳＲ値を用いて計算される。即ち、送信部は、現在受信されたＲＴＣＰ ＲＲパケットのＬＳＲ値（ＬＳＲ（ｔ_ｎ））から、以前に受信されたＲＴＣＰ ＲＲパケットのＬＳＲ値（ＬＳＲ（ｔ_ｎ−１））を減算して、２０個のＲＴＰパケットの転送に要する時間を得る。言い換えれば、送信部は、ｎ番目にフィードバックされたＲＲパケット（ＲＲ（ｔ_ｎ））のＬＳＲ値（ＬＳＲ（ｔ_ｎ））をもってｎ番目に送信されたＳＲパケット（ＳＲ（ｔ_ｎ））の送信時間を得、ｎ番目のＳＲパケット（ＳＲ（ｔ_ｎ））の送信時間からｎ−１番目のＳＲパケット（ＳＲ（ｔ_ｎ−１））の送信時間を減算して、２０個のＲＴＰパケットの転送に要する時間（ＬＳＲ（ｔ_ｎ）−ＬＳＲ（ｔ_ｎ−１））を得る。

また、前記受信部に正常に受信された総データサイズは次のように計算される。即ち、送信部は、ｎ−１番目のＳＲパケット（ＳＲ（ｔ_ｎ−１））の送信時間とｎ番目のＳＲパケット（ＳＲ（ｔ_ｎ））の送信時間の間に正常に転送されたＲＴＰパケットの個数をチェックし、前記チェックされた正常に転送されたＲＴＰパケットの個数を用いて正常に受信されたデータサイズを計算する。前記ｎ−１番目のＳＲパケット（ＳＲ（ｔ_ｎ−１））とｎ番目のＳＲパケット（ＳＲ（ｔ_ｎ））の間に正常に転送されたＲＴＰパケットの個数は、ｓ・２０・（１−ｐ（ｔ_ｎ））となる。前記ｐ（ｔ_ｎ）は、ｎ番目のＲＴＣＰ ＲＲパケットから検出されたパケット損失率を示し、前記ｓはパケットサイズを示す。

前記αとβは、パケット損失率が５％と１０％の場合、異なる数式により推定された各転送率が急激な差異なく連続した値を有するように与えられた加重値（ｗｅｉｇｈｔｉｎｇ ｆａｃｔｏｒ）である。受信部から受信されたＲＴＣＰ ＲＲパケットのパケット損失率が５％の場合と、ＲＴＣＰ ＲＲパケットのパケット損失率が１０％の場合、数式２に示す３つの式によりαとβの値を計算することができる。

ここで、前記データの転送に要する時間を一定の値とすると、結局、有効転送率（Ｒ_２（ｐ（ｔ_ｎ）））を推定する数式はパケット損失率ｐについての一次式で定義される。

一方、前記段階Ｓ１５で検出されたパケット損失率が１０％以上（ｐ（ｔ_ｎ）≧０．１）であると、送信部は、使用者により設定された最小転送率の値で有効転送率（Ｒ_３（ｐ（ｔ_ｎ）））を推定する。

図３は、本発明によりパケット損失率によって異なる演算方法で推定された転送率値を示すグラフである。

特に、図３は、パケットサイズ（ｓ）≡６２５、往復遅延時間（ＲＴＴ）≡１００ｍｓ、ＬＳＲ（ｔ_ｎ）−ＬＳＲ（ｔ_ｎ−１）≡ＲＴＴ／２＊２０の場合、パケット損失率ｐの増加によって推定された有効転送率の値を示す。ここで、α＝４４、β＝３９５６００となる。

図３に示すように、数式２により推定された有効転送率は、パケット損失率が５％以下では数式１の結果値（一般的な転送率の推定方法による結果値）と同一であり、パケット損失率が５％超過１０％未満では数式１による結果値より低く、パケット損失率が１０％以上では使用者により入力される最小転送率値となる。

従って、本発明による転送率の推定方法においては、パケット損失率が高い場合、有効転送率を一般的な転送率の推定方法による推定値より低く推定する。

以上のように、本発明の好ましい実施形態を用いて本発明を例示してきたが、本発明は、この実施形態に限定して解釈されるべきものではない。本発明は、特許請求の範囲によってのみその範囲が解釈されるべきであることが理解される。当業者は、本発明の具体的な好ましい実施形態の記載から、本発明の記載および技術常識に基づいて等価な範囲を実施することができることが理解される。本明細書において引用した特許、特許出願および文献は、その内容自体が具体的に本明細書に記載されているのと同様にその内容が本明細書に対する参考として援用されるべきであることが理解される。

受信側から受信されたＲＴＣＰ ＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケットからパケット損失率を検出し、検出されたパケット損失率が属する範囲によって異なる演算方法で有効転送率を推定することにより、パケット損失率が高い場合、ネットワークの渋滞を速やかに解消することができるマルチメディアデータ転送率の適応的推定方法を提供する。

マルチメディアデータ転送率の適応的推定方法は、マルチメディアデータ受信部からＲＴＣＰ ＲＲパケットを受信する過程と、前記ＲＴＣＰ ＲＲパケットからパケット損失率を検出する過程と、前記パケット損失率が属する範囲によって有効転送率を適応的に推定する過程とを含む。

ＲＴＰとＲＴＣＰが適用された、一般的なリアルタイムマルチメディアデータ転送システムの構成を示すブロック図である。 本発明によるマルチメディアデータ転送率の適応的推定方法を示すフローチャートである。 本発明によりパケット損失率によって異なる演算方法で推定された転送率値を示すグラフである。 パケット損失率を固定し、往復遅延時間を線形的に変化させた場合、一般的な推定方法により推定された有効転送率の変化を示すグラフである。 往復遅延時間を固定し、パケット損失率を線形的に変化させた場合、一般的な推定方法により推定された有効転送率の変化を示す図である。

Claims (6)

1. マルチメディアデータ受信部からＲＴＣＰ ＲＲパケットを受信することと、
   前記ＲＴＣＰ ＲＲパケットからパケット損失率を検出することと、
   前記パケット損失率が属する範囲によって有効転送率を適応的に推定することであって、
   前記パケット損失率が、第１の所定値以下の第１の範囲に属する場合には、第１の数式により前記有効転送率を推定することと、
   前記パケット損失率が、前記第１の所定値超過第２の所定値未満の第２の範囲であって、前記第２の所定値は前記第１の所定値よりも大きい、第２の範囲に属する場合には、第２の数式により前記有効転送率を推定することと、
   前記パケット損失率が、前記第２の所定値以上の第３の範囲に属する場合には、第３の数式により前記有効転送率を推定することと
   を包含する、ことと
   を含む、マルチメディアデータ転送率の適応的推定方法であって、
   前記第１の数式は、
   

   

   を含み、
   前記第２の数式は、
   Ｒ _２ （ｐ（ｔ _ｎ ））＝
   

   

   を含み、
   ｓ：パケットサイズ
   ＲＴＴ（ｔ _ｎ ）：往復遅延時間
   ｐ（ｔ _ｎ ）：ｎ番目のＲＴＣＰ ＲＲパケットから検出されたパケット損失率
   ＬＳＲ（ｔ _ｎ ）：ｎ番目のＲＴＣＰ ＳＲパケットの送信時間
   α、β：加重値
   である、方法。
2. 前記第３の数式は、
   使用者により設定された最小転送率を含む、請求項１に記載の方法。
3. 前記第１の所定値は５％であり、前記第２の所定値は１０％である、請求項１に記載の方法。
4. ＲＴＰパケットが所定の個数送信されるごとに、ＲＴＣＰ ＳＲパケットが１つ送信され、前記ＲＴＣＰ ＲＲパケットが１つ受信される、請求項１に記載の方法。
5. 前記所定の個数が２０である、請求項４に記載の方法。
6. 前記ＲＴＣＰ ＲＲパケットは、マルチメディアデータ送信部から受信されたＲＴＰパケットの統計情報を前記マルチメディアデータ送信部にフィードバックするための受信報告ブロックを含み、
   前記受信報告ブロックは、パケット損失率と、最後のＲＴＣＰ ＳＲパケットの送信時間（ＬＳＲ）とを含む、請求項４に記載の方法。

Images