"通信システム内でブロードキャストのファイルをダウンロードする方法であって、第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信することと、第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信することと、を備える方法。第1通信チャネルを介して前記ファイル属性を受信することと、前記少なくとも1つのファイルを第2通信チャネルを介して受信することと、を備える、請求項1に記載の方法。前記通信システムはインターネットプロトコルIPをサポートし、前記方法はさらに、前記ファイル属性を、第1ポート番号によって前記IPのユーザデータグラムプロトコルUDPを通して受信することと、前記少なくとも1つのファイルを、第2ポート番号によって前記IPの前記UDPを通して受信することと、を備える、請求項1に記載の方法。前記第2通信セッション内で、前記ブロードキャストのために複数のファイルを連続的に受信することと、前記第2通信セッションよりも前の前記第1通信セッション内で前記複数のファイルを処理するために、前記ファイル属性を受信することとをさらに備える、請求項1に記載の方法。前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法はさらに、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を受信しないことを備える、請求項1に記載の方法。前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信することを備え、前記複数のファイルを処理するために前記複数のファイル間で共用される前記ファイル属性のいくつかを使用して、前記複数のファイルを処理することをさらに備える、請求項1に記載の方法。前記少なくとも1つのファイルを所定の時間に表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための前記ファイル属性時間情報を提供することをさらに備える、請求項1に記載の方法。通信システムにおけるブロードキャストのファイル送達方法であって、前記方法は、第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを表示するためのファイル属性を送信することと、第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信することと、を備える方法。前記ファイル属性を第1通信チャネルを介して送信することと、前記少なくとも1つのファイルを第2通信チャネルを介して送信することと、をさらに備える、請求項8に記載の方法。前記通信システムはインターネットプロトコルIPをサポートし、前記方法はさらに、前記ファイル属性を、第1ポート番号を介し、前記IPのユーザデータグラムプロトコルUDPを通して送信することと、前記少なくとも1つのファイルを、第2ポート番号を介し、前記IPの前記UDPを通して送信することと、を備える、請求項8に記載の方法。前記第2通信セッションにおいて、前記ブロードキャスト用に複数のファイルを連続して送信することと、前記第2通信セッションよりも前の前記第1通信セッションにおいて、前記複数のファイルを処理するために、前記ファイル属性を送信することとをさらに備える、請求項8に記載の方法。前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法は、前記少なくとも1つのファイルを処理するために、前記各データパケット内にファイル属性を提供しないことをさらに備える、請求項8に記載の方法。さらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信することと、またさらに、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供することとを備える、請求項8に記載の方法。前記ブロードキャストの前記少なくとも1つのファイルを表示するための、前記ファイル属性時間情報をさらに備える、請求項8に記載の方法。通信システム内でブロードキャストを受信するように構成された装置であって、前記装置は、第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信する手段と、第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する手段と、を備える装置。第1通信チャネルを介して前記ファイル属性を受信する手段と、第2通信チャネルを介して前記少なくとも1つのファイルを受信する手段と、をさらに備える、請求項15に記載の装置。前記通信システムはインターネットプロトコルIPをサポートし、前記装置はさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコルUDPを通して前記ファイル属性を受信する手段と、第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信する手段と、を備える、請求項15に記載の装置。前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信する手段とをさらに備える、請求項15に記載の装置。前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記各データパケットは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項15に記載の装置。前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信する手段をさらに備え、前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して、前記複数のファイルを処理するための手段をさらに備える、請求項15に記載の装置。前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項15に記載の装置。通信システムにおいてブロードキャストのファイルを送達する装置であって、第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を送信する手段と、第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信する手段と、を備える装置。第1通信チャネルを介して前記ファイル属性を送信する手段と、第2通信チャネルを介して前記少なくとも1つのファイルを送信する手段と、をさらに備える、請求項22に記載の装置。前記通信システムはインターネットプロトコルIPをサポートし、前記装置はさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコルUDPを通して前記ファイル属性を送信する手段と、第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信する手段と、を備える、請求項22に記載の装置。前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を送信する手段とをさらに備える、請求項22に記載の装置。前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記装置は、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を提供しない手段をさらに備えている、請求項22に記載の装置。前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信する手段をさらに備え、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供する手段をさらに備える、請求項22に記載の装置。前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項22に記載の装置。通信システム内のブロードキャストにおいて使用される装置であって、前記装置は、プロセッサと、前記プロセッサに結合したメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを含む装置。前記メモリユニットは、前記第1通信チャネルを介して前記ファイル属性を受信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して受信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項29に記載の装置。前記通信システムは、インターネットプロトコルIPをサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコルUDPを通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信するための、及び前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信するためのコンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項29に記載の装置。前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信するための、及び前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して前記複数のファイルを処理するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項29に記載の装置。通信システムにおいてブロードキャストのファイルを送達する装置であって、前記装置は、プロセッサと、前記プロセッサに結合されたメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて前記ブロードキャストの前記少なくとも1つのファイルを前記ファイル属性とは別に送信するための、コンピュータ読み出し可能な命令と、を備える装置。前記メモリユニットはさらに、前記ファイル属性を第1通信チャネルを介して送信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。前記通信システムはインターネットプロトコルIPをサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコルUDPを通して前記ファイル属性を、送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。前記メモリユニットは、前記IPの前記UDPと結合した前記IPの1方向移送上でのファイル送達FLUTEとを通して少なくとも1つのファイルを送信するためのコンピュータ読み出し可能な命令をさらに備える、請求項36に記載の装置。前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信するための、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための前記ファイル属性を送信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含まない、請求項36に記載の装置。前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信するための、前記第1通信セッションにおいて前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項36に記載の装置。コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体であって、前記命令は、第1通信セッションにおいてブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信する命令と、第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する命令と、であるコンピュータ読み出し可能な媒体。第1通信チャネルを介して前記ファイル属性を受信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令をさらに備える、請求項44に記載のコンピュータ読み出し可能な媒体。前記通信システムはインターネットプロトコルIPをサポートし、前記コンピュータ読み出し可能な媒体は、第1ポート番号を介して、前記IPのユーザデータグラムプログラムUDPを通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令をさらに備える、請求項44に記載のコンピュータ読み出し媒体。第1通信セッションにおいて、ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体。第1通信チャネルを介して前記ファイル属性を送信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。第1ポート番号を介して、前記IPのユーザデータグラムプロトコルUDPを通して前記ファイル属性を送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。以下の説明は、全ての当業者が本発明を使用できるようにするために示される。また、以下の説明では説明の目的で詳細を述べている。当業者は、こうした詳細を使用しなくても本発明を実現できることを理解するはずである。別の場合では、不要な説明によって本発明を不明瞭化しないために、よく知られている構造および処理については詳述していない。そのため、本発明はここで示す実施形態に限定されるのではなく、ここで述べている原理および特徴と一致する最も広範囲に従うものである。図2は、本発明の例証的な実施形態の簡略化した概略図を示している。システム全体を参照符号40によって総体的に示している。図面を簡略化し説明を明瞭化するために、この通信システム40では2つのネットワーク42、44のみ示す。ネットワーク42、44は、イントラネットまたはインターネットのようなバックボーンネットワーク46で繋がれている。この実施形態では、ネットワーク42はサービスプロバイダによって操作されると仮定する。サービスプロバイダは、ネットワーク42にノード48をインストールする。この例では、ノード48をブロードキャストサービスディストリビュータBSDと呼ぶ。コンテンツサーバ48は、ブロードキャストコンテンツと、さらにこれに関連する、サービスプロバイダによって提供されたブロードキャスト情報とを保持することができる。ネットワーク44では、バックボーンネットワーク46を介してサーバノード48によって提供されたサービスを含むサービスを受信できる加入者ノード50が存在する。この実施形態では、ノード50は無線装置として表されており、このノード50の例のいくつかには、パーソナルデジタルアシスタントPDA、モバイルコンピュータ、携帯電話がある。ネットワーク44は、米国のTIA/EIA電気通信業界団体/米国電子工業会を含む国際標準化機関である3GPP2第3次世代パートナーシッププロジェクト2によって説明するcdma2000規格のような無線技術をサポートする。ネットワーク40はこれ以外の標準、例えば、様々な欧州の標準実体が調整およびサポートする3GPP第3世代パートナーシッププロジェクトによって公表されたWCDMA広帯域符号分割多重アクセス標準をサポートできる点について留意されたい。別の例として、送リンク専用FLOネットワークで使用する無線業界促進標準化における様々な実体の機関である転FLOフォーラムが開発した標準を挙げる。加入者ユニット50は、無線アクセスネットワークRAN52を介してネットワーク44と通信する。RAN52は、複数の基地局BS66A~66Nに接続した基地局制御装置/パケットデータ制御機能BSC/PDF54を含む。パケットデータサービスノードPDSN68とブロードキャストサービングノードBSN70がネットワーク44内で実現される。PDSN68とBSN70の両方は、ネットワーク44内のバックボーンネットワーク46とRAN52をインターフェースする機能を果たす。PDSN68が主にユニキャスト通信の利用に対応しているのに対し、BSN70はむしろマルチキャスト通信またはブロードキャスト通信を扱う場合向けにインストールされることが多い。本明細書では、マルチキャスト、ブロードキャストという用語を相互交換可能な意味で使用している。ネットワーク44内には、BSN70に接続したブロードキャスト/マルチキャストサービスBCMCSコンテンツサーバ63と呼ばれる別のサーバも存在する。一般に、BCMCSコンテンツサーバ63は、ブロードキャストコンテンツと、これに関連した、コンテンツサーバ48から提供されたものと、バックボーンネットワーク46を介して転送されたものとを含む、ブロードキャストコンテンツのデータとを事前に記憶する。この例証的な実施形態では、いくつかのノード間での通信を、無線で実施されたものとして表している。しかし、常にこの限りではない点を理解すべきである。これ以外の様々な手段によるノード間の非無線通信も適用可能である。例えば、ノード50は無線装置でなく据置きコンピュータであったり、光リンクや従来の伝導ケーブルでネットワーク44と通信する他のサーバ通信であってもよい。この実施形態において、バックボーンネットワーク46がインターネットプロトコルIPをサポートすると仮定する。動作の詳細について説明する以前に、まず、階層の異なる多様なレベルのプロトコルを介して行われ、これらの相互関係がIPの下で動作するパケットデータ通信中におけるデータパケットの処理について大まかに説明する。ネットワーク通信の技術において、プロトコルは、国際標準化機構ISOと国際電信電話諮問委員会ITU-Tが説明しているとおりの開放型システム間相互接続OSIモデルに従って階層化される。この目的は、マルチベンダ設備相互使用可能性の促進である。即ち、各レベルのプロトコル階層には独自の仕様がある。そのため、特定の階層レベルの仕様が満たされる限り、このレベルにおける製品の開発が別レベルの他の製品と互換することが保証される。図3は階層順序に並んだプロトコルのスタックを概略的に示しており、これは一般にプロトコルスタックと呼ばれ、この図では参照符号72を付している。IPプロトコルスタック72は、OSIモデルと類似するが完全に同一ではないインターネット技術標準化タスクフォースIETFモデルと一致した構造を有する。IETFモデルに従って、IPプロトコルスタック72は、層1~5までの5つの層を有する。そのため、ノードから送信されたデータパケット、例えば図2に示すノード48や50は、プロトコルスタッック72で処理しなければならない。プロトコル72のスタックは、ソフトウェアまたはハードウェア、あるいはこれらの組み合わせの形式のノード内に構築される。同様に、同一のノードによって受信されたデータパケットは、同一のプロトコルスタック72を介し、逆の順序で処理されなければならない。一例を挙げて例証を行う。データパケットをノード、例えばノード48図2から送信するように処理する場合、このデータパケットはまず、例えば層5のようなアプリケーション層内のプロトコルの1つに従って作成される。層5は、ハイパーテキスト転送プロトコルHTTP、サービスメール転送プロトコルSMTP、ファイル転送プロトコルFTP、リアルタイム転送プロトコルRTP、1方向移送/非同期層符号化上でのファイル送達FLUTE/ALCプロトコルを含む。さらに、データパケットはVoIPヴォイスオーバインターネットプロトコルセッションの積であると仮定する。そのため、層5内で、データパケットをRTPに従ってフォーマットする必要がある。例えば層5内のRTPによって生じたデータパケットのような、時間に敏感なデータパケットは、リアルタイムで処理する必要がある。詳細には、通常、欠陥パケットは再送信されず、他の接近中のデータパケットの伝送を妨害することがないよう単純にドロップされる。そのため、RTPデータパケットは、通常、移送層である層4内のユーザデータパケットプロトコルUDPを介して運ばれる。したがって、層5内のRTPからのデータパケットは、層4内のUDPに従って公式化される。一方、データパケットが層5内の別のプロトコル、例えばFTPから発生している場合には、通常、このデータパケットは層4内の移送制御プロトコルTCPを介して送信される。TCPの下では、データパケットの正確な送達は最も重要である。そのため、全体のデータ伝送処理が遅速化する可能性があっても、欠陥パケットは常に再送信される。この移送層である層4を通過したデータパケットには、セキュアポート番号や宛先ポート番号のような情報が追加される。移送層である層4を通過するデータパケットは、次に、処理のためにネットワーク層である層3へ送信される。この特定の場合には、層4から生じたデータパケットに、データパケットのソースアドレスと宛先アドレスを追加した状態にし、さらに、IPに従って再びフォーマットする必要がある。その後、データパケットをフレーム化して、リンク層である層2内に適したプロトコルに適合させる。電気電子学会InstituteofElectricalandElectronicsEngineersIEEE発行の文書第IEEE802.3で説明されているように、例えば、イーサーネット登録商標を介してサーバノード48をネットワークに接続した場合には、層2はイーサネット登録商標プロトコル形式となる。図5中のプロトコルスタック72の最下層は、物理層である層1であり、この層はデータパケットの送信を物理的に実現する。例えば、図2では、ノード48とネットワーク42の間の通信リンクが従来の有線リンクである場合に、物理層である層1は、両ノード48上のハードウェア回路とネットワーク42の物理インターフェース回路に関連する。ノード50とBS66Aの間の通信リンクがエアーインターフェースである場合には、図2の別の例のようになる。この場合は、物理層である層1は、エアースペースと、このエアースペースを介して信号のやり取りを行うRAN52のハードウェア回路とに関連する。次に再び図3を参照する。例証的なノード50が受信したデータパケットの場合図2、データパケットは同じプロトコルスタック72を介して処理されるが、しかしこの場合には、層1から層5の逆の順序で処理されなければならない。次に、システム40における例証的なブロードキャスト処理の動作について説明する。図2では、先述したように、ノード48、即ちBSDが、加入者にブロードキャストサービスを提供するサービスプロバイダによってネットワーク42にインストールされる。この場合、ノード50はこうした加入者の1人である。例えばこの場合、ノード50は別のネットワークからネットワーク44へのローミングであってよく、ネットワーク42を動作しているサービスプロバイダより入手可能な夜7時のニュースのようなニュースクリップのアクセスをシークすることができる。ネットワーク44がブロードキャストサービスをサポートする場合には、ネットワーク44には利用可能なサービスのブロードキャストチャネルが設けられていることが多い。利用可能なサービスの情報は、ダウンロード可能なファイル形式で編成できる。あるいは、この情報を、リアルタイムビューイング可能なデータの一定のストリームの形式で表すこともできる。この例証的な実施形態では、無線通信における多様な標準を統一する目的で、サービスプロバイダ、ハードウェアおよびソフトウェアベンダ、ネットワークオペレータその他を含む無線業界の様々な実体の共同体であるオープンモバイルアライアンスOMAが公表したブロードキャストサービス案内SGと類似した方法で、利用可能な複数のサービスをダウンロード可能なファイルとしてグループ化するものとする。SGの詳細は、OMAより発行の文書OMA-TS-BCAST-ServiceGuide-V1.~で説明されている。これまで、ノード50のユーザは、ネットワーク44内にある場合、利用可能なサービスについてSGを参照する必要があった。このために、ネットワーク44からSGをダウンロードしなければならない。次に、ノード50のユーザはシークしたサービスをSGから選択して、このサービスを装備しているチャネルがSGに提供された時にこれに同調する。例えば音楽のダウンロードのようないくつかのサービスでは、ノード50のユーザはシークしたファイルを最初にダウンロードし、後にこのファイルを楽しむことができる。ニュースブロードキャストセッションのような別のサービスでは、シークしたファイルのコンテンツがダウンロードされ、これとほぼ同時に表示される。これは即ち、シークしたサービスと、このサービスに関連したファイルのダウンロードとがリアルタイムに提示されるということである。こうしたアプローチにはいくつか欠点がある。これはとりわけ、ファイルコンテンツの連続提示が、コンテンツ自体のダウンロードの成功のみでなく、コンテンツファイルの処理に必要なファイル属性のダウンロードの成功にも依存することによる。こうした依存性によって遅延が生じるのは不可避であり、また多くの場合、コンテンツ提示に関連したユーザの経験に悪影響を及ぼす。これに加え、信頼性の高いデータパケットの受信度を高めるために、通常は冗長データが送信される。この結果、以降でさらに説明している利用可能な通信リソースの最も効率的な使用が得られなくなる可能性がある。シークしたサービスのファイルのコンテンツが、FLUTE/ALCプロトコルを介して移送されるとする。正確なデータ移送を確実に得るために、従来は、FLUTE/ALCプロトコルと共にカルーセルファイル配信CFD方法が使用された。図3AはFLUTE/ALCプロトコルのより詳細な概略図を示している。これについては以降でより詳細に説明する。図4は、FLUTE/ALCプロトコルの下で動作するCFDスキームの方法論を示している。図4では、ファイルを参照符号74で表している。1片のマルチメディアコンテンツ、この例では例えばニュースクリップが、複数のファイルを備えていてよい。ファイル74内では、各ALCデータパケットがデータパケット1~5の1つで表されている。確ファイル74の送達には、ファイル送達テーブルFDT78を設け、やはりALCプロトコル形式で構成されたALCデータパケットが関連している。FDT78には、データパケット1~5の復号化に必要な多様なパラメータまたは属性が含まれている。こうしたパラメータは、ファイル名、ファイル識別ID、ファイルのソース場所即ちURI、表示時間、ファイルサイズ、コンテンツタイプ、符号化スキーム、転送エラー修正FECタイプとFEC関連のパラメータ、さらに、適切であればセキュリティ関連のパラメータを備えていてよいが、しかしこれらのパラメータに限定されるものではない。CFD方法ではファイルは複数回伝送される。この例では、ファイル74はコンテンツパケット1~5と、これに関連するFDT78とを含んでおり、第1パス73において1回目、次に第2パス75において2回目の伝送が実行される。第1パス73では、FDT78がコンテンツパケット1~5よりも先に伝送される。第2パス75では、これと同一のFDT78が、コンテンツパケット1~5の最後に伝送される。各ファイルを繰り返し伝送する1つの目的は、全ての受信者が確実に同じ時間にファイルを受信する必要を排除することである。即ち、ファイル受信のために受信者を同期する必要はない。各ファイルを繰り返し伝送する別の目的は、FECスキームがインストールされていない場合、あるいは、たとえインストールされていてもFEC機構の動作が失敗した場合に、データ移送中の正確性を確実にすることである。この目的は、CFD方法を、図4に示すシナリオA、B、Cと識別される3つのシナリオを包括するように設計することで達成される。この3つのシナリオA、B、C以外にも、失敗したファイルのダウンロードの宣言を行える。シナリオAでは、ノード50がファイル74のダウンロードを試みると仮定する。第1パス73の最中に、ノード50はFDT78の受信に成功する必要がある。第1パス73におけるFDT78のダウンロードがエラーなく成功する。次に、ノード50が後続のデータパケット1~5を受信する。第1パス73において、データパケット1~5全てのダウンロードも成功したと想定する。ファイル74全体を組み立てるために、ノード50は、第1パス73からダウンロードしたFDT78内の情報を使用して、全てのパケット1~5内のデータを復号化することができる。シナリオBでは、第1パス73でのファイル74のダウンロードの最中に、FDTパケット78の取り出しが成功したと仮定する。第1パス内での、3を除いた全てのコンテンツパケット1~5の取り出しも成功したとする。実現されたFEC機構は機能しないと仮定する。この場合ノード50は、第1パス73において受信した関連する欠陥パケット3を補正するために、第2パス75の最中に、第2パス75が同一のデータパケット3を受信するまで待つ必要がある。その後、ノード50は、ファイル74を再構築するために、第1パスから入手したFDT78からの情報を使用して、全てのデータパケットを復号化することができる。シナリオCでは、全てのデータパケット1~5が第1パス73内に正確にダウンロードされるが、ノードはFDT78を第1パス73内に正確に受信することができない。この場合には、ノード50は、第1パス73からの誤ったFDT78を補正して、ファイル74の全てのデータパケットを正確に復号できるよう、第2パス75が関連のFDT78を取り出すまで待たなくてはならない。望ましくない信号受信条件の下では、上のシナリオA、B、Cの部分で説明したFECの一番最初に追加のステップを実行しても、エラーのあるデータを修正することはできない可能性がある。すなわち、先に述べたように、ファイル74のダウンロードは失敗と宣言される可能性がある。シナリオBでは、データパケット3が損失しても、表示中のファイル74の品質にしか影響が及ばないことがある。しかし、シナリオCでは、FDT78がなければファイル74全体の処理ができないため、FDT78の取り出しの失敗によってファイル74全体が損失しかねない。この場合には、ノード50は、次のカルーセル周期まで待つ必要がある。この周期は、後にFDT78取得の別の機会を得るだけのために、時間パス73、75で延長された期間のように非常に長くなる可能性がある。この場合には、さらなる時間の遅延と、通信チャネルの固定が不可避となる。この例のようにデバイス50が移動体装置である場合は、時間遅延の増加はデバイス50の電池の電力消費増加につながる。移動通信では、電池寿命の維持が非常に重要である。本発明の例証的な実施形態によれば、FDTとコンテンツデータパケットは、従来実施されていたようにインバンド方式で受信されない。代わりに、ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。これ以降では、用語インバンド方式は、伝送チャネルを介し、さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は、図4の伝送工程に図示し、説明しているとおりのものである。一方、用語アウトバンド方式は、図5に図示し、以降で説明する伝送工程によって例証されるように、こうした移送が同一の伝送チャネルを介して行われるか、あるいは別の伝送チャネルを介して行われるかに関係なく、多様な伝送セッションを介して、情報の移送を意味するものとして解釈される。次に図5を参照する。この実施形態では、データパケット1~5のようなペイロードデータと比較して、先に述べたFDT78に含まれているファイル属性のようなファイル属性82が別々に、即ち、インバンド方式ではなくアウトバンド方式で送信される。FAは、ネットワーク44図2により、またブロードキャストチャネル内で伝送されることが好ましい。例えば、FAは先に述べたSGの一部であってよい。SGとさらにFAは、ブロードキャストサービスをシークするノード50によって最初に取得される。即ち、FA82は第1通信セッション81中に取得される。FA82を正確に取得した後、ノード50は、ファイル84のようなコンテンツファイルを取得するために、SG内に提供された情報に従ってチャネルに同調する。即ち、コンテンツファイルは第2通信セッション86中に取得される。図5に示すように、コンテンツファイルパケット同士の間にはFDTが割り込んでいない。むしろ、コンテンツファイル例えばファイル83、84は、連続的および非妨害的に伝送されるよう設計されている。表現を変えれば、通信セッション81中の早い時期にノード50がFA82を正確に取り出したと確認された後にのみ、コンテンツファイルが通信セッション86中にダウンロードされる。これにより、ファイルとFDTの両方がインバンド方式で、また上述したとおりに受信される場合に、ファイル処理の成功が関連するFDTのダウンロードの成功によって決まってしまう状況を回避できる。伝送工程中の第1パス85において、図5の参照符号90で示す欠陥のあるデータパケット、例えばデータパケット4がファイル84内に見付かり、さらに、インストールされたFEC機構ファイルがこの欠陥パケット4を修正すると仮定した場合には、第2パス87内の関連するデータパケット4を取り出して修復することができる。修復工程が失敗した場合には、表示中のファイル84に特定の品質劣化が生じる可能性がある。しかし、図4に示し、上述したような失敗したシナリオCでの状況が生じることは絶対にない。これの理由は、先述したように、先の通信セッション81の最中にFA82の受信が成功しているためである。上述した方法で動作する場合には、FDTの伝送用としてインバンドチャネルを固定する必要はない。そのため、コンテンツファイルの取り出しをより高い確実性にて行える。ファイル取得時間も実質的に短縮することができる。この結果、通信チャネル間のふくそうが容易化されるため、利用可能な通信リソースをより効率的に使用できるようになる。さらに、ノード50図2が移動体装置である場合には、ファイル取得時間が短いことは、コンテンツファイルのダウンロード中に、ノード50の電池の起動に要する時間が短くて済むことを意味する。したがって、電池電力を温存できる。図5に示すFA82は、シークしたサービスセッションについて全てのファイルを適切に復号するために取得すべき多数のFAのうちの1つであり、ファイル84はこうしたファイルのうちの1つであることに留意されたい。しかし、FA82は、ファイル84だけでなく、隣接するファイル83のような他のファイルをも取り出すための共通の属性を多く有する。したがって、全てのFAを、1伝送セッション中の全てのファイルの取り出しに適した1つのマスターFAとして編成することができる。あるいはこれの代替として、マスターFAの代わりに、集合体としてのFAを2つの部分に分割することもできる。第1部分は、永続ファイルとして考慮されたファイルの属性を保持することができる。このような属性は、ファイル名、ファイルID,ファイルの場所、表示時間、配信時間ウィンドウを含んでいてよい。一方、比較的短命と考えられる属性はFAの第2部分に配置できる。短命の属性は、アプリケーションファイルのサイズ、伝送されたファイルのサイズ、コンテンツタイプ、符号化スキーム、FECタイプおよびパラメータ、セキュリティ関連のパラメータを含んでいてよい。第1部分は、比較的不変のままSG内に長期間滞留することができる。第2部分は、変化する状況を反映するために、SG内で定期的に更新することができる。先述したように、最初にいくつかのファイルをダウンロードしておき、後でユーザが選択した時間に実行することが可能である。この例には、音楽ファイルやソフトウェア更新用ファイルがある。最初にダウンロードしておくことができるが、しかし、特定の時間に表示させることが好ましいファイルもある。これの一例には、以下で説明するニュースブロードキャストセッションがある。いずれの場合でも、本発明の別の態様に従って、コンテンツファイルの取得および表示は同時に実行される必要はない。代わりに、ファイル取得をファイル表示工程前に別個に実行することができる。説明を簡単にするために、より具体的な例を例証する。次に再び図2を参照する。この例では、ノード50のユーザが、通常午後7時に、標準テレビブロードキャストを介して利用できるニュースブロードキャストを視聴したいと仮定する。ネットワーク44によってブロードキャストされたSG内では、これに関連した、午後7時のニュースクリップに関する情報が通常利用可能である。ネットワーク44は、ネットワーク42をバックボーンネットワーク46を介して提供しているサービスから取得した情報を有する。SG内では、2つの時間ウィンドウ、即ち配信ウィンドウDWと表示ウィンドウPWが指定される。図6はこうした配列を示す。DW内では時間ウィンドウが指定される。この時間ウィンドウ内では、午後7時のニュースセッションのファイルを受信するために、ノード50が起動される必要がある。時間ウィンドウは、この例においては例えば午後5時~午後6時半であり、これは、ニュースファイルを受信するためにノード50の電源がオンにされる時間間隔である。一方、PWは、例えば午後7時~午後7時半の間にダウンロードしたニュースセッションの表示時間を識別した。これは即ち、この時間スパン中に、ダウンロードしたファイルが午後7時のニュースとして表示されるということである。DWをPWから分離することの追加的利点に、加入者が、表示時間以前にファイルをダウンロードできるため、通常、ピーク時間帯にぶつかってしまう表示時間中におけるトラヒックチャネルの過負荷を回避できるということがある。DW中にネットワーク44内のトラヒック負荷が混雑している場合でも、それぞれのファイルダウンロードを受信側の受信機内へ少量ずつ行い、PWが開始する前に都合よく完了することができる。ノード50は、SGが提供した情報に基づいて、ニュースクリップを受信するために、午後5時25分~午後5時37分の期間中に電源オンにされ、起動されると仮定する。適切なファイル圧縮技術を実現した場合、ダウンロードに要する時間はこの例では12分間であり、表示時間この場合は30分間よりも短い。前述のノード50のための方法を図7のフローチャートに示す。図8は、ネットワーク44によって実行されるこれと関連した方法である。本発明のさらに別の態様では、ペイロードデータの移送をさらにストリームライン化することができる。ファイルコンテンツをダウンロードするために、FLUTE/ALCプロトコルを採用できる。先述したように、データパケットがTCP移送層図3を介して移送されるFTPとは異なり、FLUTE/ALC内のデータパケットがUDP移送層へ運ばれる。伝送工程全体は遅速化するが、FTPはより1対1のアプリケーションへと調整され、エラーが生じたパケットも正常に再伝送される。UDPを介して運ばれるFLUTE/ALCプロトコルは、マルチキャストまたはブロードキャストアプリケーションに適するように設計される。エラーの生じたデータは正常に伝送されない。その代わりに、適切な転送エラー修正FECスキームを採用することにより、データ伝送におけるエラーが縮小される。次に、参照符号96で全体的に表されるFLUTE/ALCプロトコルを示した図3Aを参照する。FLUTEプロトコルのパケットはALCプロトコルによって運ばれることで移送される。ALCプロトコルについては、2002年12月にIETFより発行された刊行物RFC3450非同期層符号化ACLプロトコルの例示AsynchronousLayeredCodingProtocolInstantiationで説明されている。ALCプロトコルは、マルチキャスト移送に提案された基本プロトコルの1つである。ALCが関与するデータ移送ではアップリングシグナリング、即ち受信機から送信機へのシグナリングが不要であり、信頼性の高いデータ取り出しを行うためにFECの使用が採用されている。ALCはまた、マルチレートふくそう制御CC97に階層型符号移送LayeredCodingTransportLCTビルディングブロック98を利用し、さらに、信頼性の高いコンテンツ送達のためにFECビルディングブロック99を利用する。LCTについては、2002年12月にIETFより発行された刊行物、RFC3451階層型符号化移送LCTビルディングブロックLayeredCodingTransportBuildingBlockにて説明されている。FECは、やはりIETFから発行されたRFC3453で説明されている。FLUTEプロトコルは、マルチキャストファイル送達へのALCの適用を表す。しかし、従来のFLUTE/ALCプロトコルは主に非移動環境用として設計されている。電池電力を温存する必要があり、エアーリンク帯域幅が貴重である無線環境では、ファイルダウンロード工程をさらにストリームライン化することが可能である。この目的を達成するために、ペイロード内の各データパケットをよりコンパクトに設計することができる。図9は、参照符号94で表されたコンパクトなALCデータパケットの一例を示しており、このALCデータパケットは、RFC3450に明記されているとおりの従来のALCパケットにより従うようにフォーマットされている。ALCパケットフォーマット94は、3GPP2が刊行文書3GPPTS23.346で公表したブロードキャスト/マルチキャストサービスMBMSと同一になるように設計されている。データパケット84内に示されているフォーマットと文書3GPPTS23.346に明記されたフォーマットとの主な違いは、ファイル記述情報のインバンド伝送が全くない、即ち、データパケット94のペイロードを処理するために必要なファイル属性が全くないことである。図10は、別の例証的なコンパクトなパケットフォーマットを参照符号96で示している。データパケット96は実質的にストリームライン化され、無線通信環境での使用に好適となる。とりわけ、ふくそう制御情報を設けずに済むようになる。無線環境と同様に、無線媒体は唯一のアクセス手段であり、異なるデータ速度での複数のアクセス手段を規制するふくそう制御が不要となる。図9に示すデータパケット94では、過負荷は16バイトである。図10に示すデータパケット96の場合には、過負荷はたった8バイトである。図11は、本発明の例証的な実施形態による、例えば図2のノード50のような装置のハードウェア実現の部分を概略的に示している。このハードウェア実現部分には参照符号100を付している。装置100は、例えば数例としてラップトップコンピュータ、PDA、携帯電話のような多様な形式で構築および組込むことができる。装置100は、数個の回路を繋ぐ中央データバス102を備えている。これらの回路はCPU中央処理装置または制御装置104、受信回路106、送信回路108、メモリユニット110を含んでいる。装置100が無線装置の一部である場合には、受信回路106と送信回路108を無線周波数RF回路に接続することができるが、これは図示していない。受信回路106は、受信した信号を、データバス102へ送信する前に処理およびバッファリングする。一方、送信回路108は、データバス102からのデータを、装置100へ送信する前に処理およびバッファリングする。CPU/制御装置104は、データバス102のデータ管理機能と、さらに、メモリユニット110の命令コンテンツの実行を含む汎用データ処理機能とを実施する。送信回路108と受信回路106を、図11に示すように別個に配置するのではなく、代替形としてCPU/制御装置104の一部とすることができる。メモリユニット110は、全体を参照符号101で示した1組の命令を含んでいる。この実施形態において、これらの命令は、とりわけ上述のFULTE/ALCプロトコルを処理することができるプロトコルスタック機能112のような部分を含んでいる。この1組の命令はまた、図7に図示し説明したような方法の実行が可能なブロードキャストクライアント機能114を含んでいる。この実施形態では、メモリユニット110はRAMランダムアクセスメモリ回路である。例証的な命令部分112、114は、ソフトウェアルーチンまたはモジュールである。メモリユニット110は、揮発性または非揮発性タイプのいずれかであってよい別のメモリ回路図示せずに連結することができる。これの代替形として、メモリユニット110を他の回路タイプ、EEPROM電気的に消去できるプログラム可能な読み出し専用メモリ、EPROM電気的にプログラム可能な読み出し専用メモリ、ROM読み出し専用メモリ、ASIC特定用途向け集積回路、磁気ディスク、光学ディスク、また技術上よく知られているこれ以外のものによって作成することが可能である。図12は、図2に示したBSN装置70のようなブロードキャストサーバのハードウェア実現の部分を、参照符号120を付して概略的に示す。この装置120は、数個の回路を繋ぐ中央データバス122を備えている。これらの回路はCPU中央処理装置または制御装置124、受信回路126、送信回路128、データベース格納ユニット129、メモリユニット131を含んでいる。受信回路126、送信回路128は、装置120が繋がれたネットワークデータバス図示せずに接続できる。受信回路126は、ネットワークデータバス図示せずから受信した信号を、内部データバス122へルーティング前に、処理およびバッファリングする。送信回路128は、データバス122からのデータを、装置120へ送出する前に、処理およびバッファリングする。あるいは、送信回路128と受信回路126を総体的にインターフェース回路と呼ぶこともできる。CPU/制御装置124は、データバス122のデータ管理の任務と、メモリユニット131の命令コンテンツの実行を含む汎用データ処理機能委の任務を実施する。データベース格納ユニット129は、様々なパラメータとコンテンツファイルを含んだSGのようなデータを格納する。メモリユニット131は、参照符号121で全体的に示す1組の命令を含んでいる。この実施形態では、命令は、とりわけプロトコルスタック132およびブロードキャストホスト134の部分を含む。メモリユニット131は、上述したメモリ回路タイプで作成されているため、これ以上の説明の繰り返しは省略する。プロトコルスタック121およびブロードキャストホスト134のための機能は、図3、図8に示し、先述したような本発明による命令の組を含んでいる。さらに、図7、図8に示し、上述した工程を、技術上周知のあらゆるコンピュータ読み出し媒体上に収容されるコンピュータ読み出し可能な命令として符号化することも可能である点に留意されたい。本明細書および添付の請求項において、用語コンピュータ読み出し可能な媒体とは、それぞれ図11、図12に図示し説明したCPU/制御装置104、124のような任意のプロセッサに命令を提供し、実行する際に関与するあらゆる媒体を意味する。こうした媒体は、格納タイプのものであってよく、また、例えばそれぞれ図11、図12のメモリユニット110、131の記述において先述したような揮発性あるいは非揮発性の格納媒体の形態であってよい。このような媒体は伝送タイプであってもよく、また、同軸ケーブル、銅線、光ケーブルや、さらに、マシンまたはコンピュータによって読み出し可能な信号を運べる音響波あるいは電磁波を伝達するエアーインターフェースを含んでいてよい。最後に、この実施形態で説明したように、ノード、即ちBSD48は、サービスプロバイダのネットワーク42にインストールされたものとして記述されている。しかし、常にこの限りでなくてもよい。BSD48を、サービスプロバイダが所有しているものではない別のネットワークにインストールすることも可能である。さらに、例証的な実施形態で説明したアウトオブバンド伝送チャネルを、拡散スペクトル通信の技術において一般的に実施されるように論理的または物理的に区別することができる。これに加え、多種のアウトオブバンドセッションを、前述した時間分離ではなく異なるポート番号によって識別することもできる。そのため、例えば図5では、FDTを、第1送信セッションに関連した1つの宛先ポートを介して、層4のUDP図3上で伝送できる。また、第2伝送セッション中に、コンテンツファイルを、別の宛先ポート番号を介し、層4のUDP上で伝送することが可能である。これに加え、図7、図8のフローチャートが、音楽ファイルのようなファイルをユーザの選択でダウンロードおよび実行するためにも適用できる点を明白にしておくべきである。例えば、ユーザはSGからファイルを拾い集め、自分のファイル配信ウィンドウおよびファイル表示ウィンドウ上で決定を行うことができる。さらに、例証的な実施形態では、バックボーンネットワークはIPの下で動作されると説明している。IP以外のプロトコルの使用も可能である。例えば、FLOネットワークでは、FLOフォーラムFLOForumが発行したfloforum2005.001の文書FLOエアーインターフェース仕様書FLOAirInterfaceSpecificationによるプロトコルの適用が可能である。FLOネットワークでは、SGではなく、関連する属性をシステム情報SIに入れることができる。これについての詳細は、FLOForumが発行した文書floforum2006.005を参照できる。これに加え、本発明に関連して説明した論理ブロック、回路、アルゴリズムステップを、ハードウェア、ソフトウェア、ファームウェア内、あるいはこれらの組み合わせにおいて実現することができる。当業者は、本発明の範囲と精神から逸脱しない限り、形態および詳細に、ここで説明した変更やその他の変更を加えられることを理解するだろう。"