JP2007522750A5 - - Google Patents

Description

マルチキャストおよびブロードキャスト送信を処理できるシステムにおけるデータ修復方法

本発明は、概して、マルチキャストおよびブロードキャスト送信技術およびサービス、すなわち、少なくとも１つのデータソース（または送信機）および少なくとも１つの受信機を有するサービスに関する。

発明の背景

ＩＰマルチキャスト、ＩＰデータキャスティング（ＩＰＤＣ）、およびマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）などのシステムを通じた１対多（すなわち、ポイントツーマルチポイント）のサービスに関して、ファイル配信（または離散的メディア配信またはファイルダウンロード）は、重要なサービスである。ファイル転送プロトコル（ＦＴＰ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）などのポイントツーポイントプロトコルを通じたファイルを配信するための機能の多くは、１対多のシナリオに対する問題を含んでいる。特に、通信制御プロトコル（ＴＣＰ）などの類似した１対１（すなわち、ポイントツーポイント）の確認応答（ＡＣＫ）プロトコルを使用した、信頼性の高いファイル配信−すなわち、保証されたファイルの配信−は、実現可能ではない。

インターネット技術特別調査委員会（Internet Engineering Task Force；ＩＥＴＦ）の高信頼性マルチキャスト送信（Reliable Multicast Transport； ＲＭＴ）ワーキンググループは、エラー耐性マルチキャストトランスポートプロトコルの２つのカテゴリを標準化しようとしている。第１のカテゴリにおいては、（プロアクティブな）前進型誤信号訂正（Forward Error Correction； ＦＥＣ）を使用することによって、すなわち、誤ったデータの再構成のために受信機の役に立つある量の冗長データを送信することで、信頼性が実現される。第２のカテゴリにおいては、受信機のフィードバックは、高信頼性マルチキャスト送信を実現するために使用される。非同期階層符号化（Asynchronous Layered Coding; ALC, RFC3450）は、第１のカテゴリに属するプロトコルの例であり、ＮＡＣＫ指向高信頼性マルチキャスト（NACK-Oriented Reliable Multicast; NORM）プロトコルは、第２のカテゴリの一例を示す。ＡＬＣおよびＮＯＲＭプロトコルは、ＩＥＴＦのワーキンググループによって作成された、「Asynchronous Layered Coding(ALC)Protocol Instantiation」（IETF, RFC3450）および「NACK-Oriented Reliable Multicast Protocol」（インターネットドラフト）という名称の出版物に詳述されている。これらの出版物の内容は、その全体を参照して本願明細書に組み込まれる。

これらのプロトコルを使用できるアクセスネットワークには、限定するものではないが、ユニバーサルモバイルテレコミュニケーションサービス（ＵＭＴＳ）システム、無線ローカルエリアネットワーク（ＷＬＡＮ）、デジタルビデオ地上放送（ＤＶＢ−Ｔ）ネットワーク、およびデジタルビデオ衛星放送（ＤＶＢ−Ｓ）ネットワークなどの、無線マルチアクセスネットワークが挙げられる。

簡潔に述べると、ＡＬＣプロトコルは、壊れたパケットまたは受信されなかったパケットを受信機が再構築できる、プロアクティブＦＥＣベースのスキームである。ＡＬＣプロトコルは、複数のチャネル上でＦＥＣ符号化を使用し、送信機は、データを場合により異種の受信機に異なるレート（チャネル）で送信することができる。加えて、ＡＬＣプロトコルは、異なるチャネル上で異なるレートを維持するために輻輳制御機構を使用する。

ＡＬＣプロトコルはアップリンクシグナリングを必要としないので、複数のユーザーについて大規模に拡張可能である。したがって、追加される受信機の数が、必ずしもシステムへの要求を増加させない。しかし、ＡＬＣプロトコルは、受信が保証されていないので１００％の信頼性があるわけではなく、したがって、概して高信頼性というよりは堅牢であると説明される場合がある。

同様に、ＮＯＲＭは、受信機に到達すると予想されたデータ（または、「データブロック」と定義される）のうちのどのパケットが受信機で受信されなかったのか（または、誤って受信された）をシグナリングするために、不許諾応答（Negative Acknowledgement；ＮＡＣＫ）メッセージの使用を規定している。換言すれば、受信機は、送信されたパケットの喪失または破損を送信機に示すためにＮＡＣＫメッセージを用いる。したがって、データ伝送でいくつかのデータブロックを「喪失した」受信機は、喪失した１つまたは複数のデータブロックを再送信するよう送信機に要求するＮＡＣＫメッセージを送信することができる。ＮＯＲＭプロトコルはまた、任意で、能動的で堅牢な送信のためにパケットレベルのＦＥＣ符号化を使用することができる。

一方向トランスポート上のファイル配信（File Delivery over Unidirectioanl Transport；ＦＬＵＴＥ）は、ＦＥＣ（RFC3452）およびＡＬＣビルディングブロックに構築する、１対多のトランスポートプロトコルである。これは、一方向性システムを通じた送信機から受信機へのファイル配信を対象としたものである。無線ポイントツーマルチポイント（マルチキャスト／ブロードキャスト）システムに適応させるための特殊化を有する。ＦＬＵＴＥプロトコルの詳細は、上述のＩＦＴＦのワーキンググループによって作成された「FLUTE-File Delivery over Unidirectioanl Transport」（インターネットドラフト）という名称の出版物に詳述されている。この出版物の内容は、その全体を参照して本願明細書に組み込まれる。

一般に、ＮＡＣＫメッセージはＮＯＲＭ特有ではなく、そのメッセージはまた、ＦＬＵＴＥのような他のプロトコルまたはシステムに関連して使用することもできる。ＡＣＫは受信機が送信する応答メッセージであって、１つ以上のデータパケットを受信した後に、データパケットを適切に受信したという確認応答である。ＮＡＣＫは、受信機が、送信されるまたは送信されたと予想されるが、まだ受信されていないパケットに関して、送信機に送信する応答である。

マルチキャストまたはブロードキャスト環境にある場合、データ伝送は、１対多の形態で生じる。送信がエラーフリーでなく、異なる受信機が異なるエラーレートを受ける場合（例えば、ＭＢＭＳおいて、異なるセルのユーザーが異なる品質の信号を受け、その結果、異なるエラーレートを受ける場合）、データの信頼性の向上に問題が生じる。これは、ＦＥＣおよび／または修復セッションを使用することによって解決することができる。

ＦＥＣは、ある程度のエラー耐性によって受信機が送信データを再構成できるようにするために、送信データにある程度の冗長性を提供する。しかし、ＦＥＣの１つの問題は、ＦＥＣがエラーが全くないエラー回復能力を提供しないこと、または、完全なエラー回復能力を提供するがデータ冗長を多用し、チャネル帯域幅の要件を厳しくすることである。

（受信機と送信機との間の）修復セッションは、（残余のチャネルエラーレートを減じるべく又は取り除くべく）ＦＥＣを補うために用いるか、またはエラー回復に対する唯一の方法として単独で使用することができる。修復セッションは、独立したセッションを使用したポイントツーポイントチャネルを通じて開始することができる。この場合、マルチキャスト／ブロードキャスト送信中に一部のデータを喪失した全ての受信機は、喪失したパケットを再送信するよう送信機に要求するＮＡＣＫ要求を送信する。しかし、全ての受信機が少なくとも１つのデータパケットを喪失するような場合、全ての受信機が、送信機とのポイントツーポイント接続を一斉に構築することになり、フィードバックの集中が生じる。すなわち、ネットワーク内の（多数のＮＡＣＫに対するアップリンク、多数の同時再送信およびネットワーク接続要求に対するダウンリンクにおける）輻輳および送信機のオーバーロードが生じる。例えば、ＭＢＭＳネットワークにおいてあり得る場合のように、数千のユーザーを考慮した場合、この状況は危機的である。

本発明の実施形態は、ブロードキャスト／マルチキャスト（１対多の）セッションの拡張可能かつ効率的な修復を提供する。

本発明の第１の側面によれば、１対多の送信ができるシステムにおけるデータ修復方法であって、
送信機から少なくとも１つの受信機にデータを送信するステップと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するステップとを含む、データ修復方法を提供する。

「１対多の送信」という用語は、本出願の文脈において、少なくとも１つの送信機から１つ以上の受信機へのあらゆる送信を意味するものとみなされる。したがって、本願明細書における「１対多」という用語は、「１対複数」を意味すると解釈することができる。「喪失データ」という用語は、正しく受信されなかったデータに加えて、受信機で全く受信されなかったデータを意味するものとみなされる。

本発明の第２の側面によれば、１対多の送信ができるシステムにおけるデータ修復のための受信機であって、
送信機によって送信されるデータを受信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するための手段とを含む、受信機を提供する。

本発明の第３の側面によれば、１対多の送信ができるシステムにおけるデータ修復のための送信機であって、
少なくとも１つの受信機にデータを送信する手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するための手段とを含む、送信機を提供する。

本発明の第４の側面によれば、送信機、ネットワーク、および少なくとも１つの受信機を備えた、１対多の送信ができるシステムであって、
前記ネットワークを経て前記送信機から前記少なくとも１つの受信機にデータを送信するための手段と、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データの修復を提供するための手段を含む、システムを提供する。

本発明の第５の側面によれば、１対多の送信ができるシステムでのデータ修復のための、受信機において実行可能なソフトウェアアプリケーションであって、
前記受信機に送信機によって送信されたデータを受信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーションを提供する。

本発明の第６の側面によれば、１対多の送信ができるシステムでのデータ修復のための、送信機において実行可能なソフトウェアアプリケーションであって、
前記送信機を少なくとも１つの受信機にデータを送信させるためのプログラムコードと、
前記受信機で喪失したデータに関して、送信機ドリブンまたは受信機ドリブンによる喪失データを修復するためのプログラムコードとを含む、ソフトウェアアプリケーションを提供する。

前記ソフトウェアアプリケーションは、プログラムコードを含み、メモリのような媒体に保存されるコンピュータプログラム製品であってよい。

従属請求項は、本発明の実施形態に関する。本発明の特定の側面に関する従属請求項に含まれる内容は、本発明の他の側面にも適用可能である。

詳細な説明

以下、添付図面を参照して本発明の実施形態について一例として説明する。本特許出願書の導入部に含まれる内容は、詳細な説明を支援するために使用することが可能である。以下、一方向トランスポート上のファイル配信（ＦＬＵＴＥ）プロトコルは、本発明がＦＬＵＴＥのみを対象とすることに限定せず、一例として使用される。１対多のマルチキャストまたはブロードキャストファイル配信ができる、あらゆる他の好適なプロトコルも、本願明細書に適用可能である。

２００３年１２月２４日に出願された米国特許、名称「AN APPARATUS,SYSTEM,METHOD AND COMPUTER PROGRAM PRODUCT FOR RELIABLE MULTICAST TRANSPORT OF DATA PACKETS」（シリアル番号ＸＸ／ＸＸＸ，ＸＸＸ）の譲受人は、本出願と同じ者であり、データパケットの高信頼性マルチキャスト送信のための方法を提起している。その出願の内容は、参照することにより完全に本願明細書に組み込まれる。

２００４年２月１３日に出願された米国特許、名称「IDENTIFICATION AND RE-TRANSMISSION OF MISSING PARTS」（シリアル番号ＸＸ／ＸＸＸ，ＸＸＸ）の譲受人は、本出願と同じ者であり、１対多の送信ができるシステムにおける喪失データの識別および再送信方法を提起している。その出願の内容も、参照することにより完全に本願明細書に組み込まれる。

図１Ａは、本発明の実施形態による、１対多のデータ伝送のシナリオを示す。送信機１０は、マルチキャストデータブロック（またはパケット）を１対多の形態で受信機２０に送信するための、サーバー、ＩＰベースの機器、ＤＶＢ機器、ＧＰＲＳ（またはＵＭＴＳ）機器、またはＡＬＣ機構および／またはＦＥＣ機構のようなプロアクティブ前進型誤信号訂正を使用することが可能な類似した機器である。各受信機器２０は、喪失ブロック（受信されていないか、または誤って受信されたブロック）に関する不許諾応答（ＮＡＣＫ）メッセージ（または要求）を送信機１０に送信する。ＮＡＣＫメッセージに応答して、送信機１０は、ＦＬＵＴＥセッション（元の送信またはその後のＦＬＵＴＥセッションのために構築された元のＦＬＵＴＥセッションと同じセッション）において、通常、喪失ブロックを受信機２０に再送信する。代わりに、ＦＬＵＴＥ以外の別のプロトコルを使用したセッションを使用してもよい。本出願の文脈において、再送信セッションを修復セッションと呼ぶ。

データは、オブジェクトとして送信機１０から受信機２０に転送される。例えば、ファイル、ＪＰＥＧ画像、ファイルスライスは、全てオブジェクトである。セッションは、ファイル（またはデータ）配信のために、送信機１０と受信機２０との間に構築される。単一のセッションは、単一のオブジェクトまたは複数のオブジェクトの送信を含むことが可能である。オブジェクトおよびセッションを識別するために異なる識別子が使用される。

各データブロックは、ソースブロック番号（ＳＢＮ）と呼ばれる番号、または類似の各ブロックを識別する番号を有する。ブロックは、一連の符号化シンボルによって表される。同様に、符号化シンボル識別子（ＥＳＩ）または類似のものは、データパケット（またはブロック）のペイロードにおいて搬送された符号化シンボルが、上述のオブジェクト（例、ファイル）からどのように生成されたのかを示す。

図１Ｂは、本発明の実施形態による、いくつかの喪失データ修復方法を示す。喪失データの修復は、送信機１０と受信機２０との間に構築されたポイントツーポイント修復セッションを使用するか、または送信機１０と複数の受信機２０との間のポイントツーマルチポイントセッションを使用することによって実行することができる。修復セッションにおいて、喪失データの全体または一部（場合による）は、送信機１０から受信機２０に再送信されるか、または全ての送信を繰り返すことができる。修復は、元の送信機１０により、または「第三者サーバー」または元のサーバーとの接続を有する修復サーバー（または、単に独立したサーバー（図示せず））により行われる。修復サーバーは、送信データや情報をバッファリングするように構成される。このサーバーは、例えば、元の送信機（例えば、ＭＢＭＳ（マルチメディアブロードキャスト／マルチキャストサービス）サーバー、またはＢＭ−ＳＣ（ブロードキャストマルチキャスト−サービスセンター）とも呼ばれる）と同じ位置に配置されるか、または、例えば、ＵＭＴＳオペレータのネットワーク内の独立したサーバーとすることが可能である。

通常、本発明の実施形態において、ＦＬＵＴＥ、または好適な下層のプロトコルを有するＨＴＴＰ、ＳＭＳ、ＦＴＰ、ＳＡＰ、ＧＰＲＳなどのＦＬＵＴＥ以外のメソッドによる独立した修復セッションを、喪失データの修復に使用することができる。

図２Ａは、本発明の実施形態による、簡略化したプロトコルアーキテクチャを示す。この実施形態によれば、送信機１０および受信機２０に対して実行されるプロトコルスタックは、アプリケーション層、ＦＬＵＴＥプロトコル層、ＵＤＰおよびＩＰ層、および下位層を含む。ＦＬＵＴＥプロトコル層は、レイヤードコーディングトランスポート（ＬＣＴ）ビルディングブロック（図示せず）のＡＬＣプロトコルのインスタンス化の上に構築される。ＦＥＣビルディングブロック（図示せず）を使用することができる。ＮＡＣＫメッセージとともにＦＬＵＴＥプロトコル層は、送信機１０から受信機２０への信頼性の高いブロック送信の提供を意図するものである。このプロトコルアーキテクチャは、１対多の送信（１対多の「最初の送信」および修復セッションにおける１対多の再送信）に使用することができる。

別様には、一実施形態では、ＵＤＰ層（図２Ｂ参照）の代わりにＴＣＰ層を使用することができる。これは、１対１（すなわちポイントツーポイント）の再送信に対して、独立したポイントツーポイント修復セッション（ここではＴＣＰセッション）を使用する場合に適用する。

一般的に、高信頼性マルチキャストシステムには、受信機−サーバー制御を必要とすることと、マルチキャストのマルチパーティという性質により拡張性の問題を示すデータメッセージングを必要とするとことという、問題点が見られる。その問題点には以下の３つがある。
ａ）限られた無線帯域幅およびアクティブ化するためのリソース。多くの無線チャネルおよびそれが使用する無線帯域幅をアクティブにするための時間によって、多くの修復処理を一度に行うことができなくなる。
ｂ）限られたサーバー容量。「修正コンテンツ」データを提供するサーバーシステムは、ある程度の時間ウィンドウの範囲内での限られた数の要求（メッセージング）および関連するセッションコンテキストデータ、および限られた量の同時データ転送セッションの処理しかできない。
ｃ）限られたエンドツーエンドの帯域幅。システム全体における１つ以上のボトルネックに起因する。ここで、同時に修復を要求している全てのユーザーに提供可能なデータ転送率は、多くの場合、このサービスを提供するには不十分である。

したがって、これらのいずれかまたは全ての制限下において拡張性を増大させるための重要な要素は、メッセージのやり取りを好適な時間に分散させるか、または該当する場合に全てのメッセージのやり取りを停止することである。

以下、マルチキャスト／ブロードキャストセッションの効率的な修復方法をいくつか説明する。これらの方法は、送信機の判断または受信機の判断に基づく。

以下の説明において、「送信機」は、データソースや、所与のマルチキャスト／ブロードキャストネットワークアーキテクチャにおいて追加される又は共用される他のデータソースを意味する。（このアーキテクチャの例として、3GPP TS 23.246 Rel.6, v.6.1.0, Sec.7.1に定義されるアプリケーション付属エンティティ（Application Adjunct Entity）がある。）「ＮＡＣＫ」（不許諾応答）という用語は、概ねどちらも目的が同じであるので、「修復要求（Repair Request）と交換可能に使用される。しかし、これらの各方法は、信頼性の高い配信ではなくデータ収集などの目的が最も重要である場合においては、修復の暗黙の要求なしに、ＮＡＣＫを使用することができる。また、不正確なデータおよび喪失データへのＮＡＣＫは、信頼性の高いマルチキャスト用としては、肯定的な確認応答スキームよりも、概して効率的な確認応答スキームであることにも留意されたい。しかし、これは、有用であれば、肯定的なＡＣＫスキームを有する上述の方法の使用を除外するものではない。

Ａ）送信機ドリブンの修復方法

方法Ａ１：

この方法によって、送信機は、（例えば、ＳＤＰなどのセッション記述プロトコルまたは他のいずれかの手段を使用する）セッションアナウンス中に、エラーレートパラメータ（例えばＳＤＵエラーレート）を受信機に送信する。（実施形態よっては、ビットやパケットなど他のデータユニットのインクリメントによる別のエラーレートが好ましいかもしれない。）

受信機は、受信したパラメータを、エラーレート閾値として解釈するが、受信機は、この閾値を越えて、ポイントツーポイントセッションを使用して修復セッションを要求してはならない。送信機が、受信機の平均エラーレートの情報および／または誤ったデータを受信する受信機の平均割合の情報を有する場合、受信機のフィードバックの集中およびデータ修復を行うポイントツーポイント接続が多くなりすぎないようにしながら、閾値に基づいて、完全なデータの再送信を判断することができる。送信機が、受信機の平均エラーレートの情報および誤ったデータを受信する受信機の平均割合を知るための手段は、例えば、セル、地理的領域、または受信機毎の品質またはエラーレート（および／または受信機数）を送信機に知らせるネットワークメッセージによって与えられる。

上述の一つの例は以下の通りである。
送信機は、ＳＤＰを利用し、ブロードキャスト／マルチキャストセッションにて送信することにより、１０％のエラーレート閾値の使用をアナウンスする。ブロードキャスト／マルチキャストセッションを開始し、受信機は、１０％以上のエラーレートでデータが受信されたことを見出す。次いで、ポイントツーポイントセッションを経た喪失パケットの再送信の要求を控える。送信機は、受信機の平均エラーレートが１０％以上であること、および／または誤ったデータを受信する受信機の平均割合が５０％以上であることを見出した場合、マルチキャスト／ブロードキャストにおいて完全なデータセッションを再送信するように判断することが可能である（ここでの１０％および５０％は例値である）。

別様には、送信機が、受信機の平均エラーレートおよび／または誤ったデータを受信する受信機の平均割合を見出し、送信機が、（例えば、受信機の平均エラーレートが高いために）データセッション全体を再送信する状況であると判断した場合、送信機は、次のことのために、セッションの終わりにポイントツーマルチポイント修復トークンの受信機への送信を決定することができる。そのこととは、セッションが、マルチキャスト／ブロードキャストの形態で、再送信される−または代わりに再送信「されない」−ことをアナウンスするためである（場合によっては、修復するファイルをリストにする（および／またはファイル内のデータのブロックをリストにする）形態で再送信等がされる。）これにより、受信機が、データ修復を実行するためのポイントツーポイント接続を開始しないようにする。修復トークンは、ISO OSIプロトコルスタックのレイヤー１乃至７のいずれかにおいて、あらゆる通信プロトコルを使用して送信される。これには、マルチキャスト／ブロードキャスト送信後の別の「アナウンス」におけるＳＤＰに依ることを含む、これはまた、マルチキャスト／ブロードキャスト送信内のＦＬＵＴＥファイル配信の最後の部分（例えば、パケットの一番最後）にも含めることができる。

方法Ａ２：

ＭＢＭＳに関して3GPP TS 23.246 Rel.6 v.6.1.0の7.1項に記載されているように、ネットワークがオーバーロードにならないようにするために、送信機は、アップリンクトラフィックのランダムな時間分散を生成するために、アプリケーション付属エンティティ（Application Adjunct Entity；ＡＡＥ）のアドレス及びパラメータを、受信機へ、そのアクティブ化時に配信することができる。明細書では「多くのうちの１つ」と述べているが、「複数のうちの１つ以上」を意味するとも理解できることに留意されたい。

方法Ａ２は、送信機が、アクティブ化時（ジョイン（join）するとき）においてではなく、（ＳＤＰまたは他の好適な手段によって）セッションアナウンス時においてこの情報を送信するという事実に依拠する。したがって、この方法は、セッションアナウンス中に受信機に配信される次の２つのパラメータを定義する。
・ＡＡＥアドレスまたは類似のもの（パラメータの名前は例示的なものである）
・ランダム時間。

このランダム時間は、例えば、送信機が受信機の位置に関する情報を有するということに基づいて計算することができる。例えば、送信機が、受信機が携帯電話ネットワーク（例、ＧＰＲＳまたはＵＭＴＳ）の異なるネットワークセルに分布しているということを知っている場合、送信機は、同じセル内の全ての受信機が同時にポイントツーポイント修復を要求しないように、ランダムな時間を計算する（したがって、物理的な位置を考慮する）。その代わり、異なるセルに関するポイントツーポイント接続要求は、異なる時間に分布するようにする。送信機が受信機の位置に関する情報を持たない場合、受信機には、時間（物理的な位置を考慮しない）のみに基づいたランダム時間パラメータを配信する。ランダム時間パラメータは、ポイントツーポイント修復セッションの開始時間を示す。

従来技術（3GPP TS 23.246 v.6.1.0）の拡張および上述の方法は、単なる「ランダム時間」というよりは「ＮＡＣＫ抑制パラメータセット」を提供するためのものである。この１つの事例は、アルゴリズム

"NACK- alg-3, fast-window = 500 seconds; uniform, slow-window=5OOO seconds; normal, error_threshold_for_slow_window"

を実行するためのものである。このアルゴリズムは、ＮＡＣＫ抑制のための２つの時間ウィンドウの使用（およびそれぞれが与えられる時間および統計的な配信パラメータ）、およびその２つの時間ウィンドウの使用を選択するための入力パラメータを定義する（この種のＮＡＣＫ抑制スキームの詳細な説明は、以下の方法Ａ４およびＡ５に関連して与えられる）。

方法Ａ３：

本発明の別の実施例において、送信機は、ある数のＮＡＣＫ要求を受信機から受信した後に、それ自体の閾値に基づいて、ポイントツーポイント接続を閉じること、およびマルチキャスト／ブロードキャストにおいてセッション全体（またはその一部）を再送信することを決定する。これは、送信機が、受信機の行った再送信要求が多すぎて（すなわち、エラーレートがより高い）、ポイントツーポイント接続を使用したネットワークリソースの消費を回避した方がよいと解釈した場合に生じる。閾値は、例えば、１セッションに対して４つの異なる受信機ＮＡＣＫというように、静的に構成されるか、または、動的に計算されることができる（例えば、１つのフットボールビデオのサービスに対して３秒以内に２つのＮＡＣＫが異なる受信機から送信されたので、１０分以内に５０００個のＮＡＣＫが予想されることが予想されるなどのような、過去のデータから推測され得る。）送信機がポイントツーポイント修復データの配信を閉じることを選択し、ポイントツーマルチポイントを使用して、直ちにではないがデータを再配信する場合、ある実施形態では、修復セッションを将来行う受信機への送信機信号を有し、それによって、喪失データについてまだＮＡＣＫしていない受信機に、ＮＡＣＫする必要がないことを知らせる。さらに、この受信機へのシグナリングは、どのデータのフラグメントが送信されるのかを正確に示すことが可能であり、したがって、受信機は、それらのコンテンツを完成させる程度、およびその後の（ポイントツーポイント）修復の必要性−を構築することが可能になる。これによって、ポイントツーマルチポイントおよびポイントツーポイントの組み合わせが可能になる。

図５は、後においてＰ−ｔ−Ｍ（ポイントツーマルチポイント）修復を指示するために修復トークン（Repair Token）を使用し、続いてＰ−ｔ−Ｍ修復データからの喪失したトークンに対してＰ−ｔ−Ｐ（ポイントツーポイント）を使用する実施形態を示す。修復トークンは、送信機（Ｙ）および修復送信機（Ｚ）それぞれから生じた場合にＰ−ｔ−ＭまたはＰ−ｔ−Ｐとすることが可能である。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ意思決定者（Ｘ）は、異なったエンティティ、または送信機（Ｙ）または修復送信機（Ｚ）と組み合わせたものとすることが可能である。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ決定主体（Ｘ）は、単一のまたは独立した論理および／または物理的機器として組み入れることが可能である第３のエンティティとすることが可能である。図５（および他の図）の修復送信機は、修復サーバーまたは類似のものと理解することができる。Ｐ−ｔ−ＰまたはＰ−ｔ−Ｍ意思決定者（または意思決定ユニット）は、同様に修復判断ユニットと呼ばれる場合もある。

方法Ａ４：

方法Ａ１にて述べたように、受信機は、閾値に達した場合、再送信を要求すべきではない（ＮＡＣＫを送信すべきでない）。
別の実施形態では、次のようにして、受信機の動作を変更する。

ａ）ＮＡＣＫ抑制アルゴリズムまたはそのパラメータの変更、および／または

ｂ）動作モードの変更

上述の「ＮＡＣＫすべきではない」（または、ＮＡＣＫしてはならない）は、ＮＡＣＫ抑制アルゴリズムの変更の極端な場合を示すものである。別の手段は、次のように動作を変更するものである。

エラーレートが閾値以下であれば、
「期間ＸにわたってＮＡＣＫを均等にランダム化し、最初の配信セッションの最後から開始する」か、あるいは、
「最初のセッションが終了した後にある時間Ｙが経過するまで待ち、次いで期間ＺにわたってＮＡＣＫをランダム化しなければならない」

Ｘ、Ｙ、Ｚは、異なる値、または等しい値となるように選択することができる。これは、認識されたユーザーのＱｏＳを最大にするために、「迅速な修復プラス遅い修復」を可能にすることに特に有用である。最初の配信において多くのエラーを受けた受信機のユーザーは、いずれにしてもＱｏＳが悪い可能性がある。ユーザーが、配信直後にそのコンテンツの消費を望む場合は、いずれにしても修復セッションを待つことになる可能性が高い。しかし、ほとんどエラーを受けなかったユーザーは、上に述べたように、「修復リソース」における優先権が与えられるので、最初のセッションの後にそのコンテンツを迅速に消費できなければならない。したがって、この方法によって、はじめは不十分な配信を受けた者であっても受信を終えることが可能になり、一方で、初めから良好な配信を受けていた者は、修復処理により、良好なＱｏＳであるとユーザーに認識されるレベルで受信を終えることができる。

上述の一般化は、一連のエラーレート［ＥＲ１、ＥＲ２、…、ＥＲｎ］、一連のＮＡＣＫのランダム化［Ｘ１、Ｘ２、…、Ｘｎ］、一連の待ち時間［Ｙ１、Ｙ２、…、Ｙｎ］、および一連のＮＡＣＫのランダム化［Ｚ１、Ｚ２、…、Ｚｎ］を使用する方法である。ここで、ｋ＝１、…、ｎ、Ｎ＋のｎ、４組のタプル（ＥＲｋ、Ｘｋ、Ｙｋ、Ｚｋ）のそれぞれは、ＥＲｋ未満のエラーレートに対して、受信機は期間ＸｋにわたってＮＡＣＫを均等にランダム化しなければならないこと、ＥＲｋ以上のエラーレートに対して、受信機は最初のセッションの終了後にある時間Ｙｋが経過するまで待ち、次いで期間ＺｋにわたってＮＡＣＫをランダム化しなければならないことを示す。一連の待ち時間は、ゼロ値アレイとしてよい。

いくつかのＮＡＣＫ抑制スキームでは、複数の役割を受信機およびホストに割り当てる。例えば、フラグ保持者スキームは、フラグ保持者がすでにＮＡＣＫを受けたと認識していなければ、エラーに直ちに応答し、他の受信機は（ランダムに）ＮＡＣＫを行うと予想する（グループメンバーシップをレポートするためのＩＭＧＰに類似）。本発明のある実施形態は、受信機の動作モードを変更するものである。例えば、閾値を超えた（あるいは閾値に達しなかった）場合、受信機は別の役割を採用することになる。フラグ保持者の例において、非常に低い閾値にある受信機（例えば、エラーが１つしかない）は、直ちに、または非常に短い時間ウィンドウの範囲でＮＡＣＫを行い、他の受信機は後でＮＡＣＫを行う。

組み合わせたある実施形態では、ある役割（例、「低エラーモード」または「高エラーモード」）が、ＮＡＣＫのオペレーションを定義し、その閾値が、使用されるモードの計算に使用されるように、「受信機の役割」をＮＡＣＫ抑制アルゴリズム／パラメータと関連づける。これは、複数の連続した測定の後にモードを変更することが可能となるように、これらの種類の判断プロセスを有するヒステリシスも含む際に好都合となり得る。例えば、受信機が１００の測定の位置の１つだけ閾値を超えた場合は、モードを変更できない場合がある。

図６は、バックオフ時間の分布を示す。図７は、閾値１以下のエラーレートとなる全て受信機（すなわち、受信機１および２）に対して、セッションの開始後６０秒にわたって要求が配信されたことを示す。閾値１より高いが閾値２よりも低いエラーレートとなる受信機（すなわち、受信機３、５、および８）に対して、要求は、６０秒後に送信され、１２０秒にわたって配信される。

方法Ａ５：

方法Ａ１に述べられているように、エラーレートの閾値を使用することが可能である。別の実施形態ではこれを提供し、また、閾値を計算するための時間および／またはデータ時間ウィンドウも提供する。例えば、

"10% packet error rate; any, 30 seconds window, sliding"

は、閾値が最後の３０秒以内のパケットの１０％（喪失またはエラーを含む）であり、最後の３０秒からスライディング時間ウィンドウによって連続的に（または擬似連続的に）サンプリングするためのものであることを示すことができる。別の例では、

"5% bit error rate, any, 2Kbyte window, blocked"

は、閾値が、複数の（任意の）２ＫＢブロックに対して５％のビットが誤りとなるようにされ、０−２ＫＢ、２−４ＫＢ、４−６ＫＢなどはサンプリングされたブロックである。当該基準に一致するあらゆるデータは、実施形態であるが、大量のデータ転送では、「セッション内でこの基準が３回満たされたならば、閾値に達したとみなす」などの代わりとして、第２のレベルの閾値を用いることが好都合となり得る。

図８は、閾値の計算のための時間ウィンドウの効果を示す。

方法Ａ６：

いくつかの実施形態は、予め設定することによって、サーバーと受信機との間でやり取りされるパラメータを共有および配信することが可能である。例えば、ＳＩＭを発行し、マルチキャストシステムを制御するオペレータによる、ＳＩＭカードへの保存が挙げられる。別の例には、予め設定された既知のパラメータを有するものが挙げられ、通常、当該既知の数値は、規格で規定されているか、または番号レジストリ機構（ＩＡＮＡなど）によって維持される。一実施形態では、そのパラメータを配信するための別の方法も提供されていれば、これらのパラメータのデフォルト値は、予め設定され、特定のセッションに対して破棄（上書き）される。

方法Ａ７：

本発明の更なる実施例では、極めて大量のコンテンツデータに対して受信機から修復要求を受信した後に、「これを後で修復する」ことを受信機に示す送信機を有することになる。その後の修復セッションは、ポイントツーポイントまたはポイントツーマルチポイントセッションであってよい。したがって、システムの帯域幅が拡張可能性要因を支配的に制限している場合、これによって、送信機は、まず迅速に満たされる受信機を処理し、その際、受信機の目標数（例、９９％）が完全な（エラーフリーの）データを有するようにするための平均時間を減じる。例えば、修復は、（最多数の受信機に対して）最初にポイントツーマルチポイント修復によって開始し、続いて（少数の受信機に対して）ポイントツーポイント修復によって行うことが可能である。

方法Ａ８：

上述したものでは、修復セッションおよびシグナリングのための開始ポイントとして、一般にセッションの最後を使用した。しかし、いくつかの実施形態では、オブジェクト（例、ファイルまたはシーン）の最後、閾値（例、１ＭＢ毎、１０００パケット毎、または５分毎）、またはセッショングループ（例、これら４つ全ての最後が関連するセッション）が、好都合となり得る。

図９は、オブジェクトの最後を検出した後の修復セッションの開始を示す。

Ｂ）受信機ドリブンの修復方法

通常、受信機は、データ修復のためのポイントツーポイント接続の確立の要求を、ある程度の時間遅延させることができ、この要求が、マルチキャスト／ブロードキャストセッション終了直後に実行されないようにすることができる。これは、多数の受信機が、修復のためのポイントツーポイント接続の要求を同時に送信することによって、ネットワークおよび送信機に輻輳が生じることを防ぐ。以下のいくつかの遅延方法では、ポイントツーポイント修復要求が与えられる。

方法Ｂ１：

修復は、遅延修復（lazy repair）とすることができる。この場合、ユーザーがデータの消費を望む場合（例えば、ユーザーがビデオクリップの再生を望む場合、マルチキャスト／ブロードキャストセッション中にダウンロードされる）、受信機は、ポイントツーポイント修復要求を実行する。これは、ユーザーは、完全なポイントツーポイント修復の実行にかかる時間だけ待たなければならない（すなわち、データ実現のためのユーザーの待ち時間が増加する）。この方法はまた、送信機が、セッションアナウンス（ＳＤＰまたは他の好適な手段を使用）において、修復に利用できる最長時間、すなわち、送信機がうまくポイントツーポイント修復を実行できるまでの制限時間も任意で必要とする。この時間ユニットのフォーマットは規定されていないが、様々な方法（制限されないが、例えば、絶対時間または相対時間）で表すことができる。修復に利用できる最長時間が経過した後は、ポイントツーポイント修復オペレーションの成功は確保されない。これは、送信機に対して、データ修復を実行するために、保存したデータを保持するための制限時間を与える。ポイントツーポイント修復が、（ユーザーがデータ再生を未だ要求していないため）修復に利用できる最長時間までに実行しなかった場合、受信機は、その時、ポイントツーポイント修復を実行させられる。受信機がオフになり、修復に利用できる最長時間が経過した場合、その後はポイントツーポイント修復は保証されない。場合によっては、最終的に「安全マージン」が確保されるように、ＮＡＣＫがランダム化される期間を減じることが好都合である。例えば、期間が４３２０００秒である場合、ＮＡＣＫは概して４０００００秒にわたって配信され、「停止している」受信機に、保証された修復時間を失うことなくオンにするための時間を最大３２０００秒与える。

上述の例を以下に述べる。
送信機が、修復に利用できる最長時間が２００４年３月１５日までであるというアナウンスを送信する場合は、受信機が指定された日時まで修復を実行できることを意味する。その日時以降は、修復オペレーションは保証されない。別の方法では、マルチキャスト／ブロードキャスト送信からの相対的な時間としての時間を表すことができる。例えば、送信機は、修復に利用できる最長時間が４３２０００秒であることを受信機にシグナリングすることが可能である。これは、ポイントツーポイント修復を行うために利用可能な期間は、マルチキャスト／ブロードキャスト送信から５日間であることを受信機に知らせる。

図１０は、遅延修復の実施形態を示す。

方法Ｂ２：

修復は、「遅延してもよい再生修復」とすることができる。この場合、受信機は、ユーザーがデータの消費を望む場合に、ポイントツーポイント修復要求を実行する。さらに、修復は、データストリームにおける最初の喪失の位置を考慮する。ストリームが、音声、またはオーディオおよびビデオストリームである場合、受信機は、いつメディアユニットに最初のデータ損失が生じるのかを正確に計算することができる。ポイントツーポイント修復は、次いで、最良の状態でデータストリームの再生を開始した後であっても開始を延期することができるが、受信機の再生が連続的な中断を受けないような方法で十分早期に実行および計算されなければならない。

（ポイントツーポイント修復オペレーションは、最初の喪失ブロックに対する時間よりも長い時間を必要とするので、）ポイントツーポイント修復が、再生と並行して行えない場合、ポイントツーポイント修復は、ユーザーが再生要求を発行すれば直ちに開始することができるが、実際の再生は、再生を中断させないために必要な時間、遅延させられる。このスキームは、上述の第１のスキーム（方法Ｂ１）に非常に似ているが、修復オペレーションおよび再生が一時的かつ部分的にオーバーラップするので、ユーザーの待ち時間が少なくなる。

また、この場合、修復に利用できる最長時間の情報は、任意で必要とされる場合があり、第１の場合（方法Ｂ１）のように受信機によって使用される場合がある。

ポイントツーポイント修復の実行に必要な時間は、測定または与えられた帯域幅のポイントツーポイント接続、ポイントツーポイントチャネルにわたって測定したラウンドトリップ時間、およびポイントツーポイントセッションの確立および終了遅延のような要素に基づいて、受信機が推定することができる。

上述の例を以下に述べる。
送信機が、５分のオーディオ／ビデオクリップを送信し、受信機が時間４'で最初に生じる３０の喪失パケットがあることを検出した場合、ユーザーは、直ちにストリームの再生を開始することができ、受信機は、３０の喪失パケット全てが再生の４分前に到着するように、ユーザーが十分早く再生することと並行してポイントツーポイント修復オペレーションを開始する。３０の喪失ブロックが、時間１'で第１の喪失ブロックが生じ、受信機が、ポイントツーポイント修復セッションは１分以上かかると推定するような場合、修復セッションが開始され、再生は、再生を中断させないために必要な時間分、遅延される。

図１１は、遅延再生修復の一つの実施形態を示す。

方法Ｂ３：

別の場合（方法Ａ７の受信機ドリブンのアプリケーションに類似）では、ＮＡＣＫ抑制が、多数の誤ったデータおよび喪失データを、回復時間を計算するための乗数として使用する。例えば、送信機が、「時間のユニット」を６０秒と示し、喪失データが１０パケットであると示している場合、５６の喪失パケットを有する受信機は、ＩＮＴ（５６／１０）×６０＝３００秒と、時間を計算することになる。これらの結果の時間は、オフセット（最初のセッションが終了して長い秒数経過する前にＮＡＣＫを開始しない）として、および／またはＮＡＣＫを配信する期間（例えば、この時間を通じて自分のＮＡＣＫが均等にランダム化される）として使用することが可能である。

方法Ｂ４：

本発明の更なる実施形態は、最初のマルチキャスト／ブロードキャストが終了する前にポイントツーポイント修復セッションを開始する可能性である。この方法では、修復がより早くなり、ユーザーは、待ち時間のより短いエラーフリーの「再生」セッションを開始することができる。正確な修復開始時間は、受信機によって決定するか、またはデータストリームおよび／またはファイル長の範囲内の第１のエラーの位置の機能とすることができる。

図１２は、「早期発見」によって開始される修復の実施形態を示す。

上述の全ての方法はまた、あらゆる可能かつ機能的に好適な組み合わせにおいて使用することもできる。

図３は、本発明の実施形態による、システムおよび受信機２０の詳細を示す。該システムは、送信機１０、ＩＰネットワークまたは他の固定ネットワークなどの伝送ネットワーク３０、無線ネットワークまたは固定および無線（携帯電話）ネットワークなどを組み合わせたもの、および受信機２０を備える。受信機２０は、移動電話、衛星電話、携帯情報端末、またはＢｌｕｅｔｏｏｔｈ機器、ＷＬＡＮ機器、ＤＶＢ機器、または他の類似した無線機器とすることができる。機器２０は、内部メモリ２１、プロセッサ２２、オペレーティングシステム２３、アプリケーションプログラム２４、ネットワークインターフェース２５、およびＮＡＣＫおよび修復機構２６を含む。内部のメモリ２１は、プロセッサ２２、オペレーティングシステム２３、およびアプリケーションプログラム２４に対応する。ＮＡＣＫおよび修復機構２６によって、データ伝送において喪失または壊れたデータに応答した、ＮＡＣＫおよび修復プロシージャが可能になる。機器２０は、ネットワークインターフェース２５およびネットワーク３０を経て、送信機１０および他の機器と通信することができる。

図４は、本発明の実施形態による、送信機１０を示す。送信機１０は、例えば、ネットワークサーバーまたはファイル（またはメディア）の配信を対象としたあらゆる好適な機器とすることができる。機器１０は、内部メモリ１１、プロセッサ１２、オペレーティングシステム１３、アプリケーションプログラム１４、ネットワークインターフェース１５、送信および修復機構１６、およびデータストレージ１７を含む。内部メモリ１１は、プロセッサ１２、オペレーティングシステム１３、およびアプリケーションプログラム１４に対応する。送信および修復機構１６によって、受信機２０へのデータパケットの送信が可能になる。さらに、修復セッションにおけるデータパケットの再送信が可能になる。受信機２０に送信されるデータおよび再送信されるデータは、データストレージ１７に保存することができる。別様には、データは、送信機１０と同じ位置または外部に配置される独立した機器に保存することができる。機器１０は、ネットワークインターフェース１５およびネットワーク３０を経て、送信機２０および他の機器と通信することができる。

喪失データの修復に関するプロシージャは、ソフトウェアによって実行することができる。受信機２０に保存され、プロセッサ２２において実行されるプログラムコードを有するコンピュータプログラム製品は、送信セッションの受信終了時にプロシージャを実行するために使用することができ、一方で、受信機１０に保存され、プロセッサ１２において実行されるプログラムコードを有するコンピュータプログラム製品は、送信終了時にプロシージャを実行するために使用することができる。

本発明の実施形態を、論理的な送信機／サーバーエンティティおよび受信機ユニットの例とともに示した。修復要求間、および修復応答間（適切な場合）に進行する第３のエンティティの使用もまた、本発明の実施形態の範囲に含まれる。当該のエンティティは、例えば、修復トークンを配信するよう要求しているポイントツーマルチポイント送信機に対して修復送信機メッセージを許可するために、または、受信機から送信機へのメッセージのための修復要求アグリゲータ／プロキシとして機能し、したがって、第３の機器における透過的なポイントツーポイントおよびポイントツーマルチポイント判断を可能にするように、ファイアウォール、プロキシ、および／または許可サービスを提供することが可能である。

修復トークンのポイントツーマルチポイント配信の使用は、上述したとおりである。加えて、ポイントツーポイント修復トークンの使用は、いくつかの実施形態において好都合となり、本発明の実施形態の範囲に含むことが可能である（ポイントツーマルチポイント修復に関して示されたことに対応する配信／フォーマットの方法を使用できる、例、ＳＤＰ）。当該スキームは、ポイントツーポイント要求がポイントツーマルチポイントによって送信するように決定した後に到着した場合、ポイントツーマルチポイント修復／再送信データが「途中」であることを受信機に知らせるか、または代わりに、受信機が、節電のために一時的にマルチポイント受信を停止させるが、依然としてこの次のポイントツーマルチポイント修復＿応答／再送信を知ることができるようにすることが可能である。

本発明の実施形態によって、拡張可能な信頼性の高いマルチキャストを提供するＮＡＣＫ抑制が可能となる。マルチキャスト／ブロードキャスト送信のための効率的かつ拡張可能なポイントツーポイント修復が提供され、フィードバックの集中およびネットワーク／送信機のオーバーロードを回避する。

本発明の特定の実現例および実施形態を説明した。本発明が、上述の実施形態の詳細に制限されないことは、当業者には明らかである。さらに、当業者は、本発明に組み込める多数の追加的な方法があり、実施例の限られた部分のうちの１つに示されていないが、それらの方法は本発明の範囲内であるということを認識している。特に、本発明は、あらゆるプロトコル、パラメータ、またはメッセージのいずれの特定の名前にも制限されるべきではない。本発明は、本発明の特性から逸脱せずに、同等の手段を使用して他の実施形態において実施することができる。本発明の範囲は、添付された特許請求の範囲によってのみ制限される。

図１Ａは本発明の実施形態による１対多のデータ伝送のシナリオを示し、図１Ｂは本発明の実施形態による異なる喪失データ修復方法を示す。 図２Ａは本発明の実施形態による簡略化したプロトコルアーキテクチャを示し、図２Ｂは本発明の別の実施形態による簡略化したプロトコルアーキテクチャを示す。 本発明の実施形態による、システムおよび受信機の詳細を示す。 本発明の実施形態による、送信機を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。 本発明の種々の実施形態を示す。