(57)【要約】  マルチキャストネットワークにおいてチャネル状態をフィードバックする方法及び装置が説明される。該方法等は、チャネル状態の指標を推定すること、チャネル状態の推定された指標に基づいて受信機クラスを決定すること、遅延を計算すること、チャネル状態の推定された指標の送信を、計算された遅延の分だけ遅らせる決定を行うこと、決定された受信機クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信すること、そして、受信したチャネル状態の指標が、推定されたチャネル状態の指標以上であった場合、上記の遅らせる決定をキャンセルすることを含む。本方法及び装置は、算出された受信クラスに関する１つのレポートをサーバに送信することをさらに含み、そのレポートは、決定された受信機クラスに関し、チャネル状態の最悪の指標を含む。
2010521099.tif 000002
【特許請求の範囲】
【請求項１】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う方法であって、
チャネル状態の指標を推定するステップと、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定するステップと、
遅延量を計算するステップと、
チャネル状態について推定された前記指標の送信を、計算された遅延量の間遅らせることを決定するステップと、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信するステップと、
チャネル状態について受信した指標が、チャネル状態について推定された前記指標より大きかった場合又は等しかった場合、前記遅らせる決定を取り消すステップと
を有する方法。
【請求項２】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項３】
チャネル状態について受信した前記指標が、チャネル状態について推定された前記指標より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項４】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項５】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項６】
サーバから周期的にレポートが受信される、請求項1記載の方法。
【請求項７】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項1記載の方法。
【請求項８】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項1記載の方法。
【請求項９】
チャネル状態について推定される指標は、周期的に推定される、請求項1記載の方法。
【請求項１０】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う装置であって、
チャネル状態の指標を推定する手段と、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定する手段と、
遅延量を計算する手段と、
チャネル状態について推定された前記指標の送信を、計算された遅延量の間遅らせることを決定する手段と、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信する手段と、
チャネル状態について受信した指標が、チャネル状態について推定された前記指標より大きかった場合又は等しかった場合、前記遅らせる決定を取り消す手段と
を有する装置。
【請求項１１】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１２】
チャネル状態について受信した前記指標が、推定されたパケット損失率より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１３】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１４】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１５】
サーバから周期的にレポートを受信する手段をさらに有する、請求項10記載の装置。
【請求項１６】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項10記載の装置。
【請求項１７】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項10記載の装置。
【請求項１８】
チャネル状態について推定される指標は、周期的に推定される、請求項10記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般にビデオマルチキャストブロードキャストシステムに関連し、特に、適応ビデオマルチキャストブロードキャストシステムのサーバに受信チャネル状態を効率的にフィードバックすることに関連する。
【背景技術】
【０００２】
ビデオマルチキャスト/ブロードキャストのアプリケーションの場合、ビデオデータは、ビデオサーバから有線及び/又は無線ネットワークを介して複数の受信機へ送信される。ここで、「/」は、同一又は類似する要素の代替名を示すのに使用される。本願で使用されるマルチキャストシステムは、サーバが同じデータを複数の受信機に同時に送信するシステムであり、複数の受信機は、受信機全体の部分集合を形成し、部分集合は最大の場合すべての受信機を含む。ブロードキャストシステムは、サーバが同じデータを総ての受信機に同時に送信するシステムである。すなわち、マルチキャストの定義はブロードキャストシステムを含み得る。
【０００３】
メディアサーバは様々な要素を含み、特に、ビデオパケットのストリームを生成するビデオエンコーダ/パケット化装置と、アプリケーションレイヤ順方向誤り訂正(FEC)エンコーダとを含み、FECエンコーダは、クロスパケットFEC符号化をビデオパケットに適用し、伝送の信頼性向上を図る。マルチキャスト又はブロードキャストされるビデオの受信機は、有線又は無線の様々なアクセスリンクを介してサーバに接続される。異なる受信機が同時に同じビデオ信号を受信したとしても、異なるチャネル状態に起因して異なるパケット損失率を経験し、所与の受信機のパケット損失率は時間と共に変化する。様々な受信機又は同じ受信機における受信品質は、時間とともに変化する。さらに、受信機はマルチキャストグループに対して脱退又は加入を行うので、ネットワークトポロジは変化する。信頼できる有効なブロードキャスト及びマルチキャスト処理を行うため、及び複数のビデオ受信機のサービス品質(QoS)条件を満足するため、ビデオサーバは、ビデオ符号化パラメータ(例えば、ビットレート、イントラフレームレート、イントラブロックレート、パケットサイズ等)やアプリケーションレイヤFECオーバーヘッドを、変化する受信機トポロジに適合させ且つ多数の受信機の受信チャネル状態に適合させる必要がある。これは、受信機が自身のチャネル状態を頻繁にビデオサーバに返すことを意味する。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明が解決しようとする課題は、複数の受信機からビデオサーバへチャネル状態のフィードバックを効率的に行う仕方を提供することである。効率的なチャネルフィードバック法は、適応ビデオマルチキャスト/ブロードキャストシステムの設計及び動作を最適化する際重要になり、そのシステムでは、ビデオパケットストリームを保護するために付加されるFECオーバーヘッド及びビデオ符号化パラメータを、複数のビデオ受信機の受信チャネル状態に応じてビデオサーバが動的に調整する。
【０００５】
報告されているあるシステムの場合、複数の受信機が自身の受信チャネル状態をビデオサーバに返すために、標準的なリアルタイムトランスポート制御プロトコル(RTCP)が使用される。しかしながら、標準的なRTCPプロトコルの場合、参加者(送信者又は受信者)は、RTCP送信者レポート又は受信者レポート(受信チャネル状態を含む)を、セッションの中で全参加者に周期的に独自に送信する。したがってこの方法にはいくつかの問題がある。第1に、この方法は多くのオーバーヘッドを導入するので、受信機数が増える場合、スケーラビリティの問題(拡張性に乏しい問題)を招く。第2に、RTCP報告の間隔は小さいので、速やかなチャネルフィードバックを要する。この方法は、サーバがフィードバックによる内部崩壊の被害を受けるおそれ(処理が追従できないおそれ)があるので、ビデオマルチキャスト/ブロードキャストのような１対多通信には有効ではない。ビデオ符号化パラメータ及びFECオーバーヘッドを効率的に適合させるのに必要な情報を、送信者/送信機/サーバがするように、RTCP制御帯域幅を確保することは重要であり、無線ネットワークの場合特に重要である。
【０００６】
本発明は、適応ビデオマルチキャスト/ブロードキャストシステムにおける複数の受信機の受信チャネル状態を効率的にフィードバックする方法をもたらすことで、上記の問題を解決する。
【課題を解決するための手段】
【０００７】
ビデオマルチキャスト/ブロードキャストのアプリケーションの場合、ビデオデータは、ビデオサーバから有線及び/又は無線ネットワークを介して複数の受信機へ送信される。メディアサーバは様々な要素を含み、特に、ビデオパケットのストリームを生成するビデオエンコーダ/パケット化装置と、アプリケーションレイヤ順方向誤り訂正(FEC)エンコーダとを含み、FECエンコーダは、クロスパケットFEC符号化をビデオパケットに適用し、伝送の信頼性向上を図る。マルチキャスト又はブロードキャストされるビデオの受信機は、有線又は無線の様々なアクセスリンクを介してサーバに接続される。異なる受信機が同時に同じビデオ信号を受信したとしても、異なるチャネル状態に起因して異なるパケット損失率を経験し、所与の受信機のパケット損失率は時間と共に変化する。様々な受信機又は同じ受信機における受信品質は、時間とともに変化する。さらに、受信機はマルチキャストグループに対して脱退又は加入を行うので、ネットワークトポロジは変化する。信頼できる有効なブロードキャスト及びマルチキャスト処理を行うため、及び多数のビデオ受信機のサービス品質(QoS)条件を満足するため、ビデオサーバは、ビデオ符号化パラメータ(例えば、ビットレート、イントラフレームレート、イントラブロックレート、パケットサイズ等)やアプリケーションレイヤFECオーバーヘッドを、変化する受信機トポロジに適合させ且つ多数の受信機の受信チャネル状態に適合させる必要がある。これは、受信機がチャネル状態を頻繁にビデオサーバにフィードバックしなければならないことを意味する。
【０００８】
本発明の一実施例によれば、マルチキャストネットワークにおいてチャネル状態をフィードバックする方法及び装置が使用され、該方法等は、チャネル状態の指標(indication)を推定すること、チャネル状態の推定された指標に基づいて受信機クラスを決定すること、遅延を計算すること、チャネル状態の推定された指標の送信を、計算された遅延の分だけ遅らせる決定を行うこと、判別された受信機クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信すること、そして、受信したチャネル状態の指標が、推定されたチャネル状態の指標以上であった場合、上記の遅らせる決定をキャンセルすることを含む。本方法及び装置は、算出された受信クラスに関する１つのレポートをサーバに送信することをさらに含み、そのレポートは、決定された受信機クラスに関し、チャネル状態の最悪の指標を含む。
【図面の簡単な説明】
【０００９】
【図１】本発明の原理を使用するネットワークの概略図。
【図２】適応順方向誤り訂正を行うサーバを示すブロック図。
【図３】受信機の構成を示すブロック図。
【図４Ａ】本発明によるフィードバック方法例を受信機の観点から表したフローチャート(その1)。
【図４Ｂ】本発明によるフィードバック方法例を受信機の観点から表したフローチャート(その2)。
【図５】本発明によるフィードバック方法例を(ビデオ)サーバの観点から表したフローチャート。
【発明を実施するための形態】
【００１０】
添付図面を参照しながら以下の詳細な説明を読むことで、本発明は最良に理解されるであろう。図面は、上記のように簡単に言及されている図を含む。
【実施例１】
【００１１】
図1を参照するに、本発明の原理を使用するマルチキャスト/ブロードキャストビデオシステム例が示されている。図1は、無線装置しか示していないが、本発明は、有線回線又は無線のコンフィギュレーションで使用されてもよいし、或いは有線回線及び無線装置双方を含むコンフィギュレーションで使用されてもよい。無線環境におけるRTCP制御帯域幅は、より重要(貴重)なものであることに留意を要する。無線装置105a、105b、105c、105d、105e及び105fは、無線アクセスポイント/基地局120a、120b、120c及び高速有線アクセスネットワーク(例えば、イーサーネット)125を介して、ビデオマルチキャストサーバ110及びインターネット115に接続されている。ビデオサーバ110は、高速有線ネットワーク125を介して無線アクセスポイント/基地局120a、120b及び120cへ、1つ以上のビデオ番組をマルチキャストする。アクセスポイント/基地局120a、120b及び120cは、無線アクセスポイント/基地局120a-120c及び無線装置105a-105fの間の無線リンクを介して、無線装置105a-105fへマルチキャスト/ブロードキャスト方式でビデオを配布する。無線装置105a-105fのユーザは、1つ以上のビデオ番組を鑑賞することができ、同時にインターネット115にアクセスすることもできる。ビデオサーバ110は、ビデオパケットのストリームを保護するために付加されたFECオーバーヘッド及びビデオ符号化パラメータを、複数のビデオ受信機の受信チャネル状態に応じて動的に調整し、信頼できる効率的なブロードキャスト及びマルチキャスト処理を行えるようにし、かつ多数のビデオ受信機のサービス品質(QoS)要求を満たすようにする。本発明は、多数のビデオ受信機の受信チャネル状態/パケット損失率に関するフィードバックを効率的に行う方法をもたらし、サーバが、ビデオ符号化パラメータ及びFECオーバーヘッドを最適化できるようにする。効率的なチャネルフィードバック法は、適応ビデオマルチキャスト/ブロードキャストシステムの設計及び処理の最適化にとって重要である。本実施例はビデオパケットストリームの観点から説明されているが、オーディオストリームを含む如何なるディジタルストリームについて本発明の方法が使用されてもよい。
【００１２】
本発明を説明する一例として無線ネットワークが使用されているが、本発明は、無線ネットワーク(3G又は無線ローカルエリアネットワーク等)、有線ネットワーク又はハイブリッド無線/有線ネットワークを介する適応ビデオマルチキャスト/ブロードキャストアプリケーションで使用可能である。
【００１３】
本発明は、RTCPメッセージが送信される際の規則を提供することに留意を要する。RTCP制御メッセージフォーマット(すなわち、送信者レポート(センダーレポート)及び受信者レポート(レシーバレポート))は、改められる必要はない。
【００１４】
本発明の場合、ビデオパケットストリームの受信機は、各自のパケット損失率に基づいて様々なクラスに分類される。ここで、
0≦P1≦P2≦．．．≦Pn-1≦Pn≦．．．≦PN≦1
は、様々な受信機クラスのパケット損失率の閾値であるとする。タイムインターバルtにおける受信機iのパケット損失率が、Pn-1＜Pi(t)≦Pn  の範囲内にあった場合、その受信機はクラスnに属する。受信機がビデオセッションに加入する際、例えばセッション記述ファイルをダウンロードすることで、或いは他の利用可能な手段を利用することで、受信機は、各クラスのパケット損失率閾値の情報を取得することができる。パケット損失率に基づいて、受信機は、自分が属するクラスを知ることができる。
【００１５】
本発明によるフィードバックアルゴリズムは次のとおりである：
・ビデオサーバが、タイムインターバルtにより周期的に、RTCPセンダーレポートを総ての受信機にマルチキャストする。
【００１６】
・各タイムインターバルtについて、アプリケーションレイヤの何らかのFFC復元が適用される前のパケット損失率を、各受信機が推定する。
【００１７】
−１−
受信機の処理前パケット損失率がP1未満であった場合、すなわちPi(t)＜P1であった場合、その受信者(受信機)は現在「クラス1のユーザ」である。受信機はこのタイムインターバルの間にレシーバレポートを送信しない。なぜなら、そのパケット損失率は、良好なQoSとして既に十分に低いからである。P1＝0は、特殊な場合であることに留意を要する。サーバは、したがって、クラス1の受信機に対して如何なる調整も施さない。
【００１８】
−２−
受信機の処理前パケット損失率がクラスnの閾値同士の間にあった場合、すなわちPn-1＜Pi(t)≦Pn  (N≧n＞1)であった場合、受信機は、そのタイムインターバルに対して現在「クラスnの受信機」である。クラスnの受信機は、ビデオ符号化パラメータ及びFECオーバーヘッドを合わせるため、レシーバレポートをビデオサーバに送信する。フィードバック制御トラフィックを減らすため、クラスnの受信機は、算出されたパケット損失率に依存して、短期間の間自身のレシーバレポートの送信を遅延させる。すなわち、パケット損失率が高いほど、遅延を短くする。具体的には、Pn-1＜Pi(t)≦Pn  の範囲内のパケット損失率を有する受信機は、自身のレシーバレポートの送信を、次式の遅延期間dだけ遅延させる。
【００１９】
【数１】
2010521099.tif 000003
ここで、D≦t  は、t/2のデフォルト値を有する一定の遅延量である。この遅延は、大きなパケット損失率を伴う受信機が先にレポートを送信するように、時間遅延を効率的にランダム化(分散)する。レシーバレポートは、そのセッションの中で、受信機から総ての参加者(ビデオサーバ及び他の受信機)へマルチキャスト形式で送信される。遅延期間の間に、クラスnの受信機は、クラスnに属する他の受信機からレポートを受信する。遅延期間の間に受信したそのようなレシーバレポートが、自身の報告するパケット損失率よりも大きいパケット損失率を伝送していた場合、その受信機は遅延タイマを解除し、その報告タイムインターバルtに関してレシーバレポートを送信しないようにする。
【００２０】
−３−
受信機の処理前パケット損失率が、クラスNの閾値より大きかった場合、すなわちPi(t)＞PNであった場合、その受信機は現在「クラスN+1の受信機」である。クラスN+1の受信機は、RTCPレシーバレポートを送信しない。なぜなら、そのパケット損失率は高すぎるので、そのタイムインターバルの中でビデオサーバは各自のQoS条件に合わせることができないからである。このことは、受信機がレシーバレポートを決して送信しないことを意味するわけではない。意味することは、クラスN+1受信機である限り、QoS条件に適合できないので、レシーバレポートを送信しないということだけである。したがって、サーバは、クラスN+1の受信機に対して如何なる調整も施さない。特殊な状態はPN=1であることに留意を要する。
【００２１】
上記のステップ2における遅延は、他の形式で表現されてもよい。一例として、代替例では、遅延は次式で表現されてもよい：
【００２２】
【数２】
2010521099.tif 000004
ここで、T0は定数であり、T1は0及びT0の間の乱数である。
【００２３】
報告インターバルtは、受信機が受信チャネル状態を更新し、サーバがビデオ符号化パラメータ及びFECオーバーヘッドを合わせるために使用されるが、アルゴリズム自体は、サーバ及び複数の受信機の間で厳密に同期していることは必須でない。受信機がセンダーレポートを適切に受信しなかった場合、受信機は、以前に受信したセンダーレポートを使用して報告タイムインターバルtを算出することができる。
【００２４】
特殊な場合、唯1つのクラスしか存在しない。すなわち、0≦P(t)≦1  である。総ての受信機がこの1つのクラスに属する。そして、上記のステップ2が総ての受信機によって使用される。すなわち、総ての受信機が自身のチャネル状態フィードバック信号を上記のステップ2に従って送信する。
【００２５】
図2を参照するに、本発明による適応FECを行うサーバを示すブロック図が示されている。ビデオサーバは、ビデオ/ソースエンコーダ205、パケット化装置210、FEC処理/符号化装置215、適応FEC制御装置220、UDP/IPプロトコルスタック通信装置及びインターフェース(例えば、無線)225を含む。適応FEC制御装置220は、センダーレポートを生成し、かつ複数の受信機から受信チャネル状態フィードバック信号を受信及び処理する。これは、ビデオ符号化パラメータ及びFEC符号オーバーヘッドを決定する。適応FEC制御装置220は、ビデオ/ソースエンコーダ205、パケット化装置210及びFEC処理/符号化装置215に対して、ビデオ符号化、パケット化及びFEC符号化を行うことを指示する。適応FEC制御装置は、UDP/IP通信装置225と通信して制御し、ビデオソースパケット及びパリティパケットを送信する。
【００２６】
図3を参照するに、本発明による受信機の構成を示すブロック図が示されている。受信機は、ビデオ/ソースデコーダ305、パケット化解除(デパケット化)装置310、FEC処理/デコード装置315、チャネル推定及びフィードバック装置320、UDP/IPプロトコルスタック通信装置及びインターフェース(例えば、無線)325を含む。チャネル推定及びフィードバック装置320は、(誤り訂正)処理前のパケット損失率を推定し、上記の方法を使用してレシーバレポートをビデオサーバへ送信する。
【００２７】
ビデオサーバの構成要素は、1つの物理装置上で実現されてもよいし、或いはネットワークにより接続された複数の装置上で実現されてもよい。受信機の構成要素は、1つの物理装置上で実現されてもよいし、或いはネットワークにより接続された複数の装置上で実現されてもよい。
【００２８】
図4は、本発明によるフィードバック方法を受信機の観点から表したフローチャートである。ステップ405において、受信機は、(ビデオ)サーバからセンダーレポートを受信する。ステップ410において、受信機は、タイムインターバルtについてパケット損失率を推定する。すなわち、受信機はパケット損失率を周期的に推定している。ステップ415において、推定されたパケット損失率が閾値P1未満であるか否かの検査が実行され、P1未満であった場合、受信機はクラス1である。推定されたパケット損失率が閾値P1未満であった場合、その推定されたパケット損失率は報告されない。なぜなら、そのパケット損失率は、総てのQoS条件に合致しており且つ(ビデオ)サーバによる如何なる調整も不要な程度に既に充分に低いからである。調整は、ビデオ符号化パラメータ、アプリケーションレイヤFEC符号化及びオーバーヘッドの最適化を含む。受信機がクラス1に該当する場合、受信機は、ステップ405において次のセンダーレポートの受信を待機する。受信機がパケット損失率を推定するためにセンダーレポートを待機することは必須でなく、都合のよいときにいつでも実行してよい。受信機がクラス1に該当しなかった場合、ステップ420において、受信機の推定したパケット損失率が、受信機をクラスN+1にする閾値PNより大きいか否かの判定が実行される。閾値PNより大きい推定パケット誤り率を有する受信機は、その推定パケット損失率を報告しない。なぜなら、その損失率は高すぎるので、(ビデオ)サーバが行い得る如何なる調整も各自のQoS条件を満たすようにできないからである。閾値PNを超える推定パケット損失率のクラスに受信機が属する場合、受信機はステップ405に戻り、次のセンダーレポートを待機する。
【００２９】
閾値PN未満であって閾値P1以上の推定パケット損失率によるクラスに受信機が該当していた場合、その受信機は、ステップ425において、自身のクラスを特定し、レシーバレポートを送信する際の遅延を算出し、その遅延時間を設定する。ステップ430において、遅延タイマがデクリメントされる(開始される)。ステップ435において、受信機が自分のクラスに属する他の受信機から何らかのレポートを受信したか否かの確認が行われる。受信機が、そのクラス内の他の受信機からレポートを受信していた場合、ステップ440において、他の受信機から受信したレポートが、自身の推定パケット損失率より高い推定パケット損失率を報告しているか否かの確認が行われる。他の受信機から受信したレポートが、自身の受信機の推定パケット損失率以上の推定パケット損失率を報告していた場合、ステップ445において、その受信機に対する遅延タイマが解除(キャンセル)され、受信機は、次のセンダーレポートを待機するステップ405に戻る。その理由は、対象の受信機クラスに関し、最大の推定パケットパケット損失を伴う受信機のみが、推定パケット損失率を報告する義務があるからである(他の報告は任意である)。最大の推定パケット損失率を有する受信機は、その推定パケット損失率を(ビデオ)サーバに送信する。サーバは、そのクラスに関し、サーバに報告された最悪の推定パケット損失率にしたがって調整を行い、その結果、そのクラス内の総ての受信機は各自のQoS条件を満たすようになる。これは、重要なことに、(ビデオ)サーバが受信及び処理する必要のあるレシーバレポート数を減らし、したがって、レシーバレポートを伝送するための帯域幅条件も緩和する。他の受信機から受信したレポートが、自身の受信機の推定パケット損失率より低い推定パケット損失率を報告していた場合、ステップ450において、遅延タイマが満了しているか否かの確認が行われる。遅延タイマが満了していなかった場合、受信機はステップ430に進み、遅延タイマをデクリメントする。遅延タイマが満了していた場合(かつ推定パケット損失率以上の他のレポートが一切受信されていなかった場合)、ステップ455において、その受信機は、レシーバレポートの推定パケット損失率を(ビデオ)サーバへ送信し、そして受信機はステップ405に進み、次のセンダーレポートを待機する。
【００３０】
図5は、本発明によるフィードバック方法を(ビデオ)サーバの観点から表したフローチャートである。ステップ505において、(ビデオ)サーバは、(ビデオ)データの送信を受ける総ての受信機にセンダーレポートを送信する。ステップ510において、(ビデオ)サーバは、クラス1及びクラスN+1を除く受信機のクラス各々から、1つのレシーバレポートを受信する。
【００３１】
本発明は、ハードウエア、ソフトウエア、ファームウエア、特殊用途プロセッサ又はそれらの組み合わせのような様々な形態で実現されてよい。好ましくは、本発明は、ハードウエア及びソフトウエアの組み合わせとして実現される。さらに、ソフトウエアは、プログラム格納装置に識別可能に組み込まれたアプリケーションプログラムとして実現されることが好ましい。アプリケーションプログラムは、アップロードされ、何らかの適切なアーキテクチャを有するマシン(又はコンピュータ)により実行されてもよい。好ましくは、そのマシンは、あるハードウエアを有するコンピュータプラットフォーム上で実現され、そのハードウエアは、1つ以上の中央処理装置(CPU)、ランダムアクセスメモリ(RAM)及び入力/出力(I/O)インターフェース等である。コンピュータプラットフォームは、オペレーティングシステム及びマイクロ命令コードを含む。本願で説明された様々なプロセス及び機能は、マイクロ命令コードの一部分でもよいし、アプリケーションプログラムの一部分でもよく、オペレーティングシステムを介して実行される。さらに、追加的なデータストレージ装置や印刷装置のように、様々な他の周辺装置がコンピュータプラットフォームに接続されてもよい。
【００３２】
添付図面に示されている一部のシステム構成要素及び方法ステップは、ソフトウエアで実現されることが好ましいので、システム構成要素間(又は、プロセスステップ間)の実際の接続は、本発明がプログラムされる方法に依存して異なるかもしれない。本願により教示された事項により、当業者は本発明に関するこれら及び類似の実現例やコンフィギュレーションを想定することができるであろう。
【図１】
2010521099.tif 000005
【図２】
2010521099.tif 000006
【図３】
2010521099.tif 000007
【図４Ａ】
2010521099.tif 000008
【図４Ｂ】
2010521099.tif 000009
【図５】
2010521099.tif 000010
【手続補正書】
【提出日】平成21年9月10日(2009.9.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う方法であって、
チャネル状態の指標を推定するステップと、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定するステップと、
遅延量を計算するステップと、
チャネル状態について推定された前記指標の送信を、計算された遅延量の間遅らせることを決定するステップと、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信するステップと、
チャネル状態について受信した指標及び推定されたチャネル状態の比較に基づいて、前記遅延量の間遅らせる決定を取り消すステップと
を有する方法。
【請求項２】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項３】
チャネル状態について受信した前記指標が、チャネル状態について推定された前記指標より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項４】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項５】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項６】
サーバから周期的にレポートが受信される、請求項1記載の方法。
【請求項７】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項1記載の方法。
【請求項８】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項1記載の方法。
【請求項９】
チャネル状態について推定される指標は、周期的に推定される、請求項1記載の方法。
【請求項１０】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う装置であって、
チャネル状態の指標を推定する手段と、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定する手段と、
遅延量を計算する手段と、
チャネル状態について推定された前記指標の送信を、計算された遅延の間遅らせることを決定する手段と、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信する手段と、
チャネル状態について受信した指標及び推定されたチャネル状態の比較に基づいて、前記遅延量の間遅らせる決定を取り消す手段と
を有する装置。
【請求項１１】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１２】
チャネル状態について受信した前記指標が、推定されたパケット損失率より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１３】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１４】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１５】
サーバから周期的にレポートを受信する手段をさらに有する、請求項10記載の装置。
【請求項１６】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項10記載の装置。
【請求項１７】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項10記載の装置。
【請求項１８】
チャネル状態について推定される指標は、周期的に推定される、請求項10記載の装置。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
本発明の一実施例によれば、マルチキャストネットワークにおいてチャネル状態をフィードバックする方法及び装置が使用され、該方法等は、チャネル状態の指標(indication)を推定すること、チャネル状態の推定された指標に基づいて受信機クラスを決定すること、遅延を計算すること、チャネル状態の推定された指標の送信を、計算された遅延の分だけ遅らせる決定を行うこと、決定された受信機クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信すること、そして、チャネル状態について受信した指標及び推定されたチャネル状態の比較に基づいて、前記遅延量の間遅らせる決定をキャンセルすることを含む。本方法及び装置は、算出された受信クラスに関する１つのレポートをサーバに送信することをさらに含み、そのレポートは、決定された受信機クラスに関し、チャネル状態の最悪の指標を含む。
【手続補正書】
【提出日】平成22年3月8日(2010.3.8)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う方法であって、
チャネル状態の指標を推定するステップと、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定するステップと、
遅延量を計算するステップと、
チャネル状態について推定された前記指標の送信を、計算された遅延量の間遅らせることを決定するステップと、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信するステップと、
チャネル状態について受信した指標及び推定されたチャネル状態の比較に基づいて、送信を前記遅延量の間遅らせる決定を取り消すステップと
を有する方法。
【請求項２】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項３】
チャネル状態について受信した前記指標が、チャネル状態について推定された前記指標より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信するステップをさらに有する、請求項1記載の方法。
【請求項４】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項５】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定するステップと、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止めるステップと
をさらに有する請求項1記載の方法。
【請求項６】
サーバから周期的にレポートが受信される、請求項1記載の方法。
【請求項７】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項1記載の方法。
【請求項８】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項1記載の方法。
【請求項９】
チャネル状態について推定される指標は、周期的に推定される、請求項1記載の方法。
【請求項１０】
マルチキャストネットワークにおいてチャネル状態フィードバックを行う装置であって、
チャネル状態の指標を推定する手段と、
チャネル状態について推定された指標に基づいて、受信機のクラスを決定する手段と、
遅延量を計算する手段と、
チャネル状態について推定された前記指標の送信を、計算された遅延量の間遅らせることを決定する手段と、
決定された受信機の前記クラスに属する他の受信機から、チャネル状態の指標を含むレポートを受信する手段と、
チャネル状態について受信した指標及び推定されたチャネル状態の比較に基づいて、送信を前記遅延量の間遅らせる決定を取り消す手段と
を有する装置。
【請求項１１】
他の受信機からレポートが受信されなかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１２】
チャネル状態について受信した前記指標が、推定されたパケット損失率より小さかった場合、チャネル状態について推定された前記指標を含むレポートを送信する手段をさらに有する、請求項10記載の装置。
【請求項１３】
チャネル状態について推定された前記指標が、閾値未満であるか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値未満であった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１４】
チャネル状態について推定された前記指標が、閾値より大きいか否かを判定する手段と、
チャネル状態について推定された前記指標が、前記閾値より大きかった場合、チャネル状態について推定された前記指標を含むレポートの送信を止める手段と
をさらに有する請求項10記載の装置。
【請求項１５】
サーバから周期的にレポートを受信する手段をさらに有する、請求項10記載の装置。
【請求項１６】
チャネル状態について推定された前記指標が、推定されたパケット損失率である、請求項10記載の装置。
【請求項１７】
チャネル状態について受信した前記指標が、受信したパケット損失率である、請求項10記載の装置。
【請求項１８】
チャネル状態について推定される指標は、周期的に推定される、請求項10記載の装置。
【国際調査報告】
2010521099.tif 000011
2010521099.tif 000012
2010521099.tif 000013