JP4357535B2 - 欠落部分の識別および再送信 - Google Patents

Description

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

ＩＰマルチキャスト、ＩＰデータキャスティング（ＩＰＤＣ）およびマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）などのシステム上における一対多数（すなわち、ポイントツーマルチポイント）サービスにとって、ファイル配信（または個々のメディア配信またはファイルダウンロード）は重要なサービスである。ファイル転送プロトコル（ＦＴＰ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）などのポイントツーポイントプロトコル上でのファイル配信に関する特徴の多くは、一対多数シナリオにとって問題のあるものである。特に、送信制御プロトコルＴＣＰなどの類似する一対一（すなわちポイントツーポイント）肯定応答（ＡＣＫ）プロトコルを使用する、信頼できるファイル配信―すなわち保証されたファイル配信―は、実行不可能である。

インターネットエンジニアリングタスクフォース（ＩＥＴＦ）のリライアブルマルチキャストトランスポート（ＲＭＴ）ワーキンググループは現在、２つのカテゴリのエラー回復マルチキャストトランスポートプロトコル標準化を進めている。第１のカテゴリにおいて、信頼性は（プロアクティブ型）前進型誤信号訂正（ＦＥＣ）の使用によって、すなわち、受信機が誤ったデータを再構成するのを助けることができる一定量の冗長データを送信することによって達成される。第２のカテゴリでは、信頼できるマルチキャストトランスポートを実行するために、受信機のフィードバックが使用される。非同期階層符号化（ＡＬＣ、ＲＦＣ３４５０）は、第１のカテゴリに属するプロトコルインスタンス化であり、一方、ＮＡＣＫ型リライアブルマルチキャスト（ＮＯＲＭ）プロトコルは第２のカテゴリの例を示すものである。ＡＬＣおよびＮＯＲＭプロトコルについての詳細は、ＩＥＴＦのワーキンググループによって作成された「Ａｓｙｎｃｈｒｏｎｏｕｓ Ｌａｙｅｒｅｄ Ｃｏｄｉｎｇ（ＡＬＣ）Ｐｒｏｔｏｃｏｌ Ｉｎｓｔａｎｔｉａｔｉｏｎ（非同期階層符号化（ＡＬＣ）プロトコルインスタンス化）」（ＲＦＣ３４５０）および「ＮＡＣＫ ｏｒｉｅｎｔｅｄ Ｒｅｌｉａｂｌｅ Ｍｕｌｔｉｃａｓｔ Ｐｒｏｔｏｃｏｌ（ＮＡＣＫ型リライアブルマルチキャストプロトコル）」（インターネットドラフト）と題された出版物においてさらに詳しく論じられている。これらの出版物の内容は、参照することにより本明細書に完全に組み込まれる。

これらのプロトコルが使用されるアクセスインターネットは、ユニバーサル移動体通信システム（ＵＭＴＳ）システム、ワイヤレスローカルエリアネットワーク（ＷＬＡＮ）、デジタルビデオ放送‐地上波（ＤＶＢ‐Ｔ）ネットワークおよびデジタルビデオ放送‐衛星（ＤＶＢ‐Ｓ）ネットワークの無線アクセスネットワークなどのワイヤレス多重アクセスネットワークを含むがこれらに限定されない。

つまり、ＡＬＣプロトコルは、受信機が壊れたパケットまたは受信されていないパケットを再構成できるようにするプロアクティブ型ＦＥＣベースのスキームである。ＡＬＣプロトコルは、多重チャネルにおいて、送信機が場合によっては異種受信機へ複数レート（チャネル）でデータを送信できるようにするＦＥＣ符号化を使用する。また、ＡＬＣプロトコルは、異なるチャネルにおいて異なるレートを維持するため、輻輳制御機構を使用する。

ＡＬＣプロトコルは、アップリンクシグナリングが必要ないため、ユーザ数に関して大規模に拡張可能である。したがって、どれだけ受信機を追加しても、必ずしもシステムの需要を増やすわけではない。しかしながらＡＬＣプロトコルは、受信が保証されていないため、１００％信頼できるわけではなく、したがって一般的に強固なものとはされていない。

同様に、ＮＯＲＭは、受信機に到着すると予期されたどのデータのパケット（または「データブロック」と定義される）が受信機で受信されなかった（または誤って受信された）のかを知らせるために、否定応答（ＮＡＣＫ）メッセージの使用法を特定する。言い換えると、受信機は、ＮＡＣＫを用いて送信されたパケットの損失または損傷を送信機に示す。したがって、データ送信から一部のデータブロックが「欠落した」受信機は、その欠落したデータブロックを再送信するよう送信機に要求するＮＡＣＫメッセージを、送信機に対して送信することができる。ＮＯＲＭプロトコルは、プロアクティブ型の強固な送信のため、任意でパケットレベルＦＥＣ符号化の使用も可能にする。

Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（一方向トランスポートでのファイル配信、ＦＬＵＴＥ）は、ＦＥＣおよびＡＬＣビルディングブロックを基礎とする一対多数トランスポートプロトコルである。これは、一方向システム上での送信機から受信機へのファイル配信用のものであり、ワイヤレスポイントツーマルチポイント（マルチキャスト）システムに適合させる特殊化を有する。ＦＬＵＴＥプロトコルについての詳細は、上述のＩＥＴＦのワーキンググループによって作成された「ＦＬＵＴＥ−Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（一方向トランスポートでのファイル配信）」（インターネットドラフト）と題された出版物においてさらに詳しく論じられている。この出版物の内容は、参照することにより本明細書に完全に組み込まれる。

ＮＡＣＫメッセージは概してＮＯＲＭ固有ではなく、その他のプロトコルまたはシステムに関連して使用することもできる。ＦＬＵＴＥセッションに関連して（または特に一対多数送信を対象とするトランスポート層プロトコルを使用するセッションにおいて）ＮＡＣＫメッセージを使用する場合、欠落パケット（またはブロック）の識別は重要な問題である。ＴＣＰなどの一対一（またはポイントツーポイント）送信用のプロトコル、およびそれらの応答方法の使用は、ここで必ずしも実行可能とは限らない。例えば、一対多数システムにおけるＴＣＰ応答方法の使用により、多額の間接費が発生するであろう。したがって、正確な再送信が行えるよう、一対多数シナリオにおいて受信されなかったパケットを確実に識別することが必要である。
AsynchronousLayered Coding (ALC) Protocol Instantiation (RFC 3450), IETF Working Group. NACKoriented Reliable Multicast Protocol (Internet Draft), IETF Working Group. FLUTE-FileDelivery over Unidirectional Transport (Internet Draft), IETF Working Group.

マルチキャスト／ブロードキャストチャネル上で確実にデータを送信するためにＮＡＣＫメッセージを使用する場合、欠落パケットの識別が重要な問題であると考えられている。これには、再送信が必要なブロックの識別に加え、送信の状況に関する情報の保守が必要である。応答時間に関して、ＮＡＣＫ要求（受信機により送信され、送信機により受信される）は以下の２つのカテゴリに分けられるとされている。
ａ）初期送信後直ちに、または間もなく受信され、同一セッション内において満たすことのできるＮＡＣＫ要求（例えば、ＦＬＵＴＥセッションまたは類似のもの）。
ｂ）セッション終了後に受信され、別のセッションによってデータが再送信されることを必要とするＮＡＣＫ要求。この場合、その他のセッションは、同一のポイントツーマルチポイントプロトコル（例えば、古いＦＬＵＴＥセッションの終了後に確立された新しいＦＬＵＴＥセッション）、または、ポイントツーポイントもしくはポイントツーマルチポイントプロトコル（例えば、ＦＴＰ、ＨＴＴＰ等）であり得る別のプロトコルを使用するセッションのいずれであってもよい。

いずれの場合も、再送信されるべきブロックを正確に識別することが重要である。

本発明の第１の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための方法であって、
送信機から少なくとも１つの受信機へ１つ以上のデータブロックを転送するステップと、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別するステップと、
前記データブロックを再送信するための措置を講じるステップとを含み、
前記識別を、ブロック番号、符号化識別子、およびその他の識別情報に基づいて行うステップを含む方法が提供される。

ある実施形態によれば、その他の情報はセッションパラメータのセットおよび／または送信オブジェクト識別子を含む。

ある実施形態によれば、その他の情報は前記ファイルの情報および／またはブロッキング情報を含む。

本発明の第２の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための受信装置であって、
送信機から１つ以上のデータブロックを受信する手段と、
受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別する手段と、
前記データブロックを再送信させるために措置を講じる手段とを備え、前記識別する手段は、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成される受信装置が提供される。

本発明の第３の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための送信装置であって、
少なくとも１つの受信機へ１つ以上のデータブロックを送信する手段と、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックであって、ブロック番号、符号化識別子およびその他の識別情報に基づいて識別されたデータブロックを再送信する手段とを備える送信装置が提供される。

本発明の第４の側面によると、一対多数送信が可能なシステムであって、
送信機から少なくとも１つの受信機へ１つ以上のデータブロックを転送する手段と、
前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別する手段と、
前記データブロックを再送信するための措置を講じる手段とを備える、
前記識別する手段は、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成されるシステムが提供される。

本発明の第５の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための受信装置において実行可能なソフトウェアアプリケーションであって、
前記受信装置に送信機から１つ以上のデータブロックを受信させるためのプログラムコードと、
受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックを識別するためのプログラムコードと、
前記受信装置に前記データブロックを再送信させるために措置を講じさせるためのプログラムコードとを備え、
前記識別するためのプログラムコードは、ブロック番号、符号化識別子およびその他の識別情報に基づいて前記データブロックを識別するように構成されるソフトウェアアプリケーションが提供される。

本発明の第６の側面によると、一対多数送信が可能なシステム内におけるファイル配信のための送信装置において実行可能なソフトウェアアプリケーションであって、
前記送信装置に、少なくとも１つの受信機へ１つ以上のデータブロックを送信させるためのプログラムコードと、
前記送信装置に、前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信されたデータブロックであって、ブロック番号、符号化識別子およびその他の識別情報に基づいて識別されたデータブロックを再送信する手段とを備えるソフトウェアアプリケーションが提供される。

ソフトウェアアプリケーションは、メモリなどの媒体に格納されたプログラムコードを含むコンピュータプログラム製品であってよい。

本発明のさらに別の側面によると、一対多数送信システム内におけるファイル配信のための方法であって、
送信機から少なくとも１つの受信機へ１つ以上のデータブロックを転送するステップと、
ブロック番号および／または符号化識別子領域を使用して、再送信されるべき欠落したデータブロックを識別するステップとを含む方法が提供される。

本発明のこの側面は、別個の側面として、または本発明のその他任意の側面に関連して実行されるべき側面として理解されることができる。

ブロック番号範囲および符号化識別子範囲は、連続的であっても非連続的であってもよい。

受信装置、送信装置、システム、およびソフトウェアアプリケーションは、個々に実装されてよい。

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

詳細な説明

以下、添付図面を例として参照し、本発明の実施形態を説明する。

本特許出願の導入部に含まれる主題は、詳細な説明を支持するために使用することができる。以下のＦｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ（一方向トランスポートでのファイル配信、ＦＬＵＴＥ）プロトコルは、本発明がＦＬＵＴＥのみに関与すると限定することを意図せず、例として使用される。一対多数マルチキャストファイル配信が可能なその他適合するプロトコルも、本発明の関係において適用できる。

図１は、本発明の実施形態に従って通信を行っている送信装置および受信装置を示す。送信装置１０は、サーバ、ＩＰベースの装置、ＤＶＢ装置、ＧＰＲＳ（またはＵＭＴＳ）装置、または、マルチキャストデータブロック（またはパケット）を受信装置２０へ送信するためにＡＬＣ機構などのプロアクティブ前進型誤信号訂正を任意で使用できる類似の装置である。受信装置２０は、欠落ブロック（受信されなかった、または誤って受信されたブロック）に関する否定応答ＮＡＣＫメッセージ（または要求）を送信装置１０に送信する。ＮＡＣＫメッセージを受けて、送信装置１０は、ＦＬＵＴＥセッション（元の送信のために確立された元のＦＬＵＴＥセッションと同一のＦＬＵＴＥセッション、または次のＦＬＵＴＥセッション）において欠落ブロックを受信装置２０へ再送信する。あるいは、ＦＬＵＴＥ以外のプロトコルを使用するセッションを使用してもよい。特定の文脈においては、再送信セッションは修復セッションと称される。

データはオブジェクトとして転送される。例えば、ファイル、ＪＰＥＧ画像、ファイルスライスはすべてオブジェクトである。ファイル（またはデータ）配信のため、送信装置１０と受信装置２０との間にセッションが確立される。単一のセッションは、単一のオブジェクトまたは複数のオブジェクトの送信を含むことができる。オブジェクトとセッションを識別するためには異なる識別子が使用される。各セッションは、送信機（ソース）のアドレス（例えば、ＩＰアドレス）、受信機（宛先）のアドレスおよび送信セッション識別子（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｓｅｓｓｉｏｎ Ｉｄｅｎｔｉｆｉｅｒ；ＴＳＩ）または同類のものによって識別される。送信機または受信機のアドレスおよびＴＳＩのみを使用することも可能である。さらに、特定のセッションに関連してパケットが転送されてくるオブジェクトを識別するために、送信オブジェクト識別子（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｏｂｊｅｃｔ Ｉｄｅｎｔｉｆｉｅｒ； ＴＯＩ）または同類のものが使用される。例えば、送信装置１０は、第１のファイルを表す０、第２のファイル等を表す１といったＴＯＩを使用して、同じセッション内のファイル数を送信するかもしれない。

各データブロックは、ソースブロック番号（Ｓｏｕｒｃｅ Ｂｌｏｃｋ Ｎｕｍｂｅｒ；ＳＢＮ）と称される番号または同類のものを有し、これによって各ブロックを識別する。ブロックは、符号化記号のセットによって表される。同様に、データパケット（またはブロック）のペイロードに運ばれる符号化記号がどのようにして上述のオブジェクト（例えば、ファイル）から生成されたかを、符号化記号識別子（Ｅｎｃｏｄｉｎｇ Ｓｙｍｂｏｌ Ｉｄｅｎｔｉｆｉｅｒ；ＥＳＩ）または同類のものが識別する。

図２Ａは、本発明の実施形態に従って、簡略化したプロトコルアーキテクチャを図示している。この実施形態によると、送信装置１０および受信装置２０のために実装されるプロトコルスタックは、アプリケーション層、ＦＬＵＴＥプロトコル層、ＵＤＰおよびＩＰ層、ならびに下位層を含む。ＦＬＵＴＥプロトコル層は、階層符号化トランスポート（ＬＣＴ）ビルディングブロック（図示せず）のＡＣＬプロトコルインスタンス化の上部に構築される。また任意でＦＥＣビルディングブロックを使用してもよい。ＦＬＵＴＥプロトコル層は、ＮＡＣＫメッセージとともに、送信装置１０から受信装置２０へ信頼できるデータブロック送信を提供することを意図されたものである。このプロトコルアーキテクチャは、一対多数送信のために（一対多数送信だけでなく一対多数の「第１の送信」のためにも）使用できる。

あるいは、ある実施形態において、ＵＤＰ層の代わりにＴＣＰ層を使用することができる（図２Ｂ参照）。これは、別個のポイントツーポイント修復セッション（ここではＴＣＰセッション）が一対一（すなわち、ポイントツーポイント）再送信のために使用される場合に当てはまる。別の再送信方法の説明は、本明細書中で後に提示する。

以下、受信機が欠落パケット（またはブロック）のセットを識別するための別の事例を提示する。ＦＬＵＴＥソースブロックまたは符号化記号（結果として、１つまたは一連のデータパケット）を識別する２つの方法がある。

識別方法Ａ
識別は、ＦＬＵＴＥセッションパラメータ（ソースアドレス、宛先アドレスおよびＴＳＩ）およびＴＯＩ（送信オブジェクト識別子）に加えて、ＳＢＮおよびＥＳＩに基づいて行われる。一般に、ＦＬＵＴＥパケット送信中にこの情報を生成するのは送信装置である。情報は、ＡＬＣ／ＦＬＵＴＥパケットに含まれる。

識別方法Ｂ
識別は、ファイル（すなわち、配信ファイルのＵＲＩ）、ファイルパラメータ（ファイル長および暗号化コード（ＭＤ５コード等）、使用するブロックアルゴリズムおよびブロックパラメータ（最大ソースブロック長、符号化記号長およびファイル長）に加えて、ＳＢＮおよびＥＳＩに基づいて行われる。情報は、これらのパラメータ／情報を含むＦＤＴ（ファイル記述テーブル）または同類のものから得られる。情報は、一般に別個のオブジェクトとしてＦＬＵＴＥセッションにより運搬される。

以上のように、識別方法ＡおよびＢの両方が、ブロック番号および符号化識別子、またさらに一定のその他の識別情報を利用する。識別方法Ａは、セッション自体（ここでは、ＦＬＵＴＥセッション）から直接得られる詳細を使用し、一方で識別方法Ｂはその他の情報（すなわち、配信ファイルについての情報）も使用する。

識別方法とは別に、後続の再送信を行うためには以下２つが考えられる。

再送信方法Ａ
再送信のために、ＦＬＵＴＥセッションが使用される（再送信は、同じ（進行中の）ＦＬＵＴＥセッション内で、または別個のＦＬＵＴＥセッションにおいて成立し得る）。この方法は、ポイントツーポイントまたはポイントツーマルチポイント送信に基づいたものであってよい。

再送信方法Ｂ
ＦＬＵＴＥ以外の方法、例えばＨＴＴＰ、ＳＭＳ、ＦＴＰ、ＳＡＰ、ＧＰＲＳ等で再送信するための別個のセッションを使用する。この方法は、ポイントツーポイントまたはポイントツーマルチポイント送信に基づいたものであってよい。

したがって、２つの異なる識別方法および再送信のためのＦＬＵＴＥまたは別のプロトコルの使用により、パケットを識別し再送信するための４つの異なる組み合わせが発生する。
１．方法Ａを使用した識別および方法Ａを使用した再送信
２．方法Ｂを使用した識別および方法Ｂを使用した再送信
３．方法Ａを使用した識別および方法Ｂを使用した再送信
４．方法Ｂを使用した識別および方法Ａを使用した再送信

上記では、送信中、各符号化記号が唯一のパケット内に含まれていると想定している。しかしながら、複数の符号化記号が同じパケット内に含まれる場合、または単一の符号化記号が複数のパケットにわたっている場合、符号化記号（および符号化記号を含むパケットの部分または単一の符号化記号をそれぞれ含む一連のパケット）が適切に認識される必要がある。

第１の組み合わせ（Ａ＋Ａ）は、同じチャネル上における、同じ送信機（またはサーバ）情報を使用した、同じＦＬＵＴＥセッション内、短いタイムスパンでのパケット再送信が望ましい状況において有用であると考えられる。例えば、ＦＬＵＴＥ送信機は、過去５分以内に送信されたすべてのＳＢＮおよびＥＳＩをバッファリングする（または一時的に格納する）ことができる。再送信要求（ＮＡＣＫ）がこの時間内に到着する場合、この方法が適用できる。

第２の組み合わせ（Ｂ＋Ｂ）は、現在のセッションが終了した後、場合によってはずっと後に再送信が必要とされる状況において有用であると考えられる。セッション中の送信についての長期情報をすべてバッファリングすることは送信装置１０にとって実行不可能かもしれないため、限定されない実施形態においては、「第三者サーバ」または修復サーバ（または単に別個のサーバ（図示せず））が送信情報をバッファリングするように構成される。このサーバは、例えば、ＢＭ‐ＳＣ（ブロードキャストマルチキャスト‐サービスセンター）とも称される元の送信機（例えば、ＭＢＭＳ（マルチメディアブロードキャスト／マルチキャストサービス））サーバと同一場所に配置されてよく、または、例えばＵＭＴＳオペレータネットワーク内の別個のサーバであってもよい。このサーバはその後、欠落パケットを再送信することができる。この例としては、ＧＰＲＳ（ＵＭＴＳ）アクセスが割安となる夜間に、ＧＰＲＳまたはＵＭＴＳ上で欠落パケットを再送信するサーバがある。再送信は、多くの受信装置２０からの再送信要求（ＮＡＣＫ）を送信装置１０にオーバーロードするのを回避するため、再送信セッションが終了した直後、またはセッション終了後およびデータが受信装置２０によって消費される前であれば、いつでも開始することができる。別個の修復サーバを有するという概念は、その他の実施形態にも当てはまる。

以下のステップは、前述の典型的な実施形態を説明するものである。
１．送信装置１０がＦＬＵＴＥセッションを使用して１つ以上のファイルを送信する。
２．セッションの終了時に、受信装置２０が、受信しなかったすべてのパケットに関する１つ以上のＮＡＣＫメッセージを送信する。このＮＡＣＫメッセージが新しいセッションの開始を表す。
３．送信装置１０が、新しいセッションにおいて、受信装置２０により要求されたすべてのデータを再送信する。
４．新しく作成されたセッションが、送信装置１０および受信装置２０で閉鎖される。

上記のステップ２に関連する例として、ＨＴＴＰ上で特定のＳＢＮおよびＥＳＩを使用するデータに関し、ＮＡＣＫを送信するには以下の方法を使用することができる。

ここで、ＳＢＮおよびＥＳＩは、否定応答される（すなわち、ＮＡＣＫされる）ファイルの部分のソースブロック番号および符号化記号ＩＤである。ここではファイル名をｎｕｍｂｅｒ１．ｍｐｓ、ＮＡＣＫされるＳＢＮおよびＥＳＩをそれぞれ１２３および２３４とする。上記のＨＴＴＰクエリーにおいて、ＳＢＮおよびＥＳＩフィールドは、ＳＢＮおよびＥＳＩ領域のためのＮＡＣＫにも使用できる。例えば、

である。

上記はファイルｎｕｍｂｅｒ１．ｍｐ３、ＳＢＮ１２３、１２６および１２７、ならびにＥＳＩ２３４乃至２３８についてＮＡＣＫするものである。その他いくつかそのような組み合わせが可能であり、例えば次のようなものがある。

ＮＡＣＫが１つ以上のパケットの再送信を求める要求を含むことが可能である。これがネットワークチャネル上で確実に送信される場合、単一のＮＡＣＫにすべてのパケット要求を含むのがより効率的である。そうでない場合、いくつかのＮＡＣＫにわたってすべてのパケットを要求できる。

以下は、あるＦＬＵＴＥセッション中に欠落したパケットを再送信するための、本発明のさらに別の実施形態を説明するものである。この実施形態は、前述の４つの識別／再送信の組み合わせとは無関係である。

この実施形態において、ＦＬＵＴＥセッションコンテキスト（ＳＢＮ、ＥＳＩ、ＴＳＩおよびＴＯＩ）は後にＦＬＵＴＥ以外で使用するために格納される。このコンテキストは、その後ＦＬＵＴＥ以外の方法を使用してデータを送信するために使用することができる。これを実行するためには、「セッションコンテキスト」を独自に識別する識別子、例えばマルチキャストＩＤを有することが有用であると考えられる。本明細書において「セッションコンテキスト」は例えばセッションのための独自の識別子を形成するために結合したセッションのすべての識別子であってよい。本明細書で使用される再送信方法は先に説明した組み合わせ方法４と同じであるが、セッション情報の格納に関して相違があることに留意すべきである。ある実施形態において、セッション情報は送信装置および受信装置の両方によって格納され、ＦＬＵＴＥセッション外において、送信装置と受信装置との間で通信を行う。

本発明のさらに別の実施形態によると、受信装置２０は、再送信が必要なパケットを算出するよりもむしろ、再送信が必要な（送信装置１０によって送信された元のオブジェクトの）バイト領域を算出する。また、この実施形態においては、ＳＢＮおよびＥＳＩを識別に使用することもできる。受信装置は、受信されなかったバイト領域を表すＮＡＣＫメッセージを送信する。同じパケット内に複数のバイト領域が存在することが可能である。ＮＡＣＫメッセージを受けて、送信装置１０は元のオブジェクトからバイト領域を再送信する。ワード領域に加えて、受信装置１０は、バイト領域の代わりにビット領域を算出し、それらが再送信されるよう要求してもよい。

本発明の別の実施形態では、ソースブロックの、ソース記号よりも、欠落している冗長符号化記号が識別され、そのすべてまたは一部が再送信される。受信装置２０から送信装置１０（１つを超える送信装置があってもよい）に送信されたＮＡＣＫは、したがって冗長記号に基づくものである。このスキームは特に、符号化された「冗長記号」だけが送信され、符号化されていない「ソース記号」は送信されず、また一般に、各ソースブロックにおける冗長符号化記号の一定の閾値数はソースブロックを完了する必要があり、したがってファイルを再構成する必要がある、体系的なＦＥＣスキームに適用できる。

例えば、各ソースブロックにつき送信装置によって送信される記号が１０００あるような典型的なＦＥＣスキームにおいて、ファイルの配信を完了する（または正しく行う）ために受信装置によって受信されるよう要求される閾値数はちょうど５００である。しかしながら、この典型的な事例において、受信装置が得る記号は、４９０だけである（単一のソースブロックから符号化記号のみが欠落していると想定する。いくつかのソースブロックから符号化記号が欠落していれば、以下の算出は欠落している記号を有する各ソースブロックについて行われる必要がある）。そのようなシナリオにおいて、各ファイルのソースブロックごとに当てはまるものとしては以下が考えられる。
１．受信装置が欠落記号を識別する；受信装置がブロックを完了するために十分な数を算定する；受信装置が欠落記号の一部（完了するために十分なもの）についてＮＡＣＫ
する；送信装置がこれらの記号を再送信する。
２．受信装置が欠落記号を識別する；受信装置がすべての欠落記号にＮＡＣＫする；送信装置がこれらの記号をすべて再送信する。
３．受信装置が欠落記号を識別する；受信装置がすべての欠落記号にＮＡＣＫする；送信装置がブロックを完了するのに十分な数を算定する；送信装置が欠落記号の一部（「十分な」数を数えて）を選択する；送信装置がこれらの記号を再送信する。
４．受信装置が受信した記号に肯定応答する（ＡＣＫする）；送信装置が欠落記号を識別する；送信装置がこれらの記号をすべて再送信する。
５．受信装置が受信した記号にＡＣＫする；送信装置が欠落記号を識別する；送信装置がブロックを完了するのに十分な数を算定する；送信装置が欠落記号の一部（「十分な」数を数えて）を選択する；送信装置がこれらの記号を再送信する。

１つを超える記号、１つを超えるソースブロックおよび／または１つを超えるファイルが各ＮＡＣＫにおいて参照されるようにＮＡＣＫ（またはＡＣＫ）を結合させるという選択は、アプリケーションごとの最適化に関する問題である。

「十分な」記号の定義は、特に他の何らかの手段（ＴＣＰトランスポート等）によって修復が確実に行われる場合、閾値数（上記の例では５１０のうち１０）を完全にするために要求される数そのものであってよく、または、リンクによる損失を見越してそれより多くてもよい（例えば、上記の例では記号の５１％が失われており、同じ通信チャネルを再度使用するならば同様のことが予測でき、したがっておそらく１０×（１００／５１）＝２０の記号を再送信するのがより適切であろう。また、さらに安全マージンを追加してもよく（例えば、バーストエラーを処理するため）、これが３つの記号である場合は、「やり遂げる」のに必要なのが１０だけであっても、２３の記号を使用して修復することができるであろう。乗数（ここでは「１００／５１」）および定数（ここでは３）のいずれも、（これらの例のように）一定のパケット損失を想定するか、または元の送信の損失パターンに依存してよい。例えば、送信装置は損失記号の分布を分析することができ、それが不均一であった場合（例えば、３つの連続する記号が約２０の記号ごとに頻繁に損失する）、いくつかの（例えば、２０の記号につき３つ）追加の記号を加えてもよい（この例においては、ここでも２３の記号という結果になる）。

さらにもう１つの例として、ファイルを完了するために必要なソースブロックにおける１０の記号の前記閾値数を識別した後、受信装置は、これらの１０の記号を再送信するよう要求するＮＡＣＫを送信装置に送信することが考えられる。送信装置はこれらの記号を以前にキャッシュに格納されている通りに再送信してもよく、または代替の方法においては、送信装置は記号に対応するファイルまたはソースブロックにおいてＦＥＣ符号化の反復を行い、これらの記号を再送信する。この後者の方法によって、初期送信、分離される、および場合によっては異なるサーバ設備に配備される修復サーバ機能が可能になる。

さらに別の例として、受信装置が５１０の欠落記号のそれぞれに関するＮＡＣＫ（または、代替の実施形態において、４９０の記号を受信したという肯定応答）を送信することが考えられる。送信装置はその後、１０の欠落記号のみを再送信するか、または５１０すべての欠落記号を再送信する。再送信するのは、以前にキャッシュに格納した記号か、新しくＦＥＣ符号化した記号であってよい。

記号識別に基づいて受信装置から送信装置へ送信された再送信（または修復）要求に加え、ファイルおよび／またはそれらのソースブロックにおいて要求は１つ以上のバイト領域を特定することができる。これは、受信した記号がブロックから欠落しているバイト領域を算定するのに十分である場合に適用できる。

欠落パケットを再送信するために、ポイントツーポイントまたはポイントツーマルチポイント送信が使用できることを説明してきた。明確にするための実施形態は、ポイントツーポイント再送信（または修復）を対象とする。この実施形態において、関係する各受信装置はポイントツーポイント接続（またはセッション）上で送信装置に否定応答（ＮＡＣＫ）メッセージを送信する。受信装置において受信されたＮＡＣＫの数および／または内容に応じて、受信装置は、
１）ポイントツーポイント接続を使用して欠落ブロックを各受信装置へ個別に送信するか否か、または、
２）ポイントツーマルチポイント接続（すなわち、マルチキャストまたは同類のもの）を使用して欠落ブロックを送信するか否か
の判断を下す。

多数の受信装置が同じ欠落パケットに関するＮＡＣＫ要求を送信した場合、２番目の選択肢がより望ましい。このように、単一の再送信で、複数の受信機の修復を行い、リソースを保存することが可能である。

図３は、本発明の実施形態に従って、システムおよび受信装置の詳細を示す。前記システムは、送信機１０、例えばＩＰネットワークまたは別の固定ネットワークやワイヤレスネットワークまたは固定およびワイヤレス（セルラー）ネットワークの組み合わせ等の送信ネットワーク３０、および受信装置２０を備える。受信装置２０は、携帯電話、衛星電話、携帯情報端末またはブルートゥース装置、ＷＬＡＮ装置、ＤＶＢ装置、もしくはその他同類のワイヤレス装置であってよい。装置２０は、内部メモリ２１、プロセッサ２２、オペレーティングシステム２３、アプリケーションプログラム２４、ネットワークインターフェイス２５および識別＆ＮＡＣＫ機構２６を含む。内部メモリ２１は、プロセッサ２２、オペレーティングシステム２３およびアプリケーションプログラム２４を収容する。識別＆ＮＡＣＫ機構２６により、データパケットの識別を行い、データ送信における欠落または壊れたパケットに応じて、送信装置１０へＮＡＣＫおよびデータを送信することが可能になる。装置２０は、ネットワークインターフェイス２５およびネットワーク３０を介して送信装置１０およびその他の装置と通信を行うことができる。

図４は、本発明の実施形態に従って、送信装置１０を示す。送信装置１０は、例えば、ネットワークサーバまたはファイル（またはメディア）配信を対照とした任意の適合する装置であってよい。装置１０は、内部メモリ１１、プロセッサ１２、オペレーティングシステム１３、アプリケーションプログラム１４、ネットワークインターフェイス１５および送信＆再送信機構１６を含む。内部メモリ１１は、プロセッサ１２、オペレーティングシステム１３およびアプリケーションプログラム１４を収容する。送信＆再送信機構１６により、データパケットの送信、および受信装置２０から受信したＮＡＣＫに応じてデータパケットの再送信を行うことが可能になる。装置１０は、ネットワークインターフェイス１５およびネットワーク３０を介して受信装置２０およびその他の装置と通信を行うことができる。

欠落したデータパケットの識別およびその再送信に関する手順は、ソフトウェアにより実行できる。受信装置２０に格納され、プロセッサ２０において作動するプログラムコードを備えるコンピュータプログラム製品は、送信セッションの受信終了時に前記手順を実行するために使用することができ、一方、送信装置１０に格納され、プロセッサ１２において作動するプログラムコードを備えるコンピュータプログラム製品は、送信終了時に前記手順を実行するために使用することができる。

以下、本発明の実施形態の利点について論じる。本発明の実施形態は、欠落データを再送信するための新しいフレームワークを提供する。

以上に基づき明らかとなったように、このフレームワークにより、以下のシナリオにおける欠落データの再送信が可能になる。
・ＦＬＵＴＥのセッション内において、欠落パケットに関する情報が送信装置でまだ利用可能であり、短時間のうちに送信装置からＮＡＣＫが受信された場合。
・欠落パケットがもともと送信された先の、元来のＦＬＵＴＥセッション外に、それらのパケットを再送信するよう要求された場合。この再送信は、ＦＬＵＴＥまたは別の送信方法を使用して発生する場合がある。

本発明の実施形態が提供する利点の一部は、
・（連続的または非連続的な）欠落ブロック（またはパケット）を独自に識別する方法
・同じ（または多数の）セッション上で１つの（または複数の）ファイルの欠落ブロック（またはパケット）を識別する方法
・多数の送信プロトコル上で欠落ブロック（またはパケット）を識別し再送信する方法
・適時に欠落パケットを再送信する能力。ここで適時は、可能な基準（利用可能な帯域幅、割安な通信事業者等）を使用して選択される
・確実に（基礎となるトランスポートプロトコルが信頼できる）および単一の修復転送セッションで欠落パケットを再送信する能力
である。

したがって、本発明の実施形態は、一対多数マルチキャストセッションの内外いずれかにおいて欠落したブロックのために、否定応答（ＮＡＣＫ）メッセージを識別し、送信するための方法を提示するものである。

本発明の特定の実行および実施形態について説明した。当業者には、本発明が上記に提示した実施形態の詳細に限定されるものでなく、本発明の特徴から逸脱することなく、同等の手段を使用してその他の実施形態で実行できることが明らかである。本発明の範囲は、添付の特許請求の範囲によってのみ限定される。

本発明の実施形態に従い通信を行っている送信装置および受信装置を示す。 図２Ａは、本発明の実施形態に従う簡略化したプロトコルアーキテクチャを図示している。図２Ｂは、本発明の別の実施形態に従う簡略化したプロトコルアーキテクチャを図示している。 本発明の実施形態に従うシステムおよび受信装置の詳細を示す。 本発明の実施形態に従う送信装置を示す。

Claims (32)

1. 一対多数送信が可能なシステム内において、ファイル配信のために受信機が実行する方法であって、
   送信機から送られてきたファイルの１つ以上のデータブロックを受信することと、
   受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別することと、
   前記データブロックを再送信するため動作を実行することとを含み、
   前記データブロックを識別することは、ブロック番号、符号化識別子、および前記ファイルのファイル情報を含むその他の識別情報に基づいて行われ、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、方法。
2. 前記その他の識別情報がセッションパラメータのセットを含む、請求項１に記載の方法。
3. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項１に記載の方法。
4. 一方向トランスポートでのファイル配信を対象とし、一対多数送信シナリオが可能なセッションベースのプロトコルが使用される、請求項１に記載の方法。
5. 前記プロトコルが、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ）であり、前記ブロック番号がソースブロック番号であり、前記符号化識別子が符号化記号識別子であり、識別に使用されるセッションパラメータのセットがソースアドレス、宛先アドレスおよび送信セッション識別子から成るグループから選択され、前記識別において、ＦＬＵＴＥによって定義されるように送信オブジェクト識別子が使用される、請求項４に記載の方法。
6. 前記その他の識別情報がブロック情報を含む、請求項１に記載の方法。
7. 一方向トランスポートでのファイル配信を対象とし、一対多数送信シナリオが可能なセッションベースのプロトコルが使用される、請求項１に記載の方法。
8. 前記プロトコルが、ＦＬＵＴＥ（Ｆｉｌｅ Ｄｅｌｉｖｅｒｙ ｏｖｅｒ Ｕｎｉ−ｄｉｒｅｃｔｉｏｎａｌ Ｔｒａｎｓｐｏｒｔ，一方向トランスポートでのファイル配信）または類似のものであり、前記ブロック番号がソースブロック番号であり、前記符号化識別子が符号化記号識別子であり、前記ファイルパラメータは、前記ファイル長と暗号化コードの少なくともいずれかを含み、
   前記識別において、使用されたブロックアルゴリズムと、最大ソースブロック長・符号化記号長・ファイル長などのブロックパラメータとから成るグループから選択されるブロック情報が使用される、請求項７に記載の方法。
9. 前記方法が、一対多数送信シナリオでの送信を対象としたプロトコルの使用におけるデータブロック送信のために、前記送信機と前記受信機との間にセッションを提供することを含む、請求項１に記載の方法。
10. 前記データブロックを再送信するための措置を講じることが、前記受信機から前記送信機へ否定応答メッセージを送信することを含む、請求項１に記載の方法。
11. ファイル配信が第１のセッションにおいて実行され、前記否定応答メッセージが同一の第１のセッション中に再送信を発生させる、請求項１０に記載の方法。
12. ファイル配信が第１のセッションにおいて実行され、前記否定応答メッセージが前記第１のセッション以外のセッション中に再送信を発生させる、請求項１０に記載の方法。
13. 前記その他のセッションが、前記第１のセッションが終了した後に確立されたセッションである、請求項１２に記載の方法。
14. 前記否定応答メッセージが、１つ以上のデータブロックまたはパケットの再送信要求を含む、請求項１０に記載の方法。
15. 前記否定応答メッセージが送信セッションの終了時に送信され、前記否定応答メッセージが、欠落したブロックの再送信を行うために新しいセッションの開始を示す、請求項１４に記載の方法。
16. セッションコンテキストが後の使用のために格納される、請求項１に記載の方法。
17. 前記セッションコンテキストが、前記セッション内に、前記セッションコンテキスト自体を独自に識別する識別子に加えて、ソースブロック番号、符号化記号識別子、送信セッション識別子、および送信オブジェクト識別子などの識別子を含む、請求項１６に記載の方法。
18. データブロックの初期送信がＦＬＵＴＥセッションにおいて行われ、再送信が同一もしくは異なるＦＬＵＴＥセッション、または別のセッションにおいて行われる、請求項１に記載の方法。
19. 否定応答メッセージがポイントツーポイントセッション上で受信機のセットから送信機へ送信され、再送信がポイントツーマルチポイントセッション上で行われる、請求項１に記載の方法。
20. 前記受信機のセットが１つを超える受信機を含む、請求項１９に記載の方法。
21. 再送信がユニキャスト（ポイントツーポイント）送信によって行われる、請求項１に記載の方法。
22. 一対多数送信が可能なシステム内におけるファイル配信のための受信装置であって、
    送信機から送られてきたファイルの１つ以上のデータブロックを受信する手段と、
    受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別する手段と、
    前記データブロックを再送信させるための動作を実行する手段とを備え、
    前記識別する手段は、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、受信装置。
23. 前記その他の識別情報がセッションパラメータのセットを含む、請求項２２に記載の受信装置。
24. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項２２に記載の受信装置。
25. 前記その他の識別情報がブロック情報を含む、請求項２２に記載の受信装置。
26. 一対多数送信が可能なシステム内におけるファイル配信のための受信装置において実行可能なコンピュータ・プログラムであって、
    前記受信装置に、送信機から送られてきたファイルの１つ以上のデータブロックを受信させるためのプログラムコードと、
    前記受信装置に、受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別させるためのプログラムコードと、
    前記受信装置に前記データブロックを再送信させるためのプログラムコードとを備え、
    前記識別するためのプログラムコードは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、ただし前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    コンピュータ・プログラム。
27. 一対多数送信が可能なシステム内におけるファイル配信のための送信装置であって、
    少なくとも１つの受信機へ、ファイルの１つ以上のデータブロックを送信する手段と、
    前記受信機において、受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルデータブロックを再送信する手段と、
    を備え、ただし前記再送信されるデータブロックは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて識別されたものであり、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    送信装置。
28. 一対多数送信が可能なシステム内におけるファイル配信のための送信装置において実行可能なコンピュータ・プログラムであって、
    前記送信装置に、少なくとも１つの受信機へ、ファイルの１つ以上のデータブロックを送信させるためのプログラムコードと、
    前記送信装置に、前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを再送信させるためのプログラムコードと、
    を含み、ただし前記再送信されるデータブロックは、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて識別されたものであり、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    コンピュータ・プログラム。
29. 一対多数送信が可能なシステムであって、
    送信機から少なくとも１つの受信機へ、ファイルの１つ以上のデータブロックを転送する手段と、
    前記受信機において受信すると予期されたがまったく受信されなかった、または誤って受信された、前記ファイルのデータブロックを識別する手段と、
    前記データブロックを再送信するための動作を実行する手段とを備え、
    前記識別する手段は、ブロック番号、符号化識別子および前記ファイルのファイル情報を含むその他の識別情報に基づいて前記データブロックを識別するように構成され、前記ファイル情報は、前記ファイルの統一リソース識別子かファイルパラメータの少なくともいずれかを含む、
    システム。
30. 前記その他の識別情報が、セッションパラメータのセットおよび送信オブジェクト識別子を含む、請求項２９に記載のシステム。
31. 前記その他の識別情報が送信オブジェクト識別子を含む、請求項２９に記載のシステム。
32. 前記その他の識別情報がブロック情報を含む、請求項２９に記載のシステム。

Images