特許 6685621 マルチキャストネットワークにおいてデータの再送を要求すること

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6685621

(24)【登録日】2020年4月3日

(45)【発行日】2020年4月22日

(54)【発明の名称】マルチキャストネットワークにおいてデータの再送を要求すること

(51)【国際特許分類】

   H04W 28/04 20090101AFI20200413BHJP

   H04W 4/06 20090101ALI20200413BHJP

   H04L 1/16 20060101ALI20200413BHJP

   H04L 29/08 20060101ALI20200413BHJP

【ＦＩ】

   H04W28/04 110

   H04W4/06 171

   H04L1/16

   H04L13/00 307Z

【請求項の数】15

【全頁数】27

(21)【出願番号】特願2018-539176(P2018-539176)

(86)(22)【出願日】2017年5月29日

(65)【公表番号】特表2019-505126(P2019-505126A)

(43)【公表日】2019年2月21日

(86)【国際出願番号】JP2017020733

(87)【国際公開番号】WO2017209308

(87)【国際公開日】20171207

【審査請求日】2018年7月26日

(31)【優先権主張番号】16305653.4

(32)【優先日】2016年6月3日

(33)【優先権主張国】EP

(73)【特許権者】

【識別番号】503163527

【氏名又は名称】ミツビシ・エレクトリック・アールアンドディー・センター・ヨーロッパ・ビーヴィ

【氏名又は名称原語表記】ＭＩＴＳＵＢＩＳＨＩ ＥＬＥＣＴＲＩＣ Ｒ＆Ｄ ＣＥＮＴＲＥ ＥＵＲＯＰＥ Ｂ．Ｖ．

(74)【代理人】

【識別番号】100110423

【弁理士】

【氏名又は名称】曾我 道治

(74)【代理人】

【識別番号】100111648

【弁理士】

【氏名又は名称】梶並 順

(74)【代理人】

【識別番号】100122437

【弁理士】

【氏名又は名称】大宅 一宏

(74)【代理人】

【識別番号】100147566

【弁理士】

【氏名又は名称】上田 俊一

(74)【代理人】

【識別番号】100161171

【弁理士】

【氏名又は名称】吉田 潤一郎

(72)【発明者】

【氏名】ロレ、ロマン

【審査官】 桑江 晃

(56)【参考文献】

【文献】 米国特許第０６３８１２１５（ＵＳ，Ｂ１）

【文献】 特表２０１０−５３６２８７（ＪＰ，Ａ）

【文献】 国際公開第２００５／１１９９６９（ＷＯ，Ａ１）

【文献】 特開２００１−１１９４３７（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｗ ４／００ − ９９／００

Ｈ０４Ｌ １／１６

Ｈ０４Ｌ ２９／０８

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−２

ＣＴ ＷＧ１

(57)【特許請求の範囲】

【請求項1】

ネットワーク内のマルチキャスト送信機によって最初に送信された損失データパケットの再送を要求する方法であって、該マルチキャスト送信機は該ネットワーク内でデータパケットをマルチキャストし、該方法は、第１のマルチキャスト受信機によって実行され、
前記マルチキャスト送信機と前記第１のマルチキャスト受信機との間のデータリンク上で少なくとも１つのデータパケットの損失を検出すると、タイマー値を設定し、タイマーを作動状態にするステップと、
前記タイマーが前記設定されたタイマー値に達したことを検出すると、アップリンク制御リンクを介して、前記マルチキャスト送信機に非確認応答メッセージを送信するステップであって、前記少なくとも１つの損失データパケットが前記マルチキャスト送信機によって先行して再送されずに、前記第１のマルチキャスト受信機でデータパケットが受信された場合には、該非確認応答メッセージは、少なくとも１つの損失データパケットの識別子を含むものと、
を含み、
前記第１のマルチキャスト受信機は、マルチキャストダウンリンク制御リンク上で前記マルチキャスト送信機から損失報告メッセージを更に受信し、該損失報告メッセージは、ユニキャストモード及びマルチキャストモードの中の送信モードに関連付けて前記マルチキャスト送信機によって再送されるべきデータパケットを識別し、
所与のデータパケットがマルチキャストモードにおいて再送されるべきと識別される場合に、かつ該所与のデータパケットが前記検出された少なくとも１つの損失データパケットに属する場合には、前記非確認応答メッセージは、前記所与のデータパケットの前記識別子を含まず、
所与のデータパケットがユニキャストモードにおいて再送されるべきと識別される場合に、かつ該所与のデータパケットが前記検出された少なくとも１つの損失データパケットに属する場合には、前記所与のデータパケットの前記識別子を少なくとも含む前記非確認応答メッセージが、前記タイマーが前記設定されたタイマー値に達するのを待つことなく、前記マルチキャスト送信機に送信される、方法。

【請求項2】

前記データパケットはシーケンス番号によって順序付けられ、前記損失データパケットは、既に受信されたパケットの最も高いシーケンス番号と連続していないシーケンス番号を有するデータパケットを受信することによって検出される、請求項１に記載の方法。

【請求項3】

前記第１のマルチキャスト受信機は、ウィンドウボトム及びウィンドウエンドを有する受信ウィンドウを保持し、前記ウィンドウボトムは前記少なくとも１つの損失データパケットのシーケンス番号の中の最も低いシーケンス番号であり、前記ウィンドウエンドは既に受信されたデータパケットの最も高いシーケンス番号＋１である、請求項２に記載の方法。

【請求項4】

前記ウィンドウボトムに対応するシーケンス番号を有する第１のデータパケットを受信すると、該第１のデータパケット及び受信された連続したデータパケットはアプリケーションユニットに送信され、前記ウィンドウボトムは更新される、請求項３に記載の方法。

【請求項5】

前記ウィンドウボトムが前記ウィンドウエンドに等しい場合には、前記タイマーは停止される、請求項４に記載の方法。

【請求項6】

少なくとも１つのデータパケットの損失を検出すると、前記第１のマルチキャスト受信機は、前記受信ウィンドウの充足比と、先行するデータパケット及び次のデータパケットのそれぞれの状態とに基づいて、前記損失データパケットが単一のパケット損失である否かを判断し、単一のパケット損失と判断すると、前記タイマー値が所定の除数で除算される、請求項３から５までのいずれか１項に記載の方法。

【請求項7】

前記非確認応答メッセージは、前記受信ウィンドウの単数又は複数の前記損失データパケットの識別子を含む、請求項３から６までのいずれか１項に記載の方法。

【請求項8】

前記方法は、前記受信ウィンドウのデータパケットの組がそれぞれの経過したタイムスタンプに関連付けられることを検出すると、
前記データパケットの組をアプリケーションユニットに送信することと、
前記受信ウィンドウから前記データパケットの組を破棄することと、
前記受信ウィンドウを更新することと、
を更に含む、請求項３から７までのいずれか１項に記載の方法。

【請求項9】

前記タイマー値は、前記第１のマルチキャスト受信機によって、最小値と最大値との間の範囲内でランダムに作成される、請求項１から８までのいずれか１項に記載の方法。

【請求項10】

前記最小値は、前記第１のマルチキャスト受信機によって受信された直前のｎ個のデータパケットの平均パケット間時間に基づいて計算され、ｎは１以上の整数である、請求項９に記載の方法。

【請求項11】

前記データパケットはビデオ／オーディオフレームを構築するために前記第１のマルチキャスト受信機によって復号され、最大値は、ウィンドウボトムの前記データパケットに対応するフレームの第１のプレゼンテーションタイムスタンプ値と、現在再生されているフレームの第２のプレゼンテーションタイムスタンプ値との間の差に基づいて設定される、請求項９又は１０、及び請求項３に記載の方法。

【請求項12】

前記データパケットはビデオ／オーディオフレームを構築するために前記第１のマルチキャスト受信機によって復号され、前記第１のマルチキャスト受信機は、マルチキャストダウンリンク制御リンク上で前記マルチキャスト送信機からコンテンツ情報メッセージを更に受信し、該コンテンツ情報メッセージは、各データパケットを、以下のタイプ、すなわち、イントラ符号化フレーム、オーディオフレーム、予測符号化フレーム、双方向予測符号化フレームの中のフレームタイプのビデオ／オーディオフレームに関連付け、
前記少なくとも１つの検出された損失パケットの中の損失パケットごとに、前記関連付けられるフレームタイプが、前記コンテンツ情報メッセージに基づいて前記第１のマルチキャスト受信機によって判断され、
前記非確認応答メッセージにおいて識別される前記損失データパケットは、それぞれの関連付けられるフレームタイプに基づいて優先順位をつけられる、請求項１から１１までのいずれか１項に記載の方法。

【請求項13】

コンピューティングデバイス内にロード可能であり、該コンピューティングデバイス内にロードされて、該コンピューティングデバイスによって実行されると、該コンピューティングデバイスに請求項１から１２までのいずれか１項に記載の方法のステップを実行させるように構成されたコンピュータープログラム命令を記憶したコンピューター可読媒体。

【請求項14】

ネットワーク内のマルチキャスト送信機によって最初に送信された損失データパケットの再送を要求するマルチキャスト受信機であって、該マルチキャスト送信機は該ネットワーク内でデータパケットをマルチキャストし、該マルチキャスト受信機は、
前記マルチキャスト送信機と前記マルチキャスト受信機との間のデータリンク上で少なくとも１つのデータパケットの損失を検出し、
前記損失を検出すると、タイマー値を設定し、タイマーを作動状態にし、
前記タイマーが前記設定されたタイマー値に達した後に、前記マルチキャスト受信機のネットワークインターフェースを介して、アップリンク制御リンク上で前記マルチキャスト送信機に非確認応答メッセージを送信する、
ように構成されるプロセッサを備え、
少なくとも１つの損失データパケットが前記マルチキャスト送信機によって先行して再送されずに、前記マルチキャスト受信機でデータパケットが受信された場合には、前記非確認応答メッセージは、該少なくとも１つの損失データパケットの識別子を含み、
前記マルチキャスト受信機はさらに、マルチキャストダウンリンク制御リンク上で前記マルチキャスト送信機から損失報告メッセージを更に受信し、該損失報告メッセージは、ユニキャストモード及びマルチキャストモードの中の送信モードに関連付けて前記マルチキャスト送信機によって再送されるべきデータパケットを識別し、
所与のデータパケットがマルチキャストモードにおいて再送されるべきと識別される場合に、かつ該所与のデータパケットが前記検出された少なくとも１つの損失データパケットに属する場合には、前記非確認応答メッセージは、前記所与のデータパケットの前記識別子を含まず、
所与のデータパケットがユニキャストモードにおいて再送されるべきと識別される場合に、かつ該所与のデータパケットが前記検出された少なくとも１つの損失データパケットに属する場合には、前記所与のデータパケットの前記識別子を少なくとも含む前記非確認応答メッセージが、前記タイマーが前記設定されたタイマー値に達するのを待つことなく、前記マルチキャスト送信機に送信される、
ように構成される、
マルチキャスト受信機。

【請求項15】

請求項１４に記載の少なくとも１つのマルチキャスト受信機と、マルチキャスト送信機とを備えるシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、包括的には、特にビデオストリーミングアプリケーションにおけるマルチキャストデータパケットの再送に関する。

【背景技術】

【0002】

このセクションにおいて記述される手法は追及することはできたが、必ずしも以前から考えられてきたか、又は追及されてきた手法であるとは限らない。それゆえ、本明細書において別の指示がない限り、このセクションにおいて記述される手法は、本出願における特許請求の範囲に対する先行技術でもなければ、このセクションに含めることによって従来技術であると認めるものでもない。

【0003】

マルチキャスティングは、特にインターネットプロトコルテレビ（ＩＰＴＶ）等のビデオストリーミングに関して広く普及した技術である。

【0004】

マルチキャスティングは、受信機に向かうユニキャストデータフローを集約することによって引き起こされることになる帯域幅の浪費を回避する。

【0005】

パケットがマルチキャストデータフローの任意の加入者によって受信されるべきであり、かつパケットがＭＡＣ再送方式によって再送できないので、ワイヤレスネットワークでは、マルチキャストデータパケットは一般に、物理レイヤによって、ロバストで、コンサバティブな（conservative：堅実な）モードにおいて送出される。

【0006】

ユニキャストデータパケットとは対照的に、マルチキャストデータパケットは、非確認応答モード（Non-Acknowledged mode）において送出され、それは、データパケットを受信しても受信機が確認応答を送信しないことを意味する。

【0007】

また、受信機内の受信状態について送信機が有する情報が少ないために、物理レイヤによるロバストな送信が選択される可能性もある。それゆえ、例えば、ユニキャストトラフィックの場合に存在し得るような、効率的なリンクアダプテーション機構を実現するのは実際には難しい。

【0008】

しかしながら、非常にロバストな物理モードを使用することによっても、無線チャネル変動及びシャドーイング効果のために、幾つかのパケット損失が生じる場合がある。

【0009】

そのようなパケット損失は、例えば、スマートフォン又はタッチパネル等の小型のハンドデバイスの場合に特に起こりがちである。

【0010】

パケット損失は、オーディオ及びビデオアーティファクトに変換されるので、ユーザーに表示されるビデオの品質にとって有害である。

【0011】

それらの理由から、ユーザーによって体感されるオーディオ／ビデオ品質を改善するために、マルチキャストビデオデータフローの効率的な反復機構を導入することが必要とされている。

【0012】

ビデオコーディングにおいて、コーデックがピクチャーを一連のイントラフレーム及びインターフレームとして配列する。

【0013】

ピクチャー群（ＧＯＰ：Group Of Pictures）は、符号化されたビデオフロー内の一群の連続したピクチャーである。ＧＯＰは、以下のフレームタイプを含むことができる。
−Ｉフレーム、又はイントラ符号化フレーム。これは、全ての他のピクチャー又はフレームから独立して符号化されるピクチャーである。各ＧＯＰはＩフレームから開始する。
−Ｐフレーム、又は予測符号化フレームは、先行して復号されたＩフレーム又はＰフレームに対する動き補償差情報を含む。
−Ｂフレーム、又は双方向予測符号化フレーム（bi-predictive coded frame：双予測符号化フレーム）は、先行して復号されたフレーム及び将来に復号されるフレームに対する動き補償差情報を含む。伝搬誤りを回避するために、Ｂフレームは一般には基準フレームとして使用されない。

【0014】

好ましい実施態様において、マルチキャストデータリンクは、ＩＥＴＦ ＲＴＰ（リアルタイムトランスポートプロトコル）プロトコルを介してトランスポートすることができる。ビデオ送信、特にインターネットストリーミングアプリケーション及びユニバーサルプラグアンドプレイ（ＵＰｎＰ）アプリケーションに関して、ＨＴＴＰ（ハイパーテキストトランスポートプロトコル）プロトコルが多くの場合に使用されるが、このプロトコルは、マルチキャスティングに適合しないＴＣＰに頼るので適していない。対照的に、ＩＰＴＶは、データトランスポートに関してＵＤＰプロトコルによるＩＥＴＦ ＲＴＰに頼る。

【0015】

大規模のマルチキャストネットワークに拡張可能であるようにデータ送達を監視できるようにするために、そして最低限の制御及び識別機能を提供するために、データトランスポートをリアルタイムトランスポート制御プロトコル（ＲＴＣＰ）等の制御プロトコルによって強化することができる。

【0016】

ＲＴＰ及びＲＴＣＰは、ＩＥＴＦ ＲＦＣ３５５０において標準化される。

【0017】

また、受信機の即時フィードバックのためのメッセージ、詳細には、否定応答（ＮＡＣＫ）メッセージをサポートするために、ＲＴＣＰもＩＥＴＦ ＲＦＣ４５８５によって拡張される。ＲＦＣ６６４２において、複数の受信機が同じパケット損失を受けるときに引き起こされるＮＡＣＫメッセージの数を削減するために、「第三者損失報告（Third Party Loss Report）」（ＴＰＬＲ）と呼ばれる新たなメッセージが導入される。「フィードバック殺到（feedback storm）」による厄介な結果として、ワイヤレスネットワークにおいて衝突が引き起こされる場合もある。それゆえ、フィードバック殺到を回避する機構を設計することが必要とされている。

【0018】

マルチメディアストリームの送信は多くの場合に、特にＩＰＴＶ機器の場合に広く使用されるＲＴＰ／ＲＴＣＰプロトコルに頼る。

【0019】

ＨＴＴＰとは異なり、ＲＴＰ／ＲＴＣＰデータストリームは、ＵＤＰデータグラムを介して搬送され、それゆえ、送達及びパケット順序付けが保証されない。しかしながら、ＵＤＰデータグラムは、有線又はワイヤレスネットワークを介してマルチキャストすることができる。

【0020】

８０２．１１（Ｗｉ−Ｆｉ）ワイヤレスネットワークにおいて、マルチキャストフローは、ブロードキャストされるフローと同じようにして送信することができる。すなわち、それらのマルチキャストフローは、いかなる確認応答ポリシーも用いることなく（ＮｏＡｃｋポリシー）、任意の受信機に適合する物理レイヤモードを用いて、アプリケーションプロバイダーＡＰによって送信される。マルチキャストデータパケットは繰り返されないので、無線条件不良の場合であっても、受信機の大部分にとって良好な受信を確実にするために、物理レイヤモードは非常にコンサバティブである。

【0021】

しかしながら、コンサバティブな物理レイヤモードは、シャドーイング効果又は高速の無線チャネル変化を取り扱うのに十分ではない。

【0022】

ビデオオンデマンド（ＶｏＤ）アプリケーションとは異なり、ライブビデオストリーミング受信機は、長時間のバッファリングをサポートしない。短時間のバッファーは、受信機の多様性も合わせると、再送方式を使用するのを妨げる。

【0023】

オーディオ／ビデオ復号器はデータ誤りに耐性があるが、ビデオフレームドロッピング及び／又はビデオ／オーディオアーティファクトを引き起こす。

【0024】

ワイヤレスネットワークに起因するパケット損失のバーストは、損失パケットがＩフレームを搬送するときに特に、オーディオ／ビデオ品質に多大な影響を及ぼす可能性がある。実際には、その場合、全てのＧＯＰが影響を及ぼされることになり、数秒間に、数多くのアーティファクトが目に見えることになる。

【発明の概要】

【発明が解決しようとする課題】

【0025】

したがって、マルチキャストデータストリームの状況において効率的で、ロバストな再送方法が必要とされている。

【課題を解決するための手段】

【0026】

これらの需要のうちの少なくとも幾つかに対処するために、本発明の第１の態様は、ネットワーク内のマルチキャスト送信機によって最初に送信された損失データパケットの再送を要求する方法であって、このマルチキャスト送信機はこのネットワーク内でデータパケットをマルチキャストし、この方法は、第１のマルチキャスト受信機によって実行され、
マルチキャスト送信機と第１のマルチキャスト受信機との間のデータリンク上で少なくとも１つのデータパケットの損失を検出すると、タイマー値を設定し、タイマーを作動状態にするステップと、
タイマーが設定されたタイマー値に達した後に、アップリンク制御リンクを介して、マルチキャスト送信機に非確認応答メッセージ（non-acknowledgment message）を送信するステップであって、少なくとも１つの損失データパケットがマルチキャスト送信機によって先行して再送されていなかった場合には、この非確認応答メッセージは、この少なくとも１つの損失データパケットの識別子を含むものと、
を含む、方法に関する。

【0027】

ＮＡＣＫメッセージを送信する前にタイマーを設定することによって、ネットワークに無用に過負荷をかけることを回避できるようになる。実際には、マルチキャストシステムでは、他の受信機が同じ損失を受けている可能性がある高い。これは、ワイヤレスマルチキャストの状況において更に深刻である。それゆえ、欠落したデータパケットが別のマルチキャスト受信機によって先行して要求されていたので、タイマーが満了する前に、欠落データパケットを受信することができる。代替的には、幾つかの受信機が損失データパケットの再送を要求していたので、損失データパケットがマルチキャストにおいて（全ての受信機に）再送されることを示す損失情報メッセージを受信することができる。

【0028】

本発明の幾つかの実施の形態によれば、データパケットはシーケンス番号によって順序付けることができ、損失データパケットは、既に受信されたパケットの最も高いシーケンス番号と連続していないシーケンス番号を有するデータパケットを受信することによって検出することができる。

【0029】

これは、パケットの損失を迅速に判断できるようにし、それゆえ、再送要求をより効率的なものにできるようにする。

【0030】

補足として、第１のマルチキャスト受信機は、ウィンドウボトム（bottom of window）及びウィンドウエンド（end of window）を有する受信ウィンドウを保持することができ、ウィンドウボトムは少なくとも１つの損失データパケットのシーケンス番号の中の最も低いシーケンス番号とすることができ、ウィンドウエンドは既に受信されたデータパケットの最も高いシーケンス番号＋１とすることができる。

【0031】

受信ウィンドウを保持することは、非正順のパケットを受信できるようにし、それゆえ、再送要求されるデータパケットの数を制限する。

【0032】

更なる補足として、ウィンドウボトムに対応するシーケンス番号を有する第１のデータパケットを受信すると、第１のデータパケット及び受信された連続したデータパケットはアプリケーションユニットに送信され、ウィンドウボトムは更新される。

【0033】

これは、受信ウィンドウを絶えず更新できるようにし、データストリームをその場で処理できるようにする。

【0034】

更なる補足として、ウィンドウボトムがウィンドウエンドに等しい場合には、タイマーは停止させることができる。

【0035】

これは、第１のマルチキャスト受信機によって消費される処理リソースを制限できるようにする。

【0036】

幾つかの実施の形態によれば、少なくとも１つのデータパケットの損失を検出すると、第１のマルチキャスト受信機は、受信ウィンドウの充足比（filling ratio：占有比）と、先行するデータパケット及び次のデータパケットのそれぞれの状態とに基づいて、損失データパケットが単一のパケット損失である否かを判断することができる。単一のパケット損失と判断すると、タイミング値を所定の除数で除算することができる。

【0037】

これは、再送要求方法の効率を高めることができるようにする。幾つかの実施の形態によれば、非確認応答メッセージは、受信ウィンドウの全ての単数又は複数の損失パケットの識別子を含む。幾つかの実施の形態によれば、方法は、受信ウィンドウのデータパケットの組がそれぞれの経過したタイムスタンプに関連付けられることを検出すると、
データパケットの組をアプリケーションユニットに送信することと、
受信ウィンドウからデータパケットの組を破棄することと、
受信ウィンドウを更新することと、
を更に含むことができる。

【0038】

これは、オーディオ／ビデオ品質を過度に低下させることなく、受信ウィンドウを再同期させることができるようにする。実際には、アプリケーションユニットが、耐性があるビデオ又はオーディオ符号化を実施することができ、幾つかのデータパケットが欠落している場合であっても、入手可能な情報を使用することができる。

【0039】

幾つかの実施の形態によれば、タイマー値は、第１のマルチキャスト受信機によって、最小値と最大値との間の範囲内でランダムに作成される。

【0040】

これは、２つのＮＡＣＫメッセージがマルチキャスト送信機に同時に送信される確率を小さくするので、他のマルチキャスト受信機によって送信されたＮＡＣＫメッセージ間の時間衝突を回避できるようにする。

【0041】

補足として、最小値は、マルチキャスト受信機によって受信された直前のｎ個のデータパケットの平均パケット間時間に基づいて計算され、ｎは１以上の整数である。

【0042】

これは、ＮＡＣＫメッセージがマルチキャスト送信機に送信される前に、少なくとも１つの次のデータパケットが第１のマルチキャスト受信機によって受信されるのを確実にできるようにし、次のデータパケットは潜在的には、ＮＡＣＫメッセージにおいて再送要求される損失データパケットのうちの１つである。

【0043】

幾つかの実施の形態によれば、データパケットはビデオ／オーディオフレームを構築するために第１のマルチキャスト受信機によって復号することができ、最大値は、ウィンドウボトムのデータパケットに対応するフレームの第１のプレゼンテーションタイムスタンプ値と、現在再生されているフレームの第２のプレゼンテーションタイムスタンプ値との間の差に基づいて設定することができる。

【0044】

これは、再送されたデータパケットが搬送するコンテンツが表示される前に、再送されたデータパケットを確実に受信できるようにする。それゆえ、ビデオ／オーディオ品質が改善される。

【0045】

幾つかの実施の形態によれば、第１のマルチキャスト受信機は、マルチキャストダウンリンク制御リンク上でマルチキャスト送信機から損失報告メッセージを更に受信することができ、この損失報告メッセージは、ユニキャストモード及びマルチキャストモードの中の送信モードに関連付けてマルチキャスト送信機によって再送されるべきデータパケットを識別する。所与のデータパケットがマルチキャストモードにおいて再送されるべきと識別される場合に、かつこの所与のデータパケットが検出された少なくとも１つの損失データパケットに属する場合には、非確認応答メッセージは、所与のデータパケットの識別子を含まない。

【0046】

これは、マルチキャストにおいて再送するために既にスケジューリングされているデータパケットのための無用なＮＡＣＫメッセージを送信するのを回避できるようにする。これはネットワーク負荷を低減する。

【0047】

幾つかの実施の形態によれば、マルチキャスト受信機は、マルチキャストダウンリンク制御リンク上でマルチキャスト送信機から損失報告メッセージを更に受信することができ、この損失報告メッセージは、ユニキャストモード及びマルチキャストモードの中の送信モードに関連付けてマルチキャスト送信機によって再送されるべきデータパケットを識別する。所与のデータパケットがユニキャストモードにおいて再送されるべきと識別される場合に、かつこの所与のデータパケットが検出された少なくとも１つの損失データパケットに属する場合には、所与のデータパケットの識別子を少なくとも含む非確認応答メッセージを、タイマーが設定されたタイマー値に達するのを待つことなく、マルチキャスト送信機に送信することができる。

【0048】

これは、第１の受信機も所与のデータパケットを受信し損なったことをマルチキャスト送信機に示すことができるようにする。これに応答して、マルチキャスト送信機は、所与のデータパケットをマルチキャストモードにおいて送信するために、所与のデータパケットの再送モードを変更することに決めることができ、それゆえ、その方法の効率を高めることができる。

【0049】

幾つかの実施の形態によれば、データパケットはビデオ／オーディオフレームを構築するために第１のマルチキャスト受信機によって復号することができ、第１のマルチキャスト受信機は、マルチキャストダウンリンク制御リンク上でマルチキャスト送信機からコンテンツ情報メッセージを更に受信することができ、コンテンツ情報メッセージは、各データパケットを、以下のタイプ、すなわち、イントラ符号化フレーム、オーディオフレーム、予測符号化フレーム、双方向予測符号化フレームの中のフレームタイプのビデオ／オーディオフレームに関連付ける。少なくとも１つの検出された損失パケットの中の損失パケットごとに、コンテンツ情報メッセージに基づいて、マルチキャスト受信機によって、関連付けられるフレームタイプを判断することができる。非確認応答メッセージにおいて識別された損失データパケットは、それぞれの関連付けられるフレームタイプに基づいて、優先順位をつけられる。

【0050】

これは、オーディオ／ビデオ品質に深刻な影響を及ぼすデータパケットの再送を優先させることができるようにする。

【0051】

本発明の第２の態様は、コンピューティングデバイス内にロード可能であり、このコンピューティングデバイス内にロードされて、このコンピューティングデバイスによって実行されると、このコンピューティングデバイスに本発明の第１の態様による方法のステップを実行させるように構成されたコンピュータープログラム命令を記憶したコンピューター可読媒体を備える、コンピュータープログラム製品に関する。

【0052】

本発明の第３の態様は、ネットワーク内のマルチキャスト送信機によって最初に送信される損失データパケットの再送を要求するマルチキャスト受信機であって、このマルチキャスト送信機はこのネットワーク内でデータパケットをマルチキャストし、このマルチキャスト受信機は、
マルチキャスト送信機と第１のマルチキャスト受信機との間のデータリンク上で少なくとも１つのデータパケットの損失を検出し、
損失を検出すると、タイマー値を設定し、タイマーを作動状態にし、
タイマーが設定されたタイマー値に達した後に、マルチキャスト受信機のネットワークインターフェースを介して、アップリンク制御リンク上でマルチキャスト送信機に非確認応答メッセージを送信する、
ように構成されるプロセッサを備え、
少なくとも１つの損失データパケットがマルチキャスト送信機によって先行して再送されていなかった場合には、非確認応答メッセージは、この少なくとも１つの損失データパケットの識別子を含む、マルチキャスト受信機に関する。

【0053】

本発明の第４の態様は、本発明の第３の態様に記載の少なくとも１つのマルチキャスト受信機と、マルチキャスト送信機とを備えるシステムに関する。

【0054】

本発明は、添付図面の図に、限定としてではなく例として示される。添付図面において、同様の参照符号は同様の要素を参照する。

【図面の簡単な説明】

【0055】

【図1】本発明の幾つかの実施の形態による、マルチキャストシステムを表す図である。

【図2】本発明の幾つかの実施の形態による、データパケットの再送を要求する方法を示すフローチャートである。

【図3】本発明の幾つかの実施の形態による、マルチキャスト受信機の受信ウィンドウを示す図である。

【図4】本発明の幾つかの実施の形態による、マルチキャスト受信機のタイマーの状態を示すフローチャートである。

【図5】本発明の幾つかの実施の形態による、データパケットの再送を要求することに関する交換図（exchange diagram）である。

【図6】パケット受信及び受信パケットによって搬送されるフレームの表示を示すタイミング図である。

【図7】本発明の幾つかの実施の形態による、マルチキャスト受信機の構造を示す図である。

【図8】本発明の幾つかの実施の形態による、再送方法を示す交換図である。

【図9】本発明の幾つかの実施の形態による、再送方法を示す交換図である。

【図10】本発明の幾つかの実施の形態による、マルチキャスト送信機の詳細な構造を示す図である。

【発明を実施するための形態】

【0056】

図１は、本発明の一実施の形態によるシステムを示す。そのシステムは、受信機に送信されるマルチキャストコンテンツにアクセスすることができるマルチキャスト送信機１０を備える。このために、マルチキャスト送信機１０は、マルチキャスト送信機１０の外部インターフェースと見なすことができる、ワイヤレス局（例えば、８０２．１１局）等の第１の局１１に接続される。

【0057】

本発明において、データパケットは、オーディオ／ビデオマルチメディアコンテンツのオーディオ／ビデオフレームを表す。データパケットは、マルチキャスト送信機１０によって、第２の局１２を介して第１のマルチキャスト受信機１４に送信され、第３の局１３を介して第２のマルチキャスト受信機１５に送信される。

【0058】

マルチメディアコンテンツを送信するために、本発明は以下のものを導入することができる。
−データ送信及び再送のための１つの一方向マルチキャストデータリンク１８。
−再送のためのｎ個の一方向ユニキャストデータリンク１９．１〜１９．２。ｎはマルチキャスト受信機の数である（図１に示される例では２）。
−後に説明されることになる新たなメッセージである、ＣＯＮＴＥＮＴ−ＩＮＦＯメッセージの送信のための１つの一方向マルチキャスト制御リンク２０（ダウンリンク）。
−フィードバックメッセージの送信ためのｎ個の一方向制御リンク２１．１〜２１．２（アップリンク）。

【0059】

それゆえ、その再送方式は、ユニキャストモードにおいてデータリンク１９．１〜１９，２を介してか、又はマルチキャストモードにおいて一方向マルチキャストデータリンク１８を介してかのいずれで、データパケットを再送することができる。

【0060】

マルチキャスト受信機１４及び１５は、受信パケットをそれぞれのアプリケーションユニット１６及び１７に送達することができ、アプリケーションユニットは、ユーザーに（例えば、画面等のディスプレイユニット上で）表示するために、データパケットからビデオ−オーディオフレームを抽出するように構成される。

【0061】

このため、アプリケーション１６及び１７に送信されるデータパケットは、データパケットのうちの１つのデータパケットのヘッダー内に示されるプレゼンテーションタイムスタンプが経過している場合を除いて、損失のない正順のデータパケットである。このタイムスタンプが経過している場合、満了したタイムスタンプを有するデータパケットはそれぞれのアプリケーションユニットに送達され、マルチキャスト受信機によって破棄される。実際には、アプリケーションユニットは、耐性があるビデオ符号化又はオーディオ符号化を実施することができ、幾つかの部分が欠落している場合であっても、入手可能な情報を使用することができる。その後、マルチキャスト受信機は、次のイントラ符号化ビデオフレームに再同期しようと試みることができる。

【0062】

正順のパケットを送信するために、マルチキャスト受信機１４及び１５は、後に説明されることになる受信ウィンドウを保持することができる。

【0063】

好ましい実施の形態において、データリンク１８、１９．１及び１９．２はＩＥＴＦ ＲＴＰプロトコルを介してトランスポートされる。しかしながら、本発明において使用されるプロトコルに制限はつけられない。

【0064】

制御リンク２０、２１．１及び２１．２は、任意選択で、これ以降「コンテンツ情報メッセージ」と呼ばれる新たなパケットタイプでＩＥＴＦ ＲＴＣＰプロトコルを拡張することによって、ＩＥＴＦ ＲＴＣＰプロトコルを介してトランスポートすることができる。

【0065】

データパケットの再送は、例えば、データパケットによってトランスポートされるオーディオ／ビデオフレームの重要性に応じて、及び／又は再送されるべき損失パケットの数及び配分に応じて、マルチキャストデータリンク１８を介して、又はユニキャストデータリンク１９．１及び１９．２のうちの幾つかを介して実行することができる。

【0066】

再送するためにデータマルチキャストリンク１８を使用することによって、幾つかの受信機が同じデータパケットを受信し損ねた場合に帯域幅を節約できるようにし、送信ロバスト性も強化する。したがって、マルチキャスト再送は、全ての受信機、又は高いパーセンテージの受信機が同じデータパケット損失を受けたときに使用されることが好ましい。例えば、Ｗｉ−Ｆｉセルの事例において、対象のＷｉ−Ｆｉセルがバス又は路面電車（tramway）等の輸送車両内に設置される場合には、マルチキャスト受信機は、固定されたＷｉ−Ｆｉセルによって引き起こされる摂動を受ける場合がある。

【0067】

再送のためにユニキャストデータリンク１９．１及び１９．２を使用することは、１つのマルチキャスト受信機又は少数のマルチキャスト受信機のみが幾つかの誤りを受ける場合、受信機に適応した物理レイヤ送信モードを選択できることから、帯域幅に関するコストが少ないので、より効率的である。

【0068】

マルチキャスト制御リンク２０は、損失報告メッセージ及びコンテンツ情報メッセージ等の異なる制御メッセージを送信するために、マルチキャスト送信機１０によって使用することができる。

【0069】

損失報告メッセージ（例えば、上記で導入されたようなＴＰＬＲメッセージ）は、少なくとも１つのマルチキャスト受信機によって既に再送要求されていたデータパケットの識別子を示すことができる。さらに、損失報告メッセージは、マルチキャストモード及びユニキャストモードの中の、マルチキャスト送信機１０によって選択された、識別されたデータパケットごとの再送モードを示すことができる。

【0070】

コンテンツ情報メッセージはマルチキャスト送信機１０によって定期的に送信することができ、データパケットのシーケンス番号に関連するオーディオ／ビデオフレーム情報を示す。オーディオ／フレーム情報は、オーディオフレームタイプ、イントラ符号化フレームタイプ、予測フレームタイプ及び双方向予測フレームタイプの中のフレームタイプを含む。

【0071】

また、コンテンツ情報メッセージは、任意選択で、低い方及び高い方のシーケンス番号、並びに関連付けられるタイムスタンプ等のマルチキャスト送信機１０の送信ウィンドウ状態を含むことができる。後に説明されるように、この情報は、マルチキャスト受信機が、あまりにも多くの誤りが生じたときにデータパケットを破棄するのに有用であり、オーディオフレーム及びビデオイントラ符号化フレームを搬送するデータパケットを高い優先順位で要求するのに有用である。

【0072】

後に詳述されるように、マルチキャスト受信機１４及び１５は、再送要求されたデータパケットを選択する役割を担う。

【0073】

図２は、本発明の幾つかの実施の形態による、再送を要求する方法のステップを示すフローチャートである。方法は、マルチキャスト受信機１４及び１５のうちの１つによって実行される。

【0074】

ステップ２００において、マルチキャスト送信機１０からマルチキャストデータリンク１８を介してデータパケットが受信される。受信されたデータパケットは、例えば、データパケットのヘッダー内にあるシーケンス番号によって識別することができる。

【0075】

ステップ２０１において、マルチキャスト受信機が、全てのパケットが正順である（受信ウィンドウが空であることを意味する）か否か、及び受信パケットのシーケンス番号が、先行して受信されたデータパケットのシーケンス番号に連続しているか否かを判断する。

【0076】

連続している場合には、ステップ２０２において、データパケットがアプリケーションユニット１６又は１７に転送される。

【0077】

連続していない場合には、ステップ２０３において、受信されたデータパケットに基づいて、受信ウィンドウが更新される。

【0078】

図３は、本発明の幾つかの実施の形態による、マルチキャスト受信機の受信ウィンドウを示す。

【0079】

受信ウィンドウ３０４によって、アプリケーションユニットにまだ送信されていない受信パケット３０３のシーケンス番号、及び欠落又は損失パケット３０２のシーケンス番号を識別できるようになる。それゆえ、受信ウィンドウ３０４は、損失データパケットが受信されていない間、不連続のシーケンス番号ＳＮを有するデータパケットを記憶することができるメモリのプールと見なすことができる。

【0080】

受信ウィンドウが空であるとき、データパケットが非正順で受信された時点で、すなわち、受信データパケットがアプリケーションユニットに送信された直前のパケットに連続していない時点で、損失データパケットを識別することができる。

【0081】

受信ウィンドウ３０４は、損失データパケット３０２の最も低いシーケンス番号に対応するウィンドウボトム３００と、受信データパケットの最も高いシーケンス番号＋１に対応するウィンドウエンド３０１とを含む。

【0082】

ステップ２０３における受信ウィンドウ３０４の更新は、新たに受信されたデータパケットを受信ウィンドウに追加することと、ウィンドウボトム３００又はウィンドウエンド３０１を再計算することとにある。例えば、受信データパケットがウィンドウボトム３００に対応する場合には、全ての連続した受信データパケットがアプリケーションユニット１６又は１７に送信され、ウィンドウボトム３００が、受信ウィンドウ３０４の次の損失データパケットのシーケンス番号に更新される。

【0083】

ステップ２０４において、少なくとも１つのデータパケットが損失したか否かがチェックされ、それは、受信ウィンドウが空でないことを意味する。

【0084】

データパケットが損失していない場合には、ステップ２０３の更新後にデータパケットの欠落はなく、それは、受信ウィンドウが空であり、ウィンドウエンド３０１がウィンドウボトム３００に等しいことを意味する。それゆえ、ステップ２１２において、後に説明されることになるタイマーが停止され、方法は、新たなデータパケットを受信するためにステップ２００に戻る。

【0085】

受信ウィンドウが空でない場合には、ステップ２０５において、タイマーがアクティブである（作動状態にされている）か否かがチェックされる。

【0086】

タイマーは本発明に従って使用される。例えば、タイマーは値０において開始し、その後、タイマー値Ｔ_ＮＡＣＫに達する。

【0087】

タイマーが既に作動状態にされている場合には、方法は、後に説明されるステップ２０８に直接進む。

【0088】

作動状態にない場合には、ステップ２０６において、タイマー値Ｔ_ＮＡＣＫが設定される（すなわち、作成される）。タイマー値Ｔ_ＮＡＣＫは、あらかじめ固定のものとする（prefix）ことができる。しかしながら、本発明の有利な実施の形態によれば、タイマー値Ｔ_ＮＡＣＫはステップ２０６においてランダムに作成される。例えば、Ｔ_ＮＡＣＫは、最小値Ｔ_Ｍｉｎと最大値Ｔ_Ｍａｘとの間の範囲［Ｔ_Ｍｉｎ；Ｔ_Ｍａｘ］内で作成することができる。

【0089】

ステップ２０７において、タイマーが作動状態にされる（起動される）。

【0090】

ステップ２０８において、タイマーがタイマー値Ｔ_ＮＡＣＫに達したか否かがチェックされる。図２のステップ２０８の右角（right angle）から出て、ステップ２０８に再び入る矢印は、ステップ２０８が連続したステップであることを示す。タイマーは実際には、ステップ２００において新たなパケットが受信されるまで、又はタイマー値Ｔ_ＮＡＣＫに達するまで絶えずチェックされる。

【0091】

タイマー値Ｔ_ＮＡＣＫに達していない場合には、方法は、ステップ２００に戻り、これは、マルチキャスト送信機から新たなデータパケットが受信されるまで続く。

【0092】

そうではなく、タイマーがタイマー値Ｔ_ＮＡＣＫに達していた場合には、ステップ２０９において、非確認応答メッセージが、アップリンク制御リンク２１．１又は２１．２を介してマルチキャスト送信機に送信され、非確認応答メッセージは、受信ウィンドウ３０４の少なくとも１つの損失データパケットの識別子を含む。また、非確認応答メッセージは、受信ウィンドウ３０４の全ての欠落（損失）データパケットの全ての識別子を含むこともできる。データパケットの識別子に制限はつけられない。例えば、データパケットは、それぞれのシーケンス番号によって識別することができる。

【0093】

その後、ステップ２１０において、新たなタイマー値Ｔ_ＮＡＣＫが、例えば、範囲［Ｔ_Ｍｉｎ；Ｔ_Ｍａｘ］内で作成され、ステップ２１１において、タイマーが再び作動状態にされる。その後、方法はステップ２００に戻る。

【0094】

タイマーの起動及び停止は図４を参照しながら要約される。

【0095】

図４は、本発明の幾つかの実施の形態による、タイマーの異なる状態を示すフローチャートである。

【0096】

初期状態４００において、データパケットの欠落はなく、受信ウィンドウ３０４は空である。初期状態において、タイマーは停止されている。

【0097】

遷移４０１により、データパケット損失が検出される（すなわち、幾つかのデータパケットの損失が検出される）。その後、欠落データパケットの数を示すカウンターをインクリメントすることができ、タイマー値Ｔ_ＮＡＣＫが作成され、タイマーが作動状態にされ、待ち状態４０２への遷移が実行される。欠落パケットの数は、定期的に更新される受信ウィンドウ３０４から入手可能であるので、欠落パケットの数をカウントするためのカウンターを生成することは、当然、任意選択である。待ち状態４０２において、幾つかの遷移が起こる場合がある。

【0098】

遷移４０３により、新たなデータパケット損失が検出され、その後、欠落データパケットの数を示すカウンターがインクリメントされ、マルチキャスト受信機は待ち状態４０２にとどまる。

【0099】

遷移４０４により、受信ウィンドウ３０４内で欠落していた再送データパケットが受信され、受信ウィンドウが更新されるが、更新された受信ウィンドウ３０４は空ではない。その後、欠落データパケットの数を示すカウンターがデクリメントされ、マルチキャスト受信機は待ち状態４０２にとどまる。

【0100】

遷移４０５により、タイマーが設定されたタイマー値Ｔ_ＮＡＣＫに達する。その後、非確認応答メッセージが送信され、新たなタイマー値Ｔ_ＮＡＣＫが作成され、タイマーが再び作動状態にされる。マルチキャスト受信機は待ち状態４０２にとどまる。

【0101】

遷移４０６により、受信ウィンドウ３０４内で欠落していた再送データパケットが受信され、受信ウィンドウ３０４が更新され、更新された受信ウィンドウ３０４は空である。その後、マルチキャスト受信機は、待ち状態４０２から初期状態４００に遷移する。

【0102】

遷移４０７により、ウィンドウボトム３００とウィンドウエンド３０１との間に位置するデータパケットのタイムスタンプが経過したので、破棄動作を決定することができる。受信ウィンドウ３０４が更新され、空になる。その後、マルチキャスト受信機は、待ち状態４０２から初期状態４００に遷移する。

【0103】

遷移４０８により、ウィンドウボトム３００と、高い方のシーケンス番号との間に位置するデータパケットのタイムスタンプが経過したので、破棄動作が決定され、高い方のシーケンス番号はウィンドウエンド３０１未満である。タイムスタンプが経過したデータパケットを削除することによって、受信ウィンドウ３０４が更新されるが、更新された受信ウィンドウ３０４は空ではない。その後、欠落データパケットの数を示すカウンターが、破棄された欠落パケットの数だけデクリメントされ、マルチキャスト受信機は待ち状態４０２にとどまる。

【0104】

遷移４０７及び４０８を実行するとき、破棄されたデータパケットをアプリケーションユニット１６又は１７に送信することができる。実際には、上記で説明されたように、アプリケーションユニットは耐性があるビデオ又はオーディオ符号化を実施することができ、幾つかのデータパケットが欠落している場合であっても入手可能な情報を使用することができる。その後、マルチキャスト受信機は、次のイントラ符号化ビデオフレームに再同期しようと試みることができる。

【0105】

図５は、本発明の幾つかの実施の形態による、データパケット再送を要求する方法を示すタイミング図である。

【0106】

タイミング図は、マルチキャスト送信機１０と、第１のマルチキャスト受信機１４と、第２のマルチキャスト受信機１５との間のやりとりを示す。

【0107】

データパケットがそれぞれのシーケンス番号によって識別される。

【0108】

データパケット１及び２が第１のマルチキャスト受信機１４及び第２のマルチキャスト受信機１５の両方によって正しく受信される。しかしながら、第１のマルチキャスト受信機１４はデータパケット３を受信しない。それゆえ、データパケット４を受信すると、第１のマルチキャスト受信機１４は、データパケット３が欠落していることを検出し、それに応じて、自らの受信ウィンドウを更新する。また、第１のマルチキャスト受信機１４は、タイマー値を作成し、タイマーを作動状態にする。

【0109】

データパケット６は、第１のマルチキャスト受信機及び第２のマルチキャスト受信機の両方によって受信されない。データパケット７は、第２のマルチキャスト受信機１５によってのみ受信されない。

【0110】

データパケット７を受信すると、データパケット７がアプリケーションユニット１６に先行して送信されていたデータパケット５と連続していないので、第１のマルチキャスト受信機１４は、データパケット６が損失したことを検出し、自らの受信ウィンドウ３０４を更新する。

【0111】

データパケット７の受信後に、第１のマルチキャスト受信機のタイマーがタイマー値ＴＮＡＣＫに達し、それゆえ、欠落データパケット３及び６を識別する確認応答メッセージがマルチキャスト送信機１０に送信される。

【0112】

その後、送信機は、マルチキャストデータリンク１８上でデータパケット３及び６を再送する。代替的には、後に説明されるように、データパケット３及び６は、ユニキャストデータリンク１９．１を介して、第１のマルチキャスト受信機１４にのみ送信することができる。

【0113】

データパケット８を受信すると、第２のマルチキャスト受信機１５は、パケット６及び７が損失していたことを検出し、自らの受信ウィンドウ３０４を更新し、タイマー値Ｔ_ＮＡＣＫを作成し、タイマーを作動状態にする。

【0114】

パケット３及び６を受信すると、第１のマルチキャスト受信機１４は、自らの受信ウィンドウを更新する。データパケット６を受信した後に、受信ウィンドウは空であり、第１のマルチキャスト受信機１４においてそれ以上のパケットが欠落していないので、第１のマルチキャスト受信機１４は自らのタイマーを停止する。

【0115】

第２のマルチキャスト受信機１５によって先行して受信されていたデータパケット３は、第２のマルチキャスト受信機１５によって無視することができる。

【0116】

第２のマルチキャスト受信機１５によるデータパケット９の受信中に、第２のマルチキャスト受信機１５のタイマーがタイマー値Ｔ_ＮＡＣＫに達し、それゆえ、第２のマルチキャスト受信機１５は、マルチキャスト送信機１０に非確認応答メッセージを送信する。以前に損失したパケット６はマルチキャスト送信機１０によって既に再送されているので、非確認応答は、データパケット７の識別子のみを含む。その後、新たなタイマー値が作成され、タイマーが再び作動状態にされる（又は再び初期化される）。

【0117】

データパケット７がマルチキャスト送信機１０によって再送される。データパケット７を受信すると、第２のマルチキャスト受信機１５は、自らの受信ウィンドウ３０４を更新し、受信ウィンドウは空になるので、その後、タイマーを停止する。

【0118】

アップリンク制御リンク２１．１及び２１．２上にリンク問題が存在する可能性もあり、非確認応答メッセージが失われる可能性がある。しかしながら、マルチキャスト受信機によって作動状態にされたタイマーは、タイマーの満了後に幾つかのデータパケットが依然として欠落している場合に、新たな非確認応答メッセージが送信されるのを確実にする。

【0119】

図５に示される実施の形態において、非確認応答メッセージを受信すると、マルチキャスト送信機１０は、識別されたデータパケットを直ちに送信する。しかしながら、後に説明されるように、幾つかの実施の形態において、再送（複数の場合もある）が遅延する可能性がある。

【0120】

マルチキャスト受信機が、ＮＡＣＫメッセージにおいて、古すぎるデータパケットの再送を要求するとき、マルチキャスト送信機１０が、マルチキャスト制御リンク２０上で、マルチキャスト受信機１４及び１５に送信ウィンドウの状態について通知するコンテンツ情報メッセージを送信することが推奨される。

【0121】

このコンテンツ情報メッセージを受信すると、マルチキャスト受信機１４又は１５は、ウィンドウボトムをコンテンツ情報メッセージにおいて示される次の回復点まで進めるために、幾つかのデータパケットを破棄することによって、自らの受信ウィンドウの一部をフラッシュすることに決めることができる。次の回復点は、例えば、イントラ符号化フレームに対応するデータパケットとすることができるか、又は送信ウィンドウのウィンドウボトムに対応することができる。これは、累積した遅延を解消できるようにし、回復されない新たな誤りによって絶えず中断されることなく、パケット送達を再開できるようにする。

【0122】

マルチキャスト受信機１４又は１５が自らの受信ウィンドウから外れたデータパケットを受信するときに、そのマルチキャスト受信機も同じフラッシング動作を実行することができる。この事例は、ウィンドウボトムに位置するパケットに連続して誤りがあるためにウィンドウが前進しないときに生じる場合がある。

【0123】

上記で説明されたように、タイマー値Ｔ_ＮＡＣＫは、範囲［Ｔ_Ｍｉｎ；Ｔ_Ｍａｘ］内で作成することができる。

【0124】

最大値Ｔ_Ｍａｘは、ウィンドウボトムのデータパケットによって搬送されるフレームのプレゼンテーションタイムスタンプ（ＰＴＳ）値と、現在再生されているフレームのＰＴＳとの間の差に基づいて設定することができる。実際には、データパケットはアプリケーションユニット１６又は１７のビデオバッファー（キャッシュ）に記憶することができ、データパケットから得られたフレームは、或る時間だけ遅延してオーディオ／ビデオ復号器によって再生される。これは、マルチキャスト受信機が次のオーディオ／ビデオフレームを搬送するデータパケットを受信するための或る時間を与える。

【0125】

図６は、マルチキャスト受信機によるデータパケットの受信と、復号器上の出力とをそれぞれ示す２つの平行なタイムラインを示す。

【0126】

第１のパケットの受信とビデオ表示の開始との間の時間差６００は、復号器のビデオキャッシュ深度に対応する。

【0127】

３つのデータパケット６０２．１が第１のフレーム６０３．１を搬送し、５つのデータパケット６０２．２が第２のフレーム６０３．２を搬送し、５つのデータパケット６０２．３が第３のフレーム６０３．３を搬送し、４つのパケット６０２．４が第４のフレーム６０３．４を搬送する。

【0128】

図６に示されるように、所与のフレームを搬送するデータパケットの完全な受信と、所与のフレームの表示との間の時間差６０１．１〜６０１．４は、負になるまで減少し、負になることは、第４のフレーム６０３．４の表示を遅延させなければならないことを意味する。

【0129】

これを回避するために、最大値Ｔ_Ｍａｘが上記で説明されたように設定される。

【0130】

また、最小値Ｔ_Ｍｉｎも、幾つかのデータパケットの受信が少なくとも持続時間Ｔ_Ｍｉｎによってカバーされるように、マルチキャスト受信機によって設定することができる。

【0131】

元のオーディオ／ビデオコンテンツは、可変ビットレートを用いて符号化することができるので、２つの連続したデータパケットの受信間に経過した時間であるパケット間時間を可変とすることができる。

【0132】

その結果として、マルチキャスト受信機は、直前のｎ個の受信された連続したデータパケットの平均パケット間時間を保持することができる。最小値Ｔ_Ｍｉｎは、平均パケット間時間に基づいて、計算することができる。例えば、最小値は、平均パケット間時間の整数倍とすることができる。

【0133】

本発明による方法の更なる任意選択の改善がここで説明される。

【0134】

幾つかの実施の形態によれば、マルチキャスト受信機は、タイマーが設定されたタイマー値Ｔ_ＮＡＣＫに達する前に、非確認応答メッセージを送信することに決めることができる。

【0135】

例えば、受信ウィンドウの充足比とデータパケット誤りバーストの平均サイズとを、単一のパケット損失を検出するための正確な指標とすることができる。受信ウィンドウの充足比は、受信したデータパケットと、送信ウィンドウ内の欠落データパケットとの比とすることができる。

【0136】

それゆえ、単一のパケット損失が検出されるとき、非確認応答メッセージの送信を加速するために、タイマー値Ｔ_ＮＡＣＫを所定の除数で割ることができる。

【0137】

また、マルチキャスト送信機から損失報告メッセージを受信すると、送信される次の非確認応答メッセージ内に含まれるべきデータパケットの識別子を含むパケット欠落リストが、マルチキャスト再送のためにスケジューリングされたデータパケットがマルチキャスト受信機によって再び要求されないように調整される。それゆえ、パケット欠落リストは、受信ウィンドウの損失パケットに対応するが、再送が既に要求されている損失データパケットを含まない。

【0138】

例えば、第２のマルチキャスト受信機１５が所与のデータパケットの再送を要求するとき、マルチキャスト送信機１０は、所与のデータパケットがマルチキャストモードにおいて再送される予定であることを示す損失報告メッセージをマルチキャストすることができる。それゆえ、第１のマルチキャスト受信機１４が同様に、所与のデータパケットが失われたことを検出する場合であっても、そのパケットは既に再送要求されているので、第１のマルチキャスト受信機１４は非確認応答メッセージ内にその所与のデータパケットの識別子を含まない。

【0139】

別の実施の形態によれば、損失報告メッセージが、（再送を要求した別のマルチキャスト受信機への）ユニキャストモードにおける所与のデータパケットの再送を示す場合に、かつそのマルチキャスト受信機が、その所与のデータパケットが欠落パケットのリストに属すると判断する場合には、そのマルチキャスト受信機は、タイマーがタイマー値Ｔ_ＮＡＣＫに達するのを待つことなく、所与のパケットの再送を要求するために、非確認応答メッセージを直ちに送信する。これにより、送信機へのユニキャスト／マルチキャスト選択プロセスを最適化できるようになり、幾つかの帯域幅リソースを節約できるようになる。

【0140】

幾つかの実施の形態によれば、非確認応答メッセージにおいて要求される損失データパケットは、それらのパケットが搬送するオーディオ／ビデオフレームのタイプに応じて、マルチキャスト受信機によって順序付けることができる。

【0141】

例えば、損失報告メッセージにおいてマルチキャスト送信機によって告知される再送されるデータパケットの数に基づいて、マルチキャスト受信機は、非確認応答メッセージに含まれる損失データパケットの識別子の数を制限することに決めることができる。

【0142】

データパケットは優先順位によって分類することができる。
１）１つの損失報告メッセージの中でユニキャストモードにおいて再送されることが既に告知されているパケット。実際には、上記で説明されたように、その場合、非確認応答メッセージは、タイマーがタイマー値Ｔ_ＮＡＣＫに達するのを待つことなく、送信することができる。
２）イントラ符号化ビデオフレーム又はオーディオフレームを搬送するパケット。
３）ビデオ予測フレームを搬送するパケット。
４）ビデオ双方向予測フレームを搬送するパケット。

【0143】

予測フレーム又は双方向予測フレームを搬送するパケットの中の、受けるデータパケット損失が最も少ないフレームに優先権を与えることができる。

【0144】

上記の分類は例示のために与えられる。当然、パケットタイプの順序は変更することができる。例えば、イントラ符号化ビデオフレームを搬送するパケットの前又は後にオーディオフレームを分類することができる。

【0145】

マルチキャスト受信機は、マルチキャスト送信機１０によって定期的に送信されるコンテンツ情報メッセージに基づいて、パケットと、フレームのタイプとの間の関連付けを推定することができる。

【0146】

これは、最も重要なデータパケットのための再送回数を制限できるようにする。実際には、システム効率を維持するために、再送されるパケットの全数は、ストリーム平均帯域幅の所与のパーセンテージ（例えば、１０％）を超えないことが好ましい。

【0147】

また、現在復号されているフレームのＰＴＳ_ｄに比べて高すぎるＰＴＳ_Ｎを有するオーディオ／ビデオフレームｎを搬送するデータパケットは、マルチキャスト受信機によって再送要求されないことが好ましい。このために、ラウンドトリップ時間（ＲＴＴ）、再送のために必要とされる最小時間Ｔ_{ＲｔｘＭｉｎ}（後に説明される）及び時間マージンσを考慮することができる。

【0148】

例えば、パケットが再送するのにふさわしいか否かをチェックするために、以下の式を適用することができる。

【0149】

ＰＴＳ_Ｎ＜ＰＴＳ_ｄ−Ｔ_{ＲｔｘＭｉｎ}−ＲＴＴ−σ

【0150】

図７は、本発明の幾つかの実施の形態による、マルチキャスト受信機７００を示す。例えば、マルチキャスト受信機７００は、第１のマルチキャスト受信機１４又は第２のマルチキャスト受信機１５とすることができる。

【0151】

マルチキャスト受信機７００は、図２から図４を参照したときに上記で説明されたような方法のステップを実行する命令を記憶することができる、ランダムアクセスメモリ７０３及びプロセッサ７０２を備える。

【0152】

また、マルチキャスト受信機７００は、本発明による方法から生じるデータを記憶するデータベース７０４も備えることができる。例えば、データベース７０４は、受信ウィンドウと、任意選択で、欠落データパケットリストとを記憶することができる。

【0153】

マルチキャスト受信機は、マルチキャスト送信機１０と通信するためのネットワークインターフェース７０１を備える。ネットワークインターフェース７０１は、局１２内に位置することもできる。その場合、受信機１４及び局１２はマルチキャスト受信機７００内に統合することができる。ネットワークインターフェース７０１は、ＩＥＥＥ８０２．１１インターフェース等のワイヤレスインターフェースとすることができる。ネットワークインターフェース７０１は、リンク１８、１９又は２０上でネットワーク送信機１０によって通信されるデータ又は制御メッセージを受信することができる。また、ネットワークインターフェース７０１は、ネットワーク送信機１０にＮＡＣＫメッセージを送信することができる。

【0154】

また、マルチキャスト受信機７００は、正順のパケットをアプリケーションユニットに送信するための、そしてより一般的には、（例えば、現在再生されているフレームのＰＴＳを得るために）アプリケーションユニットと通信するための出力インターフェース７０５を備える。

【0155】

マルチキャスト送信機１０によって実行される再送がここで説明される。

【0156】

上記で説明されたように、マルチキャスト送信機１０は、全てのマルチキャスト受信機１４及び１５にマルチキャストデータパケットによって搬送されるコンテンツについて通知するために、マルチキャスト制御リンク２０上でコンテンツ情報メッセージを定期的に送信することができる。しかしながら、マルチキャスト制御リンク２０は誤りを起こしやすい場合があるので、全てのマルチキャスト受信機がコンテンツ情報メッセージによって搬送される情報にアクセスすることができるように、同じコンテンツ情報メッセージを何回か繰り返すことが有用である。

【0157】

全てのマルチキャスト受信機１４及び１５に、再送される予定であるデータパケットについて通知するために、マルチキャスト制御リンク２０を介してマルチキャスト送信機１０によって損失報告メッセージ（例えば、ＴＰＬＲメッセージ）を送出することができる。ＴＰＬＲメッセージはＲＦＣ６６４２において標準化される。上記で言及されたように、ＴＰＬＲメッセージは、再送するためにスケジューリングされた各データパケットの送信モード（マルチキャスト又はユニキャスト）を報告するために拡張することができる。

【0158】

タイマー値Ｔ_ＴＰＬＲ及び関連付けられる送信機タイマーを用いて、ＴＰＬＲメッセージの送出を管理することができる。ユニキャスト制御チャネル２１．１及び２１．２のうちの１つを介してＮＡＣＫメッセージを受信すると、マルチキャスト送信機は、再送されるべきデータパケットの内部リストを更新することができ、送信機タイマーがタイマー値Ｔ_ＴＰＬＲに達した場合には、新たなＴＰＬＲメッセージを送信することができる。

【0159】

その後、送信機タイマーが再び作動状態にされ、Ｔ_ＴＰＬＲが規定値を用いて設定し直される。マルチキャスト送信機１０は、最小持続時間Ｔ_{ＲｔｘＭｉｎ}だけ待った後に、要求されたデータパケットを実効的に再送する。

【0160】

これは、ＴＰＬＲメッセージの受信時に（例えば、ＴＰＬＲメッセージが所与のメッセージのスケジューリングされたユニキャスト送信を示す場合に、かつ所与のメッセージがＴＰＬＲメッセージを受信するマルチキャスト受信機において欠落している場合には）、マルチキャスト送信機１０が、任意のマルチキャスト受信機１４及び１５に直ちにＮＡＣＫメッセージを送信する機会を与えることができるようにする。

【0161】

再送要求されたデータパケットが、誤りのバーストに属する場合（バーストは連続したデータパケットが欠落していることを意味する）又は幾つかのマルチキャスト受信機によって要求される場合、マルチキャスト送信機１０は、マルチキャストモードにおいてデータパケットの再送をスケジューリングすることができる。そうでない場合には、要求しているマルチキャスト受信機にユニキャストモードにおいて再送されるようにデータパケットをスケジューリングすることができる。

【0162】

再送のためにマルチキャストモードが使用されるとき、標準規格ＩＥＥＥ８０１．１１ｅによって導入されたＴｘＯｐ機構において提案されるように、レイヤ２における帯域幅使用を最適化するために、データパケットを、同じデータフローにおいて最初に送信されたデータパケットと多重化することができる。

【0163】

好ましくは、マルチキャスト送信機１０は、再送されるデータパケットの全数が、メディアストリームビットレートに比例することができる所定の閾値を超えないことを確実にすることができる。その結果として、幾つかの要求されたデータパケットは、マルチキャスト送信機１０によって再送されない場合がある。

【0164】

再送するためにデータパケットがスケジューリングされる順序は、
−ビデオイントラ符号化フレーム又はオーディオフレームを搬送するデータパケット、
−ビデオ予測フレームを搬送するデータパケット、
−ビデオ双方向予測フレームを搬送するデータパケット、
である。

【0165】

１つの優先順位内で、それぞれのシーケンス番号に従ってデータパケットを順序付け、再送することができる。

【0166】

これを示すために、図８は、本発明の第１の例に従ってマルチキャスト送信機１０によって実行される再送方法を示すフローチャートである。

【0167】

第１のマルチキャスト受信機１４はその参照符号１４によって表され、第２のマルチキャスト受信機１５はその参照符号１５によって表され、マルチキャスト送信機１０はその参照符号１０によって表される。

【0168】

ステップ８０１において、第２のマルチキャスト受信機１５が、マルチキャスト送信機１０に送信されるＮＡＣＫメッセージを介して、データパケット４〜７の再送を要求する。

【0169】

ＮＡＣＫメッセージを受信すると、マルチキャスト送信機は、データパケット４〜７のための再送モードを選択する。損失データパケット４〜７は、誤りのバーストに対応するので、マルチキャスト送信機は、データパケット４〜７をマルチキャストにおいて再送することに決めることができる。

【0170】

その後、マルチキャスト制御リンク２０上で全てのマルチキャスト受信機にＴＰＬＲメッセージが送信され、ＴＰＬＲメッセージは、パケット４〜７のマルチキャストにおける再送がスケジューリングされたことを示す。

【0171】

これに並行して、ステップ８０２においてＴＰＬＲメッセージを送出した後に、ステップ８１０．１において送信機タイマーＴ_ＴＰＬＲが作動状態にされる。

【0172】

また、マルチキャスト送信機１０は、ステップ８１１．１において持続時間Ｔ_{ＲｔｘＭｉｎ}だけ待った後に、ステップ８０３において、データパケット４をマルチキャストにおいて再送する。

【0173】

その後、マルチキャスト送信機１０は、ステップ８０４において、データパケット５をマルチキャストにおいて再送する。

【0174】

ステップ８０５において、第１のマルチキャスト受信機１４が、マルチキャスト送信機にＮＡＣＫメッセージを送信し、パケット３の再送を要求する。

【0175】

マルチキャスト送信機１０は、データパケット３のための再送モード、例えば、ユニキャストを選択する。

【0176】

その間に、送信機タイマーが満了した（値Ｔ_ＴＰＬＲに達した）ので、ステップ８０６において、マルチキャスト制御リンク２０上で、データパケット３のスケジューリングされた再送がユニキャストであり、データパケット６及び７のスケジューリングされた再送がマルチキャストであることを示す新たなＴＰＬＲメッセージがマルチキャストされる。

【0177】

これに並行して、ステップ８０６においてＴＰＬＲメッセージを送出した後に、ステップ８１０．２において送信機タイマーが作動状態にされる。

【0178】

また、マルチキャスト送信機１０は、ステップ８１１．２において、持続時間Ｔ_{ＲｔｘＭｉｎ}だけ待った後に、ステップ８０７において、データパケット３をユニキャストにおいて第１のマルチキャスト受信機１４に再送する。

【0179】

ステップ８０８において、データパケット６がマルチキャストにおいて再送され、ステップ８０９において、データパケット７がマルチキャストにおいて再送される。

【0180】

図９は、第２の例に従ってマルチキャスト送信機１０によって実行される再送方法を示すフローチャートである。

【0181】

ここでも、第１のマルチキャスト受信機１４はその参照符号１４によって表され、第２のマルチキャスト受信機１５はその参照符号１５によって表され、マルチキャスト送信機１０はその参照符号１０によって表される。

【0182】

ステップ９０１において、第２のマルチキャスト受信機１５が、マルチキャスト送信機１０に送信されるＮＡＣＫメッセージを介して、データパケット４、７、１０及び１５の再送を要求する。

【0183】

ＮＡＣＫメッセージを受信すると、マルチキャスト送信機は、データパケット４、７、１０のための再送モードを選択する。それらのパケットは誤りのバーストに対応しないので、そして、１つのマルチキャスト受信機によってのみ要求されるので、ユニキャストモードが選択される。

【0184】

その後、マルチキャスト送信機１０は、マルチキャストモードにおいて、全ての受信機に、データパケット４、７及び１０がユニキャストモードにおいて再送される予定であることを示すＴＰＬＲメッセージを送信する。また、マルチキャスト送信機は、データパケット１５のための再送モードも選択することができる。例えば、データパケット１５は、例えば、高い優先順位を有するフレームを搬送するので、マルチキャストモードにおいて再送されるようにスケジューリングされる。

【0185】

ＴＰＬＲメッセージを受信すると、第１のマルチキャスト受信機１４は、マルチキャスト送信機１０に、データパケット３、７及び１０の再送を要求する第２のＮＡＣＫメッセージを送信する。第１のマルチキャスト受信機がデータパケット７及び１０を欠落しており、これらのデータパケットはユニキャストモードにおいて（要求している第２のマルチキャスト受信機１５に）のみ再送されるようにスケジューリングされるので、第２のＮＡＣＫメッセージはＴＰＬＲメッセージの直後に送信される。

【0186】

第１のＮＡＣＫメッセージの受信と第２のＮＡＣＫメッセージの受信との間に経過した時間がＴ_{ＲｔｘＭｉｎ}未満であるので、その間にデータパケット４は再送されていない。

【0187】

これに並行して、ステップ９０２においてＴＰＬＲメッセージを送出した後に、ステップ９１４．１において送信機タイマーが作動状態にされる。ステップ９０３において第２のＮＡＣＫメッセージが受信されるときにタイマーが満了していないので、ステップ９０３後に新たなＴＰＬＲメッセージは送信されない。

【0188】

マルチキャスト送信機１０は、ステップ９０３において第２のＮＡＣＫメッセージを受信すると、ステップ９１３．１において持続時間Ｔ_{ＲｔｘＭｉｎ}だけ待った後に、ステップ９０４において、データパケット３をユニキャストにおいて第１のマルチキャスト受信機１４に再送する。

【0189】

データパケット７が少なくとも２つのマルチキャスト受信機によって再送要求されているので、ステップ９０６において、データパケット７がマルチキャストモードにおいて全てのマルチキャスト受信機に再送される。

【0190】

データパケット１０が少なくとも２つのマルチキャスト受信機によって再送要求されているので、ステップ９０７において、データパケット１０がマルチキャストモードにおいて全てのマルチキャスト受信機に再送される。

【0191】

ステップ９０８において、第１のマルチキャスト受信機１４は、マルチキャスト送信機１０に、パケット１８及び２２の再送を要求する第３のＮＡＣＫメッセージを送信する。

【0192】

マルチキャスト送信機１０は、データパケット１８及び２２のための再送モード、例えば、ユニキャストモードを選択する。

【0193】

その間に、送信機タイマーが満了した（値Ｔ_ＴＰＬＲに達した）ので、ステップ９０９において、マルチキャスト制御リンク２０上で、データパケット１５のスケジューリングされた再送がマルチキャストであり、データパケット１８及び２２のスケジューリングされた再送がユニキャストであることを示す新たなＴＰＬＲメッセージがマルチキャストされる。

【0194】

これに並行して、ステップ９０９においてＴＰＬＲメッセージを送出した後に、ステップ９１４．２において送信機タイマーが作動状態にされる。

【0195】

また、マルチキャスト送信機１０は、ステップ９１３．２において持続時間Ｔ_{ＲｔｘＭｉｎ}だけ待った後に、ステップ９１０において、データパケット１５をマルチキャストにおいて再送する。

【0196】

ステップ９１１において、データパケット１８がユニキャストにおいて第１のマルチキャスト受信機１４に再送され、ステップ９１２において、データパケット２２がユニキャストにおいて第１の受信機１４に再送される。

【0197】

図１０は、本発明の幾つかの実施の形態による、マルチキャスト送信機１０を示す。

【0198】

マルチキャスト送信機１０は、特に図８及び図９を参照しながら、上記で説明されたステップを実行する命令を記憶することができる、ランダムアクセスメモリ１００３及びプロセッサ１００２を備える。

【0199】

また、マルチキャスト送信機１０は、本発明による方法から生じるデータを記憶するデータベース１００４も備えることができる。例えば、データベース１００４は送信ウィンドウを記憶することができる。

【0200】

マルチキャスト送信機１０は、マルチキャスト受信機と通信するためのネットワークインターフェース１００１を備える。ネットワークインターフェース１００１は、局１１内に位置することもできる。その場合、局１１はマルチキャスト送信機１０内に組み込むことができる。ネットワークインターフェース１００１は、ＩＥＥＥ８０２．１１インターフェース等のワイヤレスインターフェースとすることができる。ネットワークインターフェース１００１は、リンク１８、１９又は２０上でデータパケット又は制御メッセージを送信することができる。ネットワークインターフェース１００１は、マルチキャスト受信機１４及び１５からＮＡＣＫメッセージを受信することもできる。

【0201】

本発明はコンピュータープログラム製品に組み込むこともでき、そのコンピュータープログラム製品は、本明細書において説明される方法を実施できるようにする全ての機構を含み、情報処理システムにロードされるときに、情報処理システムを生成する。この文脈におけるコンピュータープログラム手段又はコンピュータープログラムは、情報処理能力を有するシステムが直接、又は別の言語への変換後に特定の機能を実行するように意図される１組の命令に関する、任意の言語、コード又は表記における任意の表現を意味する。そのようなコンピュータープログラムは、データ、命令、メッセージ又はメッセージパケット及び他の機械可読情報を媒体から読み出すことができるようにする、コンピューター可読媒体又は機械可読媒体上に記憶することができる。コンピューター可読媒体又は機械可読媒体は、ＲＯＭ、フラッシュメモリ、ディスクドライブメモリ、ＣＤ−ＲＯＭ及び他の永久記憶装置のような不揮発性メモリを含むことができる。さらに、コンピューター可読媒体又は機械可読媒体は、例えば、ＲＡＭ、バッファー、キャッシュメモリ、及びネットワーク回線のような揮発性記憶装置を含む場合がある。さらに、コンピューター可読媒体又は機械可読媒体は、有線ネットワーク又は無線ネットワークを含む、ネットワークリンク及び／又はネットワークインターフェースのような一時的状態の媒体内にあるコンピューター可読情報又は機械可読情報を含むことができ、デバイスがそのようなコンピューター可読情報又は機械可読情報を読み出すことができるようになる。

【0202】

「備える」、「含む」、「組み込む」、「収容する」、「である」、及び「有する」のような表現は、説明及び関連する特許請求の範囲を解釈する際に非排他的に解釈されるべきであり、すなわち、同様に存在していると明示的には規定されない他の項目又は構成要素を考慮に入れるように解釈されるべきである。単数形への参照は複数形への参照であるとも解釈されるべきであり、その逆も同様である。

【0203】

現時点で本発明の好ましい実施の形態であるとみなされるものが図示及び説明されてきたが、本発明の真の範囲から逸脱することなく、種々の他の変更を加えることができること、及び代わりに均等物を用いることができることは当業者には理解されよう。さらに、本明細書において記述される中心的な発明の概念から逸脱することなく、特定の状況を本発明の教示に適合させるように数多くの変更を加えることができる。さらに、本発明の実施の形態は、上記の特徴の全てを含むとは限らない場合がある。それゆえ、本発明は開示される特定の実施の形態に限定されるのではなく、上記で広く定義されたように本発明の範囲内に入る全ての実施の形態を含むことを意図している。

【0204】

本明細書において開示される種々のパラメーターを変更できること、及び本発明の範囲から逸脱することなく、開示及び／又は特許請求される種々の実施の形態を組み合わせることができることは当業者には容易に理解されよう。

【産業上の利用可能性】

【0205】

本発明の方法、コンピュータープログラム製品、マルチキャスト受信機及びシステムは、数多くの種類の分野におけるマルチキャストネットワークに適用可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】