JP2007531458A - マルチキャスト／ブロードキャストデータ配信のためのデータ修復強化法 - Google Patents

Abstract

【課題】マルチキャスト又はブロードキャスト送信におけるデータ修復強化に関する技術を提供する。
【解決手段】送信側（１０）がポイント・ツー・マルチポイントセッションを通じて複数の受信側（２０）にデータを送信する方法、システム、装置、及びコンピュータコード製品。受信側は、予期されていたが受信されなかったデータを要求するデータ修復要求を送信側（１０）に送信し、送信側（１０）は、ポイント・ツー・マルチポイントセッションを通じて予期されていたが受信されなかったデータを再送信する。送信側（１０）はまた、ポイント・ツー・マルチポイントセッションを通じた再送信が全てのエラーを修正しない場合に、個々の受信側とのポイント・ツー・ポイントデータ修復セッションを計画することができる。送信側（１０）は、ポイント・ツー・マルチポイントセッションを使用する受信側の数に基づいて、ランダム化機構を使用してポイント・ツー・ポイント修復セッションを遅延するように構成することができる。
【選択図】図１Ｂ

Description

本発明は、一般的に、マルチキャスト及びブロードキャスト送信技術及びサービス、すなわち、少なくとも１つのデータソース（又は送信側）と少なくとも１つの受信側とのサービスに関する。より具体的には、本発明は、マルチキャスト又はブロードキャスト送信におけるデータ修復強化に関する。

ＩＰマルチキャスト、ＩＰデータキャスティング（ＩＰＤＣ）、及びマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）のようなシステムを通じた１対多数（すなわち、ポイント・ツー・マルチポイント）サービスでは、ファイル配信（又は、個別の媒体配信又はファイルダウンロード）は、重要なサービスである。ファイル転送プロトコル（ＦＴＰ）及びハイパーテキスト転送プロトコル（ＨＴＴＰ）のようなポイント−ツー・ポイントプロトコルを通じてファイルを配信するための特徴の多くは、１対多数シナリオに関して問題がある。特に、通信制御プロトコルＴＣＰのような類似の１対１（すなわち、ポイント・ツー・ポイント）肯定応答（ＡＣＫ）プロトコルを使用した信頼することができるファイルの配信、すなわち、保証されたファイル配信は、実現不可能である。

「インターネット技術標準化委員会（ＩＥＴＦ）」の「高信頼マルチキャストトランスポート（ＲＭＴ）ワーキンググループ」は、エラーに対して回復力のあるマルチキャスト転送プロトコルの２つのカテゴリを標準化する過程にある。第１のカテゴリでは、信頼性は、（予防型）順方向エラー訂正法（ＦＥＣ）の使用を通じて、すなわち、誤ったデータを再構成する場合に受信側を助けることができる冗長データのある一定の量を送信することによって実施される。第２のカテゴリでは、信頼することができるマルチキャストトランスポートを実施するために受信側フィードバックが使用される。「非同期式階層化コーディング」（ＡＬＣ、ＲＦＣ３４５０）は、第１のカテゴリに属するプロトコルインスタンス化であり、「ＡＣＫ指向高信頼マルチキャスト（ＮＯＲＭ）」プロトコルは、第２のカテゴリの例を示している。ＡＬＣ及びＮＯＲＭプロトコルの詳細は、ＩＥＴＦの「ワーキンググループ」によって準備された「非同期式階層化コーディング（ＡＬＣ）プロトコルインスタンス化」（ＩＥＴＦ、ＲＦＣ３４５０）及び「ＮＡＣＫ指向高信頼マルチキャストプロトコル」（インターネット草案）という名称の文献に更に詳しく説明されている。これらの文献の内容は、本明細書に引用により完全に組み込まれている。

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

簡単には、ＡＬＣプロトコルは、受信側にこま切れにされたパケット又は受信されなかったパケットを再構成させる予防型ＦＥＣベース方式である。ＡＬＣプロトコルは、複数のチャンネルでＦＥＣ符号化を使用し、送信側に複数の速度（チャンネル）で異機種の可能性がある受信側にデータを送信させる。更に、ＡＬＣプロトコルは、輻輳制御機構を使用して異なるチャンネル上の異なる速度を維持する。

ＡＬＣプロトコルは、アップリンク信号方式が必要ないのでユーザの数の面で大規模に拡張可能である。従って、より多くの受信側を追加することは、システムに対する要求を増すことはない。しかし、ＡＬＣプロトコルは、受信が保証されないので１００％信頼性のあるものではなく、すなわち、それは、高信頼ではなくむしろ頑強なものとして一般的に説明されるであろう。

これに対してＮＯＲＭは、受信側に到達することが予期されていたデータのどのパケット（又は、これ以外では「データブロック」と定められる）が受信側で受信されなかったか（又は、誤って受信したか）を信号で伝えるために否定応答（ＮＡＣＫ）メッセージの使用を指定する。言い換えると、受信側は、ＮＡＣＫメッセージを用いて送信側に送信パケットの損失又は損傷を示す。従って、データ送信から一部のデータブロックを「逃した」受信側は、ＮＡＣＫメッセージを送信側に送り、逃した1つ又は複数のデータブロックを送信側に再送信するよう要求することができる。ＮＯＲＭプロトコルはまた、任意的に、予防型の頑強な送信のためのパケットレベルＦＥＣ符号化の使用を考慮している。

「単方向トランスポートによるファイル配信（ＦＬＵＴＥ）」は、ＦＥＣ（ＲＦＣ３４５２）及びＡＬＣビルディングブロック上に構築される１対多数トランスポートプロトコルである。これは、送信側から受信側への単方向システム上のファイル配信用である。これは、無線ポイント・ツー・マルチポイント（マルチキャスト／ブロードキャスト）システムに適するように特化されている。ＦＬＵＴＥプロトコルの詳細は、上述の「ＩＥＴＦのワーキンググループ」によって準備された「ＦＬＵＴＥ−単方向トランスポートによるファイル配信」（インターネット草案）という名称の文献に詳細に説明されている。この文献の内容は、引用により本明細書に完全に組み込まれている。

ＮＡＣＫメッセージは、一般的にはＮＯＲＭ特定ではないが、それらはまた、ＦＬＵＴＥのような他のプロトコル又はシステムと関連して使用することができる。ＡＣＫは、受信側が１つ又はそれよりも多くのデータパケットを受信した後にそれらのデータパケットが正しく受信したということを通知するために送る応答メッセージである。ＮＡＣＫは、到着することが予期されていたが受信されなかったパケットに対して受信側が送信側に送る応答である。

マルチキャスト又はブロードキャスト環境にある時には、データ送信は、１対多数方式で発生する。送信にエラーがあり、異なる受信側が異なるエラー率に露出される場合（例えば、ＭＢＭＳでは、異なるセルのユーザは、異なる信号品質、及び結果として異なるエラー率を経験する場合がある）、高いデータ信頼性を提供することに問題が生じる。それは、ＦＥＣの使用及び／又は修復セッションの使用を通じて達成することができる。

ＦＥＣは、ある程度のエラー回復力を許して受信側が送信データを再構成することを可能にするために、送信データにある一定の量の冗長性を提供する。しかし、ＦＥＣの１つの問題は、ＦＥＣが通常はエラーのないエラー回復を提供しないか、又はチャンネル帯域幅要件を増すデータ冗長性の多くの使用という犠牲を払って完全なエラー回復を提供することである。

修復セッション（受信側と送信側の間）は、ＦＥＣ補足するために（残留チャンネルエラー率を低減又はなくすために）用いることができ、又はエラー回復のための唯一の方法として単独で使用することができる。修復セッションは、別のセッションを使用してポイント・ツー・ポイントチャンネル上で発生させることができる。この場合、マルチキャスト／ブロードキャスト送信中に一部のデータを逃した全受信側は、逃したパケットの再送信を要求するために送信側にＮＡＣＫ要求を送信する。しかし、全受信側が少なくとも１つのデータパケットを逃した場合、全受信側は、送信側とのポイント・ツー・ポイント接続を同時に設定することになり、フィードバック収束、すなわち、ネットワーク内の輻輳（多数のＮＡＣＫのためのアップリンク方向、及び多数の同時再送信及びネットワーク接続要求のためのダウンリンク方向で）、及び送信側の過負荷を引き起こす。この状況は、ＭＢＭＳネットワークにおける場合に当て嵌まる例えば何千のユーザを考えると重大である。

従って、拡張可能であり、かつマルチキャスト及びブロードキャスト環境でのメッセージの効率的な修復を提供するデータ修復のための改良された装置、システム、及び方法に対する必要性が存在する。

米国特許出願出願番号第１０／７８２，３７１号 「非同期式階層化コーディング（ＡＬＣ）プロトコルインスタンス化」（ＩＥＴＦ、ＲＦＣ３４５０）、ＩＥＴＦワーキンググループ 「ＮＡＣＫ指向高信頼マルチキャストプロトコル」（インターネット草案） 「ＦＬＵＴＥ−単方向トランスポートによるファイル配信」（インターネット草案）、ＩＥＴＦワーキンググループ

システム、方法、装置、及びコンピュータコード製品の様々な実施形態を本発明に従って開示する。様々な実施形態は、ポイント・ツー・マルチポイント通信が可能であり、ポイント・ツー・マルチポイントセッションを通じて送信側から複数の受信側にデータを送信する段階と、いずれかの予期されたデータが受信されなかったかを判断する段階と、データが失われた場合に送信側にデータ修復要求を送信する段階と、ポイント・ツー・マルチポイントセッションを通じて失われたデータを再送信する段階を含むことができる。送信側はまた、ポイント・ツー・マルチポイント再送信がデータ損失問題を修正しなかった場合に、ポイント・ツー・ポイント修復セッションを計画して実行するよう構成することができる。

ランダム化機構は、送信側がポイント・ツー・マルチポイントセッションを通じて受信されなかったとして示されたデータを再送信するまでポイント・ツー・ポイントデータ修復を遅延するために使用することができる。ランダム化機構は、複数の受信側に含まれた受信側の数を考慮するように構成することができる。代替的に（又は追加的に）、送信側は、ポイント・ツー・ポイント修復が始まることになる時間を通知するために、複数の受信側にポイント・ツー・ポイント修復トークンを送信することができる。

本発明の別の態様では、送信側装置と、送信側装置からのデータを受信することができる少なくとも１つの受信側と、ＨＴＴＰサーバと、ＦＬＵＴＥサーバとを含むシステムにおけるデータ修復の方法を開示する。本方法は、一部の予期されるデータが少なくとも１つの受信側によって受信されなかったと判断する段階、少なくとも１つの受信側からＨＴＴＰサーバにデータ要求を送信する段階、ＨＴＴＰサーバから少なくとも１つの受信側にＦＬＵＴＥのＵＲＩを含むＨＴＴＰリダイレクトメッセージを送信する段階、少なくとも１つの受信側からＦＬＵＴＥサーバにセッション要求を送信する段階、及びＦＬＵＴＥサーバと少なくとも１つの受信側の間でＦＬＵＴＥセッションを開始する段階を含むことができる。

マルチキャスト又はブロードキャストシステムにおいてデータを修復するための様々な方法及びシステムが存在する。本明細書においてその全内容が引用により組み込まれている、２００４年２月１８日出願の「データ修復」という名称の米国特許出願（出願番号第１０／７８２，３７１号）は、データ修復のための効率的な方法を説明している。この出願は、受信側からのある一定の数のＮＡＣＫ要求の受信後に、送信側がそれ自体の決定方針に基づいて受信側によってＮＡＣＫされたパケットの総数の一部、例えば受信側から最も多く要求されたパケットをポイント・ツー・マルチポイントを通じて再送信するように判断することができることを提案している。送信側はまた、ネットワークリソースを節約するためにポイント・ツー・ポイント接続を閉じることができる。

これらのような方法の１つの欠点は、最も多くＮＡＣＫされたパケットだけを再送信することが、異なるユーザのＮＡＣＫ要求間に統計的な相関関係が殆どない場合に総エラー回復をもたらさない場合があることである。例えば、特定のエラー状況がパケット１、２、及び３に対して受信側＃１ＮＡＣＫ、及びパケット４、５、及び６に対して受信側＃２ＮＡＣＫなどである場合、送信側は、「最も要求されたパケット」であるものを導出することができず、この結果、ポイント・ツー・マルチポイント修復はその効率を失う場合がある。本発明は、データ修復のための改良された方法、装置、及びシステムを提案する。

図１Ａは、本発明の実施形態によるポイント・ツー・マルチポイントデータ送信シナリオを示している。送信側装置１０は、サーバ、ＩＰベースの装置、ＤＶＢ装置、ＧＰＲＳ（又はＵＭＴＳ）装置、又は１対多数方式でマルチキャストデータブロック（又はパケット）を受信側装置２０に送信するためのＡＬＣ機構及び／又はＦＥＣ機構のような予防型順方向エラー修正法を使用することができる類似の装置とすることができる。各受信装置２０は、紛失ブロック（受信されなかった又は誤って受信したブロック）に関して送信側装置１０に否定応答ＮＡＣＫメッセージ（又は要求）を送信するように構成することができる。

データは、オブジェクトとして送信側１０から受信側２０に転送することができる。例えば、ファイル、ＪＰＥＧ画像、及びファイルスライスは、全てオブジェクトである。オブジェクトは、一連のデータブロックとして送信することができる。各データブロックは、ソースブロック番号（ＳＢＮ）又は類似の識別子と呼ばれる番号を有することができ、この番号は、各ブロックを識別するのに使用することができる。ブロックは、符号化記号のセットによって表すことができる。符号化記号識別子（ＥＳＩ）又は類似の識別子は、次に、データパケット（又はブロック）のペイロードで運ばれる符号化記号が上述のオブジェクト（例えば、ファイル）からどのように作成されたかを示すことができる。

ポイント・ツー・マルチポイントシステムでは、送信側１０は、オブジェクトを表すデータブロック又はパケットを多くの受信側２０に同時にブロードキャストすることができる。受信側２０が予期していたパケットの全てを受信しなかった場合、受信側は、どのパケットが受信されなかったかを示すＮＡＣＫメッセージをサーバ１０に送信することができる。図１Ｂは、本発明の実施形態によるいくつかの異なるデータ修復方法を示している。一般的に、紛失データの修復は、１つの送信側１０と１つの受信側２０の間に設定されたポイント・ツー・ポイント修復セッションを使用することにより、又は送信側１０と１つよりも多い受信側２０の間のポイント・ツー・マルチポイントセッションを使用することによって実行することができる。修復セッションでは、全体的又は部分的な（場合によって異なる）紛失データは、送信側１０から受信側２０に再送信することができ、又は全送信を繰り返すことができる。修復は、オリジナルの送信側１０から又はオリジナルサーバとの接続を有して送信データ／情報をバッファに入れるように構成された「第三者サーバ」又は修復サーバ（又は、単なる別のサーバ（図示せず））から行うことができる。このサーバは、例えば、オリジナル送信側（例えば、ＢＭ−ＳＣ（ブロードキャストマルチキャスト−サーバセンター）とも呼ばれるＭＢＭＳサーバ）と同一場所に配置することができ、又は例えばＵＭＴＳオペレータのネットワーク内の別のサーバとすることができる。

一般的に、信頼することができるマルチキャストシステムは、マルチキャストのマルチパーティ性のために拡張容易性の問題を呈する受信側−サーバ制御及びデータメッセージングを要求するという問題を示すことが分かっている。特に問題になるいくつかの分野がある。例えば：
ａ）多くの無線チャンネル及び無線帯域幅をアクティブ化するのに必要な時間が多くの修復が同時に行われるのを不可能にする、制限された無線帯域幅及びアクティブ化リソース、
ｂ）「修復コンテンツ」データを供給しているサーバシステムが、ある一定の時間ウィンドウ内の要求（メッセージング）及び関連するセッションコンテキストデータの制限された数及び同時データ転送セッションの制限された量しか処理できない、制限されたサーバ機能、及び
ｃ）同時に修復を要求する全ユーザに利用可能にすることができるデータ速度が多くの場合にそのサービスを提供するには不十分である、全体的なシステムにおける１つ又はそれよりも多くの障害による制限されたエンド・ツー・エンド帯域幅。

従って、これらの制限のいずれか又は全ての下で拡張容易性を増すのに使用することができる１つの要因は、メッセージングを時間で分割すること、又は可能な場合にメッセージングを完全に防ぐことである。本発明の一実施形態は、拡張可能で信頼することができるマルチキャストを提供するためにＮＡＣＫ抑制を可能にすることができる方法、装置、及びシステムに関する。

本発明の一実施形態は、少なくとも１つの受信側２０によって要求された全パケットがポイント・ツー・マルチポイントベアラでサーバ１０によって再送信されることを提案する。この実施形態では、受信側２０は、ポイント・ツー・ポイント（ｐｔｐ）ベアラとポイント・ツー・マルチポイント（ｐｔｍ）ベアラの両方を同時に設定するように構成することができる。ｐｔｐベアラは、例えば、米国特許出願第１０／７８２，３７１号で説明するように修復要求のサービスを提供するために使用することができる。本発明の一実施形態は、上述の特許出願で説明したものに類似したランダム化規則を使用することができる。しかし、本発明の実施形態は、ダウンリンクｐｔｐベアラを使用する代わりにダウンリンクｐｔｍベアラで紛失データを再送信することができる。

この実施形態では、受信側が計算したランダムバックオフ値のためにその要求する順番がまだ来ていない受信側２０は、ｐｔｍチャンネルを通じて再送信した紛失パケットを受信することによって受信側自体の損失を修復する機会を有することができる。受信側２０がｐｔｍチャンネルを通じて紛失データパケットを受信した場合、受信側２０は、このデータを使用してファイルを再構成することができ、要求のためのパケットのリストから紛失データパケットを除くことができる。受信側２０がその計算された要求時間の前にその紛失データの全てを受信することは可能であり、その場合、受信側は、あらゆる修復要求を作ることを止めることができるであろう。

本発明の別の実施形態では、ｐｔｐ修復は、上述のｐｔｍ修復機構と共に送信側１０によって提供される。これは、受信側２０の全てがｐｔｐ及びｐｔｍベアラの両方を同時にオープンにできない場合のセッションで特に有用であると考えられる。この場合、より高い効率のために、送信側１０は、ｐｔｐ修復に対する要求を遅延するようにランダム化機構を指示することができる。これは、ｐｔｍベアラでの修復を可能にし、最初に行われる受信側２０のより多い数をもたらすことができる。これを行うための１つの方法は、例えば、送信側１０によって受信側２０に送信した閾値（Ｘ、Ｙ、Ｚなど）の使用によるものである。受信側２０は、次に、その修復要求を計画するように構成することができる。本発明の一実施形態に従って、修復要求を計画するための受信側２０に対する１つのサンプル規則は、以下の通りである：
ｐｔｍ修復が可能である場合、最初の配信セッションの最後から始めて、期間ＸにわたってＮＡＣＫを均一にランダム化し、そうでなければ、最初のセッション終了後のある一定の時間Ｙの後まで待ち、次に期間ＺにわたってＮＡＣＫをランダム化する。

送信側１０はまた、ｐｔｐ修復を始めなければならない時間を明確に信号で伝えることができる。このために、送信側は、ｐｔｐ修復トークンを受信側２０に送信し、ｐｔｐ修復を始められる時間（ｐｔｐ修復が始まる場合、ｐｔｐ修復セッションは、標準的なランダム化規則に従うことができる）を通知することができる。ｐｔｐ修復トークンを送信する前に、全ての修復がｐｔｍベアラで行われる。２つの同時発生のベアラ（例えば、ｐｔｐとｐｔｍ）を有することができない受信側２０は、従って、そのｐｔｐ修復ベアラを設定する前にトークンを待つことができる。修復トークンは、例えば、マルチキャスト／ブロードキャスト送信後の別々の「告知」でのＳＤＰを通じてなどを含むＩＳＯのＯＳＩプロトコルスタックのレイヤ１−７のいずれかでいずれかの通信プロトコルを使用して送信することができる。これはまた、マルチキャスト／ブロードキャスト送信内のＦＬＵＴＥファイル配信に含むことができる。別々の「トランスポートオブジェクト識別子（ＴＯＩ）」値は、ファイルコンテンツ自体とｐｔｐ修復コンテンツを区別するために使用することができる。本発明の一実施形態では、既にｐｔｍ修復を使用した受信側２０もｐｔｐ修復を使用することができる。これは、ｐｔｍ修復が確実に行われなかった場合、すなわち、ｐｔｍベアラで再送信したパケットが紛失した場合に有用になる。

ランダム化は、フィードバック収束を防ぐのに役立ち、効率を上げるためにバックオフ時間がシステム内の受信側２０の数に応じて計算されるのが好ましい。バックオフ時間が小さく選択された場合、フィードバック収束の危険性は、特にセッション内に多数の受信側２０が存在する場合に最小にならない可能性がある。他方、バックオフ時間が大きすぎる場合、フィードバック収束の危険性は低下するが、各受信側が修復要求を行える前に不必要に長い時間待つことを要求されるのでセッションにおいてごく僅かの受信側しか存在しない場合に非効率的になる。

送信側１０がセッションにおける受信側２０の数を知っている場合、送信側１０は、受信側２０の数に基づいてそのランダム化の値をスケーリングし、システムの性能を最適化することができる。セッションの１つのこのようなタイプは、ＭＢＭＳマルチキャストセッションであり、送信側１０は、受信側がセッション参加及び退去手順を信号で伝える必要があるので、受信側２０の数を導出することができる。一実施形態では、セッションでの受信側２０の数とランダム化値との間の線形関係は、必要な閾値を計算するのに使用することができる。例えば、米国特許出願第１０／７８２，３７１号で提案されたランダム化方法を使用すると：
閾値エラー率Ｗよりも下である場合、最初の配信セッションの最後から始めて期間ＸにわたってＮＡＣＫを均一にランダム化し、そうでなければ、最初のセッション終了後のある一定の時間Ｙが終わるまで待ち、次に期間ＺにわたってＮＡＣＫをランダム化する。

Ｗ、Ｘ、Ｙ、及びＺの値は、セッションの参加者の数（受信側の数）に応じて固定でき、かつ選択することができる。以下に示されているサンプルであるルックアップテーブルは、送信側装置１０に記憶することができ、適切なテーブルエントリへのルックアップは、閾値を選択するために使用することができる。

（表）

上述のテーブルは、単に１つのサンプルである点に注意すべきである。他の値及びテーブル構造も本発明の精神及び範囲から逸脱することなく使用することができる。

４つの値（又は、一般的に、修復セッションの開始時間をランダム化するための値）は、ＳＤＰ又はあらゆる他の適切な手段を通じて送信側から受信側に伝達することができる。値は、サービス告知とセッション開始時間又は最後の参加時間との間のいつでも受信側に伝達することができる。例えば、セッションがＳＤＰを通じて今告知され、２時間後（又は代替的に、サービス告知の配信から１．５時間後の最後のセッション接続時間）に始まるように計画された場合、ランダム化パラメータを有する第２のＳＤＰは、セッションの開始前のいずれかの時間にセッションに参加した受信側２０の数を考慮に入れる第２告知又はトークンを使用して送信される。この場合、受信側２０は、セッションに参加した受信側の実際の更新された数を考慮に入れるランダム化時間の指示を取得する。代替的に、パラメータは、ＦＬＵＴＥセッションのＦＤＴ内で伝達することができ、又はこれらの値の部分集合だけが受信側の数と共に変わることになる。

ここで図２Ａを参照すると、データ修復を提供する方法の一実施形態が開示されている。図２Ａに開示する方法は、ポイント・ツー・マルチポイントセッションを通じて送信側から複数の受信側にデータパケットを送信する段階（１００）を含む。受信側のいずれかが、一部の予期していたデータを受信しなかったと判断した場合、受信側のいずれかは、正しく受信されなかったデータパケットを要求するＮＡＣＫメッセージを送信側に送り、送信側は、これらのＮＡＣＫメッセージを受信する（１０２）。次に、送信側は、ポイント・ツー・マルチポイントセッションを通じて要求されたデータパケットを受信側に再送信する（１０４）。

本発明の別の実施形態が図２Ｂに示されている。この実施形態では、送信側は、ポイント・ツー・マルチポイントセッションの開始を指示し（１１０）、次に、セッションを使用している受信側の数に関する情報を収集する（１２０）。送信側は、次に、セッションを使用している受信側の数に基づいてランダム化値を計算し（１３０）、ランダム化値を受信側に送信する（１４０）。次に、送信側は、ポイント・ツー・マルチポイントセッションを通じて受信側へのデータパケットの送信を開始する（１５０）。受信側のいずれかが、予期していたデータパケットの全てを受信しなかった場合、受信側のいずれかは、失われたデータパケットの再送信を要求するＮＡＣＫメッセージを送信側に送信する。送信側は、これらのＮＡＣＫメッセージを受信し（１６０）、ポイント・ツー・マルチポイントセッションで要求されたデータパケットを再送信する。次に、サーバは、ポイント・ツー・ポイントセッションを通じてあらゆる残りのデータ修復要求のサービスを開始する（１８０）。ポイント・ツー・ポイントセッションは、ポイント・ツー・マルチポイントセッションを使用した受信側の数に基づいて送信側によって計算されたランダム化値に基づき、ある一定の期間にわたってランダム化される。

本明細書に説明されるデータ修復方法は、従来技術の方法に比べて特異な利点を提供する。例えば、受信側２０がダウンリンクｐｔｐを通す代わりにｐｔｍを通したｐｔｐ修復を通じて要求する修復ブロックを送信する段階は、ｐｔｐチャンネルをアンロードし、同じ修復ブロックを必要とする可能な他の受信側２０を助ける。また、受信側の数に応じてランダム化値をスケーリングする段階は、要求を送信するのに必要な遅延を最小にすると同時にフィードバック収束の危険性を防ぐのを助ける。

効率的な方法で多くのユーザにデータを送信するためのＦＬＵＴＥのような機構を使用する場合、紛失データを識別し、ＮＡＣＫし、更に再送信する方法が必要である。本発明の一実施形態では、これを行うためにＨＴＴＰを使用することができる。例えば、受信している端末は、送信サーバにあるファイル又はファイルの一部の再送信を要求するためにＨＴＴＰを使用することができる。場合によっては、サーバは、ファイルをいくつかの端末に再送信するよう要求される可能性があり、又はファイルを持たない可能性があり、このために要求を別のサーバに再転送する必要がある場合がある。本発明の１つの態様は、ＦＬＵＴＥ及び他のこのようなセッションに対するｐｔｍ修復のための効率的なシステム及び方法を提供する。

ＨＴＴＰ要求は、送信からデータの紛失セットを取得するために使用することができ、多数の受信側にある送信を再度受信することができるようにする修復機構を有することが望ましい。一実施形態では、これは、ＦＬＵＴＥのためのダウンロードＵＲＩを持ったＨＴＴＰリダイレクト機構を使用することによって実施することができる。ＦＬＵＴＥのためのダウンロードＵＲＩは、ＨＴＴＰのＵＲＬに類似のものにすることができる。すなわち、これは、ＨＴＴＰのＵＲＬに類似しているがＦＬＵＴＥにも適用可能である。ＦＬＵＴＥのＵＲＩは、ある一定のＦＬＵＴＥセッション中に送信される単一のファイルと呼ぶことができる。ＦＬＵＴＥのＵＲＩを使用して、ある一定のＦＬＵＴＥセッションからのファイルは、従って、一意的に識別することができる。

この実施形態では、ＨＴＴＰサーバは、受信側によって要求されたファイルがどのソースから利用可能であるかを受信側に示すことができる。ＨＴＴＰリダイレクト機構を使用することにより、ＨＴＴＰサーバは、送信を正しく受信しなかった１つ又はそれよりも多くの端末を、複数の受信側のための新しいｐｔｍ修復セッションを開始することができるＦＬＵＴＥサーバにリダイレクトすることができる。

この実施形態の別の態様では、ＨＴＴＰリダイレクト機構はまた、ＦＬＵＴＥセッション記述ファイル（ＳＤＰファイルなど）のロケーションを受信側に示すために使用することができる。セッション記述ファイルを使用することにより、受信側は、ＦＬＵＴＥセッションに参加することができ、関連のファイルを取得することができる。クライアントは、次に、既に受信されて記憶されたセッション記述を相互参照することができ、この特定のセッション記述ファイルを既に受信していたかを検査することができる。次に、クライアントは、ＨＴＴＰ／ＦＬＵＴＥなどを使用して紛失ファイル／パケット／リソースのフェッチを試みることができる。この実施例では、ＦＬＵＴＥのＵＲＩは、当該ファイルが属するＦＬＵＴＥセッション（すなわち、送信されて端末がこのファイルを受信した間のＦＬＵＴＥセッション）を説明したＳＤＰファイルのＵＲＩとすることができる。

他の実施形態では、ＨＴＴＰリダイレクトはまた、ペイロードとしてセッション記述ファイルを包含することができる。これは、ペイロードの絶対ＵＲＩを使用して及び／又は転送コードを使用して行うことができる。セッション記述ファイルがリダイレクトを行うために使用される場合、セッション記述ファイルをバージョン化することが望ましい。これは、拡張ヘッダを使用することによって又はメタデータエンベロープを使用することによって実施することができる。メタデータエンベロープは、セッション記述ファイルを封入するか又は参照し、バージョン化機構を提供する。この実施例では、ファイルのＵＲＬは、形式ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｆｉｌｅ／ｍｐ３のようなＨＴＴＰリダイレクトメッセージのヘッダに含むことができる。

図５は、ｐｔｍファイル修復セッションを開始するためにＦＬＵＴＥのＵＲＩ及びＨＴＴＰリダイレクト機構を使用する１つの方法の実施形態を示している。図５に示すように、ＦＬＵＴＥセッションの送信では、受信側は、完全なファイルを受信していないことを認識する場合がある。このような場合、受信側は、修復要求をＨＴＴＰサーバに送信することができる。ＨＴＴＰサーバのアドレスは、ＦＬＵＴＥセッション中に送信した修復情報から受信側に既知である。修復要求の取得に応じて、ＨＴＴＰサーバは、ＨＴＴＰを使用するいくつかの個々のｐｔｐ修復セッションではなく、ＦＬＵＴＥを使用するｐｔｍセッションを行う方がより効率的であると判断することができる。これは、受信した修復要求の数があまりにも多くＨＴＴＰサーバ自体が要求されたファイルを有していないなどのいくつかの理由のために行われるであろう。この場合、ＨＴＴＰサーバは、リダイレクトをファイルのＦＬＵＴＥのＵＲＩと共に受信側に送信することができる。ＨＴＴＰサーバからのリダイレクトの取得に応じて、受信側は、「セッション要求」をＦＬＵＴＥサーバに送信することができる。ＦＬＵＴＥサーバは、次に、「受信中」の潜在的に多くの受信側とｐｔｍＦＬＵＴＥセッションを開始することができる。ＦＬＵＴＥとＨＴＴＰサーバは、別々のエンティティとすることができるが、依然として同じ物理的機械上に位置することができる。

セッション記述のために使用することができるＳＤＰファイルの一例は、以下の通りである。
ｖ＝０
０＝ｕｓｅｒ１２３ ２８９０８４４５２６ ２８９０８４２８０７ ＩＮ ＩＰ６
２２０１：０５６Ｄ：：１１２Ｅ：１４４Ａ：１Ｅ２４
ｓ＝Ｆｉｌｅ ｄｅｌｉｖｅｒｙ ｓｅｓｓｉｏｎ ｅｘａｍｐｌｅ
ｉ＝Ｍｏｒｅ ｉｎｆｏｒｍａｔｉｏｎ
ｔ＝２８７３３９７４９６ ２８７３４０４６９６
ａ＝ｓｏｕｒｃｅ−ｆｉｌｔｅｒ：ｉｎｃｌ ＩＮ ＩＰ６^*２００１：２１０：１：２：２４０：９６ＦＦ：ＦＥ２５：８ＥＣ９
ａ＝ｆｌｕｔｅ−ｔｓｉ：３
ａ＝ｆｌｕｔｅ−ｃｈ：２
ｍ＝ａｐｐｌｉｃａｔｉｏｎ １２３４５ ＦＬＵＴＥ／ＵＤＰ ０
ｃ＝ＩＮ ＩＰ６ ＦＦ１Ｅ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ２４／１
ｍ＝ａｐｐｌｉｃａｔｉｏｎ １２３４６ ＦＬＵＴＥ／ＵＤＰ ０
ｃ＝ＩＮ ＩＰ６ ＦＦ１Ｅ：０３ＡＤ：：７Ｆ２Ｅ：１７２Ａ：１Ｅ３０／１

この例示的なファイルは、受信側がＦＬＵＴＥセッションに参加することができる方法を説明している。これは、送信側ＩＰアドレス、セッションのチャンネル数、セッションの各チャンネルに対する宛先ＩＰアドレス及びポート番号、セッションの「トランスポートセッション識別子（ＴＳＩ）」、及びセッションの開始及び終了時間に関する情報を提供する。

図３は、本発明によるシステム５及び受信側装置２０の一実施形態を示している。システム５は、送信側装置１０、送信ネットワーク３０、例えばＩＰネットワーク又は別の固定ネットワーク、無線ネットワーク又は固定及び無線（セルラー）ネットワークなどの組合せ、及び受信側装置２０を含むことができる。受信側装置２０は、例えば、携帯電話、衛星電話、携帯情報端末、「Ｂｌｕｅｔｏｏｔｈ」装置、ＷＬＡＮ装置、ＤＶＢ装置、又は他の類似の無線装置とすることができる。受信側２０は、内部メモリ２１、プロセッサ２２、オペレーティングシステム２３、アプリケーションプログラム２４、ネットワークインタフェース２５、及びＮＡＣＫ及び修復機構２６を含むことができる。内部メモリ２１は、プロセッサ２２、オペレーティングシステム２３、及びアプリケーションプログラム２４に適合するように構成することができる。ＮＡＣＫ及び修復機構２６は、データ送信における紛失又はこま切れにされたデータに応じてＮＡＣＫ処理及び修復手順を有効にすることができる。受信側装置２０は、ネットワークインタフェース２５及びネットワーク３０を通じて送信側装置１０及び他の装置と通信することができる。

図４は、本発明による送信側装置１０の一実施形態を示している。送信側装置１０は、例えば、ネットワークサーバ又はファイル（又は媒体）配信を目的としたあらゆる適切な装置とすることができる。送信側装置１０は、内部メモリ１１、プロセッサ１２、オペレーティングシステム１３、アプリケーションプログラム１４、ネットワークインタフェース１５、送信及び修復機構１６、及びデータ記憶装置１７を含むことができる。内部メモリ１１は、プロセッサ１２、オペレーティングシステム１３、及びアプリケーションプログラム１４に適合するように構成することができる。送信及び修復機構１６は、受信側装置２０へのデータパケットの送信を可能にするように構成することができる。更に、それは、修復セッションでデータパケットの再送信を有効にするように設定することができる。受信側装置２０に送信されるデータ及び再送信されるデータは、データ記憶装置１７に記憶することができる。代替的に、データは、送信側装置１０と同一場所に配置することができ、又はその外側の別の装置に記憶することができる。送信側装置１０は、ネットワークインタフェース１５及びネットワーク３０を通じて受信側装置２０及び他の装置と通信するように構成することができる。

紛失データの修復に関する手順は、ソフトウエアによって実行することができる。受信側装置２０で記憶されてプロセッサ２２で実行されるプログラムコードを含むコンピュータプログラム製品は、送信セッションの受信側で手順を実行するために使用することができるが、送信側装置１０に記憶されてプロセッサ１２で実行されるプログラムコードを含むコンピュータプログラム製品は、送信側で手順を実行するのに使用することができる。

本発明の実施形態を実施例又は論理的なレシーバ／サーバエンティティ及び受信側ユニットによって例証したが、修復要求及び修復応答（適切な場合）のためにその間を行く他のエンティティの使用も考えられており、本発明の範囲内と考えられる。このようなエンティティは、ファイアウォール、プロキシ、及び／又は許可サービスを提供することができる。

「図面」に例証して上述した例示的な実施形態が現時点では好ましいが、これらの実施形態は、単に例示的に与えられたことを理解すべきである。他の実施形態は、例えば、同じ作動を実行するための異なる技術を含むことができる。本発明は、特定的な実施形態に制限されず、特許請求の範囲及び精神に依然として該当する様々な修正、組合せ、及び置換に拡張される。

本発明の一実施形態によるポイント・ツー・マルチポイント送信シナリオを示すブロック図である。 本発明の実施形態による異なる紛失データ修復方法を示すブロック図である。 本発明によるデータ修復の方法の一実施形態を示す流れ図である。 本発明によるデータ修復の方法の別の実施形態を示す流れ図である。 本発明の一実施形態によるシステム及び受信側装置を示すブロック図である。 本発明の一実施形態による送信側装置を示すブロック図である。 本発明による修復機構の一実施形態を示す図である。

符号の説明

１０ 送信側
２０ 受信側

Claims (47)

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. 前記コンピュータコードは、前記予期されていたが受信されなかったデータの再送信後にポイント・ツー・ポイントデータ修復セッションを計画するように更に構成されていることを特徴とする請求項３１に記載のコンピュータコード製品。
33. 前記コンピュータコードは、前記ポイント・ツー・マルチポイントセッションに対する受信側の数を判断し、該判断された受信側の数に基づいて前記ポイント・ツー・ポイントデータ修復セッションを計画するように更に構成されていることを特徴とする請求項３１に記載のコンピュータコード製品。
34. ポイント・ツー・マルチポイント通信システムに使用するための送信側装置であって、
    ポイント・ツー・マルチポイントセッションを通じて複数の受信側にデータを送信するための手段と、
    予期されていたが受信されなかったデータを要求するデータ修復要求を前記複数の受信側から受信するための手段と、
    ポイント・ツー・マルチポイントセッションを通じて前記予期されていたがまだ受信されていないデータを再送信するための手段と、
    を含むことを特徴とする装置。
35. 前記予期されていたがまだ受信されていないデータを再送信した後で前記複数の受信側とのポイント・ツー・ポイントデータ修復セッションを計画するための手段を更に含むことを特徴とする請求項３４に記載の送信側装置。
36. 前記送信側装置は、前記ポイント・ツー・マルチポイントセションを使用する受信側の数を判断するための手段を更に含み、
    前記送信側は、前記判断された受信側の数に基づいて前記ポイント・ツー・ポイントデータ修復セションを計画するように構成されている、
    ことを特徴とする請求項３４に記載の送信側装置。
37. 送信側装置と、該送信側装置からデータを受信することができる少なくとも１つの受信側と、ＨＴＴＰサーバと、ＦＬＵＴＥサーバとを含むシステムにおけるデータ修復の方法であって、
    一部の予期されていたデータが少なくとも１つの受信側によって受信されなかったと判断する段階と、
    前記少なくとも１つの受信側からＨＴＴＰサーバにデータ修復要求を送信する段階と、
    前記ＨＴＴＰサーバから前記少なくとも１つの受信側にＨＴＴＰリダイレクトメッセージを送信する段階と、
    前記少なくとも１つの受信側からＦＬＵＴＥサーバにセッション要求を送信する段階と、
    前記ＦＬＵＴＥサーバと前記少なくとも１つの受信側との間でＦＬＵＴＥセッションを開始する段階と、
    を含むことを特徴とする方法。
38. 前記リダイレクトメッセージは、前記予期されていたが受信されなかったデータに対するＦＬＵＴＥのＵＲＩを含むことを特徴とする請求項３７に記載の方法。
39. 前記リダイレクトメッセージは、前記少なくとも１つの受信側が前記ＦＬＵＴＥセッションに参加することができる方法を示すセッション記述ファイルを含むことを特徴とする請求項３７に記載の方法。
40. 前記リダイレクトメッセージは、前記少なくとも１つの受信側が前記ＦＬＵＴＥセッションに参加することができる方法を含むセッション記述ファイルのロケーションへの参照を含むことを特徴とする請求項３７に記載の方法。
41. 送信側装置と該送信側装置からデータを受信することができる少なくとも１つの受信側とを含むシステムにおけるデータ修復の方法であって、
    一部の予期されていたデータが少なくとも１つの受信側によって受信されなかったと判断する段階と、
    前記少なくとも１つの受信側からデータ修復要求を送信する段階と、
    データ修復要求に応答して、前記少なくとも１つの受信側をセッション記述に該セッション記述のロケータを使用してリダイレクトする段階と、
    を含むことを特徴とする方法。
42. 送信側装置と該送信側装置からデータを受信することができる少なくとも１つの受信側とを含むシステムにおけるデータ修復の方法であって、
    一部の予期されていたデータが少なくとも１つの受信側によって受信されなかったと判断する段階と、
    前記少なくとも１つの受信側からデータ修復要求を送信する段階と、
    前記データ修復要求に応答して、前記少なくとも１つの受信側をセッション記述まで、リダイレクトメッセージペイロードとして該セッション記述を運ぶリダイレクトメッセージによってリダイレクトする段階と、
    を含むことを特徴とする方法。
43. 送信側装置と該送信側装置からデータを受信することができる少なくとも１つの受信側とを含むシステムにおけるデータ修復の方法であって、
    一部の予期されていたデータが少なくとも１つの受信側によって受信されなかったと判断する段階と、
    前記少なくとも１つの受信側からデータ修復要求を送信する段階と、
    データ修復要求に応答して、前記少なくとも１つの受信側を該受信側が引き続き修復セッション又はセッション記述を発見することができる記述にリダイレクトする段階と、
    を含むことを特徴とする方法。
44. ポイント・ツー・マルチポイント通信が可能なシステムにおけるデータ修復の方法であって、
    ポイント・ツー・マルチポイントセッションを通じて送信側から複数の受信側にデータを送信する段階と、
    前記複数の受信側のいずれかが、受信されなかったデータを予期していたかを判断する段階と、
    前記ポイント・ツー・マルチポイントセッションを使用する受信側の数を判断する段階と、
    前記判断された受信側の数に基づいて、ランダム化機構に対するランダム化の値を計算する段階と、
    受信されなかったデータを予期していた前記複数の受信側のいずれともポイント・ツー・ポイント修復セッションを計画する段階と、
    前記計算されたランダム化の値に基づいて、前記ポイント・ツー・ポイントデータ修復セッションを遅延する段階と、
    を含むことを特徴とする方法。
45. ポイント・ツー・マルチポイントセッションを通じて送信側から複数の受信側にデータを送信し、
    予期されていたデータが前記複数の受信側のいずれかで受信されなかったかを判断し、
    いずれかのデータが前記複数の受信側のいずれかで受信されなかった場合には、データ修復要求を作成し、
    前記ポイント・ツー・マルチポイントセッションに対する受信側の数を判断し、
    全ての予期されたデータを受信しなかった各受信側に対してポイント・ツー・ポイントデータ修復セッションを計画し、
    前記判断された受信側の数に基づいて、前記ポイント・ツー・ポイントデータ修復セッションを遅延する、
    ように構成されたコンピュータコード、
    を含むことを特徴とするコンピュータコード製品。
46. ポイント・ツー・マルチポイント通信システムに使用するための送信側装置であって、
    ポイント・ツー・マルチポイントセッションを通じて複数の受信側にデータを送信するための手段と、
    予期されていたが受信されなかったデータを要求するデータ修復要求を前記複数の受信側から受信するための手段と、
    前記ポイント・ツー・マルチポイントセッションを使用する受信側の数を判断するための手段と、
    を含み、
    全ての予期されたデータを受信しなかった受信側とのポイント・ツー・ポイントデータ修復セッションを計画するように構成され、かつ
    前記判断された受信側の数に基づいて前記ポイント・ツー・ポイントデータ修復セッションを遅延する、
    ことを特徴とする装置。
47. データ修復が可能なポイント・ツー・マルチポイント通信システムであって、
    ポイント・ツー・マルチポイント通信が可能な送信側装置と、
    前記送信側装置からデータを受信することが可能な複数の受信側と、
    を含み、
    前記送信側は、ポイント・ツー・マルチポイントセッションを通じて前記複数の受信側にデータを送信するように構成されており、
    前記複数の受信側は、前記送信側装置によって送信されたデータを受信し、いずれかの予期されたデータが受信されなかったかを判断し、受信されなかった場合には、該予期されていたが受信されなかったデータが再送信されることを要求するデータ修復要求を該送信側装置に送信して戻すように構成されており、
    前記送信側は、前記ポイント・ツー・マルチポイントセッションに対する受信側の数を判断し、該判断された受信側の数に基づいてランダム化機構を判断するように構成されており、
    前記送信側はまた、受信されなかったデータを予期していた受信側とのポイント・ツー・ポイント修復セッションを計画するように構成されており、該ポイント・ツー・ポイント修復セッションは、前記ランダム化機構に基づいて遅延される、
    ことを特徴とするシステム。

Images