(57)【要約】本発明は、１対多の送信ができるシステムにおけるデータ修復方法に関する。該方法は、送信機から少なくとも１つの受信機にデータを送信するステップを含み、種々の送信機ドリブンまたは受信機ドリブンの喪失データの修復方法を提供する。【選択図】図３
2007522750.tif 000002
【特許請求の範囲】
【請求項１】
１対多の送信ができるシステムにおけるデータ修復方法であって、
送信機から少なくとも１つの受信機にデータを送信するステップと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するステップとを含む、データ修復方法。
【請求項２】
修復は、
喪失データ全体を再送信するステップ、
喪失データの一部だけを再送信するステップ、
元の送信全体を繰り返すステップ、のうちの１つを含む修復セッションにて行われる、請求項１に記載の方法。
【請求項３】
エラーレートパラメータが送信機から受信機に送信され、喪失データの修復の要求における閾値として使用される、請求項１に記載の方法。
【請求項４】
前記エラーレートパラメータは、時間ウィンドウおよび／またはデータウィンドウにおける閾値の計算に使用される、請求項３に記載の方法。
【請求項５】
前記方法は、セッションまたはその一部がポイントツーマルチポイントの形態で再送信されることを受信機に示すステップを含む、請求項１に記載の方法。
【請求項６】
前記示すステップは、ポイントツーマルチポイント修復トークンを用いて実行される、請求項５に記載の方法。
【請求項７】
前記方法は、受信機から送信機に送信される修復要求のランダムまたは擬似ランダムな時間分散を発生させるステップを含む、請求項１に記載の方法。
【請求項８】
前記方法は、関連する期間を通じて統計的に一様な配信を提供する、請求項７に記載の方法。
【請求項９】
前記方法は、受信機の複数の役割を使用するステップを含む、請求項１に記載の方法。
【請求項１０】
前記役割の１つ以上は、オフセット時間およびランダムな期間によって与えられるバックオフ時間を含む、請求項９に記載の方法。
【請求項１１】
前記役割の１つ以上は、フラグ保持者動作を含む、請求項９に記載の方法。
【請求項１２】
前記方法は、予め設定することによって、送信機と受信機との間に時間パラメータおよび／またはデータパラメータおよび／またはエラーパラメータを共有するステップを含む、請求項１に記載の方法。
【請求項１３】
前記方法は、修復要求を受信した後に、修復が後にしか実行されないことをサーバーから受信機に示すステップを含む、請求項１に記載の方法。
【請求項１４】
前記方法は、異なる修復方法間に優先順位をつけるステップを含む、請求項１に記載の方法。
【請求項１５】
前記方法は、最初にポイントツーマルチポイント修復を始め、ポイントツーポイント修復が続くステップを含む、請求項１４に記載の方法。
【請求項１６】
前記方法は、修復セッション／シグナリングのための開始ポイントを使用するステップを含み、前記開始ポイントは、セッションの終了、オブジェクトの終了、オブジェクトの閾値、およびセッショングループの終了を含むグループから選択される、請求項１に記載の方法。
【請求項１７】
前記方法は、前記受信機での修復要求の送信を遅延させるステップを含む、請求項１に記載の方法。
【請求項１８】
前記修復要求は、所定の時間量遅延される、請求項１に記載の方法。
【請求項１９】
修復要求は、受信機においてデータの使用が必要な場合にのみ実行される、請求項１に記載の方法。
【請求項２０】
修復に利用できる最長時間が提供される、請求項１に記載の方法。
【請求項２１】
前記方法は、データストリームでの最初の損失位置を考慮するステップをさらに含む、請求項１９に記載の方法。
【請求項２２】
回復時間が計算され、喪失データの修復に使用される、請求項１に記載の方法。
【請求項２３】
独立した修復セッションは、最初のマルチキャスト／ブロードキャスト送信が終了する前に、要求および／または開始される、請求項１に記載の方法。
【請求項２４】
前記方法は、修復を要求する前に待機するために、修復要求抑制時間を計算するステップを含む、請求項１に記載の方法。
【請求項２５】
１対多の送信ができるシステムにおけるデータ修復のための受信機であって、
送信機によって送信されるデータを受信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復のための手段とを含む、受信機。
【請求項２６】
１対多の送信ができるシステムにおけるデータ修復のための送信機であって、
少なくとも１つの受信機にデータを送信する手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復のための手段とを含む、送信機。
【請求項２７】
送信機、ネットワーク、および少なくとも１つの受信機を備える１対多の送信ができるシステムであって、
前記ネットワークを経て前記送信機から前記少なくとも１つの受信機にデータを送信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するための手段とを含む、システム。
【請求項２８】
１対多の送信ができるシステムでのデータ修復のための受信機において実行可能なソフトウェアアプリケーションであって、
前記受信機に送信機によって送信されたデータを受信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーション。
【請求項２９】
１対多の送信ができるシステムでのデータ修復のための送信機において実行可能なソフトウェアアプリケーションであって、
前記送信機が少なくとも１つの受信機にデータを送信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーション。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、マルチキャストおよびブロードキャスト送信技術およびサービス、すなわち、少なくとも１つのデータソース（または送信機）および少なくとも１つの受信機を有するサービスに関する。
【背景技術】
【０００２】
ＩＰマルチキャスト、ＩＰデータキャスティング（ＩＰＤＣ）、およびマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）などのシステムを通じた１対多（すなわち、ポイントツーマルチポイント）のサービスに関して、ファイル配信（または離散的メディア配信またはファイルダウンロード）は、重要なサービスである。ファイル転送プロトコル（ＦＴＰ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）などのポイントツーポイントプロトコルを通じたファイルを配信するための機能の多くは、１対多のシナリオに対する問題を含んでいる。特に、通信制御プロトコル（ＴＣＰ）などの類似した１対１（すなわち、ポイントツーポイント）の確認応答（ＡＣＫ）プロトコルを使用した、信頼性の高いファイル配信−すなわち、保証されたファイルの配信−は、実現可能ではない。
【０００３】
インターネット技術特別調査委員会（Internet Engineering Task Force；ＩＥＴＦ）の高信頼性マルチキャスト送信（Reliable
Multicast Transport； ＲＭＴ）ワーキンググループは、エラー耐性マルチキャストトランスポートプロトコルの２つのカテゴリを標準化しようとしている。第１のカテゴリにおいては、（プロアクティブな）前進型誤信号訂正（Forward
Error Correction； ＦＥＣ）を使用することによって、すなわち、誤ったデータの再構成のために受信機の役に立つある量の冗長データを送信することで、信頼性が実現される。第２のカテゴリにおいては、受信機のフィードバックは、高信頼性マルチキャスト送信を実現するために使用される。非同期階層符号化（Asynchronous
Layered Coding；ＡＬＣ、ＲＦＣ  ３４５０）は、第１のカテゴリに属するプロトコルの例であり、ＮＡＣＫ指向高信頼性マルチキャスト（ＮＡＣＫ−Ｏｒｉｅｎｔｅｄ  Ｒｅｌｉａｂｌｅ  Ｍｕｌｔｉｃａｓｔ；ＮＯＲＭ）プロトコルは、第２のカテゴリの一例を示す。ＡＬＣおよびＮＯＲＭプロトコルは、ＩＥＴＦのワーキンググループによって作成された、「Ａｓｙｎｃｈｒｏｎｏｕｓ  Ｌａｙｅｒｅｄ  Ｃｏｄｉｎｇ（ＡＬＣ）Ｐｒｏｔｏｃｏｌ  Ｉｎｓｔａｔｉａｔｉｏｎ」（ＩＥＴＦ、ＲＦＣ  ３４５０）および「ＮＡＣＫ−Ｏｒｉｅｎｔｅｄ  Ｒｅｌｉａｂｌｅ  Ｍｕｌｔｉｃａｓｔ  Ｐｒｏｔｏｃｏｌ」（インターネットドラフト）という名称の出版物に詳述されている。これらの出版物の内容は、その全体を参照して本願明細書に組み込まれる。
【０００４】
これらのプロトコルを使用できるアクセスネットワークには、限定するものではないが、ユニバーサルモバイルテレコミュニケーションサービス（ＵＭＴＳ）システム、無線ローカルエリアネットワーク（ＷＬＡＮ）、デジタルビデオ地上放送（ＤＶＢ−Ｔ）ネットワーク、およびデジタルビデオ衛星放送（ＤＶＢ−Ｓ）ネットワークなどの、無線マルチアクセスネットワークが挙げられる。
【０００５】
簡潔に述べると、ＡＬＣプロトコルは、壊れたパケットまたは受信されなかったパケットを受信機が再構築できる、プロアクティブＦＥＣベースのスキームである。ＡＬＣプロトコルは、複数のチャネル上でＦＥＣ符号化を使用し、送信機は、データを場合により異種の受信機に異なるレート（チャネル）で送信することができる。加えて、ＡＬＣプロトコルは、異なるチャネル上で異なるレートを維持するために輻輳制御機構を使用する。
【０００６】
ＡＬＣプロトコルはアップリンクシグナリングを必要としないので、複数のユーザーについて大規模に拡張可能である。したがって、追加される受信機の数が、必ずしもシステムへの要求を増加させない。しかし、ＡＬＣプロトコルは、受信が保証されていないので１００％の信頼性があるわけではなく、したがって、概して高信頼性というよりは堅牢であると説明される場合がある。
【０００７】
同様に、ＮＯＲＭは、受信機に到達すると予想されたデータ（または、「データブロック」と定義される）のうちのどのパケットが受信機で受信されなかったのか（または、誤って受信された）をシグナリングするために、不許諾応答（Ｎｅｇａｔｉｖｅ  Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ；ＮＡＣＫ）メッセージの使用を規定している。換言すれば、受信機は、送信されたパケットの喪失または破損を送信機に示すためにＮＡＣＫメッセージを用いる。したがって、データ伝送でいくつかのデータブロックを「喪失した」受信機は、喪失した１つまたは複数のデータブロックを再送信するよう送信機に要求するＮＡＣＫメッセージを送信することができる。ＮＯＲＭプロトコルはまた、任意で、能動的で堅牢な送信のためにパケットレベルのＦＥＣ符号化を使用することができる。
【０００８】
一方向トランスポート上のファイル配信（Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏａｎｌ  Ｔｒａｎｓｐｏｒｔ；ＦＬＵＴＥ）は、ＦＥＣ（ＲＦＣ  ３４５２）およびＡＬＣビルディングブロックに構築する、１対多のトランスポートプロトコルである。これは、一方向性システムを通じた送信機から受信機へのファイル配信を対象としたものである。無線ポイントツーマルチポイント（マルチキャスト／ブロードキャスト）システムに適応させるための特殊化を有する。ＦＬＵＴＥプロトコルの詳細は、上述のＩＦＴＦのワーキンググループによって作成された「ＦＬＵＴＥ−Ｆｉｌｅ  Ｄｅｌｉｖｅｒｙ  ｏｖｅｒ  Ｕｎｉｄｉｒｅｃｔｉｏａｎｌ  Ｔｒａｎｓｐｏｒｔ」（インターネットドラフト）という名称の出版物に詳述されている。この出版物の内容は、その全体を参照して本願明細書に組み込まれる。
【０００９】
一般に、ＮＡＣＫメッセージはＮＯＲＭ特有ではなく、そのメッセージはまた、ＦＬＵＴＥのような他のプロトコルまたはシステムに関連して使用することもできる。ＡＣＫは受信機が送信する応答メッセージであって、１つ以上のデータパケットを受信した後に、データパケットを適切に受信したという確認応答である。ＮＡＣＫは、受信機が、送信されるまたは送信されたと予想されるが、まだ受信されていないパケットに関して、送信機に送信する応答である。
【００１０】
マルチキャストまたはブロードキャスト環境にある場合、データ伝送は、１対多の形態で生じる。送信がエラーフリーでなく、異なる受信機が異なるエラーレートを受ける場合（例えば、ＭＢＭＳおいて、異なるセルのユーザーが異なる品質の信号を受け、その結果、異なるエラーレートを受ける場合）、データの信頼性の向上に問題が生じる。これは、ＦＥＣおよび／または修復セッションを使用することによって解決することができる。
【００１１】
ＦＥＣは、ある程度のエラー耐性によって受信機が送信データを再構成できるようにするために、送信データにある程度の冗長性を提供する。しかし、ＦＥＣの１つの問題は、ＦＥＣがエラーが全くないエラー回復能力を提供しないこと、または、完全なエラー回復能力を提供するがデータ冗長を多用し、チャネル帯域幅の要件を厳しくすることである。
【００１２】
（受信機と送信機との間の）修復セッションは、（残余のチャネルエラーレートを減じるべく又は取り除くべく）ＦＥＣを補うために用いるか、またはエラー回復に対する唯一の方法として単独で使用することができる。修復セッションは、独立したセッションを使用したポイントツーポイントチャネルを通じて開始することができる。この場合、マルチキャスト／ブロードキャスト送信中に一部のデータを喪失した全ての受信機は、喪失したパケットを再送信するよう送信機に要求するＮＡＣＫ要求を送信する。しかし、受信機が少なくとも１つのデータパケットを喪失した場合、全ての受信機は、送信機とのポイントツーポイント接続を一斉に構築することになり、フィードバックの集中が生じる。すなわち、ネットワーク内の（多数のＮＡＣＫに対するアップリンク、多数の同時再送信およびネットワーク接続要求に対するダウンリンクにおける）輻輳および送信機のオーバーロードが生じる。例えば、ＭＢＭＳネットワークにおいてあり得る場合のように、数千のユーザーを考慮した場合、この状況は危機的である。
【発明の開示】
【００１３】
本発明の実施形態は、ブロードキャスト／マルチキャスト（１対多の）セッションの拡張可能かつ効率的な修復を提供する。
【００１４】
本発明の第１の側面によれば、１対多の送信ができるシステムにおけるデータ修復方法であって、
送信機から少なくとも１つの受信機にデータを送信するステップと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するステップとを含む、データ修復方法を提供する。
【００１５】
「１対多の送信」という用語は、本出願の文脈において、少なくとも１つの送信機から１つ以上の受信機へのあらゆる送信を意味するものとみなされる。したがって、本願明細書における「１対多」という用語は、「１対複数」を意味すると解釈することができる。「喪失データ」という用語は、誤って受信したデータに加えて、受信機で全く受信されなかったデータを意味するものとみなされる。
【００１６】
本発明の第２の側面によれば、１対多の送信ができるシステムにおけるデータ修復のための受信機であって、
送信機によって送信されるデータを受信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するための手段とを含む、受信機を提供する。
【００１７】
本発明の第３の側面によれば、１対多の送信ができるシステムにおけるデータ修復のための送信機であって、
少なくとも１つの受信機にデータを送信する手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するための手段とを含む、送信機を提供する。
【００１８】
本発明の第４の側面によれば、送信機、ネットワーク、および少なくとも１つの受信機を備えた、１対多の送信ができるシステムであって、
前記ネットワークを経て前記送信機から前記少なくとも１つの受信機にデータを送信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するための手段を含む、システムを提供する。
【００１９】
本発明の第５の側面によれば、１対多の送信ができるシステムでのデータ修復のための、受信機において実行可能なソフトウェアアプリケーションであって、
前記受信機に送信機によって送信されたデータを受信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーションを提供する。
【００２０】
本発明の第６の側面によれば、１対多の送信ができるシステムでのデータ修復のための、送信機において実行可能なソフトウェアアプリケーションであって、
前記送信機を少なくとも１つの受信機にデータを送信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーションを提供する。
【００２１】
前記ソフトウェアアプリケーションは、プログラムコードを含み、メモリのような媒体に保存されるコンピュータプログラム製品であってよい。
【００２２】
従属請求項は、本発明の実施形態に関する。本発明の特定の側面に関する従属請求項に含まれる内容は、本発明の他の側面にも適用可能である。
【発明を実施するための最良の形態】
【００２３】
以下、添付図面を参照して本発明の実施形態について一例として説明する。本特許出願書の導入部に含まれる内容は、詳細な説明を支援するために使用することが可能である。以下、一方向トランスポート上のファイル配信（ＦＬＵＴＥ）プロトコルは、本発明がＦＬＵＴＥのみを対象とすることに限定せず、一例として使用される。１対多のマルチキャストまたはブロードキャストファイル配信ができる、あらゆる他の好適なプロトコルも、本願明細書に適用可能である。
【００２４】
２００３年１２月２４日に出願された米国特許、名称「ＡＮ  ＡＰＰＡＲＡＴＵＳ，ＳＹＳＴＥＭ，ＭＥＴＨＯＤ  ＡＮＤ  ＣＯＭＰＵＴＥＲ  ＰＲＯＧＲＡＭ  ＰＲＯＤＵＣＴ  ＦＯＲ  ＲＥＬＩＡＢＬＥ  ＭＵＬＴＩＣＡＳＴ  ＴＲＡＮＳＰＯＲＴ  ＯＦ  ＤＡＴＡ  ＰＡＣＫＥＴＳ」（シリアル番号ＸＸ／ＸＸＸ，ＸＸＸ）は、本出願と同じ譲受人であり、データパケットの高信頼性マルチキャスト送信のための方法を提起している。その出願の内容は、参照することにより完全に本願明細書に組み込まれる。
【００２５】
２００４年２月１３日に出願された米国特許、名称「ＩＤＥＮＴＩＦＩＣＡＴＩＯＮ  ＡＮＤ  ＲＥ−ＴＲＡＮＳＭＩＳＳＩＯＮ  ＯＦ  ＭＩＳＳＩＮＧ  ＰＡＲＴＳ」（シリアル番号ＸＸ／ＸＸＸ，ＸＸＸ）は、本出願と同じ譲受人であり、１対多の送信ができるシステムにおける喪失データの識別および再送信方法を提起している。その出願の内容も、参照することにより完全に本願明細書に組み込まれる。
【００２６】
図１Ａは、本発明の実施形態による、１対多のデータ伝送のシナリオを示す。送信機１０は、マルチキャストデータブロック（またはパケット）を１対多の形態で受信機２０に送信するための、サーバー、ＩＰベースの機器、ＤＶＢ機器、ＧＰＲＳ（またはＵＭＴＳ）機器、またはＡＬＣ機構および／またはＦＥＣ機構のようなプロアクティブ前進型誤信号訂正を使用することが可能な類似した機器である。各受信機器２０は、喪失ブロック（受信されていないか、または誤って受信されたブロック）に関する不許諾応答（ＮＡＣＫ）メッセージ（または要求）を送信機１０に送信する。ＮＡＣＫメッセージに応答して、送信機１０は、ＦＬＵＴＥセッション（元の送信またはその後のＦＬＵＴＥセッションのために構築された元のＦＬＵＴＥセッションと同じセッション）において、通常、喪失ブロックを受信機２０に再送信する。代わりに、ＦＬＵＴＥ以外の別のプロトコルを使用したセッションを使用してもよい。本出願の文脈において、再送信セッションを修復セッションと呼ぶ。
【００２７】
データは、オブジェクトとして送信機１０から受信機２０に転送される。例えば、ファイル、ＪＰＥＧ画像、ファイルスライスは、全てオブジェクトである。セッションは、ファイル（またはデータ）配信のために、送信機１０と受信機２０との間に構築される。単一のセッションは、単一のオブジェクトまたは複数のオブジェクトの送信を含むことが可能である。オブジェクトおよびセッションを識別するために異なる識別子が使用される。
【００２８】
各データブロックは、ソースブロック番号（ＳＢＮ）と呼ばれる番号、または類似の各ブロックを識別する番号を有する。ブロックは、一連の符号化シンボルによって表される。同様に、符号化シンボル識別子（ＥＳＩ）または類似のものは、データパケット（またはブロック）のペイロードにおいて搬送された符号化シンボルが、上述のオブジェクト（例、ファイル）からどのように生成されたのかを示す。
【００２９】
図１Ｂは、本発明の実施形態による、異なる喪失データ修復方法を示す。喪失データの修復は、送信機１０と受信機２０との間に構築されたポイントツーポイント修復セッションを使用するか、または送信機１０と複数の受信機２０との間のポイントツーマルチポイントセッションを使用することによって実行することができる。修復セッションにおいて、喪失データの全体または一部（場合による）は、送信機１０から受信機２０に再送信されるか、または全ての送信を繰り返すことができる。修復は、元の送信機１０により、または「第三者サーバー」または元のサーバーとの接続を有する修復サーバー（または、単に独立したサーバー（図示せず））により行われ、送信データや情報をバッファリングするように構成される。このサーバーは、例えば、元の送信機（例えば、ＭＢＭＳ（マルチメディアブロードキャスト／マルチキャストサービス）サーバー、またはＢＭ−ＳＣ（ブロードキャストマルチキャスト−サービスセンター）とも呼ばれる）と同じ位置に配置されるか、または、例えば、ＵＭＴＳオペレータのネットワーク内の独立したサーバーとすることが可能である。
【００３０】
通常、本発明の実施形態において、ＦＬＵＴＥ、または好適な下層のプロトコルを有するＨＴＴＰ、ＳＭＳ、ＦＴＰ、ＳＡＰ、ＧＰＲＳなどのＦＬＵＴＥ以外の方法による独立した修復セッションを、喪失データの修復に使用することができる。
【００３１】
図２Ａは、本発明の実施形態による、簡略化したプロトコルアーキテクチャを示す。この実施形態によれば、送信機１０および受信機２０に対して実行されるプロトコルスタックは、アプリケーション層、ＦＬＵＴＥプロトコル層、ＵＤＰおよびＩＰ層、および下位層を含む。ＦＬＵＴＥプロトコル層は、レイヤードコーディングトランスポート（ＬＣＴ）ビルディングブロック（図示せず）のＡＬＣプロトコルのインスタンス化の上に構築される。ＦＥＣビルディングブロック（図示せず）を使用することができる。ＮＡＣＫメッセージとともにＦＬＵＴＥプロトコル層は、送信機１０から受信機２０への信頼性の高いブロック送信の提供を意図するものである。このプロトコルアーキテクチャは、１対多の送信（１対多の「最初の送信」および修復セッションにおける１対多の再送信）に使用することができる。
【００３２】
別様には、一実施形態では、ＵＤＰ層（図２Ｂ参照）の代わりにＴＣＰ層を使用することができる。これは、１対１（すなわちポイントツーポイント）の再送信に対して、独立したポイントツーポイント修復セッション（ここではＴＣＰセッション）を使用する場合に適用する。
【００３３】
一般的に、高信頼性マルチキャストシステムには、受信機−サーバー制御を必要とすることと、マルチキャストのマルチパーティという性質により拡張性の問題を示すデータメッセージングを必要とするとことという、問題点が見られる。その問題点には以下の３つがある。
ａ）限られた無線帯域幅および起動リソース。多くの無線チャネルおよびそれが使用する無線帯域幅を起動させるための時間によって、多くの修復を一度に行うことができなくなる。
ｂ）限られたサーバー容量。「修正コンテンツ」データを提供するサーバーシステムは、ある程度の時間ウィンドウの範囲内での限られた数の要求（メッセージング）および関連するセッションコンテキストデータ、および限られた量の同時データ転送セッションの処理しかできない。
ｃ）限られたエンドツーエンドの帯域幅。システム全体における１つ以上のボトルネックに起因する。ここで、同時に修復を要求している全てのユーザーに提供可能なデータ転送率は、多くの場合、このサービスを提供するには不十分である。
【００３４】
したがって、これらのいずれかまたは全ての制限下において拡張性を増大させるための重要な要素は、メッセージングを好適な時間に配信するか、または該当する場合に全てのメッセージングを回避することである。
【００３５】
以下、マルチキャスト／ブロードキャストセッションの効率的な修復方法を提供する。この方法は、送信機の判断または受信機の判断に基づく。
【００３６】
以下の説明において、「送信機」は、データソースや、所与のマルチキャスト／ブロードキャストネットワークアーキテクチャにおいて追加される又は共用される他のデータソースを意味する。（このアーキテクチャの例として、３ＧＰＰ  ＴＳ  ２３．２４６  Ｒｅｌ．６、ｖ．６．１．０、Ｓｅｃ．７．１に定義されるアプリケーション付属エンティティ（Ａｐｐｌｉｃａｔｉｏｎ  Ａｄｊｕｎｃｔ  Ｅｎｔｉｔｙ）がある。）通常、「ＮＡＣＫ」（不許諾応答）という用語は、該してどちらも同じであるとして、「修復要求（Repair Request）と交換可能に使用される。しかし、これらの各々の方法は、信頼性の高い配信ではなくデータ収集などの目的が最も重要である実施形態における修復のための暗黙の要求を用いずに、ＮＡＣＫに使用することができる。また、誤ったデータおよび喪失データへのＮＡＣＫは、信頼性の高いマルチキャスト用としては、肯定的な確認応答スキームよりも、概して効率的な確認応答スキームであることにも留意されたい。しかし、これは、有用であれば、肯定的なＡＣＫスキームを有する上述の方法の使用を除外するものではない。
【００３７】
Ａ）送信機ドリブンの修復方法
方法Ａ１：
この方法によって、送信機は、（例えば、ＳＤＰなどのセッション記述プロトコルまたは他のいずれかの手段を使用する）セッションアナウンス中に、エラーレートパラメータ（例えばＳＤＵエラーレート）を受信機に送信する。（ビット、パケット、および他のデータユニットのインクリメントにおける他のエラーレートは、実施形態よっては好ましいかもしれない。）
【００３８】
受信機は、受信したパラメータを、エラーレート閾値として解釈するが、受信機は、この閾値を越えて、ポイントツーポイントセッションを使用して修復セッションを要求してはならない。送信機が、受信機の平均エラーレートの情報および／または誤ったデータを受信する受信機の平均割合の情報を有する場合、受信機のフィードバックの集中およびデータ修復を行うポイントツーポイント接続が多くなりすぎないようにしながら、閾値に基づいて、完全なデータの再送信を判断することができる。送信機が、受信機の平均エラーレートの情報および誤ったデータを受信する受信機の平均割合を知るための手段は、例えば、セル、地理的領域、または受信機毎の品質またはエラーレート（および／または受信機数）を送信機に知らせるネットワークメッセージによって与えられる。
【００３９】
上述の一つの例は以下の通りである。
送信機は、１０％のエラーレート閾値を送信するＳＤＰブロードキャスト／マルチキャストセッションの使用をアナウンスする。ブロードキャスト／マルチキャストセッションを開始し、受信機は、１０％以上のエラーレートでデータが受信されたことを見出す。次いで、ポイントツーポイントセッションを経た喪失パケットの再送信の要求を控える。送信機は、受信機の平均エラーレートが１０％以上であること、および／または誤ったデータを受信する受信機の平均割合が５０％以上であることを見出した場合、マルチキャスト／ブロードキャストにおいて完全なデータセッションを再送信するように判断することが可能である（ここでの１０％および５０％は例値である）。
【００４０】
別様には、送信機が、受信機の平均エラーレートおよび／または誤ったデータを受信する受信機の平均割合を見出し、送信機が、（例えば、受信機の平均エラーレートが高いために）データセッション全体を再送信する状況であると判断した場合、送信機は、次のことのために、セッションの終わりにポイントツーマルチポイント修復トークンの受信機への送信を決定することができる。そのこととは、セッションが、マルチキャスト／ブロードキャストの形態で、再送信される−または代わりに再送信「されない」−ことをアナウンスするためである（場合によっては、修復するファイルをリストにする（および／またはファイル内のデータのブロックをリストにする）形態で再送信等がされる。）これにより、受信機が、データ修復を実行するためのポイントツーポイント接続を開始しないようにする。修復トークンは、マルチキャスト／ブロードキャスト送信後の独立した「アナウンス」におけるＳＤＰを経ることを含む、ＩＳＯ  ＯＳＩプロトコルスタックの層１乃至７のいずれかにおいて、あらゆる通信プロトコルを使用して送信される。これはまた、マルチキャスト／ブロードキャスト送信内のＦＬＵＴＥファイル配信の最後の部分（例えば、パケットの一番最後）にも含めることができる。
【００４１】
方法Ａ２：
ＭＢＭＳに関して３ＧＰＰ  ＴＳ  ２３．２４６  Ｒｅｌ．６、ｖ．６．１．０の７．１項に記載されているように、ネットワークがオーバーロードにならないようにするために、送信機は、アップリンクトラフィックのランダムな時間分散を生成するために、アプリケーション付属エンティティ（Application Adjunct Entity；ＡＡＥ）のアドレス及びパラメータを、受信機へ、その活性化時に配信することができる。明細書では「多くのうちの１つ」と述べているが、「複数のうちの１つ以上」を意味するとも理解できることに留意されたい。
【００４２】
方法Ａ２は、送信機が、活性化時（ジョイン（join））においてではなく、セッションアナウンス時間（ＳＤＰまたは他の好適な手段を経て）においてこの情報を送信するという事実に依拠する。したがって、この方法は、セッションアナウンス中に受信機に配信される次の２つのパラメータを定義する。
・ＡＡＥアドレスまたは類似のもの（パラメータの名前は例示的なものである）
・ランダム時間。
【００４３】
このランダム時間は、例えば、送信機が受信機の位置に関する情報を有するということに基づいて計算することができる。例えば、送信機が、受信機は携帯電話ネットワーク（例、ＧＰＲＳまたはＵＭＴＳ）の異なるネットワークセルに分布しているということを知っている場合、送信機は、同じセル内の全ての受信機が同時にポイントツーポイント修復を要求しないように、ランダムな時間を計算する（したがって、物理的な位置を考慮する）。その代わりとして、ポイントツーポイント接続のための要求が、異なるセルには異なる時間に配信されるようにする。送信機が受信機の位置に関する情報を持たない場合、受信機には、時間（物理的な位置を考慮しない）のみに基づいたランダム時間パラメータを配信する。ランダム時間パラメータは、ポイントツーポイント修復セッションの開始時間を示す。
【００４４】
従来技術（３ＧＰＰ  ＴＳ  ２３．２４６  ｖ．６．１．０）の拡張および上述の方法は、単なる「ランダム時間」というよりは「ＮＡＣＫ抑制パラメータセット」を提供するためのものである。この１つの事例は、アルゴリズム
“NACK- alg-3,
fast-window = 500 seconds; uniform, slow-window=5OOO seconds; normal, error_threshold_for_slow_window”
を実行するためのものである。このアルゴリズムは、ＮＡＣＫ抑制のための２つの時間ウィンドウの使用−およびそれぞれが与えられる時間および統計的な配信パラメータ−、およびその２つの時間ウィンドウの使用を選択するための入力パラメータを定義する（この種のＮＡＣＫ抑制スキームの詳細な説明は、以下の方法Ａ４およびＡ５に関連して与えられる）。
【００４５】
方法Ａ３：
本発明の別の実施例において、送信機は、ある数のＮＡＣＫ要求を受信機から受信した後に、それ自体の閾値に基づいて、ポイントツーポイント接続を閉じること、およびマルチキャスト／ブロードキャストにおいてセッション全体（またはその一部）を再送信することを決定する。これは、送信機が、受信機の行った再送信要求が多すぎて（すなわち、エラーレートがより高い）、ポイントツーポイント接続を使用したネットワークリソースの消費を回避した方がよいと解釈した場合に生じる。閾値は、例えば、１セッションに対して４つの異なる受信機ＮＡＣＫというように、静的に構成されるか、または、動的に計算されることができる（例えば、１つのフットボールビデオのサービスに対して３秒以内に２つのＮＡＣＫが異なる受信機から送信されたので、１０分以内に５０００個のＮＡＣＫが予想されることが予想されるなどのような、過去のデータから推測され得る。）送信機がポイントツーポイント修復データの配信を閉じることを選択し、ポイントツーマルチポイントを使用して、直ちにではないがデータを再配信する場合、ある実施形態では、修復セッションを将来行う受信機への送信機信号を有し、それによって、喪失データについてまだＮＡＣＫしていない受信機に、ＮＡＣＫする必要がないことを知らせる。さらに、この受信機へのシグナリングは、どのデータのフラグメントが送信されるのかを正確に示すことが可能であり、したがって、受信機は、それらのコンテンツを完成させる程度、およびその後の（ポイントツーポイント）修復の必要性−を構築することが可能になる。これによって、ポイントツーマルチポイントおよびポイントツーポイントの組み合わせが可能になる。
【００４６】
図５は、後においてＰ−ｔ−Ｍ（ポイントツーマルチポイント）修復を指示するために修復トークン（Ｒｅｐａｉｒ  Ｔｏｋｅｎ）を使用し、続いてＰ−ｔ−Ｍ修復データからの喪失したトークンに対してＰ−ｔ−Ｐ（ポイントツーポイント）を使用する実施形態を示す。修復トークンは、送信機（Ｙ）および修復送信機（Ｚ）それぞれから生じた場合にＰ−ｔ−ＭまたはＰ−ｔ−Ｐとすることが可能である。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ意思決定者（Ｘ）は、異なったエンティティ、または送信機（Ｙ）または修復送信機（Ｚ）と組み合わせたものとすることが可能である。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ決定主体（Ｘ）は、単一のまたは独立した論理および／または物理的機器として組み入れることが可能である第３のエンティティとすることが可能である。図５（および他の図）の修復送信機は、修復サーバーまたは類似のものと理解することができる。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ意思決定者（または意思決定ユニット）は、同様に修復判断ユニットと呼ばれる場合もある。
【００４７】
方法Ａ４：
方法Ａ１にて述べたように、受信機は、閾値に達した場合、再送信を要求すべきではない（ＮＡＣＫを送信すべきでない）。
別の実施形態では、次のようにして、受信機のコンテキストを変更する。
ａ）ＮＡＣＫ抑制アルゴリズムまたはそのパラメータの変更、および／または
ｂ）動作モードの変更
【００４８】
上述の「ＮＡＣＫすべきではない」（または、ＮＡＣＫしてはならない）は、ＮＡＣＫ抑制アルゴリズムの変更の極端な場合を示すものである。別の手段は、次のように動作を変更するものである。
エラーレートが閾値以下であれば、
「期間ＸにわたってＮＡＣＫを均等にランダム化し、最初の配信セッションの最後から開始する」か、あるいは、
「最初のセッションが終了した後にある時間Ｙが経過するまで待ち、次いで期間ＺにわたってＮＡＣＫをランダム化しなければならない」
【００４９】
Ｘ、Ｙ、Ｚは、異なる値、または等しい値となるように選択することができる。これは、認識されたユーザーのＱｏＳを最大にするために、「迅速な修復プラス遅い修復」を可能にすることに特に有用である。最初の配信において多くのエラーを受けた受信機のユーザーは、いずれにしてもＱｏＳが悪い可能性がある。ユーザーが、配信直後にそのコンテンツの消費を望む場合は、いずれにしても潜在的に長い修復セッションを待つことになる。しかし、ほとんどエラーを受けなかったユーザーは、上に述べたように、「修復リソース」における優先権が与えられるので、最初のセッションの後にそのコンテンツを迅速に消費できなければならない。したがって、この方法によって、不十分な最初の配信であっても完了することが可能になり、一方で、良好なＱｏＳであるとユーザーに認識されるレベルでの修復による良好な最初の配信を確保する。
【００５０】
上述の一般化は、一連のエラーレート［ＥＲ１、ＥＲ２、…、ＥＲｎ］、一連のＮＡＣＫのランダム化［Ｘ１、Ｘ２、…、Ｘｎ］、一連の待ち時間［Ｙ１、Ｙ２、…、Ｙｎ］、および一連のＮＡＣＫのランダム化［Ｚ１、Ｚ２、…、Ｚｎ］を使用する方法である。ここで、ｋ＝１、…、ｎ、Ｎ＋のｎ、４組のタプル（ＥＲｋ、Ｘｋ、Ｙｋ、Ｚｋ）のそれぞれは、ＥＲｋ未満のエラーレートに対して、受信機は期間ＸｋにわたってＮＡＣＫを均等にランダム化しなければならないこと、ＥＲｋ以上のエラーレートに対して、受信機は最初のセッションの終了後にある時間Ｙｋが経過するまで待ち、次いで期間ＺｋにわたってＮＡＣＫをランダム化しなければならないことを示す。一連の待ち時間は、ゼロ値アレイとしてよい。
【００５１】
いくつかのＮＡＣＫ抑制スキームでは、複数の役割を受信機およびホストに割り当てる。例えば、フラグ保持者スキームは、フラグ保持者がすでにＮＡＣＫを受けたと認識していなければ、エラーに直ちに応答し、他の受信機は（ランダムに）ＮＡＣＫを行うと予想する（グループメンバーシップをレポートするためのＩＭＧＰに類似）。本発明のある実施形態は、受信機の動作モードを変更するものである。例えば、閾値を超えた（あるいは閾値に達しなかった）場合、受信機は別の役割を採用することになる。フラグ保持者の例において、非常に低い閾値にある受信機（例えば、エラーが１つしかない）は、直ちに、または非常に短い時間ウィンドウの範囲でＮＡＣＫを行い、他の受信機は後でＮＡＣＫを行う。
【００５２】
組み合わせたある実施形態では、ある役割（例、「低エラーモード」または「高エラーモード」）が、ＮＡＣＫのオペレーションを定義し、その閾値が、使用されるモードの計算に使用されるように、「受信機の役割」をＮＡＣＫ抑制アルゴリズム／パラメータと関連づける。これは、複数の連続した測定の後にモードを変更することが可能となるように、これらの種類の判断プロセスを有するヒステリシスも含む際に好都合となり得る。例えば、受信機が１００の測定の位置の１つだけ閾値を超えた場合は、モードを変更できない場合がある。
【００５３】
図６は、バックオフ時間の分布を示す。図７は、閾値１以下のエラーレートとなる全て受信機（すなわち、受信機１および２）に対して、セッションの開始後６０秒にわたって要求が配信されたことを示す。閾値１より高いが閾値２よりも低いエラーレートとなる受信機（すなわち、受信機３、５、および８）に対して、要求は、６０秒後に送信され、１２０秒にわたって配信される。
【００５４】
方法Ａ５：
方法Ａ１に述べられているように、エラーレートの閾値を使用することが可能である。別の実施形態ではこれを提供し、また、閾値を計算するための時間および／またはデータ時間ウィンドウも提供する。例えば、
“10% packet
error rate; any, 30 seconds window, sliding”
は、閾値が最後の３０秒以内のパケットの１０％（喪失またはエラーを含む）であり、最後の３０秒からスライディング時間ウィンドウによって連続的に（または擬似連続的に）サンプリングするためのものであることを示すことができる。別の例では、
“5% bit error
rate, any, 2Kbyte window, blocked”
は、閾値が、複数の（任意の）２ＫＢブロックに対して５％のビットが誤りとなるようにされ、０−２ＫＢ、２−４ＫＢ、４−６ＫＢなどはサンプリングされたブロックである。当該基準に一致するあらゆるデータは、実施形態であるが、大量のデータ転送では、「セッション内でこの基準が３回満たされたならば、閾値に達したとみなす」などの代わりとして、第２のレベルの閾値を用いることが好都合となり得る。
【００５５】
図８は、閾値の計算のための時間ウィンドウの効果を示す。
【００５６】
方法Ａ６：
いくつかの実施形態は、予め設定することによって、サーバーと受信機との間でやり取りされるパラメータを共有および配信することが可能である。例えば、ＳＩＭを発行し、マルチキャストシステムを制御するオペレータによる、ＳＩＭカードへの保存が挙げられる。別の例には、予め設定された既知のパラメータを有するものが挙げられ、通常、当該既知の数値は、規格で規定されているか、または番号レジストリ機構（ＩＡＮＡなど）によって維持される。一実施形態では、そのパラメータを配信するための別の方法も提供されていれば、これらのパラメータのデフォルト値は、予め設定され、特定のセッションに対して破棄（上書き）される。
【００５７】
方法Ａ７：
本発明の更なる実施例では、極めて大量のコンテンツデータに対して受信機から修復要求を受信した後に、「これを後で修復する」ことを受信機に示す送信機を有することになる。その後の修復セッションは、ポイントツーポイントまたはポイントツーマルチポイントセッションであってよい。したがって、システムの帯域幅が拡張可能性要因を支配的に制限している場合、これによって、送信機は、まず迅速に満たされる受信機を処理し、その際、受信機の目標数（例、９９％）が完全な（エラーフリーの）データを有するようにするための平均時間を減じる。例えば、修復は、（最多数の受信機に対して）最初にポイントツーマルチポイント修復によって開始し、続いて（少数の受信機に対して）ポイントツーポイント修復によって行うことが可能である。
【００５８】
方法Ａ８：
上述したものでは、修復セッションおよびシグナリングのための開始ポイントとして、一般にセッションの最後を使用した。しかし、いくつかの実施形態では、オブジェクト（例、ファイルまたはシーン）の最後、閾値（例、１ＭＢ毎、１０００パケット毎、または５分毎）、またはセッショングループ（例、これら４つ全ての最後が関連するセッション）が、好都合となり得る。
【００５９】
図９は、オブジェクトの最後を検出した後の修復セッションの開始を示す。
【００６０】
Ｂ）受信機ドリブンの修復方法
通常、受信機は、ある程度の時間のデータ修復のためのポイントツーポイント接続の確立の要求を遅延させることができ、この要求が、マルチキャスト／ブロードキャストセッション終了直後に実行されないようにすることができる。これは、多数の受信機が、同時に修復するためのポイントツーポイント接続の要求を送信することによって、ネットワークおよび送信機が輻輳しないようにする。以下のいくつかの遅延方法では、ポイントツーポイント修復要求が与えられる。
【００６１】
方法Ｂ１：
修復は、遅延修復とすることができる。この場合、ユーザーがデータの消費を望む場合（例えば、ユーザーがビデオクリップの再生を望む場合、マルチキャスト／ブロードキャストセッション中にダウンロードされる）、受信機は、ポイントツーポイント修復要求を実行する。これは、ユーザーは、完全なポイントツーポイント修復の実行にかかる時間だけ待たなければならない（すなわち、データ実現のためのユーザーの待ち時間が増加する）。この方法はまた、送信機が、セッションアナウンス（ＳＤＰまたは他の好適な手段を使用）において、修復に利用できる最長時間、すなわち、送信機がうまくポイントツーポイント修復を実行できるまでの制限時間も任意で必要とする。この時間ユニットのフォーマットは規定されていないが、様々な方法（制限されないが、例えば、絶対時間または相対時間）で表すことができる。修復に利用できる最長時間が経過した後は、ポイントツーポイント修復オペレーションの成功は確保されない。これは、送信機に対して、データ修復を実行するために、保存したデータを保持するための制限時間を与える。ポイントツーポイント修復が、（ユーザーがデータ再生を未だ要求していないため）修復に利用できる最長時間までに実行しなかった場合、受信機は、その時、ポイントツーポイント修復を実行させられる。受信機がオフになり、修復に利用できる最長時間が経過した場合、連続する時間でのポイントツーポイント修復は保証されない。場合によっては、最終的に「安全マージン」が確保されるように、ＮＡＣＫがランダム化される期間を減じることが好都合である。例えば、期間が４３２０００秒である場合、ＮＡＣＫは概して４０００００秒にわたって配信され、「停止している」受信機に、保証された修復時間を失うことなくオンにするための時間を最大３２０００秒与える。
【００６２】
上述の例を以下に述べる。
送信機が、修復に利用できる最長時間が２００４年３月１５日までであるというアナウンスを送信する場合は、受信機が指定された日時まで修復を実行できることを意味する。その日時以降は、修復オペレーションは保証されない。別の方法では、マルチキャスト／ブロードキャスト送信からの相対的な時間としての時間を表すことができる。例えば、送信機は、修復に利用できる最長時間が４３２０００秒であることを受信機にシグナリングすることが可能である。これは、ポイントツーポイント修復を行うために利用可能な期間は、マルチキャスト／ブロードキャスト送信から５日間であることを受信機に知らせる。
【００６３】
図１０は、遅延修復の実施形態を示す。
【００６４】
方法Ｂ２：
修復は、「遅延してもよい再生修復」とすることができる。この場合、受信機は、ユーザーがデータの消費を望む場合に、ポイントツーポイント修復要求を実行する。さらに、修復は、データストリームにおける第１の喪失の位置を考慮する。ストリームが、音声、またはオーディオおよびビデオストリームである場合、受信機は、いつメディアユニットに第１のデータ損失が生じるのかを正確に計算することができる。ポイントツーポイント修復は、次いで、最良の状態でデータストリームの再生を開始した後であっても開始を延期することができるが、受信機の再生が連続的な中断を受けないような方法で十分早期に実行および計算されなければならない。
【００６５】
（ポイントツーポイント修復オペレーションは、第１の喪失ブロックに対する時間よりも長い時間を必要とするので、）ポイントツーポイント修復が、再生と並行して行えない場合、ポイントツーポイント修復は、ユーザーが再生要求を発行すれば直ちに開始することができるが、実際の再生は、再生を中断させないために必要な時間、遅延させられる。このスキームは、上述の第１のスキーム（方法Ｂ１）に非常に似ているが、修復オペレーションおよび再生が一時的かつ部分的にオーバーラップするので、ユーザーの待ち時間が少なくなる。
【００６６】
また、この場合、修復に利用できる最長時間の情報は、任意で必要とされる場合があり、第１の場合（方法Ｂ１）のように受信機によって使用される場合がある。
【００６７】
ポイントツーポイント修復の実行に必要な時間は、測定または与えられた帯域幅のポイントツーポイント接続、ポイントツーポイントチャネルにわたって測定したラウンドトリップ時間、およびポイントツーポイントセッションの確立および終了遅延のような要素に基づいて、受信機が推定することができる。
【００６８】
上述の例を以下に述べる。
送信機が、５分のオーディオ／ビデオクリップを送信し、受信機が時間４’で最初に生じる３０の喪失パケットがあることを検出した場合、ユーザーは、直ちにストリームの再生を開始することができ、受信機は、３０の喪失パケット全てが再生の４分前に到着するように、ユーザーが十分早く再生することと並行してポイントツーポイント修復オペレーションを開始する。３０の喪失ブロックが、時間１’で第１の喪失ブロックが生じ、受信機が、ポイントツーポイント修復セッションは１分以上かかると推定するような場合、修復セッションが開始され、再生は、再生を中断させないために必要な時間分、遅延される。
【００６９】
図１１は、遅延再生修復の一つの実施形態を示す。
【００７０】
方法Ｂ３：
別の場合（方法Ａ７の受信機ドリブンのアプリケーションに類似）では、ＮＡＣＫ抑制が、多数の誤ったデータおよび喪失データを、回復時間を計算するための乗数として使用する。例えば、送信機が、「時間のユニット」を６０秒と示し、喪失データが１０パケットであると示している場合、５６の喪失パケットを有する受信機は、ＩＮＴ（５６／１０）×６０＝３００秒と、時間を計算することになる。これらの結果の時間は、オフセット（最初のセッションが終了して長い秒数経過する前にＮＡＣＫを開始しない）として、および／またはＮＡＣＫを配信する期間（例えば、この時間を通じて自分のＮＡＣＫが均等にランダム化される）として使用することが可能である。
【００７１】
方法Ｂ４：
本発明の更なる実施形態は、最初のマルチキャスト／ブロードキャストが終了する前にポイントツーポイント修復セッションを開始する可能性である。この方法では、修復がより早くなり、ユーザーは、待ち時間のより短いエラーフリーの「再生」セッションを開始することができる。正確な修復開始時間は、受信機によって決定するか、またはデータストリームおよび／またはファイル長の範囲内の第１のエラーの位置の機能とすることができる。
【００７２】
図１２は、「早期発見」によって開始される修復の実施形態を示す。
【００７３】
上述の全ての方法はまた、あらゆる可能かつ機能的に好適な組み合わせにおいて使用することもできる。
【００７４】
図３は、本発明の実施形態による、システムおよび受信機２０の詳細を示す。該システムは、送信機１０、ＩＰネットワークまたは他の固定ネットワークなどの伝送ネットワーク３０、無線ネットワークまたは固定および無線（携帯電話）ネットワークなどを組み合わせたもの、および受信機２０を備える。受信機２０は、移動電話、衛星電話、携帯情報端末、またはＢｌｕｅｔｏｏｔｈ機器、ＷＬＡＮ機器、ＤＶＢ機器、または他の類似した無線機器とすることができる。機器２０は、内部メモリ２１、プロセッサ２２、オペレーティングシステム２３、アプリケーションプログラム２４、ネットワークインターフェース２５、およびＮＡＣＫおよび修復機構２６を含む。内部のメモリ２１は、プロセッサ２２、オペレーティングシステム２３、およびアプリケーションプログラム２４に対応する。ＮＡＣＫおよび修復機構２６によって、データ伝送において喪失または壊れたデータに応答した、ＮＡＣＫおよび修復プロシージャが可能になる。機器２０は、ネットワークインターフェース２５およびネットワーク３０を経て、送信機１０および他の機器と通信することができる。
【００７５】
図４は、本発明の実施形態による、送信機１０を示す。送信機１０は、例えば、ネットワークサーバーまたはファイル（またはメディア）の配信を対象としたあらゆる好適な機器とすることができる。機器１０は、内部メモリ１１、プロセッサ１２、オペレーティングシステム１３、アプリケーションプログラム１４、ネットワークインターフェース１５、送信および修復機構１６、およびデータストレージ１７を含む。内部メモリ１１は、プロセッサ１２、オペレーティングシステム１３、およびアプリケーションプログラム１４に対応する。送信および修復機構１６によって、受信機２０へのデータパケットの送信が可能になる。さらに、修復セッションにおけるデータパケットの再送信が可能になる。受信機２０に送信されるデータおよび再送信されるデータは、データストレージ１７に保存することができる。別様には、データは、送信機１０と同じ位置または外部に配置される独立した機器に保存することができる。機器１０は、ネットワークインターフェース１５およびネットワーク３０を経て、送信機２０および他の機器と通信することができる。
【００７６】
喪失データの修復に関するプロシージャは、ソフトウェアによって実行することができる。受信機２０に保存され、プロセッサ２２において実行されるプログラムコードを有するコンピュータプログラム製品は、送信セッションの受信終了時にプロシージャを実行するために使用することができ、一方で、受信機１０に保存され、プロセッサ１２において実行されるプログラムコードを有するコンピュータプログラム製品は、送信終了時にプロシージャを実行するために使用することができる。
【００７７】
本発明の実施形態を、論理的な送信機／サーバーエンティティおよび受信機ユニットの例とともに示した。修復要求間、および修復応答間（適切な場合）に進行する第３のエンティティの使用もまた、本発明の実施形態の範囲に含まれる。当該のエンティティは、例えば、修復トークンを配信するよう要求しているポイントツーマルチポイント送信機に対して修復送信機メッセージを許可するために、または、受信機から送信機へのメッセージのための修復要求アグリゲータ／プロキシとして機能し、したがって、第３の機器における透過的なポイントツーポイントおよびポイントツーマルチポイント判断を可能にするように、ファイアウォール、プロキシ、および／または許可サービスを提供することが可能である。
【００７８】
修復トークンのポイントツーマルチポイント配信の使用は、上述したとおりである。加えて、ポイントツーポイント修復トークンの使用は、いくつかの実施形態において好都合となり、本発明の実施形態の範囲に含むことが可能である（ポイントツーマルチポイント修復に関して示されたことに対応する配信／フォーマットの方法を使用できる、例、ＳＤＰ）。当該スキームは、ポイントツーポイント要求がポイントツーマルチポイントによって送信するように決定した後に到着した場合、ポイントツーマルチポイント修復／再送信データが「途中」であることを受信機に知らせるか、または代わりに、受信機が、節電のために一時的にマルチポイント受信を停止させるが、依然としてこの次のポイントツーマルチポイント修復＿応答／再送信を知ることができるようにすることが可能である。
【００７９】
本発明の実施形態によって、拡張可能な信頼性の高いマルチキャストを提供するＮＡＣＫ抑制が可能となる。マルチキャスト／ブロードキャスト送信のための効率的かつ拡張可能なポイントツーポイント修復が提供され、フィードバックの集中およびネットワーク／送信機のオーバーロードを回避する。
【００８０】
本発明の特定の実現例および実施形態を説明した。本発明が、上述の実施形態の詳細に制限されないことは、当業者には明らかである。さらに、当業者は、本発明に組み込める多数の追加的な方法があり、実施例の限られた部分のうちの１つに示されていないが、それらの方法は本発明の範囲内であるということを認識している。特に、本発明は、あらゆるプロトコル、パラメータ、またはメッセージのいずれの特定の名前にも制限されるべきではない。本発明は、本発明の特性から逸脱せずに、同等の手段を使用して他の実施形態において実施することができる。本発明の範囲は、添付された特許請求の範囲によってのみ制限される。
【図面の簡単な説明】
【００８１】
【図１】図１Ａは本発明の実施形態による１対多のデータ伝送のシナリオを示し、図１Ｂは本発明の実施形態による異なる喪失データ修復方法を示す。
【図２】図２Ａは本発明の実施形態による簡略化したプロトコルアーキテクチャを示し、図２Ｂは本発明の別の実施形態による簡略化したプロトコルアーキテクチャを示す。
【図３】本発明の実施形態による、システムおよび受信機の詳細を示す。
【図４】本発明の実施形態による、送信機を示す。
【図５】本発明の種々の実施形態を示す。
【図６】本発明の種々の実施形態を示す。
【図７】本発明の種々の実施形態を示す。
【図８】本発明の種々の実施形態を示す。
【図９】本発明の種々の実施形態を示す。
【図１０】本発明の種々の実施形態を示す。
【図１１】本発明の種々の実施形態を示す。
【図１２】本発明の種々の実施形態を示す。
【図１】
2007522750.tif 000003
【図２】
2007522750.tif 000004
【図３】
2007522750.tif 000005
【図４】
2007522750.tif 000006
【図５】
2007522750.tif 000007
【図６】
2007522750.tif 000008
【図７】
2007522750.tif 000009
【図９】
2007522750.tif 000010
【図１０】
2007522750.tif 000011
【図１１】
2007522750.tif 000012
【図１２】
2007522750.tif 000013
【図８】
2007522750.tif 000014
【国際調査報告】
2007522750.tif 000015
2007522750.tif 000016
2007522750.tif 000017