JP2011061876A - ポイント・ツー・マルチポイント送信システム用のポイント・ツー・ポイントリペア要求メカニズム - Google Patents

Abstract

【課題】ポイント・ツー・マルチポイント送信を行う能力を備えたシステムにおけるデータパケット送信のための改善された方法、システム、送信機、ネットワークエレメント、受信機およびソフトウェアアプリケーションを提供する。
【解決手段】本発明では、送信機から１以上の受信機へ１以上のデータパケットを送信し、少なくとも上記受信機のうちの１つの特定の受信機側でリペアデータパケットの受信を要求し、このリペアデータパケットの送信をトリガするためにリペアサーバへリペア情報の信号送信を行い、このリペア情報には特定の受信機側で正確に受信した送信データパケットの個数に関連する情報が含まれる。例えば１方向トランスポートプロトコルを介するファイル配信によりデータパケットの送信を制御することも可能であり、例えばハイパーテキスト転送プロトコルによりリペア情報の信号送信を制御することも可能である。
【選択図】図３

Description

本発明は、方法、システム、送信機、ネットワークエレメント、受信機、並びに、ポイント・ツー・マルチポイント送信が可能なシステム用のソフトウェアアプリケーションに関する。

インターネットプロトコル（ＩＰ）マルチキャスト、ＩＰデータキャスティング（ＩＰＤＣ）およびマルチメディアブロードキャスト／マルチキャストサービス（ＭＢＭＳ）のようなシステムを介するポイント・ツー・マルチポイントサービス（１から多数へのサービスとして表示される場合もある）用として、例えば、マルチメディアファイルのダウンロードのようなファイル配信は重要なサービスである。

しかしながら、例えば、ファイル転送プロトコル（ＦＴＰ）およびハイパーテキスト転送プロトコル（ＨＴＴＰ）のようなポイント・ツー・ポイントプロトコルを介してファイルの配信を行うための特徴の多くは、ポイント・ツー・マルチポイントシナリオにとって厄介な問題を含むものとなる。特に、信頼性のあるファイル配信、すなわち、トランスポート制御プロトコル（ＴＣＰ）のような同様のポイント・ツー・ポイント確認応答（ＡＣＫ）プロトコルを利用するファイルの保証された配信を行うことは実行不可能である。

インターナショナル・エンジニアリング・タスクフォース（ＩＥＴＦ）の信頼性のあるマルチキャストトランスポート（ＲＭＴ）作業グループが、２つのカテゴリにおけるエラーからの復元力のあるマルチキャストトランスポートプロトコルの標準化を現在行っている最中である。第１のカテゴリでは、順方向エラー修正（ＦＥＣ）の利用によって、すなわち、エラーを含むデータの再構成時に受信機を助けることができる或る一定量の冗長なデータを送信することによって、信頼性が実現される。第２のカテゴリの信頼性は、受信機からのフィードバック情報の利用によって実現される。

非同期層型符号化（ＡＬＣ）は第１のカテゴリに属するプロトコルインスタンス化であるが、これに対して受信否定応答（ＮＡＣＫ）指向型の信頼性のあるマルチキャスト（ＮＯＲＭ）プロトコルは第２のカテゴリに属する。これらのプロトコルを利用できるアクセスネットワークには、一般移動通信システム（ＵＭＴＳ：移動通信用広域システム進化無線アクセスネットワーク（ＧＥＲＡＮ）およびＵＭＴＳ地上無線アクセスネットワーク（ＵＴＲＡＮ）を含む）、無線ローカルエリアネットワークディジタルビデオ放送地上（ＤＶＢ−Ｔ）ネットワーク、およびディジタルビデオ放送衛星（ＤＶＢ−Ｓ）ネットワークを含む無線多重アクセスネットワークが包含される（但し、これらのみに限定されるわけではない）。

手短に言えば、ＡＬＣプロトコルは、ずたずたにされた（mangled）パケットや受信されていないパケットを受信機が再構成することを可能にするためのプロアクティブな（proactive）ＦＥＣベースのスキームである。ＡＬＣプロトコルはマルチチャネルでＦＥＣ符号化を用いて、マルチレート（チャネル）でおそらく異種の受信機へデータを送信することが可能になる。さらに、ＡＬＣプロトコルは通信渋滞制御メカニズムを利用して、異なるチャネルで異なるレートを維持するものである。

ＡＬＣプロトコルは、アップリンク信号送信が必要でないためユーザの数に関して大規模に増大可能なものである。したがって、受信機の量の追加によって、厳密に言うと必ずしもシステムに対する要求が増加するというわけではない。しかしながら、ＡＬＣプロトコルは、受信が保証されていないため、１００％信頼性のあるものではなく、したがって、一般的には、ロバスト（robust）なものであるとしてＡＬＣプロトコルを記述するわけにはいかないことになる。これに対して、ＮＯＲＭは、受信否定応答（ＮＡＣＫ）メッセージを指定して、受信機に着信すると予想されていたどのデータパケットが受信機側で全く受信されなかったか、あるいは、不正確に受信されたかについて信号送信を行うように図るものである。言い換えれば、受信機は、ＮＡＣＫメッセージを用いて、送信されたデータパケットの紛失や損傷を送信機へ示すようにする。したがって、データ送信により送信された幾つかのデータパケットの受信に失敗した受信機は、これらの受信に失敗した単一または複数のデータブロックの再送を送信機（またはリペアサーバ）に要求するＮＡＣＫメッセージを送信機（またはリペアサーバ）へ送信することができる。ＮＯＲＭプロトコルは、プロアクティブでロバストな送信を行うためのデータパケットレベルのＦＥＣ符号化の利用も、オプションとしてサポートしている。

ＮＡＣＫメッセージは一般にＮＯＲＭ専用のものではないが、他のプロトコルやシステムと一緒に、例えば、１方向トランスポート（ＦＬＵＴＥ：unidirectional transport control）プロトコルを介するファイル配信によって制御されるセッションをサポートするシステムと共に利用することが可能である。

ＦＬＵＴＥは、ＦＥＣおよびＡＬＣの構成ブロックに依存する１つ乃至多数のトランスポートプロトコルである。ＦＬＵＴＥは、１方向システムにわたって（単一または複数の）送信機から（単一または複数の）受信機へのファイルの配信を目的とするものである。ＦＬＵＴＥには、当該ＦＬＵＴＥを無線ポイント・ツー・マルチポイントシステムにとって適切なものにするための特殊化が含まれている。ＦＬＵＴＥプロトコルの詳細については、ＩＥＴＦの前述のＲＭＴ作業グループによって作成された「１方向トランスポートを介するＦＬＵＴＥ−ファイル配信（FLUTE-File Delivery over Unidirectional Transport）」（インターネットドラフト）と題する公報にてより詳しく解説されている。

ＦＬＵＴＥの利用は、例えば、ＭＢＭＳシステムのセッション時にファイルのダウンロード用として第３世代パートナプロジェクト（３ＧＰＰ）により仕様化されている。ＦＥＣはこのようなＦＬＵＴＥセッション時に利用してもよいし、しなくてもよい。いずれにせよ、セッションにおけるすべての受信機が、セッションの終了時にファイル全体を受信できるとはかぎらない。この目的のために、３ＧＰＰはポイント・ツー・ポイントリペアセッションを規定している最中であり、この場合、受信機は、例えば、十分な数のデータシンボルを受信し、次いで、ダウンロード済みコンテンツの再構成ができるようにするために、ＮＡＣＫメッセージを介してデータパケットの再送信を求める要求を送信機やリペアサーバへ信号送信することが許される。

ＦＬＵＴＥセッションに関連してＮＡＣＫメッセージを使用する際に（あるいは、特にポイント・ツー・マルチポイント送信をサポートすることを目的としてトランスポート層プロトコルを用いる別のセッション時に）受信機側で欠落データパケットΝを特定することは、重要な論点である。ＴＣＰのようなポイント・ツー・ポイントの送信を目的とするプロトコルの利用およびそれらの確認応答方法は、本願明細書では必ずしも実行可能である必要はない。

ＦＬＵＴＥセッション時に、例えばマルチメディアファイルや当該マルチメディアファイルの一部などのトランスポートオブジェクトは、トランスポート識別子（ＴＯＩ）によって特定され、さらに、当該トランスポートオブジェクトは、トランポートセッション識別子（ＴＳＩ）によって特定されるトランスポートセッションの範囲内で送信機から複数の受信機へ送信される。上記トランスポートオブジェクトの送信は、実際にはＦＬＵＴＥデータパケットの送信によって実行される。この場合、ＦＬＵＴＥデータパケットは、上記トランスポートオブジェクトの部分（いわゆる符号化シンボル）をペイロードとして含む。上記ＦＬＵＴＥデータパケットにはＴＳＩとＴＯＩ、並びに、ＦＥＣペイロード用ＩＤがさらに含まれるが、これらについては以下で説明する。

ＲＭＴ作業グループによって指定された種々のＦＥＣのスキームは、ソースブロックおよび符号化シンボル構造に基づくものであるである。このようなＦＥＣのスキームは、ＲＦＣ公報３４５２「順方向エラー修正により構成されるブロック（Forward Error Correction Building Block）」およびＲＦＣ公報３６９５「コンパクトな順方向エラー修正（ＦＥＣ）のスキーム（Compact Forward Error Correction (FEC) Schemes）」に記載されている。個々の符号化シンボルはそのソースブロック番号（ＳＢＮ）およびその符号化シンボル用ＩＤ（ＥＳＩ）によって特定することができる。これらすべてのＦＥＣのスキームでは、個々のトランスポートオブジェクト内で、ＳＢＮが連続して１つずつ増加すること、および、ソースブロック内で送信される個々の符号化シンボルに対してＥＳＩが１つずつ増加することが仮定されている。ＳＢＮとＥＳＩの双方は、ＦＬＵＴＥデータパケットの中にＦＥＣペイロード用ＩＤの形で含まれている。

これらのＦＥＣのスキームでは、受信機側で全く受信されなかったり、正確に受信されなかったりしたＦＬＵＴＥデータパケットの特定は、上記のＳＢＮとＥＳＩにより行うことも可能であり、これらのＳＢＮとＥＳＩは、ＦＬＵＴＥデータパケットのＦＥＣペイロード用ＩＤの中に含まれている。次いで、これらのパラメータをＮＡＣＫとして逆方向に送信機へ信号送信を行い、これらの特定されたデータパケットの再送信を行わせることも可能である。

しかしながら、エム．ルビー（M. Luby）による「シンプルな順方向エラー修正（ＦＥＣ）のスキーム（Simple Forward Error Correction (FEC) Schemes）」（インターネットドラフト）と題する公報では、さらにシンプルなＦＥＣペイロード用ＩＤを用いるＦＥＣのスキームであって、明示的なソースブロック構造をまったく用いることなく、ＦＥＣペイロード用ＩＤを用いてオブジェクトの配信を行うことができるようなＦＥＣのスキームが導入される。これらのＦＥＣスキームは、例えばレートレス符号（rate-less code）やラプタ（Raptor）符号を用いるものであってもよい。

コンピュータサイエンス（ＦＯＣＳ）の基礎に関するＡＣＭシンポジウム会報（２００２年）に記載のＬＴエンコーダ（LT-encoder）（エム．ルビーによる「ＬＴ符号（LT-code）」を参照のこと）は、ｋ個のデータビットの疎なランダム線形結合である符号化済みビットストリームを送信するものである。受信機は、ノイズの多いバージョンの符号化済みビットをピックアップし、信頼度伝播デコーダを用いてｋ個のデータビットの計算を試みる。復号化の成功のために必要なノイズの多い符号化済みビット数ｎは、チャネルの品質とタイプに左右される。「ロバストなソリトン次数分布（robust soliton degree distribution）」を利用するように設計されたＬＴ符号は、すべての２元消失通信路（ＢＥＣ：every binary erasure channel）で能力（capacity）を達成することができる。すなわち、Ｒ＝ｋ／ｎは、すべての消去発生確率ｐについて（１−ｐ）へ任意に近づけることができる。

ラプタ符号化（エー．ショクロラヒ（A. Shokrollahi）による「ラプタ符号（Raptor codes）」，ディジタル ファウンテン社（Digital Fountain Inc.）, 技術報告書（Tech. Rep.）ＤＦ２００３−０６−００１）を参照のこと）についての重要な着想は、すべての入力シンボルの回復が必要であるという条件を緩和するものである。ＬＴ符号がその入力シンボルの一定割合部分のみの回復を必要とする場合、その復号グラフは、線形時間符号化を処理する０（ｋ）エッジを有するだけで十分である。それでもＬＴ符号を用いて従来の消去訂正コードの連接によってすべての入力シンボルを回復することが可能であり、固定割合の中間シンボルからすべての入力シンボルを回復する能力を備えた（ｋ，ｎ）個の消去訂正ブロックコードを用いてｋ個の入力シンボルを符号化することによりｎ個の中間シンボルが得られる。ｎ個の中間シンボルは、その出力シンボルから中間シンボルの必要とされる一部を回復することができるようなＬＴ符号を用いて符号化される。

これらのＦＥＣのスキーム用として提案されるＦＥＣペイロード用ＩＤは４バイトキーから構成され、この４バイトキーから復号化グラフが生成される。ＳＢＮは、上記ＦＥＣペイロード用ＩＤには含まれず、ＥＳＩは、このケースでは、上記４バイトキーのような識別子を有することが意図される。

さらに、これらのキーは、ＦＥＣエンコーダによってランダムに生成される。したがって、受信機は、この受信機がセッション時に受信した他のデータパケットのキーから欠落データパケットを特定できないかもしれない。この結果、それらの関連づけられたＳＢＮとＥＳＩとによる欠落ＦＬＵＴＥデータパケットの特定は、これらのＦＥＣのスキームでは適用できなくなる。

上記の問題点に鑑みて、ポイント・ツー・マルチポイント送信を行う能力を備えたシステムにおけるデータパケット送信のための改善された方法、システム、送信機、ネットワークエレメント、受信機およびソフトウェアアプリケーションに対する要望が存在する。

本発明では、ポイント・ツー・マルチポイント送信が可能なシステムにおいてデータパケットを送信する方法であって、送信機から１以上の受信機へ１以上のデータパケットを送信し、少なくとも上記受信機のうちの１つの特定の受信機側でリペアデータパケットの受信を要求するステップと、上記リペアデータパケットの送信をトリガするためにリペアサーバへリペア情報の信号送信を行い、上記リペア情報は、上記特定の受信機側で正確に受信した送信データパケットの個数に関連する情報を含むステップとを有する方法が提案されている。

上記システムは、任意の無線接続または有線接続システムを表すことも可能であり、データパケットは、少なくとも１つの送信機から１以上の受信機へ送信される。上記送信は、上記送信機によってすべての受信機がアドレス指定されるブロードキャスト送信にするか、または、上記送信機によってすべての受信機のサブグループのみがアドレス指定されるマルチキャスト送信にすることが可能である。上記システムは、例えば、ＵＭＴＳ、ＬＡＮ、ＷＬＡＮ、ＤＶＢ−ＴまたはＤＶＢ−Ｓのようなコンテキストの中で利用することも可能であり、さらに、例えば、マルチメディアファイルのようなコンテンツを複数の受信機へ配信することも可能である。上記１以上のデータパケットの上記送信は、１方向送信リンクまたは双方向送信リンク上において実行することも可能である。

上記送信データパケットは、例えば上記受信機へ転送すべきコンテンツに関係するものであってもよい。上記受信機への送信をサポートするために、上記コンテンツをセグメント化し、処理するようにしてもよい。これに対して、上記データパケットは上記セグメント化および処理の結果として理解される。例えば、上記データパケットはＦＬＵＴＥデータパケットであってもよく、当該ＦＬＵＴＥデータパケットのペイロードは、マルチメディアファイルなどのトランスポートオブジェクトのＦＥＣ符号化によって得られることも可能である。このケースでは、上記ＦＬＵＴＥデータパケットの上記ペイロードは、例えば符号化シンボルあるいは符号化パケットであってもよい。

特定の受信機として示される少なくとも１つの受信機側で、リペアデータパケットの受信が必要となるが、これは、例えば送信データパケットの正しくない受信や紛失のような複数の理由によるものであると考えられる。上記特定の受信機は、上記データ送信パケットの送信中にあるいは上記データパケットの送信が終了した後に、リペアデータパケットを受信しなければならないという要件を認知している場合もある。

上記リペアデータパケットは、例えば上記特定の受信機によって受信されなかったシンプルな送信データパケットのコピーであってもよい。同様に、上記リペアデータパケットは、符号化および実際のコンテンツの双方に関して異なるものであってもよい。例えば、レートレスＦＥＣ符号化を用いる場合、リペアデータパケットの生成時に異なるキーを適用することも可能である。したがって、リペアデータパケットは、上記特定の受信機が必要とする情報量を上記特定の受信機に供給する役割を果たすことになる。

上記リペアサーバからのリペアデータパケットの送信をトリガするために、上記特定の受信機は上記リペアサーバへリペアデータ情報の信号送信を行う。このことは２地点間転送の際に起こる場合もある。したがって、リペアサーバは、適切なリペアデータパケットの生成と、特定の受信機への当該リペアデータパケットの送信とを可能にするものである。この転送は、例えば２地点間転送などであってもよい。

本発明によれば、上記特定の受信機側で正確に受信した複数の送信データパケットの関連情報が上記リペア情報の中に含まれることが提案されている。この場合、「正確に受信した」という用語は、受信機が、さらなる処理のために上記受信データパケットの中に含まれている情報を利用できるということ、並びに、データパケットを破棄する必要はないことを意味するものと理解される。このことは、例えばデータパケットに含まれているチェックサムに基づいて決定することも可能である。このような提案の背後にある論拠として、上記送信機と上記１以上の受信機間での上記ポイント・ツー・マルチポイント転送時に実際に転送すべきデータオブジェクトから上記データパケットを生成するために利用できる或るＦＥＣ符号化技法の場合、最低数のデータパケットが受信機による上記データオブジェクト自体の再構成を可能にするという点が挙げられる。例えば、データオブジェクトを符号化してＮ個のデータパケットにする場合、上記データオブジェクトを再構成できるように、受信機側でＬ＜Ｎ個のデータパケットのみを必要とする場合もある。この場合、Ｌ個の特定のデータパケットのさらなる受信は要求されず、単にＮ個のデータパケットの中からＬ個の異なるデータパケットの受信のみが要求されようにすることも可能である。したがって、リペアサーバによるリペアデータパケットの生成を可能にするためには、ＦＥＣ符号化技法に関連する別の構造的情報と共に、上記特定の受信機側で正確に受信したデータパケットの個数に関する情報があれば十分である。

したがって、従来技術とは対照的に、例えば、或る一定のトランスポートオブジェクトと或る一定のトランスポートセッションとに関係するＳＢＮとＥＳＩという点から見て、上記特定の受信機が要求するデータパケットの正確な特定を逆方向に上記リペアサーバへ信号送信する必要はもはやなく、これによって、リペアセッション時に遭遇する信号送信オーバヘッド（signaling overhead）は激減することになる。

本発明の方法の好ましい実施形態によれば、上記特定の受信機側での上記送信データパケットのうちの少なくとも１つの送信データパケットの紛失または正しくない受信に起因して、上記リペアデータパケットが必要となる。これは、例えば送信チャネルの減衰、遅延、歪みあるいは追加ノイズに起因して生じる場合もある。同様に、上記送信データパケットのうちの幾つかあるいはすべてが、上記特定の受信機側で全く受信されなくなる場合もある。

本発明の方法の別の好ましい実施形態によれば、上記送信データパケットがデータオブジェクトに関連する。例えば、上記データパケットは、未加工の形または符号化された形で上記データオブジェクトの一部を含むことも可能である。

本発明の方法の別の好ましい実施形態によれば、上記特定の受信機側で上記データオブジェクトのうちの少なくとも１つを再構成するために、上記リペアデータパケットが必要となる。例えば、特定の受信機が、現在ダウンロード中のトランスポートオブジェクト全体の再構成のために必要なすべてのデータパケットを受信してしまわないうちに上記送信機がデータ送信パケットを終了させるケースが生じることが考えられる。この場合、上記特定の受信機側の欠落データパケットは、実際には上記送信機によってそれ以前に送信されなかったデータパケットであってもよい。

本発明の方法の別の好ましい実施形態によれば、上記データオブジェクトはトランスポートオブジェクトであり、上記リペア情報は、上記トランスポートオブジェクトのうちの１つのトランスポートオブジェクトの識別子を含むものである。上記トランスポートオブジェクトは、例えば（マルチメディア）ファイルや、当該（マルチメディア）ファイルの一部であってもよい。

本発明の方法の別の好ましい実施形態によれば、上記データオブジェクトはトランスポートオブジェクトの一部であり、上記リペア情報は、上記トランスポートオブジェクトの一部のうちの１つの部分の識別子と、対応するトランスポートオブジェクトの識別子とを含むものである。上記トランスポートオブジェクトは、例えば、上記受信機によってダウンロードされた（マルチメディア）ファイルであってもよい。上記トランスポートオブジェクトをセグメント化して、例えば、トランスポートオブジェクトのソースブロックなどの部分に変えることも可能であり、次いで、これらの部分は上記データオブジェクトを表す。その後、例えば、上記ソースブロックのＦＥＣ符号化を行ってＮ個のデータパケットに変えることにより、上記部分（ソースブロック）から上記データパケットを生成することも可能になる。次いで、上記部分（そのＳＢＮなど）の識別子、並びに、対応するトランスポートオブジェクトの識別子（そのＴＯＩなど）を設けると好適であり、これによって、トランスポートオブジェクトのソースブロックに関係するどれだけの数のデータパケットが上記特定の受信機側で正確に受信されたかに関する情報に基づいて、リペアサーバが、上記トランスポートオブジェクトの上記ソースブロックに関係するリペアデータパケットを何個上記特定の受信機へ送信する必要があるかを決定するようにすることも可能である。トランスポートオブジェクトをセグメント化して幾つかの合成ソースブロック構造に変えることも可能であり、次いで、上記トランスポートオブジェクトの上記部分の上記識別子が、上記合成ソースブロック構造のうちの１つ、並びに、当該ブロック構造の中に含まれているソースブロックを特定することも可能である。

本発明の方法の別の好ましい実施形態によれば、上記トランスポートオブジェクトはトランスポートセッションに関連するものであり、上記リペア情報には上記トランスポートセッションの識別子が含まれる。複数のトランスポートオブジェクトを同じトランスポートセッション内で送信することも可能であり、さらに、幾つかの併存するトランスポートセッションの存在も可能である。

本発明の方法の別の好ましい実施形態によれば、上記リペア情報には、上記特定の受信機側で正確に受信した送信データパケットの個数が含まれている。

本発明の方法の別の好ましい実施形態によれば、上記リペア情報には、上記特定の受信機側で正確に受信しなかった送信データパケットの個数が含まれる。データパケットの全個数が上記特定の受信機に知られているかどうかが、正確に受信したデータパケットの上記個数から付加的に決定され得る限り、正確に受信しなかったデータパケットの上記個数は、正確に受信したデータパケットの個数に関係することになる。

本発明の方法の別の好ましい実施形態によれば、上記データパケットと上記リペアデータパケットとは、順方向誤り訂正符号化によって上記データオブジェクトから生成される。例えば、上記の完全なデータオブジェクトを直ちに符号化することによって、または、当該データオブジェクトを区分的に符号化することによって、上記データパケットを生成することも可能である。この場合、「符号化」という用語は、送信チャネルによって導入された破損に起因して生じた符号化済みデータの破損の検出および／または訂正を単純化するために、生のデータに冗長性を追加する何らかの技法として理解される。

本発明の方法の別の好ましい実施形態によれば、上記符号化は、上記データパケットとリペアデータパケットとの中に含まれる符号化キーに少なくとも部分的に基づくものである。上記キーは、上記データパケットの復号化に必要なものであってもよい。上記キーは、例えば、２進疑似ランダムキーなどであってもよい。

本発明の方法の別の好ましい実施形態によれば、上記データオブジェクトを再構成できるようにするために、上記順方向誤り訂正符号化は、１つのデータオブジェクトに関連するすべての送信データパケットのサブセットのみを受信機により正確に受信する必要があるという特性を有するものとなる。例えば、上記データオブジェクト（または当該データオブジェクトの一部）の符号化プロセス時にＮ個のデータパケットが生成される場合、Ｌ＜Ｎ個の正確に受信されたデータパケットのみを要求して、上記データオブジェクト（または当該データオブジェクトの一部）を再構成するようにすることも可能である。しかしながら、追加データパケットの受信は再構成の品質向上に寄与することも考えられる。

本発明の方法の別の好ましい実施形態によれば、上記リペアサーバは、上記データオブジェクトを再構成できるようにするために、少なくとも部分的に、信号送信済みの上記リペア情報に基づいて、何個のリペアデータパケットを上記特定の受信機へ送信する必要があるかを決定し、上記リペアデータパケットを生成し、少なくとも上記特定の受信機へ上記リペアデータパケットを送信する。上記の決定は、例えば、特定の受信機から信号送信された正確に受信したデータパケットの個数と、例えば、上記データオブジェクトをセグメント化して形成された部分の数という点から見た上記データオブジェクトのサイズと、どれだけの数のデータパケットがデータオブジェクトの適切な再構成に必要な最小量のデータパケットを上回っているかを受信機に示す受信オーバヘッドのようなパラメータとに基づいて行うことが可能である。

本発明の方法の別の好ましい実施形態によれば、上記順方向誤り訂正は、少なくとも部分的にＬＴ符号に基づくものである。

本発明の方法の別の好ましい実施形態によれば、上記順方向誤り訂正は、少なくとも部分的にラプタ符号に基づくものである。

本発明の方法の別の好ましい実施形態によれば、１以上の受信機への１以上のデータパケットの上記送信は、１方向ポイント・ツー・マルチポイント転送を目的とするセッションベースのプロトコルによって少なくとも部分的に制御される。

本発明の方法の別の好ましい実施形態によれば、１以上の受信機への１以上のデータパケットの上記送信は、１方向トランスポートプロトコルを介するファイル配信によって少なくとも部分的に制御される。次いで、上記データパケットは、例えばＦＬＵＴＥプロトコルのプロトコルデータユニットなどであってもよい。

本発明の方法の別の好ましい実施形態によれば、上記特定の受信機と上記リペアサーバとの間でポイント・ツー・ポイントセッション時に上記リペア情報の上記信号送信が行われる。

本発明の方法の別の好ましい実施形態によれば、上記リペア情報の上記信号送信は、ハイパーテキスト転送プロトコルによって少なくとも部分的に制御される。

本発明の方法の別の好ましい実施形態によれば、上記リペア情報の上記信号送信のためにハイパーテキスト転送プロトコルのＧＥＴ法またはＰＯＳＴ法が用いられる。

本発明の方法の別の好ましい実施形態によれば、上記リペアサーバから上記特定の受信機への上記リペアデータパケットの上記送信は、ポイント・ツー・ポイントセッション時に行われる。

本発明の方法の別の好ましい実施形態によれば、上記システムは、第３世代パートナプロジェクトの規格に準拠するマルチメディアブロードキャスト／マルチキャストシステムである。

データパケットを送信するシステムがさらに提案されている。上記システムは、ポイント・ツー・マルチポイント送信を行うことが可能であり、送信機と、１以上の受信機と、リペアサーバとを備え、１以上のデータパケットが上記送信機から上記受信機へ送信され、少なくとも上記受信機のうちの１つの特定の受信機側でリペアデータパケットの受信を必要とし、上記リペアデータパケットの送信をトリガするために上記リペアサーバへリペア情報の信号送信が行われ、上記リペア情報は、上記特定の受信機側で正確に受信した送信データパケットの個数に関連する情報を含むものである。

ポイント・ツー・マルチポイント送信が可能なシステムにおける送信機であって、１以上の受信機へ１以上のデータパケットを送信するように構成された手段を備え、少なくとも上記受信機のうちの１つの特定の受信機側でリペアデータパケットの受信を必要とし、上記リペアデータパケットの送信をトリガするためにリペアサーバへリペア情報の信号送信が行われ、上記リペア情報は、上記特定の受信機側で正確に受信した送信データパケットの個数に関連する情報を含む送信機がさらに提案されている。上記送信機は、上記リペアサーバと共置することも可能であり、あるいは、上記リペアサーバと同一のものであることさえ可能である。

本発明の送信機の好ましい実施形態によれば、上記送信データパケットがデータオブジェクトに関連し、上記送信機は、順方向誤り訂正符号化によって上記データオブジェクトから上記データパケットを生成するように構成された手段をさらに備える。

ポイント・ツー・マルチポイント送信が可能なシステムにおけるネットワークエレメントであって、送信機から１以上の受信機へ１以上のデータパケットが送信され、少なくとも上記受信機のうちの１つの特定の受信機側でリペアデータパケットの受信を必要とし、上記ネットワークエレメントは、上記リペアデータパケットの送信をトリガするために上記ネットワークエレメントへ信号送信されたリペア情報を受信するように構成された手段を備え、上記リペア情報が上記特定の受信機側で正確に受信した送信データパケットの個数に関連する情報を含むネットワークエレメントがさらに提案されている。上記ネットワークエレメントは、上記送信機と共置することも可能であり、あるいは、上記送信機と同一であることさえ可能であり、例えば、上記ネットワークエレメントはリペアサーバなどであってもよい。

本発明のネットワークエレメントの好ましい実施形態によれば、上記送信データパケットがデータオブジェクトに関連し、上記データオブジェクトを再構成できるようにするために、順方向誤り訂正符号化は、上記データオブジェクトから上記リペアデータパケットを生成し、１つのデータオブジェクトに関連するすべての送信データパケットのサブセットのみを受信機により正確に受信しなければならないという特性を有し、上記ネットワークエレメントは、上記データオブジェクトを再構成できるようにするために、少なくとも部分的に、信号送信済みの上記リペア情報に基づいて、何個のリペアデータパケットを上記特定の受信機へ送信する必要があるかを決定する手段と、上記リペアデータパケットを生成する手段と、少なくとも上記特定の受信機へ上記リペアデータパケットを送信する手段とを備える。

本発明のネットワークエレメントの別の好ましい実施形態によれば、上記送信データパケットがデータオブジェクトに関連し、上記ネットワークエレメントは、順方向誤り訂正符号化によって上記データオブジェクトから上記リペアデータパケットを生成するように構成された手段をさらに備える。

ポイント・ツー・マルチポイント送信が可能なシステムにおける受信機であって、送信機から１以上の受信機へ送信される１以上のデータパケットを受信するように構成され、少なくとも上記受信機側でリペアデータパケットの受信を要求する手段と、上記リペアデータパケットの送信をトリガするためにリペアサーバへリペア情報の信号送信を行い、上記リペア情報は、上記受信機側で正確に受信した送信データパケットの個数に関連する情報を含む手段とを備える受信機がさらに提案されている。

ポイント・ツー・マルチポイント送信が可能なシステムの受信機において実行可能なソフトウェアアプリケーションであって、上記ソフトウェアアプリケーションは、送信機から１以上の受信機へ送信される１以上のデータパケットを受信機に受信させるためのプログラムコードであって、少なくとも上記受信機側でリペアデータパケットの受信を要求するプログラムコードと、上記リペアデータパケットの送信をトリガするために、リペアサーバへのリペア情報の信号送信を受信機に行わせるためのプログラムコードであって、上記リペア情報は、上記受信機側で正確に受信した送信データパケットの個数に関連する情報を含むプログラムコードと、を有するソフトウェアアプリケーションがさらに提案されている。

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

前述のような本発明の態様並びにその他の態様は、本願明細書で後述する実施形態から明らかにされ、当該実施形態を参照しながら解明されるであろう。

ＭＢＭＳファイルのダウンロードを行うためのラプタ符号仕様に準拠してトランスポートオブジェクトの符号化を行い、一連のデータパケットに変換する処理を示す概略図である。 本発明に係るポイント・ツー・マルチポイントシステムを示す概略図であって、データパケットが送信機から複数の受信機へ送信される様子を示す概略図である。 本発明に係るポイント・ツー・マルチポイントシステムを示す概略図であって、特定の受信機が逆方向にリペアサーバへリペア情報の信号送信を行う様子を示す概略図である。 本発明に係るポイント・ツー・マルチポイントシステムを示す概略図であって、リペアサーバがリペアデータパケットを特定の受信機へ送信する様子を示す概略図である。 本発明に係るポイント・ツー・マルチポイントシステムにおいてデータパケットおよびリペアデータパケットを受信する方法を説明するための例示的なフローチャートである。

冒頭のコメントとして、以下の詳細な説明を裏付けるために本願明細書の導入部分の主題を利用できることに留意されたい。

本発明は、ポイント・ツー・マルチポイントデータパケット送信システムにおいて、特定の受信機側で正確に受信したデータパケットの個数に関する情報を逆方向にリペアサーバへ信号送信し、上記特定の受信機が要求した送信処理やリペアデータパケットのトリガ処理を行うことを提案するものである。リペアサーバがどのリペアデータパケットを上記特定の受信機へ送信する必要があるかの判定を可能にするための情報のフィードバックが、上記の提案により格段に効率よくできるようになる。ＬＴ符号やラプタ符号のようなレートレス符号を介するトランスポートオブジェクトのＦＥＣ符号化によって上記データパケットを生成する際に、上記のアプローチは特に有益である。

図１は、Ｎ個の符号化キー２−１〜２−Ｎを使用する場合に、３ＭＢサイズ（ＭＢＭＳファイルのダウンロード用として一般的なサイズ）のトランスポートオブジェクト１の、一連のＮ個の符号化パケット３−１〜３−Ｎ内へのＦＥＣ符号化を概略的に示す図である。ここで、上記ＦＥＣ符号化は、ＭＢＭＳファイルのダウンロード用ラプタ符号仕様（３ＧＰＰ発表のＴｄｏｃ Ｓ４−０４０２３０「ＭＢＭＳファイルのダウンロードを行うためのラプタ符号仕様（Raptor Code Specification for MBMS File Download）」（ＳＡ４＃３１，２００４年５月１７日〜５月２１日，カナダ，モントリオール）を参照のこと）に対応する。この場合、上記ＦＥＣ符号化（特に１以上の符号化シンボル３０−ｉ）によって取得された符号化パケット３−１〜３−Ｎの部分は、さらに詳細に後述するように、例えばＦＬＵＴＥデータパケット用ペイロードなどとして機能するものであってもよい。

ＴＯＩによって特定可能な、図１のトランスポートオブジェクト１は、複数のトランスポートオブジェクトのうちの１つだけを表すものであり、当該トランスポートオブジェクトは、送信セッション内で送信機から複数の受信機へ送信され、ＴＳＩによって特定されたものである。図１によれば、トランスポートオブジェクト１は、１６個のソースブロック１０−１〜１０−１６により構成され、これらのソースブロックの各々は、Ｋ＝６１４４個の３２バイトのソースシンボルにより構成され、これらのソースシンボルはソースブロック１０−１に対して１００−１〜１００−６１４４の形で例示的にラベルが付けられる。個々のソースブロック１０−１〜１０−１６は、３２バイト×６１４４のサイズを有する。

上記トランスポートオブジェクト１全体のＦＥＣ符号化は、Ｋ×Ｎの行列を用いてトランスポートオブジェクト１の行列乗算により達成される。上記Ｋ×Ｎの行列は６１４４×１の２進符号化キーで構成され、当該符号化キーの“１”は黒い領域として概略的に描かれ、“０”は白い領域として概略的に描かれている。上記Ｎ個の異なる符号化キーは、例えば２進擬似ランダムコードなどを表すものであってもよいが、同様にさらに慎重な選択を行うようにしてもよい。

上記の使用符号化キーの数字Ｎは、Ｋよりも大きく、受信機のオーバヘッドを決定する。Ｎの増加と共に、符号化シンボル３−１〜３−Ｎのセットから得られるトランスポートオブジェクト１の正しい再構成の発生確率は上昇する。

前述の行列乗算を行うことにより、Ｎ個の符号化パケット３−１〜３−Ｎが得られ、個々の符号化パケットは５１２バイトの寸法になる。個々の符号化パケットが、例えば符号化シンボル３−１に対してそれぞれ符号化パケット３０−１〜３０−１６の１６個の符号化シンボルから構成されていることは、符号化パケットに付けられた図１の様々な陰影から容易にわかる。符号化シンボル３０−１は、唯一の符号化キー２−１を除く、ソースブロック１０−１のすべてのエレメントにより影響を受けるということもまた図１からわかる。同様に、符号化シンボル３０−２は、ソースブロック１０−２のすべてのエレメントと符号化キー２−１により影響を受けている。したがって、符号化キー２−１は、キー３１として符号化パケット３−１の中に含まれ、同様に他の符号化キー２−１〜２−Ｎは、それぞれＮ個の符号化パケット３−２〜３−Ｎの中に含まれることになる。この場合、「含む」という言葉は、必ずしも図１に描かれているような２進キー全体が符号化パケットの中に含まれるということを意味するとはかぎらない。符号化パケット３−１用のキー３１として図１に例示的に図示しているようなそれぞれ４バイトの識別子によって、それぞれの符号化キー２−１〜２−Ｎを特定するほうがさらに効率的である。上記識別子は、例えば所望の符号化キーの作成に適したシフトレジスタの状態や、同様の状態などに関係するものとなることが考えられる。

個々の符号化パケット３−ｉが１つの符号化キー２−ｉのみに依存するという事実は、単一の符号化パケットに基づいてソースブロック全体の分離復号化が可能であるという印象を与えるべきではない。図１からわかるように、実際には、１つのソースブロック１０−ｉの情報は、すべての符号化パケット３−１〜３−Ｎのそれぞれの符号化シンボルの中に含まれることになる。ソースブロック１０−ｉを正確に復号化するためには、レートレス符号の特性に基づいて少なくともＫ個の符号化パケットを処理する必要がある。例えばＮ個のすべての符号化シンボルのようなＫ個よりも多くの処理によって、復号化の品質が改善されることになる。（Ｋより多くの個数の）十分な数の符号化パケットを復号化に利用することができるならば、１つのソースブロック１０−ｉだけでなく、すべてのソースブロック１０−１〜１０−１６の復号化も可能になることは容易に理解される。したがって、Ｋ個よりも多くの符号化パケットを復号化に利用することができるならば、トランスポートオブジェクト１全体の再構成が可能になる。

上記の原理は、紛失の多い送信チャネルでレートレス符号を使用する場合に利用される。図１に描かれているように、トランスポートオブジェクトのソースブロックがＫ個のソースシンボルから個々に構成されていて、当該トランスポートオブジェクトを符号化してＮ個の符号化パケットの中へ入れる場合、受信機は、トランスポートオブジェクト１の再構成を可能にするために、必ずしもＮ個すべての符号化パケットを正確に受信する必要があるわけではない。さらに、特定のシーケンスの符号化パケットの受信や、符号化パケットの一時的に隣接するブロックの受信さえ必要ではない。というのは、トランスポートオブジェクトの復号化のために受信データパケットを利用するには、個々の符号化パケットの中に含まれている符号化キー内の情報で十分であるからである。

したがって、受信機側で十分な数の符号化パケットが利用可能であることを保証するためには、本発明によって提案されているように、（本発明のケースでは、個々のデータパケットの中にペイロードとして１つの符号化パケットが含まれているため）正確に受信された符号化パケットの個数に対応する、正確に受信されたデータパケットの個数をリペアサーバへ信号送信すれば十分である。次いで、当該リペアサーバは、さらに別の符号化パケット（リペアデータパケット）の生成を処理し、上記符号化パケットが正確に受信された後、これらの符号化パケッによって受信機による上記トランスポートオブジェクトの復号化が可能になる。（本発明のケースでは、正確に受信した符号化パケットの数に対応する）正確に受信したデータパケットの上記個数から少なくとも構成される上記リペア要求情報の中にはＴＳＩとＴＯＩとが好適にさらに含まれ、このＴＳＩとＴＯＩとによってトランスポートセッションの特定を行うことが可能になり、さらに、リペアデータパケットの要求対象となる幾つかのトランスポートオブジェクトが存在する場合には、そのようなトランスポートオブジェクトの特定を行うことが可能になる。さらに、このリペア要求には送信機のＩＰアドレスが含まれる場合がある。同じサーバが複数の送信機用の好適なリペアサーバとして機能することがあるため、上記のようにリペア要求が送信機のＩＰアドレスを含むように要求される場合がある。このような場合、リペア要求は送信機のＩＰアドレスについても言及する必要があることが考えられる。このようにして、送信機のＩＰアドレスとＴＳＩとによってセッションの一意的特定が行われることになる。

図１では、トランスポートブロック１全体はセグメント化されて、ソースブロック１０−１〜１０−１０の形にされ、これらのソースブロックは同じ符号化キー２−１〜２−Ｎを用いてまとめて符号化されて、符号化パケット３−１〜３−Ｎが得られる。個々のＦＬＵＴＥデータパケットの中に符号化パケット３−ｉ全体が含まれている場合、欠落データパケットに起因して特定の受信機のリペア要求が生じる際には、リペアサーバによる完全な符号化パケット３−ｉの生成も必要となることを理解されたい。しかしながら、トランスポートブロックをセグメント化してソースブロックにする処理は、受信機のデコーダ側での小型の高速メモリを用いる復号化を容易にするのに好都合な場合もある。すなわち、受信機の高速メモリは、この場合、１つのソースブロックに対応する符号化シンボルのみを同時に保持するだけでよいことになる。さらに、デコーダは、個々のソースブロックの回復時に同じステップを繰り返すことも可能である。というのは、この時点で、デコーダは、受信シーケンス内で全く同じ位置を共有している符号化シンボルから復号化を行うからである。

これに対して、個々のＦＬＵＴＥデータパケットが、個々の符号化パケット（例えば図１の３−１など）の中から得られる符号化シンボル（例えば図１の３０−１など）のみを含む場合、欠落データパケットのケースでは、符号化パケット全体ではなく符号化シンボルを含むリペアデータパケットのみを生成しなければならなくなる。しかしながら、上記のようなリペアデータパケットのみの生成処理では、符号化シンボルが関係するソースブロックを特定できるようにするために、個々のＦＬＵＴＥデータパケットのＦＥＣペイロード用ＩＤの形のＳＢＮの追加表示が要求される。この場合、個々のＦＬＵＴＥデータパケットのヘッダには、例えばＴＳＩ、ＴＯＩ、ＳＢＮおよびキー識別子などが含まれ、さらに、ＦＬＵＴＥデータパケットの紛失や正しくない受信が生じた場合には、すでに正確に受信済みのＦＬＵＴＥデータパケットの個数に加えて、特定の受信機が、紛失データパケット内の符号化シンボルが参照するトランスポートオブジェクトのソースブロックのＳＢＮをさらに含まなければならなくなる場合もある。この時点で、リペアサーバは、リペア情報の中にＳＢＮが示しているように、ソースブロック用の新たな符号化シンボルを生成するだけでよい。

ソースファイルが大きすぎて、図１の合成ソースブロック構造の中にぴったり入らない場合、ソースファイルをセグメント化して２以上の合成ソースブロック構造にする必要がある場合もある。この場合は、リペア要求が合成ソースブロック構造用ＩＤも含まなければならないようにしてよい。この場合、個々のＦＬＵＴＥデータパケットヘッダには、例えばＴＳＩ、ＴＯＩ、合成ＳＢＮおよびキー識別子などが含まれ、さらに、ＦＬＵＴＥデータパケットの紛失や正しくない受信が生じた場合には、（正確に受信した符号化シンボルの数に対応する）すでに正確に受信したＦＬＵＴＥデータパケットの個数に加えて、特定の受信機が、紛失したデータパケット内の符号化シンボルが参照するトランスポートオブジェクトのソースブロックのＳＢＮをさらに含まなければならなくなる場合もある。この時点で、リペアサーバは、リペア情報の中に合成ＳＢＮが示しているように、合成ソースブロック用の新たな符号化シンボルを生成するだけでよくなる場合もある。

符号化パケット全体の符号化シンボル、または、単一の符号化シンボルのいずれかをＦＬＵＴＥデータパケットの中へ組み入れるという前述の可能性は、双方とも本発明の目的とするところである。

図２ａは、ポイント・ツー・マルチポイント送信シナリオにおける送信機４および受信機５−１の機能コンポーネントの概観を示す図である。ここでは、（符号化パケットのすべての符号化シンボル、または、単一の符号化シンボルを前述のようにペイロードとして有する）ＦＬＵＴＥデータパケットが、複数の受信機５−１〜５−３へ送信される。

送信機４は、例えばインターネットなどのネットワーク６へのインタフェース４０を備え、これによって、当該ネットワークが提供するコンテンツへのアクセスが行われる。次いで、当該コンテンツは、ブロードキャスト／マルチキャストセッション時に上記受信機５−１〜５−３へ配信されるようになる。次いで、このようなコンテンツは、例えば上記送信機のメモリ４１などに格納することも可能である。上記コンテンツを送信できるようにするために、変調および符号化用インスタンス（instance）４２により上記コンテンツの符号化および変調が行われる。上記インスタンス４２が行う上記の処理は、ＩＳＯ／ＯＳＩプロトコルスタックの異なるプロトコル層により課されている要件を満たすものである。特に、ＦＬＵＴＥデータパケットのペイロード（データパケット毎に１つのまたは複数のペイロードのいずれか）として符号化シンボルを得るための、トランスポートオブジェクトのＦＥＣ符号化に基づくＦＬＵＴＥデータパケットの生成、並びに、例えば（４バイトキー識別子とおそらくＳＢＮとに対応するレートレスＦＥＣ符号化についての本発明のケースおける）ＴＳＩ、ＴＯＩおよびＦＥＣペイロード用ＩＤを含むＦＬＵＴＥデータパケットのヘッダフィールドの規定は、このインスタンス４２において行われる。次いで、インスタンス４２は、インスタンス４３が送信した変調信号を出力し、当該インスタンス４３は、無線送信チャネルまたは（光などの）有線送信チャネルへのインタフェースとして機能することになる。送信機４のすべてのインスタンス４０、４１、４２および４３は、制御ユニット４４により制御される。

本図で特定の受信機と見なす受信機５−１側で、上記変調信号は、インスタンス５０を介して受信され、次いで、機能的に送信機４の符号化および変調用インスタンス４２に対応する復調および復号化用インスタンス５１の中へ出力される。特に、上記変調信号は復調され、次いで、ＦＬＵＴＥデータパケットが正確に受信されたか否かのチェックが行われる。例えばチェックサムや類似の技法などの手段によって、ＦＬＵＴＥ層の下に在るプロトコル層により上記チェックを行ってもよい。ＦＬＵＴＥデータパケットが正確に受信されたことが判定されると、上記インスタンス５１内のカウンタ５１０のカウント値が増えることになる。上記復調および復号化用インスタンス５１はまた、受信済みのＦＬＵＴＥデータパケット用バッファとしての役割も果たし、さらに、十分な数のＦＬＵＴＥパケットを受信した場合、ＦＬＵＴＥデータパケットの復号化を行って、所望のトランスポートオブジェクトを再構成し、次いで、当該トランスポートオブジェクトを受信機５−１のメモリ５２に格納することが可能になる。上記受信機５−１は、送信機４の変調および符号化用インスタンス４２と類似の機能を有する変調および符号化用インスタンス５３と、送信チャネルへのインタフェースとして機能するインスタンス５４とをさらに備えている。すべてのインスタンス５０、５１、５２、５３および５４は、制御インスタンス５５により制御される。

図２ｂは、図２ａに描かれているようなデータパケットの送信中または送信終了後に、リペアサーバ７と特定の受信機５−１との間で確立されたポイント・ツー・ポイントリペアセッションを例示する図である。この目的のために、受信機５−１はカウンタ５１０のチェックを行って、トランスポートオブジェクトの再構成を行うのに十分な数のＦＬＵＴＥデータパケットが受信されたかどうかの判定を行う。上記十分な数のＦＬＵＴＥデータパケットが受信されなかった場合、コントローラ（制御インスタンス）５５は、変調および符号化用インスタンス５３によって（ＮＡＣＫメッセージと同様の）リペア要求メッセージを生成させる。上記インスタンス５３には、例えばＴＳＩおよびＴＯＩと、上記カウンタ５１０がカウントするような正確に受信したデータパケットの個数と、ＳＢＮなどのリペア情報とが含まれる。上記リペア要求メッセージの生成には、上記ポイント・ツー・マルチポイント送信用として使用されたプロトコルスタックのような少なくとも部分的に異なるプロトコルスタックを使用してもよく、例えばＨＴＴＰなどを使用してもよい。この時点で、上記リペア要求メッセージは、例えば以下の〔数１〕に示すような形をとることができる。

上記ＧＥＴメッセージの中には、リペアサーバ、ＴＳＩ（１２３）、ＴＯＩ（４５６）、および、正確に受信したデータパケットの個数（５４３２）がリペア情報として含まれる。ＭＢＭＳサーバのＩＰアドレス（またはＵＲＬ）もリペア要求メッセージの中に含むことが可能である。

上記とは別に、ＰＯＳＴのような別のＨＴＴＰメソッドを利用して、欠落データパケットを要求することも可能である。例えば、下記の〔数２〕に示すようなＰＯＳＴメッセージは、上記に示したＧＥＴメッセージに相当するものである。

次いで、上記リペア要求メッセージは、インスタンス５４を介してリペアサーバ７へ送信され、インスタンス７０を介して受信され、特定の受信機５−１においてインスタンス５３に対して逆の機能性を与えるインスタンス７１の中で復調および復号化が行われ、そして、必要に応じてメモリ７２に格納される。上記リペアサーバ７は、変調および符号化用インスタンス７３、送信用インスタンス７４およびネットワーク６へのインタフェース７５をさらに備える。リペアサーバのすべてのインスタンスは、制御インスタンス７６により制御される。

最後に図２ｃは、リペアサーバ７が、図２ｂで送られた上記リペア要求メッセージに応じて、ＦＬＵＴＥリペアデータパケットを上記特定の受信機５−１へ送信する場合のシナリオを描く図である。この目的のために、リペアサーバは、ＨＴＴＰを介して特定の受信機５−１から受信したリペア情報を評価し、どれだけの数のデータパケットを生成し、このデータパケットを上記特定の受信機へ送信する必要があるかを決定して、当該特定の受信機が上記トランスポートオブジェクトの再構成を行うことができるようにする。図１に例示のように、リペアサーバ７は、そのメモリ、または、インタフェース７５を介してネットワーク６のいずれか一方から、上記トランスポートオブジェクトまたは当該トランスポートオブジェクトの部分をフェッチし、上記トランスポートオブジェクトまたは当該トランスポートオブジェクトの部分に対するＦＥＣ符号化を行って、ＦＬＵＴＥリペアデータパケット用ペイロードとしての役割を果たす符号化シンボルを取得する。この場合、１つまたは幾つかの符号化シンボルのいずれかをデータパケット用ペイロードとして使用してもよい。リペアサーバ７は、例えば、トランスポートオブジェクト１（図１内の変数Ｋ）の列の数、受信オーバヘッド、および、リペア要求メッセージの形で特定の受信機によって信号送信されるような正確に受信されたＦＬＵＴＥデータパケットの個数に基づいて、個々の（ＴＳＩ、ＴＯＩおよびおそらくＳＢＮ）オブジェクト用のＦＬＵＴＥリペアデータパケットの個数Ｍの決定を行うことも可能である。この時点で、リペアサーバ７は、Ｍキーのセットを生成し、対応する符号化シンボルを生成し、次いで、当該対応する符号化シンボルは、（１つまたは幾つかの符号化シンボルのいずれか一方として）ＦＬＵＴＥリペアデータパケットの中へ組み込まれ、変調され、そして、インスタンス７３および７４を介して上記特定の受信機５−１へ送信される。

次いで、ＦＬＵＴＥリペアデータパケットを含む変調信号は、上記受信機５−１側でインスタンス５０を介して受信され、それから、インスタンス５１の中で処理されて、データパケットが正確に受信されたかどうかの判定が行われる。十分な数のＦＬＵＴＥデータパケットまたはリペアデータパケットが正確に受信されていた場合、上記インスタンス５１によりトランスポートオブジェクトを再構成し、上記メモリ５２に格納してさらに処理を行うことが可能になる。

図３は、ポイント・ツー・マルチポイントシステムにおいて受信機側でデータパケットを受信する方法を説明するための例示的なフローチャートを描く図である。第１のステップ８０１で、パケットカウンタを０にセットし、例えば新たなトランスポートオブジェクトに関するデータパケットの受信開始が図られる。次いで、ステップ８０２で送信機が複数の受信機へ送信したデータパケットを受信する。その後、ステップ８０３で、個々の単一の受信データパケットが正しいものか否かのチェックを行う。個々の単一受信データパケットが正しいものであればパケットカウンタを１増加し、そうでなければ増加をスキップする。次いで、ステップ８０５でデータパケットの送信が終了したかどうかをチェックする。送信が終了していなければ、ステップ８０２のデータパケット受信までジャンプして戻る。送信が終了した場合、ステップ８０６で、パケットカウンタ値がデータパケットの最小限必要な個数以上かどうかを比較することによって、十分な数のデータパケットが受信されたかどうかのチェックを行う。十分な数のデータパケットが受信された場合、ステップ８０７で受信データパケットを復号化して、所望のトランスポートオブジェクトが得られることになる。送信が終了していなかった場合、少なくともパケットカウンタと、おそらくＳＢＮとを含み、さらに、好ましくはＴＳＩとＴＯＩとをさらに含むようなリペア情報をリペア要求メッセージ内で信号送信することによって、リペアセッションを開始する必要がある。次いで、リペアサーバは、上記信号送信済みリペア情報に基づいてリペアデータパケットの送信を開始し、これによって、受信機は、ステップ８０２のリペアデータパケットの受信へとジャンプして戻る。上記の処理は、ステップ８０６でチェックされるように、上記受信機側で十分な数のデータパケットが正確に受信されるまで継続される。

以上、好ましい実施形態によって本発明を説明した。当業者にとって明らかな代替例および変更例が存在し、添付の特許請求の範囲に記載の各請求項の範囲と精神から逸脱することなく上記代替例および変更例が実現可能であることを付記しておく。

Claims (54)

1. 送信機から１以上の受信機へ送信された１以上のデータパケットを、前記１以上の受信機のうちの１つの受信機において、受信するステップと、
   前記１つの受信機において要求されるリペアデータパケットの送信をトリガするために、前記１つの受信機からリペアサーバへリペア情報を信号送信するステップであって、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、ステップと、
   を具備する方法。
2. 前記１つの受信機での前記送信データパケットのうちの少なくとも１つの送信データパケットの紛失または正しくない受信に起因して、前記リペアデータパケットが必要となる、請求項１に記載の方法。
3. 前記１つの受信機で前記データオブジェクトを再構成するために、前記リペアデータパケットが必要となる、請求項１に記載の方法。
4. 前記データオブジェクトはトランスポートオブジェクトであり、前記リペア情報は、前記トランスポートオブジェクトの識別子を含む、請求項１に記載の方法。
5. 前記データオブジェクトはトランスポートオブジェクトの一部であり、前記リペア情報は、対応するトランスポートオブジェクトの識別子を含み、前記一部の識別子を含まない、請求項１に記載の方法。
6. 前記トランスポートオブジェクトはトランスポートセッションに関連し、前記リペア情報は、前記トランスポートセッションの識別子を含む、請求項４に記載の方法。
7. 前記リペア情報は、前記１つの受信機で正確に受信された送信データパケットの数を含む、請求項１に記載の方法。
8. 前記リペア情報は、前記１つの受信機で正確に受信されなかった送信データパケットの数を含む、請求項１に記載の方法。
9. 前記符号化は、前記データパケットとリペアデータパケットとの中に含まれる符号化キーに少なくとも部分的に基づく、請求項１に記載の方法。
10. 前記順方向誤り訂正は、少なくとも部分的にＬＴ符号またはラプタ符号に基づく、請求項１に記載の方法。
11. １以上の受信機への１以上のデータパケットの前記送信は、１方向ポイント・ツー・マルチポイント転送を目的とするセッションベースのプロトコルによって少なくとも部分的に制御される、請求項１に記載の方法。
12. １以上の受信機への１以上のデータパケットの前記送信は、１方向トランスポートプロトコルを介するファイル配信によって少なくとも部分的に制御される、請求項１に記載の方法。
13. 前記１つの受信機と前記リペアサーバとの間でポイント・ツー・ポイントセッション時に前記リペア情報の前記信号送信が行われる、請求項１に記載の方法。
14. 前記リペア情報の前記信号送信は、ハイパーテキスト転送プロトコルによって少なくとも部分的に制御される、請求項１に記載の方法。
15. 前記リペア情報の前記信号送信のために、ハイパーテキスト転送プロトコルのＧＥＴ法またはＰＯＳＴ法が用いられる、請求項１４に記載の方法。
16. 前記リペアサーバから前記１つの受信機への前記リペアデータパケットの前記送信は、ポイント・ツー・ポイントセッション時に行われる、請求項１に記載の方法。
17. 前記方法は、第３世代パートナプロジェクトの規格に準拠するマルチメディアブロードキャスト／マルチキャストサービスで使用可能である、請求項１に記載の方法。
18. 前記リペア情報は、前記１つの受信機において正確に受信された送信データパケットの数に関連する情報を含む、請求項１に記載の方法。
19. １つの受信機から信号送信されたリペア情報を受信するステップであって、該１つの受信機においては、送信機から１以上の受信機へ送信された１以上のデータパケットの受信後にリペアデータパケットの受信が要求され、該１以上の受信機の１つが前記１つの受信機であり、該リペア情報は、前記１つの受信機において要求される、リペアサーバから前記１つの受信機への前記リペアデータパケットの送信をトリガするためのものであり、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１つの受信機を含む前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、ステップ、
    を具備する方法。
20. 前記リペア情報は、前記１つの受信機において正確に受信された送信データパケットの数に関連する情報を含む、請求項１９に記載の方法。
21. １以上の受信機への１以上のデータパケットの前記送信は、１方向トランスポートプロトコルを介するファイル配信によって少なくとも部分的に制御される、請求項１９に記載の方法。
22. 前記１以上のデータパケットは、第３世代パートナプロジェクトの規格に準拠するマルチメディアブロードキャスト／マルチキャストサービスにおいて送信される、請求項１９に記載の方法。
23. １つの受信機から信号送信されたリペア情報を受信するように構成された手段であって、該１つの受信機においては、送信機から１以上の受信機へ送信された１以上のデータパケットの受信後にリペアデータパケットの受信が要求され、該リペア情報は、リペアサーバから前記１つの受信機への前記リペアデータパケットの送信をトリガするためのものであり、前記１つの受信機は前記１以上の受信機の１つであり、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、手段、
    を具備する装置。
24. 前記１つの受信機が前記データオブジェクトを再構成できるようにするために、少なくとも部分的に、信号送信済みの前記リペア情報に基づいて、何個のリペアデータパケットを前記１つの受信機へ送信する必要があるかを決定するように構成された手段と、
    前記１つの受信機へ前記リペアデータパケットを送信するように構成された手段と、
    を更に具備する、請求項２３に記載の装置。
25. 順方向誤り訂正符号化によって前記データオブジェクトから前記リペアデータパケットを生成するように構成された手段、
    を更に具備する、請求項２３に記載の装置。
26. 前記リペア情報は、前記１つの受信機において正確に受信された送信データパケットの数に関連する情報を含む、請求項２３に記載の装置。
27. 前記１つの受信機への前記１以上のデータパケットの前記送信は、１方向トランスポートプロトコルを介するファイル配信によって少なくとも部分的に制御される、請求項２３に記載の装置。
28. 前記１以上のデータパケットは、第３世代パートナプロジェクトの規格に準拠するマルチメディアブロードキャスト／マルチキャストサービスにおいて送信される、請求項２３に記載の装置。
29. １つの受信機において具備される受信機であって、
    送信機から１以上の受信機へ送信される１以上のデータパケットを受信するように構成された手段であって、前記１つの受信機が前記１以上の受信機の１つである、手段と、
    前記１つの受信機において受信が要求されるリペアデータパケットの送信をトリガするためにリペアサーバへリペア情報を信号送信するように構成された手段であって、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、手段と、
    を具備する受信機。
30. 前記リペア情報は、前記１つの受信機において正確に受信された送信データパケットの数に関連する情報を含む、請求項２９に記載の装置。
31. 前記１つの受信機での前記送信データパケットのうちの少なくとも１つの送信データパケットの紛失または正しくない受信に起因して、前記リペアデータパケットが必要となる、請求項２９に記載の装置。
32. 前記１つの受信機で前記データオブジェクトを再構成するために、前記リペアデータパケットが必要となる、請求項２９に記載の装置。
33. 前記データオブジェクトはトランスポートオブジェクトであり、前記リペア情報は、前記トランスポートオブジェクトの識別子を含む、請求項２９に記載の装置。
34. 前記データオブジェクトはトランスポートオブジェクトの一部であり、前記リペア情報は、対応するトランスポートオブジェクトの識別子を含み、前記一部の識別子を含まない、請求項２９に記載の装置。
35. 前記トランスポートオブジェクトはトランスポートセッションに関連し、前記リペア情報は、前記トランスポートセッションの識別子を含む、請求項３３に記載の装置。
36. 前記リペア情報は、前記装置で正確に受信された送信データパケットの数を含む、請求項２９に記載の装置。
37. 前記リペア情報は、前記装置で正確に受信されなかった送信データパケットの数を含む、請求項２９に記載の装置。
38. 前記符号化は、前記データパケットとリペアデータパケットとの中に含まれる符号化キーに少なくとも部分的に基づく、請求項２９に記載の装置。
39. 前記順方向誤り訂正は、少なくとも部分的にＬＴ符号またはラプタ符号に基づく、請求項２９に記載の装置。
40. 少なくとも部分的に、１方向ポイント・ツー・マルチポイント転送を目的とするセッションベースのプロトコルの制御下で、前記１以上のデータパケットを受信するように構成されている、請求項２９に記載の装置。
41. 少なくとも部分的に、１方向トランスポートプロトコルを介するファイル配信の制御下で、前記１以上のデータパケットを受信するように構成されている、請求項２９に記載の装置。
42. 前記リペアサーバへポイント・ツー・ポイントセッション時に前記リペア情報を信号送信するように構成されている、請求項２９に記載の装置。
43. ハイパーテキスト転送プロトコルの制御下で前記リペア情報を信号送信するように構成されている、請求項２９に記載の装置。
44. 前記リペア情報の前記信号送信のために、ハイパーテキスト転送プロトコルのＧＥＴ法またはＰＯＳＴ法を使用するように構成されている、請求項４３に記載の装置。
45. ポイント・ツー・ポイントセッション時に前記リペアサーバから前記リペアデータパケットを受信するように構成されている、請求項２９に記載の装置。
46. 第３世代パートナプロジェクトの規格に準拠するマルチメディアブロードキャスト／マルチキャストサービスにおいて使用可能である、請求項２９に記載の装置。
47. 送信機から１以上の受信機へ送信された１以上のデータパケットを、前記１以上の受信機のうちの１つの受信機において、受信するステップと、
    前記１つの受信機において要求されるリペアデータパケットの送信をトリガするために、前記１つの受信機からリペアサーバへリペア情報を信号送信するステップであって、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、ステップと、
    をコンピュータに実行させるためのプログラム。
48. １つの受信機から信号送信されたリペア情報を受信するステップであって、該１つの受信機においては、送信機から１以上の受信機へ送信された１以上のデータパケットの受信後にリペアデータパケットの受信が要求され、該１以上の受信機の１つが前記１つの受信機であり、該リペア情報は、前記１つの受信機において要求される、リペアサーバから前記１つの受信機への前記リペアデータパケットの送信をトリガするためのものであり、前記データパケットと前記リペアデータパケットとは順方向誤り訂正符号化技法によってデータオブジェクトから生成され、前記データオブジェクトは前記送信機と前記１以上の受信機との間で転送されるべきものであり、前記順方向誤り訂正符号化技法は、前記データオブジェクトから生成されるデータパケットの数より小さい、最低数のデータパケットの受信が、前記１つの受信機による前記データオブジェクトの再構成を可能にするために十分であるという特性を有し、前記リペア情報は、前記１つの受信機による前記データオブジェクトの再構成を可能にするために何個のリペアデータパケットが前記１つの受信機に送信される必要があるかを前記リペアサーバが決定するのを可能にし、前記リペア情報は、前記１つの受信機において要求されるデータパケットの識別表示（identification）を含まない、ステップ、
    をコンピュータに実行させるためのプログラム。
49. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項１に記載の方法。
50. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項１９に記載の方法。
51. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項２３に記載の装置。
52. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項２９に記載の装置。
53. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項４７に記載のプログラム。
54. 前記リペア情報は、また、前記１つの受信機において要求されるデータパケットの識別を可能にする情報を含まない、請求項４８に記載のプログラム。

Images