JP2008508762A - ポイント・ツー・マルチポイント伝送システムのためのポイント・トゥー・ポイントリペア応答メカニズム - Google Patents

Abstract

本発明は、データシンボルを伝送するシステムにおける、方法、システム、送信機、ネットワークエレメント、受信機およびソフトウェアアプリケーションに関し、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ１以上のデータシンボルが伝送され、ファイル配信プロトコルに従って第１のタイプのヘッダが前記データシンボルに付与され、ポイント・ツー・ポイントリペアセッション内でリペアサーバから前記受信機のうちの１つの特定の受信機へ１以上のリペアデータシンボルが伝送され、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダが前記リペアデータシンボルに付与される。

Description

本発明は、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ１以上のデータシンボルを伝送し、ポイント・ツー・ポイントリペアセッション内でリペアサーバから前記受信機のうちの１つの特定の受信機へ１以上のリペアデータシンボルが伝送される、データシンボルを伝送するシステムにおける、方法、システム、送信機、ネットワークエレメント、受信機およびソフトウェアアプリケーションに関する。

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

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

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

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

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

ＦＬＵＴＥはＦＥＣおよびＡＬＣの構成ブロックに構成する１つ乃至多数のトランスポートプロトコルである。ＦＬＵＴＥは、（単複の）送信機から（単複の）受信機への１方向システムにわたるファイル配信を目的とするものである。ＦＬＵＴＥには、ＦＬＵＴＥを無線ＰｔＭシステムにとって適切なものにする特殊化が含まれている。ＦＬＵＴＥプロトコルの詳細については、ＩＥＴＦの上述のＲＭＴ作業グループによって作成された“１方向トランスポートを介するＦＬＵＴＥファイル配信”（インターネットドラフト）と題する文献にさらに詳細な解説がある。

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

受信機がリペアセッションのスケジューリングを行うとき、例えばＨＴＴＰセッションなどのＰｔＰセッションがこの時受信機とリペアサーバとの間で確立され、該セッション時に所望のリペアデータシンボルが受信機へ送信される。

例えばユーザデータグラムプロトコル（ＵＤＰ）のような信頼性のないプロトコルに基づくＰｔＭセッション時にデータシンボルが伝送され、かつ、例えばトランスポート制御プロトコル（ＴＣＰ）などのような信頼性のあるプロトコルに基づくＰｔＰセッション時にリペアデータシンボルが伝送されるものの、データシンボルと同じヘッダ情報が現在リペアデータシンボルに供給されている。このヘッダ情報には、デフォルトの層符号化トランスポート（ＬＣＴ）ヘッダと、ヘッダ拡張子セクションと、ＦＥＣペイロードＩＤセクションとが含まれている。

ＬＣＴヘッダには以下が含まれている：
フラグアレイと、ＬＣＴヘッダ長フィールドと、ＦＥＣ符号化ＩＤのシグナリングを行うためのコードポイントフィールドとを含む第１のセクションと、
輻輳状態制御情報（ＣＣＩ）
移送セッション識別子（ＴＳＩ）
トランスポートオブジェクト識別子（ＴＯＩ）
送信機の現在時刻（ＳＣＴ）
予想残り時間（ＥＲＴ）

しかし、受信機がリペアデータシンボルを簡単に特定し、マルチキャスト／放送ＰｔＭセッション中に部分的にダウンロードした（単複の）ファイルの復号化を終了できるように、最も効率のよい方法でリペアデータシンボルを送信することが望ましい。リペアデータシンボルの伝送時に受けるオーバヘッドは通常すでに送信されたデータシンボルの再送信を表わすものであり、したがって、ＰｔＰ応答時間を減らすために、受信機の操作を単純に保ちながら該オーバヘッドを小さく保つことが望ましい。

したがって、さらに効率のよい方法、システム、送信機、ネットワークエレメント、受信機並びにソフトウェアアプリケーションに対する要望がポイント・ツー・マルチポイントセッションとポイント・ツー・ポイントセッションの双方におけるデータシンボルの伝送システムに存在することになる。

ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ１以上のデータシンボルを伝送し、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与するステップと、ポイント・ツー・ポイントリペアセッション内で前記受信機のうちの１つの特定の受信機からリペアサーバへ１以上のリペアデータシンボルを伝送し、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与するステップと、を有するデータシンボルの伝送方法が提案される。

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

前記伝送データシンボルは、例えば、前記受信機へ転送すべきコンテンツに関係するものであってもよい。このコンテンツをセグメント化し、処理して、前記受信機への伝送をサポートするようにしてもよい。これに対して、前記データシンボルは上記セグメント化と処理との結果と理解される。例えば、マルチメディアファイルなどのトランスポートオブジェクトや該トランスポートオブジェクトの一部をＦＥＣ符号化することによって、１つのデータシンボルが（符号化パケットなどの）１以上の符号化シンボルを表わす場合がある。その場合、個々のデータシンボルが、１つの２進数（ビット）などの唯一の情報単位や、複数の情報単位を表わすようにしてもよい。

例えば、ＦＬＵＴＥプロトコルなどのファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与する。前記付与は、例えば前記データシンボルに前記ヘッダを追加することによって、あるいは、前記第１のタイプのヘッダと前記データシンボルとの間の関連付けを形成する別の技法によって行うようにしてもよい。前記第１の型のデータシンボルと該データシンボルの関連するデータシンボルとが、例えばＦＬＵＴＥパケットを形成するようにしてもよい。これらの第１のタイプのヘッダは、例えば、前記送信機側および前記受信機側におけるプロトコルエンティティ間での前記データシンボルの論理転送に関連する情報を含むものであってもよい。

少なくとも、特定の受信機として示される、前記受信機のうちの１つの受信機側でリペアデータシンボルの受信が要求されるが、該リペアデータシンボルの受信は、例えば不正確な受信や伝送データシンボルの損失のような複数の理由に起因して生じる場合がある。前記特定の受信機は上記要件を認知して、前記データ伝送シンボル中に、あるいは、データ伝送シンボルが終了した後にリペアデータシンボルの受信を図るようにしてもよい。

前記リペアデータシンボルは、例えば、前記特定の受信機が受信しなかった伝送データシンボルの単純なコピーであってもよい。同様に、上記リペアデータシンボルは、符号化と実際のコンテンツとの双方に関して異なるものであってもよい。リペアデータシンボルは、前記特定の受信機が必要とする情報量を前記特定の受信機に提供するのに役立つものである。

前記リペアサーバからのリペアデータシンボルの伝送をトリガするために、前記特定の受信機はリペア要求メッセージの形でリペアデータ情報を前記リペアサーバへ信号送信してもよい。この信号送信はポイント・ツー・ポイント転送の形で行われる場合もある。このようにしてリペアサーバは適切なリペアデータシンボルを生成し、この適切なリペアデータシンボルを特定の受信機へ伝送することが可能となる。リペアデータシンボルの上記転送はポイント・ツー・ポイントリペアセッション時に行われる。

前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与する。したがって、前記第２の型のデータシンボルヘッダは、例えば前記ファイル配信プロトコルに完全に従うことも可能であり、次いで、該第２の型のデータシンボルヘッダは、少なくとも２つの異なるタイプのデータシンボルヘッダを定義するように要求される。同様に、前記第２のタイプのヘッダが、前記ファイル配信プロトコルによって定義される１以上のデータシンボルヘッダの修正を表わすようにしてもよい。その場合、前記修正は、すべての形の前記第１のタイプのヘッダのパラメータの追加、除去または変更、並びに、いくつかのおそらく修正済みの第１のタイプのヘッダの組み合わせを含むようにすることが可能である。好適には、前記第１のタイプのヘッダの少なくとも１つのパラメータを除去することによって、前記修正が前記第１のタイプのヘッダの減少のみを含むようにすることが望ましい。例えば、第２のタイプのヘッダをリペアデータシンボルに追加することによって、または、前記リペアデータシンボルを前記第２のタイプのヘッダと関連づけることによって前記付与を行うことも可能である。例えば、いくつかのリペアデータシンボルを組み合わせて、１つのＨＴＴＰパケットに変え、次いで、１つの第２のタイプのヘッダを前記ＨＴＴＰパケットの中へ含むようにすることも可能である。その場合、前記第２のタイプのヘッダが前記ＨＴＴＰパケット内のすべてのリペアデータシンボル用として有効な情報を含むことになる。

したがって、本発明は一方でデータシンボルの転送用として、そして、他方でリペアデータシンボルの転送用として異なるタイプのヘッダの利用を提案するものである。上記提案は、（ＵＤＰなどの）信頼性のないプロトコルに基づくデータシンボルはポイント・ツー・マルチポイントセッション時に伝送し、これに対して、（ＴＣＰなどの）信頼性のあるプロトコルに基づくリペアデータシンボルはポイント・ツー・ポイントセッション時に伝送するようにし、それによって、リペアデータシンボルが使用する第２の型のデータシンボルヘッダの中に含む必要のないパラメータのうちの少なくともいくつかのパラメータをデータシンボル用として使用する第１のタイプのヘッダの中に含むようにする必要があるという事実を考慮するものである。本発明に基づくこのアプローチは、オーバヘッドを大幅に減らす、リペアデータシンボルのさらに効率のよい転送を可能にするものである。前記ファイル配信プロトコルに少なくとも部分的に従う第２のタイプのヘッダを用いる場合、リペアサーバ側のプロトコルインスタンスと、受信機側のプロトコルインスタンスの双方並びに実施構成において小さな変更が不要となったり、あるいは、小さな変更のみが必要となったりする場合がある。

本発明によれば、前記第１のタイプのヘッダは前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。前記パラメータは、例えば、輻輳状態制御情報（ＣＣＩ）、送信機の現在時刻（ＳＣＴ）、予想残り時間（ＥＲＴ）、および、場合によっては移送セッション識別子（ＴＳＩ）であってもよい。

本発明によれば、前記ファイル配信プロトコルは前記ポイント・ツー・マルチポイントセッション時にユーザデータグラムプロトコルのサービスを利用することが可能となる。

本発明によれば、前記ファイル配信プロトコルは前記ポイント・ツー・ポイントリペアセッション時にトランスポート制御プロトコルのサービスを利用することが可能となる。

本発明によれば、前記ファイル配信プロトコルはポイント・ツー・ポイントリペアセッション時にハイパーテキスト転送プロトコルのサービスを利用することが可能となる。このプロトコルはトランスポート制御プロトコルのサービスを順番に利用することも可能である。

本発明によれば、前記ファイル配信プロトコルは１方向トランスポートを介するファイル配信（ＦＬＵＴＥ）プロトコルであってもよく、前記データシンボルと前記リペアデータシンボルとはＦＬＵＴＥ符号化シンボルを表わすものであってもよい。例えば、前記ポイント・ツー・マルチポイントセッション時に前記１以上の受信機へ配信すべきトランスポートオブジェクトの複数部分の順方向エラー修正の符号化を行うことによって前記ＦＬＵＴＥ符号化シンボルを取得することも可能である。個々のデータシンボルは、例えば１乃至いくつかの符号化シンボルを表わすことも可能である。

本発明によれば、前記ＦＬＵＴＥプロトコルは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）のサービスを利用することも可能であり、前記ＨＴＴＰは前記リペアサーバと前記特定の受信機との間でＨＴＴＰパケットを転送することも可能である。この目的のために、前記データシンボルと、該データシンボルの関連する１以上の第２のタイプのヘッダとをペイロードとして前記ＨＴＴＰパケットの中へ組み込むことも可能である。

本発明の第１の実施形態によれば、１つのＦＬＵＴＥ符号化シンボルと、１つの関連する第２のタイプのヘッダとの組み合わせによって圧縮済みＦＬＵＴＥパケットが形成され、前記ＨＴＴＰパケットのうちの少なくとも１つのＨＴＴＰパケットは、ＨＴＴＰパケットヘッダと、１以上の前記圧縮済みＦＬＵＴＥパケットとを含むことになる。

本発明の前記第１の実施形態によれば、前記圧縮済みＦＬＵＴＥパケットの前記第２のタイプのヘッダは、少なくとも、層別符号化移送ヘッダの一部と、前記圧縮済みＦＬＵＴＥパケット内の前記ＦＬＵＴＥ符号化シンボルの識別子と、前記ＦＬＵＴＥ符号化シンボルのサイズとを有する。前記層別符号化移送ヘッダは、ＦＬＵＴＥプロトコル層が最上部に構成されている層符号化トランスポートビルディングブロックから生じるヘッダであってもよい。前記ＦＬＵＴＥ符号化シンボルの前記識別子は、例えばソースブロック番号（ＳＢＮ）と、前記ＦＬＵＴＥ符号化シンボルに対応する符号化シンボル識別子（ＥＳＩ）とを示すＦＥＣペイロードＩＤなどであってもよい。

本発明の第２の実施形態によれば、前記少なくとも１つのＨＴＴＰパケットはマルチパート多目的インターネットメール拡張子（ＭＩＭＥ）構造を有し、前記圧縮済みＦＬＵＴＥパケットは、ＭＩＭＥ境界によって前記ＨＴＴＰパケットヘッダから離間し、かつ、互いに離間される。このとき、ＭＩＭＥ境界による前記離間によって、符号化シンボルサイズ用パラメータのスキップを前記第２のタイプのヘッダ内で行うことも可能である。

本発明の前記第２の実施形態によれば、前記圧縮済みＦＬＵＴＥパケットの前記第２のタイプのヘッダは、層別符号化移送ヘッダの一部と、前記ＦＬＵＴＥ符号化シンボルの識別子とを前記圧縮済みＦＬＵＴＥパケットの中に含むものである。

本発明の第３の実施形態によれば、前記ＨＴＴＰパケットのうちの少なくとも１つのＨＴＴＰパケットには、ＨＴＴＰパケットヘッダと、少なくとも２つのＦＬＵＴＥ符号化シンボルおよびそれぞれの関連する識別子を含む１以上のブロックと、前記ブロックの各ブロック用の１つのそれぞれの第２のタイプのヘッダとが含まれ、個々それぞれの第２のタイプのヘッダがそれぞれのブロックのすべてのＦＬＵＴＥ符号化シンボルに対して有効である。ＦＬＵＴＥ符号化シンボルを組み合わせてブロックに変える処理によって、ＦＬＵＴＥ符号化シンボル毎に１つの第２のタイプのヘッダを提供する代わりに、個々のブロック用として唯一の第２のタイプのヘッダを利用することが可能となる。組み合わされてブロックにされた前記ＦＬＵＴＥ符号化シンボルは、同じサイズ、同じＴＯＩ、同じＴＳＩなどの同じ特徴、並びに、個々のＦＬＵＴＥ符号化シンボルについて異なる特徴を好適に有し、この時、該ＦＬＵＴＥ符号化シンボルを前記ＦＬＵＴＥ符号化シンボルブロックの中へ組み込むことも可能である。

本発明の前記第３の実施形態によれば、前記少なくとも１つのＨＴＴＰパケットはＭＩＭＥ構造を有し、前記ＨＴＴＰパケットヘッダと、前記ブロックと、前記第２のタイプのヘッダとはＭＩＭＥ境界によって互いに離間される。この場合、ＦＬＵＴＥ符号化シンボルのブロックサイズの明示的伝送が要求されない場合もある。

本発明の前記第３の実施形態によれば、前記それぞれの第２のタイプのヘッダは、層別符号化移送ヘッダの一部と、前記ＦＬＵＴＥ符号化シンボルのサイズとを前記それぞれのブロックの中に含むものである。

本発明の前記第３の実施形態によれば、前記ブロックのうちの少なくとも１つのブロックは、ＦＬＵＴＥ符号化シンボルと、それぞれの関連する識別子と、それぞれの層別符号化移送ヘッダ長と、少なくとも１つの層別符号化移送ヘッダ拡張子とを有している。前記ＬＣＴヘッダ拡張子は、例えばＥＸＴ_ＦＴＩやＥＸＴ_ＦＤＴなどであってもよい。前記それぞれのＬＣＴヘッダ長は、前記ヘッダ拡張子のうちの１以上のヘッダ拡張子が存在しているか、いないかを示すことも可能である。

本発明の第４の実施形態によれば、前記ＨＴＴＰパケットのうちの少なくとも１つのパケットは、ＨＴＴＰパケットヘッダと、１つの第２のタイプのヘッダと、少なくとも２つのＦＬＵＴＥ符号化シンボルを含む１以上のブロックとを有する。この場合、唯一の第２のタイプのヘッダが、前記ＨＴＴＰパケットの中に含まれているすべてのＦＬＵＴＥ符号化シンボルに対して用いられ、上記第２のタイプのヘッダは、前記ＦＬＵＴＥ符号化シンボルのすべてに対してすべてのヘッダ情報を提供するインデックスオブジェクトとして機能する。次いで、例えば、前記第２のタイプのヘッダを区分化して、前記ＦＬＵＴＥ符号化シンボルブロックの各々に関連するサブヘッダに変えることが可能となる。

本発明の前記第４の実施形態によれば、前記少なくとも１つのＨＴＴＰパケットはＭＩＭＥ構造を有し、前記ＨＴＴＰパケットヘッダと、前記１つの第２のタイプのヘッダと、前記１以上のブロックとはＭＩＭＥ境界によって互いに離間される。この離間によって、ＦＬＵＴＥ符号化シンボルブロックのサイズを明示的も伝送する処理のスキップが可能となる。

本発明の前記第４の実施形態によれば、前記第２のタイプのヘッダが、個々それぞれのブロック用の１つのそれぞれのサブヘッダを前記ＨＴＴＰパケットの中に含み、前記それぞれのサブヘッダの各々が、層別符号化移送ヘッダの一部と、前記それぞれのブロック内の前記ＦＬＵＴＥ符号化シンボルのサイズと、前記それぞれのブロック内のＦＬＵＴＥ符号化シンボルの数と、前記それぞれのブロック内の個々のＦＬＵＴＥ符号化シンボル用の１つの識別子とを有することになる。

本発明の前記第４の実施形態によれば、前記サブヘッダのうちの少なくとも１つのサブヘッダは、個々のＦＬＵＴＥ符号化シンボル用の１つの層別符号化移送ヘッダ長を前記それぞれのブロック内に有し、前記ＦＬＵＴＥ符号化シンボルのうちの少なくとも１つのシンボル用の少なくとも１つの層別符号化移送ヘッダ拡張子を前記それぞれのブロック内に有する。前記ＬＣＴヘッダ拡張子は、例えばＥＸＴ_ＦＤＴやＥＸＴ_ＦＴＩなどであってもよい。前記ＬＣＴヘッダ長は、前記ヘッダ拡張子のうちの１以上のヘッダ拡張子が存在しているか、いないかを示すものであってもよい。

本発明によれば、前記第２のタイプのヘッダが、前記ポイント・ツー・マルチポイント伝送セッションの識別子をさらに有することも可能である。前記識別子は、例えば移送セッション識別子（ＴＳＩ）であってもよい。しかし、唯一の伝送セッションのみが存在する場合、あるいは、前記ＦＬＵＴＥ符号化シンボルがどの伝送セッションに関連するかがコンテキストから暗黙のうちに明らかな場合、前記伝送セッションの前記識別子が不要となる場合もある。

本発明によれば、前記第２のタイプのヘッダは、前記ＦＬＵＴＥ符号化シンボルが関係するトランスポートオブジェクトの識別子をさらに有するであってもよい。この識別子は、例えばトランスポートオブジェクト識別子（ＴＯＩ）であってもよい。しかし、トランスポートセッション毎に唯一のトランスポートオブジェクトを伝送する場合、前記識別子が不要となる場合もある。

本発明によれば、前記第２のタイプのヘッダが、前記ＦＬＵＴＥ符号化シンボルが関係するトランスポートオブジェクトの識別子をさらに含むようにすることも可能である。これらのヘッダ拡張子は例えばＥＸＴ_ＦＴＩやＥＸＴ_ＦＤＴなどであってもよい。

本発明によれば、前記層別符号化移送ヘッダの前記一部が、層別符号化移送バージョン番号と、輻輳状態制御フラグと、予約済みスペースと、移送セッション識別子フラグと、移送オブジェクト識別子ＴＯＩフラグと、ハーフワードフラグと、送信機の現在時刻フラグと、予想残り時間フラグと、クローズセッションフラグと、クローズオブジェクトフラグと、層別符号化移送ヘッダ長と、コードポイントとを有することも可能である。前記層別符号化移送ヘッダの前記一部は例えば４バイト長であってもよい。

データシンボルを伝送するシステムであって、送信機と、１以上の受信機と、リペアサーバとを備え、ポイント・ツー・マルチポイント伝送セッション内で前記送信機から前記１以上の受信機へ１以上のデータシンボルを伝送し、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与し、ポイント・ツー・ポイントリペアセッション内で前記受信機のうちの１つの特定の受信機から前記リペアサーバへ１以上のリペアデータシンボルを伝送し、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与するシステムがさらに提案される。

本発明のシステムによれば、 前記第１のタイプのヘッダは前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

データシンボルを伝送するための、システム内の送信機であって、ポイント・ツー・マルチポイント伝送セッション内で前記送信機から１以上の受信機へ１以上のデータシンボルを伝送するように構成された手段を備え、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与し、ポイント・ツー・ポイントリペアセッション内で前記受信機のうちの１つの特定の受信機からリペアサーバへ１以上のリペアデータシンボルを伝送し、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与する送信機がさらに提案される。前記送信機と前記リペアサーバとは共置することも可能であり、あるいは、同一のものであることさえ可能である。

本発明の送信機によれば、前記第１のタイプのヘッダは前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

データシンボルを伝送するための、システム内のネットワークエレメントであって、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ１以上のデータシンボルを伝送し、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与するネットワークエレメントであって、前記ネットワークエレメントが、ポイント・ツー・ポイントリペアセッション内で前記ネットワークエレメントから前記受信機のうちの１つの特定の受信機へ１以上のリペアデータシンボルを伝送するように構成され、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与する手段を備えたネットワークエレメントがさらに提案される。前記送信機と前記ネットワークエレメントとは共置することも可能であり、あるいは、同一のものであることさえ可能である。前記ネットワークエレメントは、例えばリペアサーバなどであってもよい。

本発明のネットワークエレメントによれば、前記第１のタイプのヘッダは、前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

データシンボルを伝送するための、システムのネットワークエレメントにおいて実行可能なソフトウェアアプリケーションであって、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ１以上のデータシンボルを伝送し、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与し、前記ソフトウェアアプリケーションが、ポイント・ツー・ポイントリペアセッション内で前記ネットワークエレメントから前記受信機のうちの１つの特定の受信機へ１以上のリペアデータシンボルを前記ネットワークエレメントに伝送させるためのプログラムコードであって、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与するプログラムコードを備えたソフトウェアアプリケーションがさらに提案される。

前記ソフトウェアアプリケーションは、例えば、前記ネットワークエレメントのメモリとして媒体に格納されたプログラムコードを備えたコンピュータプログラム製品であってもよい。

本発明のソフトウェアアプリケーションによれば、前記第１のタイプのヘッダは、前記第２のタイプのヘッダの中には含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

データシンボルを伝送するための、システム内の受信機であって、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ送信された１以上のデータシンボルを受信するように構成された手段であって、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与する手段と、ポイント・ツー・ポイントリペアセッション内でリペアサーバから１以上のリペアデータシンボルを受信するように構成された手段であって、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与する手段とを備えた受信機がさらに提案される。

本発明の受信機によれば、前記第１のタイプのヘッダは前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

データシンボルを伝送するためにシステムの受信機において実行可能なソフトウェアアプリケーションであって、該ソフトウェアアプリケーションが、ポイント・ツー・マルチポイント伝送セッション内で送信機から１以上の受信機へ送信された１以上のデータシンボルを前記受信機に受信させるプログラムコードであって、ファイル配信プロトコルに従って第１のタイプのヘッダを前記データシンボルに付与するプログラムコードと、ポイント・ツー・ポイントリペアセッション内で１以上のリペアデータシンボルをリペアサーバから前記受信機に受信させるプログラムコードであって、前記同じファイル配信プロトコルに少なくとも部分的に従う１以上の第２のタイプのヘッダを前記リペアデータシンボルに付与するプログラムコードと、を含むソフトウェアアプリケーションがさらに提案される。

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

本発明のソフトウェアアプリケーションによれば、前記第１のタイプのヘッダは、前記第２のタイプのヘッダの中に含まれていない少なくとも１つのパラメータを含むものであってもよく、前記パラメータはポイント・ツー・マルチポイント伝送に関係するものであってもよい。

本発明の上記局面並びにその他の局面は、本明細書で後述する実施形態から明らかにされ、該実施形態を参照しながら解明される。

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

本発明は、２つの異なるヘッダタイプの利用を提案するものであり、これら２つのヘッダタイプは、一方で送信機から複数の受信機へデータシンボルのＰｔＭ伝送を行うためのものであり、他方でリペアサーバから前記受信機のうちの１つの受信機へリペアデータシンボルのＰｔＰ伝送を行うためのものである。上記提案は、例えばＵＤＰの場合のような信頼性の低いプロトコルに基づいてデータシンボルの伝送を行い、それによって、例えばＴＣＰの場合のように、信頼性のより高いプロトコルに基づいて行われるリペアデータシンボルの伝送の際に、該データシンボルの伝送がより多くのオーバヘッド情報を必要とするという事実を勘考するものである。

本発明の詳細な説明では、ＰｔＭ伝送の場合のＦＬＵＴＥ／ＵＤＰの利用事例並びにＰｔＰ伝送の場合のＨＴＴＰ／ＴＣＰの利用事例を頻繁に参照する。上記利用事例の選択は、単に例示的な性質の選択にすぎないことことを付記し、さらに、或る一定のプロトコルに従って、最初にＰｔＭシナリオの形で伝送されるデータシンボルをＰｔＰシナリオの形で再送する必要があり、その際少なくとも部分的に前記プロトコルを堅持する必要がある同様のシナリオにおいても本発明が十分同等に適用可能であることを付記しておく。

図１ａは、送信機１から複数の受信機３−１〜３−３へデータシンボルを伝送するＰｔＭセッションを描く図である。この送信機は、例えばインターネットなどのネットワーク２と接続され、例えば３ＧＰＰ ＭＢＭＳシステムの範囲内で行われる放送セッション時や、マルチキャストセッション時に、前記複数の受信機へ配信する配信対象コンテンツにアクセスする。この目的のために、上記送信機はプロセッサ１０、メモリ１１および送受信（Ｔｘ／Ｒｘ）インスタンスを備えている。プロセッサ１０の制御の下でコンテンツは、ネットワーク２から収集され、おそらくメモリ１１に一時的に記憶され、次いで、符号化と変調とを行って、Ｔｘ／Ｒｘインスタンス１２を介して、受信機３−１〜３−３のＴｘ／Ｒｘインスタンス３２へ伝送される。前記プロセッサ１０は、ＩＳＯ／ＯＳＩプロトコルスタックのすべての層の機能、特に、コンテンツを符号化して、ＦＬＵＴＥヘッダと共にＦＬＵＴＥパケットを形成するＦＬＵＴＥ符号化シンボルに変える機能を実行し、これらＦＬＵＴＥヘッダの生成は、前記プロセッサ１０が実行するものと理解される。

前記受信機３−１〜３−３（これら受信機のうち受信機３−１のみをより詳細に図示）側では、Ｔｘ／Ｒｘインスタンス３２を介してＦＬＵＴＥパケットが受信され、プロセッサ３０により復調と復号化とが行われ、前記受信機内で、あるいは、接続された装置内で実行する任意のタイプのアプリケーション用の入力として該ＦＬＵＴＥパケットはメモリ３１に格納される。

図１ｂは、前記受信機３−１側でＦＬＵＴＥパケットが正しく受信されなかったり、前記受信機３−１側で十分なＦＬＵＴＥパケットが受信されなかったりした結果、前記受信機３−１が、前記送信機１により配布されたコンテンツの完全な再構成が可能となるリペアデータシンボルの伝送が要求されるケースを描く図である。この目的のために、リペア要求メッセージは受信機３−１からリペアサーバ４へ送信されるが、このリペアサーバ４は送信機１と類似の設定を有し、さらに前記送信機１と全く同一のものである場合さえある。前記リペア要求メッセージの伝送は例えばＨＴＴＰセッション時に行うことも可能である。次いで、前記リペアサーバ４は、前記受信機３−１が要求するＦＬＵＴＥパケット関連情報が含まれている前記リペア要求メッセージの処理を行う。

図１ｃはリペアサーバ４の上記処理の結果を描く図である。リペアサーバ４が、受信機３−１へ送信する必要があるリペア応答時のリペアデータシンボルとしてＦＬＵＴＥ符号化シンボルを判定した場合、 例えば必要なＦＬＵＴＥ符号化シンボルが関連するトランスポートオブジェクトや、該トランスポートオブジェクトの一部などの上記リペアデータシンボルの生成に必要な情報が上記リペアサーバ４によってネットワーク２からフェッチされることになる。上記トランスポートオブジェクトに基づいて、リペアデータシンボル（ＦＬＵＴＥ符号化シンボル）がプロセッサ４０により生成され、圧縮済みＦＬＵＴＥパケットを取得するために、該リペアデータシンボルに圧縮済みＦＬＵＴＥヘッダが付与され、次いで、該リペアデータシンボルはリペア応答メッセージの形で受信機３−１へ送信される。

したがって、本発明によれば、ＦＬＵＴＥパケット内でデータシンボル用として使用するＦＬＵＴＥヘッダと比べて、リペアサーバ４は圧縮済みＦＬＵＴＥヘッダをリペアデータシンボル用として使用することになる。すなわち、この圧縮済みＦＬＵＴＥヘッダには、前記ＦＬＵＴＥヘッダよりも少ないパラメータすなわち情報が含まれていることになる。例えば、ＰｔＭ伝送に固有のすべてのパラメータであって、かつ、ＰｔＰ伝送時には不要なすべてのパラメータのスキップが、前記圧縮済みＦＬＵＴＥヘッダ内で可能となる。また、いくつかのＦＬＵＴＥ符号化シンボルによる、同じ圧縮済みＦＬＵＴＥヘッダの共有も可能となる。

図２ａはプロトコルスタックを概略的に描く図であり、該プロトコルスタックは、送信機１側のＦＬＵＴＥプロトコルエンティティから、受信機３−１〜３−３側のピアＦＬＵＴＥプロトコルエンティティへ、（ＦＬＵＴＥパケットに含まれる）ＦＬＵＴＥ符号化シンボルのＰｔＭ伝送を行うのに利用される。ＦＬＵＴＥパケットを転送するために、ＦＬＵＴＥ層５１はＵＤＰ層５３のサービスを利用し、次いで、該ＵＤＰ層はインターネットプロトコル（ＩＰ）層５３のサービスを利用する。この場合、実際のＩＰパケットの転送はプロトコルスタックの下位層５４によって行われる。上記実際のＩＰパケットの転送では、ＦＬＵＴＥプロトコルに対応するＦＬＵＴＥヘッダが使用される。

図２ｂはプロトコルスタックを概略的に描く図であり、該プロトコルスタックは、リペアサーバ４側のＦＬＵＴＥプロトコルエンティティから、受信機３−１側のピアＦＬＵＴＥプロトコルエンティティへ（圧縮済みＦＬＵＴＥパケットに含まれる）ＦＬＵＴＥ符号化シンボルのＰｔＰ伝送を行うのに利用される。このケースでは圧縮済みＦＬＵＴＥヘッダが使用される。図２ａのプロトコルスタックとは対照的に、ＴＣＰ層５６の上に存在し、ＦＬＵＴＥプロトコル層５１の下に存在するＨＴＴＰ層５５のＰｔＰ伝送サービスが今度はＦＬＵＴＥプロトコル層５１によって利用される。この目的のために、圧縮済みＦＬＵＴＥパケットがＨＴＴＰパケットの中へ組み込まれ、次いで、該ＨＴＴＰパケットはリペアサーバ４側のピアＨＴＴＰエンティティと受信機３−１との間で転送される。上記転送のために、ＨＴＴＰ／ＴＣＰは下に在るＩＰ層５３のサービスを利用する。図２ａの場合と同様、次にＩＰパケットは下位層５４により転送される。

本発明の第１の実施形態
図３ａは、本発明の第１の実施形態による圧縮済みＦＬＵＴＥパケット８を描く図である。上記圧縮済みＦＬＵＴＥパケット８は、圧縮済みＦＬＵＴＥヘッダ６と、ペイロードとしての１つの符号化シンボル７とから構成されている。

ＰｔＭ伝送時に使用されるＦＬＵＴＥパケット内の或るフィールドのなかには、ＰｔＰリペアセッション時にはもはや不要となるものもある。というのは、信頼性のないＵＤＰリンクを介して配信されるＰｔＭセッション時のＦＬＵＴＥパケットとは対照的に、リペア応答は信頼性のあるＴＣＰリンクを介して配信されるからである。したがって、本発明は、リペアセッション時に使用するＰｔＰ応答ペイロードフォーマットの中に最も主要なフィールドのみを含むことを保証しながら、最小限にまでＦＬＵＴＥパケットのティアダウンを行うことを提案するものである。

図３ａの圧縮済みＦＬＵＴＥヘッダには、最初の４バイトのデフォルト層符号化トランスポート（ＬＣＴ）ヘッダ６１が含まれる。対応するフィールド６１００〜６１１１並びにこれらフィールドの意味に変化はない。ＴＳＩフラグ６１０３、ＴＯＩフラグ６１０４およびハーフワードフラグ６１０５フィールドは、ＴＳＩフィールド６２とＴＯＩフィールド６３のサイズに関する情報を提供するフィールドである。コードポイント６１１１フィールドを利用して、ＦＬＵＴＥプロトコルによって特定されているように、信号ＦＥＣ符号化ＩＤの信号送信が行われる。輻輳状態制御フラグ６１０１、送信機の現在時刻フラグ６１０６、予想残り時間フラグ６１０７、クローズセッションフラグ６１０８およびクローズオブジェクトフラグ６１０９のようないくつかのフィールドが、ＰｔＰ応答時に送信されない場合がある。というのは、上記フィールドは、信頼性のあるＰｔＰ接続を介して送信する場合、役に立たないからである。コンテンツおよびＬＣＴヘッダセクション６１のフィールドのビットサイズは以下のように要約できる：
Ｖ＝ＬＣＴバージョン番号（４ビット）
Ｃ＝輻輳状態制御フラグ（２ビット）
Ｒ＝予備（２ビット）
Ｓ＝ＴＳＩフラグ（１ビット）
Ｏ＝ＴＯＩフラグ（２ビット）
Ｈ＝ハーフワードフラグ（１ビット）
Ｔ＝送信機の現在時刻フラグ（１ビット）
Ｒ＝予想残り時間フラグ（１ビット）
Ａ＝クローズセッションフラグ（１ビット）
Ｂ＝クローズオブジェクトフラグ（１ビット）
ＨＤＲ_ＬＥＮ＝ＬＣＴヘッダの長さ（８ビット）
ＣＰ＝コードポイント（８ビット）

圧縮済みＦＬＵＴＥヘッダ６のＴＳＩフィールド６２は、０、１６、３２または４８ビットのサイズを有することができる。ＴＳＩはセッションの特定に必要となる。特定の受信機は、ＰｔＰリペアセッションに先立って、同じ送信機から２以上のＦＬＵＴＥダウンロードセッションに参加したものであってもよい。したがって、特定の受信機は、ＰｔＰリペア要求時に該特定の受信機がＰｔＰリペアに要求を行う際の対象セッションを指定する必要がある。リペアサーバは、ＰｔＰリペア応答時にＴＳＩを送信し、それによって特定の受信機は、リペアデータシンボルが属するセッションの特定を行うことが可能となる。送信機のアドレスとＴＳＩとによって上記セッションは一意的に特定されることになる。

圧縮済みＦＬＵＴＥヘッダ６のＴＯＩフィールド６３は、０、１６、３２、４８、６４、８０、９６または１１２ビットのサイズを有することができる。ＴＯＩは、セッション内でのトランスポートオブジェクトの特定に必要となる。ＦＬＵＴＥダウンロードは、単一のセッション時に２以上のトランスポートオブジェクト（ファイル）から構成することができる。例えば、オーディオファイルとビデオファイルとは同じＦＬＵＴＥセッション時にダウンロードしたものであってもよい。特定の受信機は、該特定の受信機がＰｔＰリペアに要求を行う際の対象セッションを指定する必要がある。上記（ＴＯＩ、ＴＳＩ）はトランスポートオブジェクトを一意的に特定するものである。

圧縮済みＦＬＵＴＥヘッダ６のＦＥＣペイロードＩＤ６４はＦＥＣ符号化ＩＤに依存して決められる。ＦＥＣ符号化ＩＤとＦＥＣペイロードＩＤ間のマッピングは、ＩＥＴＦ発行のＲＦＣ３４５２“順方向エラー修正ビルディングブロック”およびＩＥＴＦ発行のＲＦＣ３６９５“コンパクトな順方向エラー修正（ＦＥＣ）方式”の中で、および、２００４年６月７日発表の、Ｍ．Ｌｕｂｙのデジタルファウンテン（ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｍａｉｌ−ａｒｃｈｉｖｅ／ｗｅｂ／ｒｍｔ／ｃｕｒｒｅｎｔ／ｍｓｇ００３１２．ｈｔｍｌで入手可能）による、最新のＩＥＴＦインターネットドラフト“シンプルな順方向エラー修正方式”の中で定義されているものと同じものである。例えば、（ＭＢＭＳ ＦＬＵＴＥにより採用されている）ＲＦＣ３６９５によると、ＦＥＣ符号化ＩＤ＝０（ノーコードＦＥＣ）の場合、ＦＥＣペイロードＩＤは以下のものによって構成されている：
ＳＢＮ＝ソースブロック番号（２バイト）
ＥＳＩ＝符号化シンボルＩＤ（２バイト）

圧縮済みＦＬＵＴＥヘッダ６のフィールド符号化シンボルサイズ６５は２バイト長を有し、圧縮済みＦＬＵＴＥパケット８の中にペイロードとして含まれている符号化シンボル７のサイズは上記シンボルサイズ６５の中に含まれている。

ＦＬＵＴＥ／ＵＤＰ ＰｔＭ伝送のために使用されるＦＬＵＴＥヘッダ内には、輻輳状態制御情報（ＣＣＩ）、送信機の現在時刻（ＳＣＴ）、および、予想残り時間（ＥＲＴ）を示すパラメータが存在するものの、本発明の第１の実施形態による圧縮済みＦＬＵＴＥヘッダ６がそれ以上上記パラメータを含まないことは明らかである。これらのパラメータは、信頼性のないトランスポートと、大容量スケーラビリティとをサポートするものであり、したがって、ＦＬＵＴＥ／ＨＴＴＰ ＰｔＰ伝送のために使用する圧縮済みＦＬＵＴＥヘッダ６の中にこれらのパラメータを含める必要はない。

図３ａに図示のように、圧縮済みＦＬＵＴＥヘッダ６の情報は、受信機３−１側での再構成に必要な基本情報と考えることができる。本発明の別の実施項目として、任意の数のフィールドを上記最低限の情報に追加してもよい。しかし、本発明の別の実施形態では、いくつかの点で図３ａに図示の圧縮済みＦＬＵＴＥパケット８とは異なる圧縮済みＦＬＵＴＥパケットの利用が可能である。例えば、コンテキストから導き出すことができれば、フィールドのすべてが存在しなくてもよい。例えば、ＦＬＵＴＥセッション時に唯一の単一オブジェクト（ファイル）が配信されたと仮定される場合、ＴＯＩフィールド６３を省いてもよい。本発明の最も一般的な実施形態では、２以上の伝送セッションに関して特定の受信機がリペアデータを要求しなくなる可能性が高い。その場合、ＴＳＩはコンテキストから暗黙のうちにわかり、ＰｔＰリペア応答時に送信されるすべてのパケットに対してＴＳＩはそのまま同じ状態となる。したがって、圧縮済みＦＬＵＴＥヘッダからＴＳＩフィールドを省いてもよいことになる。図３に示されているようなＦＬＵＴＥパケットヘッダ６は、例えばＥＸＴ_ＦＴＩやＥＸＴ_ＦＤＴなどのＬＣＴヘッダ拡張子セクションのような別のセクションを含むものであってもよい。さらに、リペアサーバ４は、コンテキストからＰｔＭ伝送セッション１の送信機のＩＰアドレスが認知できなければ、該ＩＰアドレスも送信して、送信機ＩＰアドレスとＴＳＩとによって上記セッションの完全な特定を図るようにしてもよい。

図３ｂは、図３ａの複数の圧縮済みＦＬＵＴＥパケット８−１〜８−Ｍの、ＨＴＴＰパケット９内への組込みを例示する図であり、この場合、該パケット９は、リペアサーバ４側のピアプロトコルエンティティと、受信機３−１との間でＨＴＴＰ／ＴＣＰにより転送される。この場合、ＨＴＴＰパケット９には、実験的コンテンツタイプの“ｘ−ｆｌｕｔｅＰｔＰ／ｃｏｍｐｒｅｓｓｅｄｆｌｕｔｅｐｋｔ”と共にＨＴＴＰヘッダ９がさらに含まれ、上記“ｘ−ｆｌｕｔｅＰｔＰ／ｃｏｍｐｒｅｓｓｅｄｆｌｕｔｅｐｋｔ”は、ＨＴＴＰパケット９のメッセージ本文の中に圧縮済みＦＬＵＴＥパケット８−１〜８−Ｍが含まれることを示す。

リペアサーバ４から受信機３−１へ伝送されたＰｔＰ ＨＴＴＰレスポンスは、この時以下の形をとる：
ＨＴＴＰ／１．１ ２００ ＯＫ
コンテンツタイプ：x-flutePtP/compressedFlutePkt
コンテンツ長：TOTAL_LENGTH
コンテンツ伝送符号化：２進
圧縮済みＦＬＵＴＥパケット−１
圧縮済みＦＬＵＴＥパケット−２
圧縮済みＦＬＵＴＥパケット−Ｍ

この場合、TOTAL_LENGTHはすべての圧縮済みＦＬＵＴＥパケットのサイズを示す。

本発明の第２の実施形態
本発明の第１の実施形態（図３ａおよび図３ｂを参照のこと）によれば、ＨＴＴＰパケット９に含まれている情報を別の方法で圧縮または再構成を行うことも可能となる。

例えば、本発明の第２の実施形態によれば、マルチパートＭＩＭＥ構造を利用して、圧縮済みＦＬＵＴＥパケットの離間と、送信とを行うことが可能である。マルチパートＭＩＭＥ構造では、“境界文字列（boundary string）”によって構成部分の離間が行われる。このため、図３ａの圧縮済みＦＬＵＴＥヘッダ６の符号化シンボルサイズフィールド６５の省略が可能となり、図４ａによれば圧縮済みＦＬＵＴＥパケット８’に含まれる圧縮済みＦＬＵＴＥヘッダ６’が生じることになる。

図４ｂは対応するＨＴＴＰパケット９’を描く図である。このＨＴＴＰパケット９’では、ＨＴＴＰヘッダフィールド“コンテンツタイプ”は“マルチパート／ミックス”にセットされる。ＨＴＭＬの本体部分が独立し、この本体部分をある特別の順序で束ねる必要が生じたとき、マルチパートの第１のサブタイプ“ミックス”の利用が図られる。他の関連性のあるコンテンツタイプ、例えば、“マルチパート／パラレル”や、“マルチパート／リレーテッド”の利用も可能である。特に、“マルチパート／パラレル”エンティティでは本体部分の順序は重要ではない。関係するＭＩＭＥの本体部分の集合体であるオブジェクトを表わす一般的なメカニズムが“マルチパート／リレーテッド”コンテンツタイプによって、提供される。実施構成によって認識されないマルチパートサブタイプは、サブタイプ“マルチパート／ミックス”から構成されるものとして処理しなければならない。本発明の第２の実施形態によれば、カスタム境界文字列(BOUNDARY_P2P_REPAIR_RESPONSE)９２を上記のように定義して、図４ｂのＨＴＴＰパケット９’内のマルチパートＭＩＭＥ構造の個々の部分の開始点をマークするようになっている。上記境界文字列９２は、７０キャラクタ長を有するものであってもよい。この境界文字列９２は、いずれの本体部分にも現れない（あるいは消える可能性を伴って現れる）ように好適に選択される。最終部の後の境界文字列には“？”が後続する。

マルチパートＭＩＭＥの各部のコンテンツ伝送符号化は“２進”でセットされる。というのは、圧縮済みＦＬＵＴＥパケット８’が本質的に、一回に１バイトの読込みが可能な２進オブジェクトであるからである。“２進”符号化方式はオーバヘッドを必要としない。“ベース６４”のような他の関連する符号化方式の利用も可能である。“ベース６４”符号化の結果３３％のオーバヘッドが生じる場合がある。

ＨＴＴＰヘッダ９１、境界文字列９２および圧縮済みＦＬＵＴＥパケット８’−Ｌ〜８’−Ｍを含む図４ｂのＨＴＴＰパケット９’は以下の擬似コードによって表現することができる。

ＨＴＴＰ／１．１ ２００ ＯＫ
コンテンツタイプ：マルチパート／ミックス；
境界＝BOUNDARY_P2P_REPAIR_RESPONSE
-- BOUNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/compressedFlutePkt
コンテンツ伝送符号化：２進
圧縮済みＦＬＵＴＥパケット−１
-- BOUNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/compressedFlutePkt
コンテンツ伝送符号化：２進
圧縮済みＦＬＵＴＥパケット−２
-- BOUNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/compressedFlutePkt
コンテンツ伝送符号化：２進
圧縮済みＦＬＵＴＥパケット−Ｍ
-- BOUNDARY P2P REPAIR RESPONSE?

本発明の第３の実施形態
本発明の第３の実施形態によれば、第２の実施形態と比べて、マルチパートＭＩＭＥ ＰｔＰ ＨＴＴＰレスポンスの情報をさらに効率のよい方法で伝送することも可能となる。図５ａ〜図５ｃを参照しながら上記第３の実施形態について以下説明する。

リペアサーバ４は、同じＴＳＩとＴＯＩとを含むすべてのＦＬＵＴＥパケットを処理し、該ＦＬＵＴＥパケットのＦＬＵＴＥ符号化シンボル７を組み合わせて、それぞれの共通ＦＬＵＴＥヘッダ６’’−ｍを共有するＦＬＵＴＥパケットのＭ個のブロック７’’−ｍに変えることができる。但し、整数ｍは１からＭの範囲の整数である。このようにして、圧縮済みＦＬＵＴＥヘッダの同一部分の反復が回避されることになる。

例えばＨＴＴＰがすでにサポートしているマルチパートＭＩＭＥ構造を利用することにより、上記処理の実行が可能となる。上記目的のために、以下の実験的コンテンツタイプを導入して、マルチパートＭＩＭＥ構造内で個々の部分のコンテンツの特定が図られる：

“x-flutePtP/encSymbolHdr”は、マルチパートＭＩＭＥ構造の次の部分（ＦＬＵＴＥ符号化シンボルのブロック１’’−ｍ）内のすべての符号化シンボルに共通の共通ＦＬＵＴＥヘッダ６’’−ｍがメッセージ本文の中に含まれていることを示す。

“x-flutePtP/encSymbolVideo”は、ビデオオブジェクトに対応して、（対応するＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍと共に）ＦＬＵＴＥ符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍがメッセージ本文の中に含まれていることを示す。但しＭｍはブロック７’’−ｍ当たりのＦＬＵＴＥ符号化シンボルの数を示す。

“x-flutePtP/encSymbolAudio”は、オーディオオブジェクトに対応して、（対応するＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍと共に）ＦＬＵＴＥ符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍがメッセージ本文に含まれていることを示す。

“x-flutePtP/encSymbolOther”は、“他の”オブジェクトに対応して、（対応するＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍと共に）ＦＬＵＴＥ符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍがメッセージ本文に含まれていることを示す。

上記とは別に、実施形態によっては、異なるメディアタイプを区別する処理を選択せず、例えば“flutePtP/encSymbolData”のような汎用性のあるコンテンツタイプを利用するものもある。

結果として生じるＰｔＰＨＴＴＰレスポンス９’’構造を図５ａに例示し、共通ＦＬＵＴＥヘッダ６’’−ｍを図５ｂに示し、さらにＦＬＵＴＥ符号化シンボルのブロック７’’−ｍのフォーマットを図５ｃに示す。図５ｃから分かるように、個々のＦＬＵＴＥ符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍ（ｍは１からＭの範囲の整数を示す）に対応するＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍは、このＦＥＣペイロードＩＤがＦＬＵＴＥ符号化シンボル専用のＩＤであるという理由でＦＬＵＴＥ符号化シンボルのブロック７’’−ｍの中へ好適に移される。さらに、ＦＬＵＴＥ符号化シンボルは、ＭＩＭＥ境界によって相互に離間されていないため、共通ＦＬＵＴＥヘッダ６’’−ｍの中でＦＬＵＴＥ符号化シンボル７−１ｍ〜７−Ｍｍ−ｍのサイズ６５−ｍを定義する必要がある。図５ｂを参照されたい。

図５ａのＨＴＴＰレスポンス９’’は、擬似コードによって次のように表現することができる（コメントはダブルスラッシュ（／／）で開始される）：
ＨＴＴＰ／１．１ ２００ ＯＫ
ＭＩＭＥバージョン：１．０
コンテンツタイプ：マルチパート／ミックス
境界＝?BOUNDARY_P2P_REPAIR_RESPONSE
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolHdr
コンテンツ伝送符号化：２進
／／以下の部分のすべてのＦＬＵＴＥ符号化シンボルに共通の
／／ＴＳＩ、ＴＯＩおよび符号化シンボルサイズを含む。
／／（本例では、以下の部分はビデオオブジェクトに属する
／／すべての符号化シンボルを含む）。
-- BOUNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/encSymbolVideo
コンテンツ伝送符号化：２進
／／ビデオオブジェクトに属する（当該ＦＥＣペイロードＩＤを持つ）
／／すべてのＦＬＵＴＥ符号化シンボルを含む。
ＦＥＣペイロードＩＤ−１、符号化シンボル−１
ＦＥＣペイロードＩＤ−２、符号化シンボル−２
ＦＥＣペイロードＩＤ−Ｍ１、符号化シンボル−Ｍ１
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolHdr
コンテンツ伝送符号化：２進
／／以下の部分のすべてのＦＬＵＴＥ符号化シンボルに共通の
／／ＴＳＩ、ＴＯＩおよび符号化シンボルサイズを含む。
／／（本例では、以下の部分はオーディオオブジェクトに属する
／／すべての符号化シンボルを含む）。
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolAudio
コンテンツ伝送符号化：２進
／／オーディオオブジェクトに属する（当該ＦＥＣペイロードＩＤを持つ）
／／すべてのＦＬＵＴＥ符号化シンボルを含む。
ＦＥＣペイロードＩＤ−１、符号化シンボル−１
ＦＥＣペイロードＩＤ−２、符号化シンボル−２
ＦＥＣペイロードＩＤ−Ｍ２、符号化シンボル−Ｍ２
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolHdr
コンテンツ伝送符号化：２進
／／以下の部分のすべてのＦＬＵＴＥ符号化シンボルに共通の
／／ＴＳＩ、ＴＯＩおよび符号化シンボルサイズを含む。
／／（本例では、以下の部分はオーディオオブジェクトに属する
／／すべての符号化シンボルを含む）。
-- B0UNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/encSymbolOther
コンテンツ伝送符号化：２進
／／オーディオオブジェクトに属する（当該ＦＥＣペイロードＩＤを持つ）
／／すべてのＦＬＵＴＥ符号化シンボルを含む。
ＦＥＣペイロードＩＤ−１、符号化シンボル−１
ＦＥＣペイロードＩＤ−２、符号化シンボル−２
ＦＥＣペイロードＩＤ−ＭＭ、符号化シンボル−ＭＭ
-- BOUNDARY_P2P_REPAIR_RESPONSE-

本発明の第３の実施形態では、ＥＸＴ_ＦＴＩやＥＸＴ_ＦＤＴのようなＬＣＴヘッダ拡張子がＦＬＵＴＥヘッダの中には含まれていないとこれまで仮定されていた。したがって、図５ｃに図示のように、ＦＬＵＴＥ符号化シンボルのブロックの７’’−ｍにはヘッダ拡張子は含まれていない。

しかし、ＦＬＵＴＥ符号化シンボルのうちの少なくともいくつかのＦＬＵＴＥ符号化シンボルがＬＣＴヘッダ拡張子を使用する場合、本発明の第３の実施形態は、これまで図５ａ〜図５ｃを参照して示したようなＦＬＵＴＥ符号化シンボルのブロック７’’−ｍのセットアップに関してのみ変更を行う必要がある。この変更は図５ｄに例示的に描かれており、図５ｃのブロックの代替として機能するため同じ参照番号が保持されている。

図５ｃによれば、ＦＬＵＴＥ符号化シンボルのブロック７’’−ｍには、符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍがまだ含まれている。但し、整数ｍは１からＭまでの範囲の整数であり、Ｍｍはブロックｍ当たりの符号化シンボルの個数であり、Ｍはブロックの全個数である。図５ｃに図示のように、個々の符号化シンボルに対応するＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍは、それぞれの符号化シンボルよりも前に前記ブロックの中に含まれている。しかし、符号化シンボルのうちの少なくともいくつかの符号化シンボルがＬＣＴヘッダ拡張子を利用することを考慮して、ブロック７’’−ｍでは、個々の符号化シンボル７−１−ｍ〜７−Ｍｍ−ｍに対応するヘッダ長フィールド（ＨＤＲ_ＬＥＮ）６１１０−１−ｍ〜６１１０−Ｍｍ−ｍが導入される。上記ＬＣＴヘッダ長フィールドは、ＬＣＴヘッダ拡張子が使用されているかどうか、および、何個のＬＣＴヘッダ拡張子が個々の符号化シンボルと関連づけられているかを示すフィールドである。次いで、上記ＬＣＴヘッダ拡張子６８−１−ｍ〜６８−Ｍｍ−ｍがそれぞれＬＣＴヘッダ長フィールドの後に含まれることになる。

図５ｄの例では、ブロックの第１の符号化シンボルの中に２つのＥＸＴ_ＦＴＩが存在し、第２の符号化シンボルの中にはＥＸＴ_ＦＴＩは存在せず、そして最後の符号化シンボルの中には１つのＥＸＴ_ＦＴＩが存在している。この場合、共通の符号化シンボルヘッダ（図５ｂに図示の６’’−ｍ）の中に含まれているＨＤＲ_ＬＥＮフィールド６１１０は意味のないフィールドとなる場合がある。

容易に理解できるように、ＬＣＴヘッダ拡張子の利用をサポートする上述の方法はＥＸＴ−ＦＤＴ ＬＣＴヘッダインスタンスに対しても同様に機能し、符号化シンボルがファイル配信テーブル（ＦＤＴ）インスタンスに属しているとき、上記ヘッダインスタンスが利用される。

本発明の第４の実施形態
ＨＴＴＰレスポンスの中に含まれている情報を再構成することにより本発明のさらに別の実施形態が図６ａ〜図６ｃを参照して以下に記載するようなＰｔＰが得られる。

本発明の上記実施形態によれば、同じＴＳＩおよびＴＯＩと関連づけられたＦＬＵＴＥ符号化シンボルが、ＦＬＵＴＥ符号化シンボルのブロック１’’’−ｍに再度格納され（ｍは１からＭまでの範囲の整数）、次いで共通ＦＬＵＴＥヘッダが、個々のブロックのＦＬＵＴＥ符号化シンボルに対して使用される。しかし、第３の実施形態とは対照的に、すべての共通ＦＬＵＴＥヘッダのフィールドは１つのインデックスオブジェクト６’’’の中に組み合わされ、さらに、ＦＬＵＴＥ符号化シンボルの１つのブロック１’’’−ｍの中に含まれているすべてのＦＬＵＴＥ符号化シンボルのＦＥＣペイロードＩＤも、第３の実施形態の場合のようには前記ＦＬＵＴＥ符号化シンボルのブロックの中にそれ以上格納されずに、ＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍのブロック専用アレイの中に格納されて、前記インデックスオブジェクト６’’’の中へ組み込まれる。上記によって、ＰｔＰ ＨＴＴＰレスポンス９’’’内の個々の所望のＦＬＵＴＥ符号化シンボルへのランダムなアクセスが可能となる。

上記ＨＴＴＰレスポンス（パケット）９’’’が図６ａに例示されている。再言するが、ＭＩＭＥ境界９２を有するマルチパートＭＩＭＥ構造を利用して、異なるタイプのＦＬＵＴＥ符号化シンボルのインデックスオブジェクト６’’’とブロック７’’’−ｍとの離間を図ることが可能となる。新しいコンテンツタイプ“x-flutePtP/IndexObject”が本例で定義されているが、この新しいコンテンツタイプは、インデックスオブジェクト６’’’がメッセージ本文に含まれていることを示すものである。

図６ｂは、ＨＴＴＰレスポンス９’’’で送信されたすべての符号化シンボルの情報（ＴＳＩ、ＴＯＩ、符号化シンボル長、ＦＥＣペイロードＩＤ）を含むインデックスオブジェクト６’’’のフォーマットを示す図である。インデックスオブジェクト６’’’は、ｍ＝１〜ＭでインデックスされたＭ個のサブヘッダ（第３の実施形態の修正済みの共通ＦＬＵＴＥヘッダ）から構成されているものと理解することができる。この場合、前記サブヘッダの各々は、ある特定のＴＳＩ、ＴＯＩ、ＦＬＵＴＥ符号化シンボルサイズと関係し、当然のことであるが、ＦＬＵＴＥ符号化シンボルの個々のブロック７’’’−ｍに対応するいくつかのＦＬＵＴＥ符号化シンボルＭｍと関係し、この場合、上記数量はフィールド６２−ｍ、６３−ｍ、６５−ｍおよび６７−ｍにそれぞれに格納される。前記サブヘッダの各々には、さらにＬＣＴヘッダ６１−ｍの一部、および、ＦＥＣペイロードＩＤ６４−１−ｍ〜６４−Ｍｍ−ｍの前記ブロック専用アレイが含まれる。

上記の情報から、受信機３−１は、個々のＦＥＣペイロードＩＤを受信済みバイトストリームで一意のバイトレンジにマップすることができる。これによって、受信機３−１は、要求された任意の符号化シンボルに対してランダムアクセスを行うことが可能となる。ＦＬＵＴＥ符号化シンボルのブロック７’’’−ｍのフォーマットを図６ｃに示す（ｍは１からＭまでの範囲の整数で、ＭはＦＬＵＴＥ符号化シンボルのブロック数を示す）。ＦＥＣペイロードＩＤは現在、インデックスオブジェクト６’’’の中に含まれているため、ＦＥＣペイロードＩＤがＦＬＵＴＥ符号化シンボルのブロックには含まれていないことは明らかであり、これは本発明の第３の実施形態とは対照的な点である。

図６ａのＨＴＴＰレスポンス９’’’’は、擬似コードで以下のように表現することができる（コメントはダブルスラッシュ（／／）で開始される）：
ＨＴＴＰ／１．１ ２００ ＯＫ
ＭＩＭＥバージョン：１．０
コンテンツタイプ：マルチパート／ミックス
境界＝BOUNDARY_P2P_REPAIR_RESPONSE
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/IndexObject
コンテンツ伝送符号化：２進
／／（ＴＳＩ、ＴＯＩ、ＦＥＣペイロードＩＤ）によって
／／一意に特定された任意のＦＬＵＴＥ符号化シンボルに
／／アクセスするために必要なすべての情報を
／／含むインデックスオブジェクトを含む。
-- BOUNDARY_P2P_REPAIR_RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolVideo
コンテンツ伝送符号化：２進
／／ビデオオブジェクトに属する
／／すべてのＦＬＵＴＥ符号化シンボルを含む。
符号化シンボル−１
符号化シンボル−２
符号化シンボル−Ｍ１。
-- B0UNDARY_P2P_REPAIR_RESP0NSE
コンテンツタイプ：x-flutePtP/encSymbolAudio
コンテンツ伝送符号化：２進
／／オーディオオブジェクトに属する
／／すべてのＦＬＵＴＥ符号化シンボルを含む。
符号化シンボル−１
符号化シンボル−２
符号化シンボル−Ｍ２。
-- BOUNDARY_P2P_REPAIR__RESPONSE
コンテンツタイプ：x-flutePtP/encSymbolOther
コンテンツ伝送符号化：２進
／／“他の”オブジェクトに属する
／／すべての符号化シンボルを含む。
符号化シンボル−１
符号化シンボル−２
符号化シンボル−ＭＭ。
-- BOUNDARY_P2P_REPAIR_RESPONSE

本発明の第４の実施形態についての説明では、ＥＸＴ_ＦＴＩやＥＸＴ_ＦＤＴのようなＬＣＴヘッダ拡張子は符号化シンボルと関連づけられていないことが仮定されている。しかし、本発明の第３の実施形態（図５ｄを参照のこと）で適用された形と類似の技法が、本発明の第４の実施形態についても採用可能であることに留意されたい。この目的のために、ＬＣＴヘッダ長のアレイが個々のサブヘッダ内へ単純に含まれており、このＬＣＴヘッダ長のアレイによって、個々の符号化シンボルについて、ＬＣＴヘッダ拡張子が使用されているかどうか、並びに、ＬＣＴヘッダ拡張子が何個使用されているかが示される。次いで、上記アレイのエントリは、個々のサブヘッダ内の符号化シンボル固有のデータ構造に格納されたヘッダ拡張子の個数を表示する。

図７は、本発明に準拠するデータシンボル伝送方法を示す例示フローチャートを記述するものである。上記フローチャートでは、説明を簡略にするために、送信機１とリペアサーバ４が同じ装置により具現化されていると仮定されている。

第１のステップ７０１で、送信機１は、例えば複数の受信機３−１〜３−３へＰｔＭセッション時に転送されるトランスポートオブジェクトのＦＥＣ符号化部分によってＦＬＵＴＥ符号化シンボルの生成を行う。次いで、ステップ７０２で、上記ＦＬＵＴＥ符号化シンボルにはＦＬＵＴＥプロトコルに従うＦＬＵＴＥヘッダ（ファーストタイプヘッダ）が付されて、ＦＬＵＴＥパケットが生み出され、その後ステップ７０３で上記ＦＬＵＴＥパケットは前記複数の受信機へ送信される。例えば、ＵＤＰおよび基底に在るＩＰプロトコルのサービスを利用することにより上記処理の達成が可能となる。次いで、伝送ＦＬＵＴＥパケットは、受信機３−１〜３−３側で、並びに、前記受信機のうちの少なくとも１つの受信機３−１側で受信され、パケットの紛失や不正確な受信や別の理由に起因してリペアデータパケットの追加受信が必要となるということが分かった。次いで、受信機３−１は、リペア要求をリペアサーバへ通知するが、本例示ケースでは該リペアサーバは送信機と同一のものである。

ステップ７０４で、前記リペア要求が前記リペアサーバ４側で受信され、次いで該リペア要求に含まれているリペア情報が、例えば脱落したＦＬＵＴＥ符号化シンボルのＴＳＩ、ＴＯＩ、ＳＢＮおよびＥＳＩなどの４つの符号化シンボルを利用して、どのＦＬＵＴＥ符号化シンボルをリペアデータシンボルとして生成する必要があるかが判定される。上記処理はステップ７０５でリペアサーバ４により行われる。次いで、ステップ７０６で、例えば、図３ａによる本発明の第１の実施形態の圧縮済みＦＬＵＴＥヘッダ６のようなＦＬＵＴＥプロトコルに従う圧縮済みＦＬＵＴＥヘッダ（第２のタイプのヘッダ）が生成済みのＦＬＵＴＥ符号化シンボルに付される。次いで、 ＦＬＵＴＥ符号化シンボルと圧縮済みＦＬＵＴＥヘッダとによって図３ａの圧縮済みＦＬＵＴＥパケット８が形成される。次いで、上記圧縮済みＦＬＵＴＥパケット８は、ＰｔＰリペアセッション内でリペアサーバにより特定の受信機へ伝送される（ステップ７０７を参照のこと）が、例えば、リペア要求に対する応答として機能する１つのＨＴＴＰパケット９の中へ複数の圧縮済みＦＬＵＴＥパケット８−１〜８−Ｍを組み込むこと（図３ｂを参照のこと）ことによって、並びに、リペアサーバ４のエンティティと受信機３−１との間で上記ＨＴＴＰパケットを転送することによって、並びに、ＨＴＴＰ／ＴＣＰのサービスを利用することによって上記伝送は実行される。

以上、推奨実施形態によって本発明を説明した。当業者にとっては明白なことである代替方法および変更例が存在し、添付の請求項の範囲と精神とから逸脱することなく上記代替方法および変更例が実現可能であることに留意されたい。特に本発明の範囲は、決して、ＦＬＵＴＥプロトコルまたは３ＧＰＰ ＭＢＭＳシステムというコンテキストにおける用途に限定されるものではない。このことは、一方でＰｔＭ伝送用として、かつ、他方でＰｔＰ伝送用として同じプロトコルの異なるタイプのヘッダを利用するという本発明の発明原理がいずれの特定のプロトコルや特定のシステムにも束縛されないという事実に因るものである。

本発明によるポイント・ツー・マルチポイント（ＰｔＭ）伝送セッション時のデータシンボルの伝送を示す概略図。 本発明によるポイント・ツー・ポイント（ＰｔＰ）リペアセッション時のリペアデータシンボルを求める要求シグナリングを示す概略図。 本発明によるＰｔＰリペアセッション時のリペアデータシンボルの伝送を示す概略図。 本発明によるＰｔＭ伝送セッション時のデータシンボルの伝送に用いるプロトコルスタックを示す概略図。 本発明によるＰｔＰリペアセッション時のリペアデータシンボルの伝送に用いるプロトコルスタックを示す概略図。 本発明の第１の実施形態による圧縮済みＦＬＵＴＥパケットを示す概略図。 本発明の第１の実施形態による圧縮済みＦＬＵＴＥパケットのＨＴＴＰパケット内への組込みを示す概略図。 本発明の第２の実施形態による圧縮済みＦＬＵＴＥパケットを示す概略図。 本発明の第２の実施形態による圧縮済みＦＬＵＴＥパケットのＨＴＴＰパケット内への組込みを示す概略図。 本発明の第３の実施形態によるＨＴＴＰパケットを示す概略図。 本発明の第３の実施形態による共通ＦＬＵＴＥヘッダを示す概略図。 本発明の第３の実施形態による符号化シンボルのブロックを示す概略図。 本発明の第３の実施形態によるＬＣＴヘッダ拡張子を使用する場合の符号化シンボルの代替ブロックを示す概略図。 本発明の第４の実施形態によるＨＴＴＰパケットを示す概略図。 本発明の第４の実施形態によるインデックスオブジェクトヘッダを示す概略図。 本発明の第４の実施形態による符号化シンボルのブロックを示す概略図。 本発明による方法を示す例示フローチャート。

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