マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置
【課題】マルチキャスト通信またはブロードキャスト通信において拡張したファイル配信を行う方法および装置
【解決手段】ブロードキャストサービスを提供する通信システムにおいて、ブロードキャスト用のファイルにユーザがアクセスすることができる。ブロードキャストファイルを処理するために必要なブロードキャストファイルのコンテンツとファイル属性のコンテンツはと別々に送信される。こうして配列することにより、コンテンツファイルよりも前にファイル属性を受信することで、ブロードキャストファイルのより効率的なダウンロードと処理が可能となる。
【解決手段】ブロードキャストサービスを提供する通信システムにおいて、ブロードキャスト用のファイルにユーザがアクセスすることができる。ブロードキャストファイルを処理するために必要なブロードキャストファイルのコンテンツとファイル属性のコンテンツはと別々に送信される。こうして配列することにより、コンテンツファイルよりも前にファイル属性を受信することで、ブロードキャストファイルのより効率的なダウンロードと処理が可能となる。
【発明の詳細な説明】
【優先権の主張】
【0001】
(米国特許法第119条の下での優先権の請求)
本特許出願は、2005年4月8日に提出され、譲受人に譲渡され、米国仮出願60/669,505号、「移動体ブロードキャスト通信用途のためにファイル配信を拡張する方法および装置(Method and Apparatus to Enhance File Distribution for Mobile Broadcast Applications)」に対して優先権を請求するものであり、参照として明確に本明細書に組み込まれている。
【技術分野】
【0002】
I.分野
本発明は、概してデータ通信に関し、特に、マルチキャスト通信またはマルチキャスト通信環境におけるデータ通信システムでのファイル配信の拡張に関する。
【背景技術】
【0003】
II.背景
ネットワークを地球規模で相互接続することで、地理的距離に関係なく、情報に非常に素早くアクセスできるようになる。図1はネットワークの地球規模の接続の簡単な概略図を示す。この接続は一般にインターネットと呼ばれ、同図中では参照符号20を付している。インターネット20は本質的に、階層レベルの異なる多数のネットワークである。インターネット20は、インターネット技術標準化タスクフォース(Internet Engineering Task Force)(IETF)が公表しているインターネットプロトコル(IP)の下で動作される。IPの詳細は、IETFから発行されたコメントの要求(Request for Comments)(RFC)791に見ることができる。
【0004】
インターネット20には様々な個々のネットワークが接続しており、多くの場合、これらはネットワークサイズによってローカルエリアネットワーク(LAN)またはワイドエリアネットワーク(WAN)と呼ばれる。図1には、こうしたネットワークのいくつかである22、24、26を示している。
【0005】
各ネットワーク22、24、26内では、様々な設備が接続し、相互に通信することができる。これの本発明の数例として、コンピュータ、プリンタ、サーバが挙げられ、これらは一般にノードと呼ばれる。ノードは、属するネットワークを超え、インターネット20を介して通信する場合には、IPに準拠したデータパケットを別のネットワーク内の関連するノードへ送信する必要がある。同様に、別のネットワーク内の関連するノードによって開始ノードへ送出されたデータパケットもIPと一致しなければならない。
【0006】
タイプの異なる用途には、IPと連係して動作する各種レベルのプロトコルが必要である。数例を挙げて例証する。ネットワーク22内のノード28が、ネットワーク26内の別のノード30からファイルをダウンロードしようとしたと仮定する。ファイルを転送するには、非常に多くの場合、ファイル転送プロトコル(FTP)と呼ばれるより高次のプロトコルを使用する。FTPは、IETFより発行のRFC959に見ることができる。そのため、ノード30がノード28へ送信したデータパケットは、とりわけFTPおよびIPと一致しなければならない。
【0007】
別例として、ネットワーク22内のノード28が、インターネット20を介して、また別のネットワーク24内のノード32が提示したウェブサイトをブラウジングする場合を挙げる。この場合は、ノード28、32は別のより高次なプロトコル、即ちハイパーテキスト転送プロトコル(HTTP)を使用する。HTTPについては、IETFが発行しているRFC2616に見ることができる。この場合にも、交換されたデータパケットは、とりわけHTTPおよびIPと一致している必要がある。
【0008】
例証的なプロトコルFTP、HTTPは、さらに別の中間レベルのプロトコル、即ち転送制御プロトコル(TCP)によっても伝送できる。TCPはRFC793に見ることができる。TCPの下では、データを正確に伝送することが目的である。そのため、エラーを含んだデータは常に再伝送される。1対1のアプリケーションでは、TCPと、これに実装されたFTPやHTTPのようなプロトコルとを採用することが一般的である。
【0009】
技術の進歩により、データ集約型のデータ転送が可能となった。例えば、広帯域幅に対応可能なネットワークによって、通常は大容量のデータを保持したオーディオファイルやビデオファイルのようなマルチメディアファイルを交換することができるようになった。多数のノードがこうしたマルチメディアファイルを受信する場合には、従来のユニキャスト方法によるファイル送達では不十分であることが多い。とりわけ、まずファイルを複製し、その後で個々のファイルを各ノードへ送達しなければならない。したがって、1対多数のアプリケーションにおける増加する要求に対応でき、ブロードキャストまたはマルチキャストサービスでの使用に適した別タイプのプロトコルを開発する必要がある。
【0010】
この要求を満たすために、マルチキャストファイル配信用途に好適な1方向移送上でのファイル送達(FLUTE)プロトコルが考案された。FLUTEプロトコルは、IETFより2003年11月14日に発行のRFC3926「FLUTE−1方向移送上でのファイル送達(File Delivery over Unidirectional Transport)」に見ることができる。マルチキャストセッションでは、トラフィックの流れは幾分1方向的である。これは即ち、反対方向のデータの流れがあれば全て制限されるということである。こうした1方向的な使用は、1つの通信ソースが多数の受信側にデータを送信するブロードキャストまたはマルチキャスト用途では一般的である。
【0011】
FLUTEプロトコルの下で伝送されたデータは、HTTPおよびFTPプロトコルでのようにTCP上に実装されるのではなく、ユーザデータグラムプロトコル(User Datagram Protocol)(UDP)上に実装される。UDPの下では、エラーを含んだデータは通常再送信されない。データを正確に伝送するために、通常、FLUTEプロトコルは冗長においてデータを伝送し、エラー修正スキームを使用する。
【0012】
FLUTEプロトコルを使用することにより、ファイル送達セッション中に1または複数のファイルが転送される。ファイルはALCパケットと呼ばれる非同期層符号化(ALC)の形式のデータパケットにて運ばれる。各ファイルは、これの長さに応じて、1または複数のALCパケットにて識別される。ファイルはオブジェクトと呼ばれる。オブジェクトは、ファイル伝送テーブル(FDT)に含まれたファイル属性(file attributes)によって識別される。このファイル属性は、受信側にて、ALCパケットからオリジナルのファイルを再構築する上で信頼される。受信したファイルオブジェクトは、関連のファイル属性が正確に受信されるまでは処理されない。FDT受信の信頼性を高めるために、複写FDTインスタンスの間には、受信側へ送られたALCパケット内のペイロードデータが介在している。以前は、FDTファイルとコンテンツファイルは幾分併発的に伝送されていた。そのため、常に正常に受信されるわけではないコンテンツファイルがたとえ正確に受信された場合でも、受信側はFDTを正確に受信し、FDTからファイル属性を抽出し、その後、受信したコンテンツファイルを処理する必要がある。即ち、受信したファイルの復号とその後の表示の成功は、ALCパケットの処理に必要なファイル属性のダウンロードの成功に幾分同時に依存する。このような依存性によって遅延が生じることは不可避であり、また、多くの場合、コンテンツ表示の質に悪影響を及ぼす。さらに、ユーザが正確なファイル属性を持っていない場合には、必要なファイル属性の取得を試みようとして通信チャネルの入力を複数回繰り返すことが非常に多い。これの結果、利用可能な通信リソースの最も効率的な使用でなくなってしまう可能性がある。
【0013】
したがって、よりよい品質のブロードキャストのためのより効果的なスキームと、通信リソースをより経済的に利用するスキームとを提供する必要がある。
【発明の概要】
【0014】
ブロードキャストサービスを提供する通信システムでは、ユーザはブロードキャスト用のファイルにアクセスできる。ブロードキャストファイルのコンテンツは1つの通信セッション中に送信される。ブロードキャストファイルの処理に必要なファイル属性は、別の通信セッションで別個に送信される。こうして配列することにより、コンテンツファイルよりも先にファイル属性を受信することで、ブロードキャストファイルをより効率的にダウンロードおよび処理できるようになる。
【0015】
これらおよびこれ以外の特徴や利点は、添付の図面と以下の詳細な説明から当業者に明白となる。図面中、同様の部分には同様の参照符号を付している。
【図面の簡単な説明】
【0016】
【図1】図1は、ネットワークの地球規模の接続の概略図である。
【図2】図2は、本発明の例証的な実施形態に関与するノードおよびネットワークの概略図である。
【図3】図3は、階層順序にあるプロトコルのスタックを示す概略図である。
【図3A】図3Aは、FLUTEプロトコルのより詳細な概略図である。
【図4】図4は、FLUTEプロトコルの下で動作するCFD方法の方法論を示す概略図である。
【図5】図5は、本発明の例証的な実施形態に従って動作するCFD方法を示す概略図である。
【図6】図6は、異なる時間ウィンドウ中に実行されるファイルの伝送および表示を示す時間線図である。
【図7】図7は、本発明の例証的な実施形態による、ファイルの取り出しおよび処理を示すフローチャートである。
【図8】図8は、本発明の例証的な実施形態によるファイル伝送を示すフローチャートである。
【図9】図9は、例証的なコンパクトなALCデータパケットを示す概略図である。
【図10】図10は、無線通信上でのファイル伝送に適した別のコンパクトなパケットフォーマットを示す概略図である。
【図11】図11は、本発明の例証的な実施形態による、ブロードキャストファイルを受信および処理するように構成されたノードの回路の一部を示す概略図である。
【図12】図12は、本発明の例証的な実施形態による、ブロードキャストファイルを伝送するように構成されたノードの回路の一部の概略図である。
【発明を実施するための最良の形態】
【0017】
以下の説明は、全ての当業者が本発明を使用できるようにするために示される。また、以下の説明では説明の目的で詳細を述べている。当業者は、こうした詳細を使用しなくても本発明を実現できることを理解するはずである。別の場合では、不要な説明によって本発明を不明瞭化しないために、よく知られている構造および処理については詳述していない。そのため、本発明はここで示す実施形態に限定されるのではなく、ここで述べている原理および特徴と一致する最も広範囲に従うものである。
【0018】
図2は、本発明の例証的な実施形態の簡略化した概略図を示している。システム全体を参照符号40によって総体的に示している。図面を簡略化し説明を明瞭化するために、この通信システム40では2つのネットワーク42、44のみ示す。ネットワーク42、44は、イントラネットまたはインターネットのようなバックボーンネットワーク46で繋がれている。
【0019】
この実施形態では、ネットワーク42はサービスプロバイダによって操作されると仮定する。サービスプロバイダは、ネットワーク42にノード48をインストールする。この例では、ノード48をブロードキャスト・サービスディストリビュータ(BSD)と呼ぶ。コンテンツサーバ48は、ブロードキャストコンテンツと、さらにこれに関連する、サービスプロバイダによって提供されたブロードキャスト情報とを保持することができる。
【0020】
ネットワーク44では、バックボーンネットワーク46を介してサーバノード48によって提供されたサービスを含むサービスを受信できる加入者ノード50が存在する。この実施形態では、ノード50は無線装置として表されており、このノード50の例のいくつかには、パーソナル・デジタル・アシスタント(PDA)、モバイルコンピュータ、携帯電話がある。ネットワーク44は、米国のTIA/EIA(電気通信業界団体/米国電子工業会)を含む国際標準化機関である3GPP2(第3次世代パートナーシッププロジェクト2)によって説明するcdma2000規格のような無線技術をサポートする。ネットワーク40はこれ以外の標準、例えば、様々な欧州の標準実体が調整およびサポートする3GPP(第3世代パートナーシッププロジェクト)によって公表されたWCDMA(広帯域符号分割多重アクセス)標準をサポートできる点について留意されたい。別の例として、送リンク専用(FLO)ネットワークで使用する無線業界促進標準化における様々な実体の機関である転FLOフォーラムが開発した標準を挙げる。
【0021】
加入者ユニット50は、無線アクセスネットワーク(RAN)52を介してネットワーク44と通信する。RAN52は、複数の基地局(BS)66A〜66Nに接続した基地局制御装置/パケットデータ制御機能(BSC/PDF)54を含む。パケットデータ・サービスノード(PDSN)68とブロードキャスト・サービングノード(BSN)70がネットワーク44内で実現される。PDSN68とBSN70の両方は、ネットワーク44内のバックボーンネットワーク46とRAN52をインターフェースする機能を果たす。PDSN68が主にユニキャスト通信の利用に対応しているのに対し、BSN70はむしろマルチキャスト通信またはブロードキャスト通信を扱う場合向けにインストールされることが多い。本明細書では、「マルチキャスト」、「ブロードキャスト」という用語を相互交換可能な意味で使用している。
【0022】
ネットワーク44内には、BSN70に接続したブロードキャスト/マルチキャストサービス(BCMCS)コンテンツサーバ63と呼ばれる別のサーバも存在する。一般に、BCMCSコンテンツサーバ63は、ブロードキャストコンテンツと、これに関連した、コンテンツサーバ48から提供されたものと、バックボーンネットワーク46を介して転送されたものとを含む、ブロードキャストコンテンツのデータとを事前に記憶する。
【0023】
この例証的な実施形態では、いくつかのノード間での通信を、無線で実施されたものとして表している。しかし、常にこの限りではない点を理解すべきである。これ以外の様々な手段によるノード間の非無線通信も適用可能である。例えば、ノード50は無線装置でなく据置きコンピュータであったり、光リンクや従来の伝導ケーブルでネットワーク44と通信する他のサーバ通信であってもよい。
【0024】
この実施形態において、バックボーンネットワーク46がインターネットプロトコル(IP)をサポートすると仮定する。動作の詳細について説明する以前に、まず、階層の異なる多様なレベルのプロトコルを介して行われ、これらの相互関係がIPの下で動作するパケットデータ通信中におけるデータパケットの処理について大まかに説明する。
【0025】
ネットワーク通信の技術において、プロトコルは、国際標準化機構(ISO)と国際電信電話諮問委員会(ITU−T)が説明しているとおりの開放型システム間相互接続(OSI)モデルに従って階層化される。この目的は、マルチベンダ設備相互使用可能性の促進である。即ち、各レベルのプロトコル階層には独自の仕様がある。そのため、特定の階層レベルの仕様が満たされる限り、このレベルにおける製品の開発が別レベルの他の製品と互換することが保証される。
【0026】
図3は階層順序に並んだプロトコルのスタックを概略的に示しており、これは一般に「プロトコルスタック」と呼ばれ、この図では参照符号72を付している。IPプロトコルスタック72は、OSIモデルと類似するが完全に同一ではないインターネット技術標準化タスクフォース(IETF)モデルと一致した構造を有する。IETFモデルに従って、IPプロトコルスタック72は、層1〜5までの5つの層を有する。そのため、ノードから送信されたデータパケット、例えば図2に示すノード48や50は、プロトコルスタッック72で処理しなければならない。プロトコル72のスタックは、ソフトウェアまたはハードウェア、あるいはこれらの組み合わせの形式のノード内に構築される。同様に、同一のノードによって受信されたデータパケットは、同一のプロトコルスタック72を介し、逆の順序で処理されなければならない。
【0027】
一例を挙げて例証を行う。データパケットをノード、例えばノード48(図2)から送信するように処理する場合、このデータパケットはまず、例えば層5のようなアプリケーション層内のプロトコルの1つに従って作成される。層5は、ハイパーテキスト転送プロトコル(HTTP)、サービスメール転送プロトコル(SMTP)、ファイル転送プロトコル(FTP)、リアルタイム転送プロトコル(RTP)、1方向移送/非同期層符号化上でのファイル送達(FLUTE/ALC)プロトコルを含む。さらに、データパケットはVoIP(ヴォイスオーバ・インターネットプロトコル)セッションの積であると仮定する。そのため、層5内で、データパケットをRTPに従ってフォーマットする必要がある。
【0028】
例えば層5内のRTPによって生じたデータパケットのような、時間に敏感なデータパケットは、リアルタイムで処理する必要がある。詳細には、通常、欠陥パケットは再送信されず、他の接近中のデータパケットの伝送を妨害することがないよう単純にドロップされる。そのため、RTPデータパケットは、通常、移送層である層4内のユーザデータパケットプロトコル(UDP)を介して運ばれる。したがって、層5内のRTPからのデータパケットは、層4内のUDPに従って公式化される。
【0029】
一方、データパケットが層5内の別のプロトコル、例えばFTPから発生している場合には、通常、このデータパケットは層4内の移送制御プロトコル(TCP)を介して送信される。TCPの下では、データパケットの正確な送達は最も重要である。そのため、全体のデータ伝送処理が遅速化する可能性があっても、欠陥パケットは常に再送信される。
【0030】
この移送層である層4を通過したデータパケットには、セキュアポート番号や宛先ポート番号のような情報が追加される。
【0031】
移送層である層4を通過するデータパケットは、次に、処理のためにネットワーク層である層3へ送信される。この特定の場合には、層4から生じたデータパケットに、データパケットのソースアドレスと宛先アドレスを追加した状態にし、さらに、IPに従って再びフォーマットする必要がある。
【0032】
その後、データパケットをフレーム化して、リンク層である層2内に適したプロトコルに適合させる。電気電子学会(Institute of Electrical and Electronics Engineers)(IEEE)発行の文書第IEEE802.3で説明されているように、例えば、イーサーネット(登録商標)を介してサーバノード48をネットワークに接続した場合には、層2はイーサネット(登録商標)プロトコル形式となる。
【0033】
図5中のプロトコルスタック72の最下層は、物理層である層1であり、この層はデータパケットの送信を物理的に実現する。例えば、図2では、ノード48とネットワーク42の間の通信リンクが従来の有線リンクである場合に、物理層である層1は、両ノード48上のハードウェア回路とネットワーク42の物理インターフェース回路に関連する。ノード50とBS66Aの間の通信リンクがエアーインターフェースである場合には、図2の別の例のようになる。この場合は、物理層である層1は、エアースペースと、このエアースペースを介して信号のやり取りを行うRAN52のハードウェア回路とに関連する。
【0034】
次に再び図3を参照する。例証的なノード50が受信したデータパケットの場合(図2)、データパケットは同じプロトコルスタック72を介して処理されるが、しかしこの場合には、層1から層5の逆の順序で処理されなければならない。
【0035】
次に、システム40における例証的なブロードキャスト処理の動作について説明する。図2では、先述したように、ノード48、即ちBSDが、加入者にブロードキャストサービスを提供するサービスプロバイダによってネットワーク42にインストールされる。この場合、ノード50はこうした加入者の1人である。例えばこの場合、ノード50は別のネットワークからネットワーク44へのローミングであってよく、ネットワーク42を動作しているサービスプロバイダより入手可能な夜7時のニュースのようなニュースクリップのアクセスをシークすることができる。
【0036】
ネットワーク44がブロードキャストサービスをサポートする場合には、ネットワーク44には利用可能なサービスのブロードキャストチャネルが設けられていることが多い。利用可能なサービスの情報は、ダウンロード可能なファイル形式で編成できる。あるいは、この情報を、リアルタイム・ビューイング可能なデータの一定のストリームの形式で表すこともできる。
【0037】
この例証的な実施形態では、無線通信における多様な標準を統一する目的で、サービスプロバイダ、ハードウェアおよびソフトウェアベンダ、ネットワークオペレータその他を含む無線業界の様々な実体の共同体であるオープン・モバイル・アライアンス(OMA)が公表したブロードキャストサービス案内(SG)と類似した方法で、利用可能な複数のサービスをダウンロード可能なファイルとしてグループ化するものとする。SGの詳細は、OMAより発行の文書OMA−TS−BCAST−ServiceGuide−V1.〜@#$@@`で説明されている。
【0038】
これまで、ノード50のユーザは、ネットワーク44内にある場合、利用可能なサービスについてSGを参照する必要があった。このために、ネットワーク44からSGをダウンロードしなければならない。次に、ノード50のユーザはシークしたサービスをSGから選択して、このサービスを装備しているチャネルがSGに提供された時にこれに同調する。
【0039】
例えば音楽のダウンロードのようないくつかのサービスでは、ノード50のユーザはシークしたファイルを最初にダウンロードし、後にこのファイルを楽しむことができる。ニュースブロードキャストセッションのような別のサービスでは、シークしたファイルのコンテンツがダウンロードされ、これとほぼ同時に表示される。これは即ち、シークしたサービスと、このサービスに関連したファイルのダウンロードとがリアルタイムに提示されるということである。こうしたアプローチにはいくつか欠点がある。これはとりわけ、ファイルコンテンツの連続提示が、コンテンツ自体のダウンロードの成功のみでなく、コンテンツファイルの処理に必要なファイル属性のダウンロードの成功にも依存することによる。こうした依存性によって遅延が生じるのは不可避であり、また多くの場合、コンテンツ提示に関連したユーザの経験に悪影響を及ぼす。これに加え、信頼性の高いデータパケットの受信度を高めるために、通常は冗長データが送信される。この結果、以降でさらに説明している利用可能な通信リソースの最も効率的な使用が得られなくなる可能性がある。
【0040】
シークしたサービスのファイルのコンテンツが、FLUTE/ALCプロトコルを介して移送されるとする。正確なデータ移送を確実に得るために、従来は、FLUTE/ALCプロトコルと共にカルーセルファイル配信(CFD)方法が使用された。図3AはFLUTE/ALCプロトコルのより詳細な概略図を示している。これについては以降でより詳細に説明する。図4は、FLUTE/ALCプロトコルの下で動作するCFDスキームの方法論を示している。
【0041】
図4では、ファイルを参照符号74で表している。1片のマルチメディアコンテンツ、この例では例えばニュースクリップが、複数のファイルを備えていてよい。ファイル74内では、各ALCデータパケットがデータパケット#1〜#5の1つで表されている。確ファイル74の送達には、ファイル送達テーブル(FDT)78を設け、やはりALCプロトコル形式で構成されたALCデータパケットが関連している。
【0042】
FDT78には、データパケット#1〜#5の復号化に必要な多様なパラメータまたは属性が含まれている。こうしたパラメータは、ファイル名、ファイル識別(ID)、ファイルのソース場所(即ちURI)、表示時間、ファイルサイズ、コンテンツタイプ、符号化スキーム、転送エラー修正(FEC)タイプとFEC関連のパラメータ、さらに、適切であればセキュリティ関連のパラメータを備えていてよいが、しかしこれらのパラメータに限定されるものではない。
【0043】
CFD方法ではファイルは複数回伝送される。この例では、ファイル74はコンテンツパケット#1〜#5と、これに関連するFDT78とを含んでおり、第1パス73において1回目、次に第2パス75において2回目の伝送が実行される。第1パス73では、FDT78がコンテンツパケット#1〜#5よりも先に伝送される。第2パス75では、これと同一のFDT78が、コンテンツパケット#1〜#5の最後に伝送される。
【0044】
各ファイルを繰り返し伝送する1つの目的は、全ての受信者が確実に同じ時間にファイルを受信する必要を排除することである。即ち、ファイル受信のために受信者を同期する必要はない。
【0045】
各ファイルを繰り返し伝送する別の目的は、FECスキームがインストールされていない場合、あるいは、たとえインストールされていてもFEC機構の動作が失敗した場合に、データ移送中の正確性を確実にすることである。この目的は、CFD方法を、図4に示すシナリオA、B、Cと識別される3つのシナリオを包括するように設計することで達成される。この3つのシナリオA、B、C以外にも、失敗したファイルのダウンロードの宣言を行える。
【0046】
シナリオAでは、ノード50がファイル74のダウンロードを試みると仮定する。第1パス73の最中に、ノード50はFDT78の受信に成功する必要がある。第1パス73におけるFDT78のダウンロードがエラーなく成功する。次に、ノード50が後続のデータパケット#1〜#5を受信する。第1パス73において、データパケット#1〜#5全てのダウンロードも成功したと想定する。ファイル74全体を組み立てるために、ノード50は、第1パス73からダウンロードしたFDT78内の情報を使用して、全てのパケット#1〜#5内のデータを復号化することができる。
【0047】
シナリオBでは、第1パス73でのファイル74のダウンロードの最中に、FDTパケット78の取り出しが成功したと仮定する。第1パス内での、#3を除いた全てのコンテンツパケット#1〜#5の取り出しも成功したとする。実現されたFEC機構は機能しないと仮定する。この場合ノード50は、第1パス73において受信した関連する欠陥パケット#3を補正するために、第2パス75の最中に、第2パス75が同一のデータパケット#3を受信するまで待つ必要がある。その後、ノード50は、ファイル74を再構築するために、第1パスから入手したFDT78からの情報を使用して、全てのデータパケットを復号化することができる。
【0048】
シナリオCでは、全てのデータパケット#1〜#5が第1パス73内に正確にダウンロードされるが、ノードはFDT78を第1パス73内に正確に受信することができない。この場合には、ノード50は、第1パス73からの誤ったFDT78を補正して、ファイル74の全てのデータパケットを正確に復号できるよう、第2パス75が関連のFDT78を取り出すまで待たなくてはならない。
【0049】
望ましくない信号受信条件の下では、上のシナリオA、B、Cの部分で説明したFECの一番最初に追加のステップを実行しても、エラーのあるデータを修正することはできない可能性がある。すなわち、先に述べたように、ファイル74のダウンロードは失敗と宣言される可能性がある。シナリオBでは、データパケット#3が損失しても、表示中のファイル74の品質にしか影響が及ばないことがある。しかし、シナリオCでは、FDT78がなければファイル74全体の処理ができないため、FDT78の取り出しの失敗によってファイル74全体が損失しかねない。この場合には、ノード50は、次のカルーセル周期まで待つ必要がある。この周期は、後にFDT78取得の別の機会を得るだけのために、時間パス73、75で延長された期間のように非常に長くなる可能性がある。この場合には、さらなる時間の遅延と、通信チャネルの固定が不可避となる。この例のようにデバイス50が移動体装置である場合は、時間遅延の増加はデバイス50の電池の電力消費増加につながる。移動通信では、電池寿命の維持が非常に重要である。
【0050】
本発明の例証的な実施形態によれば、FDTとコンテンツデータパケットは、従来実施されていたようにインバンド方式で受信されない。代わりに、ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。
【0051】
これ以降では、用語「インバンド方式」は、伝送チャネルを介し、さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は、図4の伝送工程に図示し、説明しているとおりのものである。一方、用語「アウトバンド方式」は、図5に図示し、以降で説明する伝送工程によって例証されるように、こうした移送が同一の伝送チャネルを介して行われるか、あるいは別の伝送チャネルを介して行われるかに関係なく、多様な伝送セッションを介して、情報の移送を意味するものとして解釈される。
【0052】
次に図5を参照する。この実施形態では、データパケット#1〜#5のようなペイロードデータと比較して、先に述べたFDT78に含まれているファイル属性のようなファイル属性82が別々に、即ち、インバンド方式ではなくアウトバンド方式で送信される。
【0053】
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のダウンロードの成功によって決まってしまう状況を回避できる。
【0054】
伝送工程中の第1パス85において、図5の参照符号90で示す欠陥のあるデータパケット、例えばデータパケット#4がファイル84内に見付かり、さらに、インストールされたFEC機構ファイルがこの欠陥パケット#4を修正すると仮定した場合には、第2パス87内の関連するデータパケット#4を取り出して修復することができる。修復工程が失敗した場合には、表示中のファイル84に特定の品質劣化が生じる可能性がある。しかし、図4に示し、上述したような失敗したシナリオCでの状況が生じることは絶対にない。これの理由は、先述したように、先の通信セッション81の最中にFA82の受信が成功しているためである。
【0055】
上述した方法で動作する場合には、FDTの伝送用としてインバンドチャネルを固定する必要はない。そのため、コンテンツファイルの取り出しをより高い確実性にて行える。ファイル取得時間も実質的に短縮することができる。この結果、通信チャネル間のふくそうが容易化されるため、利用可能な通信リソースをより効率的に使用できるようになる。さらに、ノード50(図2)が移動体装置である場合には、ファイル取得時間が短いことは、コンテンツファイルのダウンロード中に、ノード50の電池の起動に要する時間が短くて済むことを意味する。したがって、電池電力を温存できる。
【0056】
図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内で定期的に更新することができる。
【0057】
先述したように、最初にいくつかのファイルをダウンロードしておき、後でユーザが選択した時間に実行することが可能である。この例には、音楽ファイルやソフトウェア更新用ファイルがある。最初にダウンロードしておくことができるが、しかし、特定の時間に表示させることが好ましいファイルもある。これの一例には、以下で説明するニュースブロードキャストセッションがある。いずれの場合でも、本発明の別の態様に従って、コンテンツファイルの取得および表示は同時に実行される必要はない。代わりに、ファイル取得をファイル表示工程前に別個に実行することができる。
【0058】
説明を簡単にするために、より具体的な例を例証する。次に再び図2を参照する。この例では、ノード50のユーザが、通常午後7時に、標準テレビブロードキャストを介して利用できるニュースブロードキャストを視聴したいと仮定する。ネットワーク44によってブロードキャストされたSG内では、これに関連した、午後7時のニュースクリップに関する情報が通常利用可能である。ネットワーク44は、ネットワーク42をバックボーンネットワーク46を介して提供しているサービスから取得した情報を有する。SG内では、2つの時間ウィンドウ、即ち「配信ウィンドウ(DW)」と「表示ウィンドウ(PW)」が指定される。図6はこうした配列を示す。
【0059】
DW内では時間ウィンドウが指定される。この時間ウィンドウ内では、午後7時のニュースセッションのファイルを受信するために、ノード50が起動される必要がある。時間ウィンドウは、この例においては例えば午後5時〜午後6時半であり、これは、ニュースファイルを受信するためにノード50の電源がオンにされる時間間隔である。一方、PWは、例えば午後7時〜午後7時半の間にダウンロードしたニュースセッションの表示時間を識別した。これは即ち、この時間スパン中に、ダウンロードしたファイルが午後7時のニュースとして表示されるということである。DWをPWから分離することの追加的利点に、加入者が、表示時間以前にファイルをダウンロードできるため、通常、ピーク時間帯にぶつかってしまう表示時間中におけるトラヒックチャネルの過負荷を回避できるということがある。DW中にネットワーク44内のトラヒック負荷が混雑している場合でも、それぞれのファイルダウンロードを受信側の受信機内へ少量ずつ行い、PWが開始する前に都合よく完了することができる。
【0060】
ノード50は、SGが提供した情報に基づいて、ニュースクリップを受信するために、午後5時25分〜午後5時37分の期間中に電源オンにされ、起動されると仮定する。適切なファイル圧縮技術を実現した場合、ダウンロードに要する時間はこの例では12分間であり、表示時間(この場合は30分間)よりも短い。
【0061】
前述のノード50のための方法を図7のフローチャートに示す。図8は、ネットワーク44によって実行されるこれと関連した方法である。
【0062】
本発明のさらに別の態様では、ペイロードデータの移送をさらにストリームライン化することができる。
【0063】
ファイルコンテンツをダウンロードするために、FLUTE/ALCプロトコルを採用できる。先述したように、データパケットがTCP移送層(図3)を介して移送されるFTPとは異なり、FLUTE/ALC内のデータパケットがUDP移送層へ運ばれる。伝送工程全体は遅速化するが、FTPはより1対1のアプリケーションへと調整され、エラーが生じたパケットも正常に再伝送される。UDPを介して運ばれるFLUTE/ALCプロトコルは、マルチキャストまたはブロードキャストアプリケーションに適するように設計される。エラーの生じたデータは正常に伝送されない。その代わりに、適切な転送エラー修正(FEC)スキームを採用することにより、データ伝送におけるエラーが縮小される。
【0064】
次に、参照符号96で全体的に表されるFLUTE/ALCプロトコルを示した図3Aを参照する。FLUTEプロトコルのパケットはALCプロトコルによって運ばれることで移送される。ALCプロトコルについては、2002年12月にIETFより発行された刊行物RFC3450「非同期層符号化(ACL)プロトコルの例示(Asynchronous Layered Coding (ALC) Protocol Instantiation))」」」」)で説明されている。ALCプロトコルは、マルチキャスト移送に提案された基本プロトコルの1つである。ALCが関与するデータ移送ではアップリングシグナリング、即ち受信機から送信機へのシグナリングが不要であり、信頼性の高いデータ取り出しを行うためにFECの使用が採用されている。ALCはまた、マルチレートふくそう制御(CC)97に階層型符号移送(Layered Coding Transport)(LCT)ビルディングブロック98を利用し、さらに、信頼性の高いコンテンツ送達のためにFECビルディングブロック99を利用する。LCTについては、2002年12月にIETFより発行された刊行物、RFC3451「階層型符号化移送(LCT)ビルディングブロック(Layered Coding Transport (LCT) Building Block)」にて説明されている。FECは、やはりIETFから発行されたRFC3453で説明されている。
【0065】
FLUTEプロトコルは、マルチキャストファイル送達へのALCの適用を表す。しかし、従来のFLUTE/ALCプロトコルは主に非移動環境用として設計されている。電池電力を温存する必要があり、エアーリンク帯域幅が貴重である無線環境では、ファイルダウンロード工程をさらにストリームライン化することが可能である。この目的を達成するために、ペイロード内の各データパケットをよりコンパクトに設計することができる。
【0066】
図9は、参照符号94で表されたコンパクトなALCデータパケットの一例を示しており、このALCデータパケットは、RFC3450に明記されているとおりの従来のALCパケットにより従うようにフォーマットされている。ALCパケットフォーマット94は、3GPP2が刊行文書3GPP TS 23.346で公表したブロードキャスト/マルチキャストサービス(MBMS)と同一になるように設計されている。データパケット84内に示されているフォーマットと文書3GPP TS 23.346に明記されたフォーマットとの主な違いは、ファイル記述情報のインバンド伝送が全くない、即ち、データパケット94のペイロードを処理するために必要なファイル属性が全くないことである。
【0067】
図10は、別の例証的なコンパクトなパケットフォーマットを参照符号96で示している。データパケット96は実質的にストリームライン化され、無線通信環境での使用に好適となる。とりわけ、ふくそう制御情報を設けずに済むようになる。無線環境と同様に、無線媒体は唯一のアクセス手段であり、異なるデータ速度での複数のアクセス手段を規制するふくそう制御が不要となる。図9に示すデータパケット94では、過負荷は16バイトである。図10に示すデータパケット96の場合には、過負荷はたった8バイトである。
【0068】
図11は、本発明の例証的な実施形態による、例えば図2のノード50のような装置のハードウェア実現の部分を概略的に示している。このハードウェア実現部分には参照符号100を付している。装置100は、例えば数例としてラップトップコンピュータ、PDA、携帯電話のような多様な形式で構築および組込むことができる。
【0069】
装置100は、数個の回路を繋ぐ中央データバス102を備えている。これらの回路はCPU(中央処理装置)または制御装置104、受信回路106、送信回路108、メモリユニット110を含んでいる。
【0070】
装置100が無線装置の一部である場合には、受信回路106と送信回路108を無線周波数(RF)回路に接続することができるが、これは図示していない。受信回路106は、受信した信号を、データバス102へ送信する前に処理およびバッファリングする。一方、送信回路108は、データバス102からのデータを、装置100へ送信する前に処理およびバッファリングする。CPU/制御装置104は、データバス102のデータ管理機能と、さらに、メモリユニット110の命令コンテンツの実行を含む汎用データ処理機能とを実施する。
【0071】
送信回路108と受信回路106を、図11に示すように別個に配置するのではなく、代替形としてCPU/制御装置104の一部とすることができる。
【0072】
メモリユニット110は、全体を参照符号101で示した1組の命令を含んでいる。この実施形態において、これらの命令は、とりわけ上述のFULTE/ALCプロトコルを処理することができるプロトコルスタック機能112のような部分を含んでいる。この1組の命令はまた、図7に図示し説明したような方法の実行が可能なブロードキャストクライアント機能114を含んでいる。
【0073】
この実施形態では、メモリユニット110はRAM(ランダムアクセスメモリ)回路である。例証的な命令部分112、114は、ソフトウェアルーチンまたはモジュールである。メモリユニット110は、揮発性または非揮発性タイプのいずれかであってよい別のメモリ回路(図示せず)に連結することができる。これの代替形として、メモリユニット110を他の回路タイプ、EEPROM(電気的に消去できるプログラム可能な読み出し専用メモリ)、EPROM(電気的にプログラム可能な読み出し専用メモリ)、ROM(読み出し専用メモリ)、ASIC(特定用途向け集積回路)、磁気ディスク、光学ディスク、また技術上よく知られているこれ以外のものによって作成することが可能である。
【0074】
図12は、図2に示したBSN装置70のようなブロードキャストサーバのハードウェア実現の部分を、参照符号120を付して概略的に示す。この装置120は、数個の回路を繋ぐ中央データバス122を備えている。これらの回路はCPU(中央処理装置)または制御装置124、受信回路126、送信回路128、データベース格納ユニット129、メモリユニット131を含んでいる。
【0075】
受信回路126、送信回路128は、装置120が繋がれたネットワークデータバス(図示せず)に接続できる。受信回路126は、ネットワークデータバス(図示せず)から受信した信号を、内部データバス122へルーティング前に、処理およびバッファリングする。送信回路128は、データバス122からのデータを、装置120へ送出する前に、処理およびバッファリングする。あるいは、送信回路128と受信回路126を総体的にインターフェース回路と呼ぶこともできる。CPU/制御装置124は、データバス122のデータ管理の任務と、メモリユニット131の命令コンテンツの実行を含む汎用データ処理機能委の任務を実施する。データベース格納ユニット129は、様々なパラメータとコンテンツファイルを含んだSGのようなデータを格納する。
【0076】
メモリユニット131は、参照符号121で全体的に示す1組の命令を含んでいる。この実施形態では、命令は、とりわけプロトコルスタック132およびブロードキャストホスト134の部分を含む。メモリユニット131は、上述したメモリ回路タイプで作成されているため、これ以上の説明の繰り返しは省略する。プロトコルスタック121およびブロードキャストホスト134のための機能は、図3、図8に示し、先述したような本発明による命令の組を含んでいる。
【0077】
さらに、図7、図8に示し、上述した工程を、技術上周知のあらゆるコンピュータ読み出し媒体上に収容されるコンピュータ読み出し可能な命令として符号化することも可能である点に留意されたい。本明細書および添付の請求項において、用語「コンピュータ読み出し可能な媒体」とは、それぞれ図11、図12に図示し説明したCPU/制御装置104、124のような任意のプロセッサに命令を提供し、実行する際に関与するあらゆる媒体を意味する。こうした媒体は、格納タイプのものであってよく、また、例えばそれぞれ図11、図12のメモリユニット110、131の記述において先述したような揮発性あるいは非揮発性の格納媒体の形態であってよい。このような媒体は伝送タイプであってもよく、また、同軸ケーブル、銅線、光ケーブルや、さらに、マシンまたはコンピュータによって読み出し可能な信号を運べる音響波あるいは電磁波を伝達するエアーインターフェースを含んでいてよい。
【0078】
最後に、この実施形態で説明したように、ノード、即ちBSD48は、サービスプロバイダのネットワーク42にインストールされたものとして記述されている。しかし、常にこの限りでなくてもよい。BSD48を、サービスプロバイダが所有しているものではない別のネットワークにインストールすることも可能である。さらに、例証的な実施形態で説明したアウトオブバンド伝送チャネルを、拡散スペクトル通信の技術において一般的に実施されるように論理的または物理的に区別することができる。これに加え、多種のアウトオブバンドセッションを、前述した時間分離ではなく異なるポート番号によって識別することもできる。そのため、例えば図5では、FDTを、第1送信セッションに関連した1つの宛先ポートを介して、層4のUDP(図3)上で伝送できる。また、第2伝送セッション中に、コンテンツファイルを、別の宛先ポート番号を介し、層4のUDP上で伝送することが可能である。これに加え、図7、図8のフローチャートが、音楽ファイルのようなファイルをユーザの選択でダウンロードおよび実行するためにも適用できる点を明白にしておくべきである。例えば、ユーザはSGからファイルを拾い集め、自分のファイル配信ウィンドウおよびファイル表示ウィンドウ上で決定を行うことができる。さらに、例証的な実施形態では、バックボーンネットワークはIPの下で動作されると説明している。IP以外のプロトコルの使用も可能である。例えば、FLOネットワークでは、FLOフォーラム(FLO Forum)が発行したfloforum2005.001の文書「FLOエアーインターフェース仕様書(FLO Air Interface Specification)」によるプロトコルの適用が可能である。FLOネットワークでは、SGではなく、関連する属性をシステム情報(SI)に入れることができる。これについての詳細は、FLO Forumが発行した文書floforum2006.005を参照できる。これに加え、本発明に関連して説明した論理ブロック、回路、アルゴリズムステップを、ハードウェア、ソフトウェア、ファームウェア内、あるいはこれらの組み合わせにおいて実現することができる。当業者は、本発明の範囲と精神から逸脱しない限り、形態および詳細に、ここで説明した変更やその他の変更を加えられることを理解するだろう。
【優先権の主張】
【0001】
(米国特許法第119条の下での優先権の請求)
本特許出願は、2005年4月8日に提出され、譲受人に譲渡され、米国仮出願60/669,505号、「移動体ブロードキャスト通信用途のためにファイル配信を拡張する方法および装置(Method and Apparatus to Enhance File Distribution for Mobile Broadcast Applications)」に対して優先権を請求するものであり、参照として明確に本明細書に組み込まれている。
【技術分野】
【0002】
I.分野
本発明は、概してデータ通信に関し、特に、マルチキャスト通信またはマルチキャスト通信環境におけるデータ通信システムでのファイル配信の拡張に関する。
【背景技術】
【0003】
II.背景
ネットワークを地球規模で相互接続することで、地理的距離に関係なく、情報に非常に素早くアクセスできるようになる。図1はネットワークの地球規模の接続の簡単な概略図を示す。この接続は一般にインターネットと呼ばれ、同図中では参照符号20を付している。インターネット20は本質的に、階層レベルの異なる多数のネットワークである。インターネット20は、インターネット技術標準化タスクフォース(Internet Engineering Task Force)(IETF)が公表しているインターネットプロトコル(IP)の下で動作される。IPの詳細は、IETFから発行されたコメントの要求(Request for Comments)(RFC)791に見ることができる。
【0004】
インターネット20には様々な個々のネットワークが接続しており、多くの場合、これらはネットワークサイズによってローカルエリアネットワーク(LAN)またはワイドエリアネットワーク(WAN)と呼ばれる。図1には、こうしたネットワークのいくつかである22、24、26を示している。
【0005】
各ネットワーク22、24、26内では、様々な設備が接続し、相互に通信することができる。これの本発明の数例として、コンピュータ、プリンタ、サーバが挙げられ、これらは一般にノードと呼ばれる。ノードは、属するネットワークを超え、インターネット20を介して通信する場合には、IPに準拠したデータパケットを別のネットワーク内の関連するノードへ送信する必要がある。同様に、別のネットワーク内の関連するノードによって開始ノードへ送出されたデータパケットもIPと一致しなければならない。
【0006】
タイプの異なる用途には、IPと連係して動作する各種レベルのプロトコルが必要である。数例を挙げて例証する。ネットワーク22内のノード28が、ネットワーク26内の別のノード30からファイルをダウンロードしようとしたと仮定する。ファイルを転送するには、非常に多くの場合、ファイル転送プロトコル(FTP)と呼ばれるより高次のプロトコルを使用する。FTPは、IETFより発行のRFC959に見ることができる。そのため、ノード30がノード28へ送信したデータパケットは、とりわけFTPおよびIPと一致しなければならない。
【0007】
別例として、ネットワーク22内のノード28が、インターネット20を介して、また別のネットワーク24内のノード32が提示したウェブサイトをブラウジングする場合を挙げる。この場合は、ノード28、32は別のより高次なプロトコル、即ちハイパーテキスト転送プロトコル(HTTP)を使用する。HTTPについては、IETFが発行しているRFC2616に見ることができる。この場合にも、交換されたデータパケットは、とりわけHTTPおよびIPと一致している必要がある。
【0008】
例証的なプロトコルFTP、HTTPは、さらに別の中間レベルのプロトコル、即ち転送制御プロトコル(TCP)によっても伝送できる。TCPはRFC793に見ることができる。TCPの下では、データを正確に伝送することが目的である。そのため、エラーを含んだデータは常に再伝送される。1対1のアプリケーションでは、TCPと、これに実装されたFTPやHTTPのようなプロトコルとを採用することが一般的である。
【0009】
技術の進歩により、データ集約型のデータ転送が可能となった。例えば、広帯域幅に対応可能なネットワークによって、通常は大容量のデータを保持したオーディオファイルやビデオファイルのようなマルチメディアファイルを交換することができるようになった。多数のノードがこうしたマルチメディアファイルを受信する場合には、従来のユニキャスト方法によるファイル送達では不十分であることが多い。とりわけ、まずファイルを複製し、その後で個々のファイルを各ノードへ送達しなければならない。したがって、1対多数のアプリケーションにおける増加する要求に対応でき、ブロードキャストまたはマルチキャストサービスでの使用に適した別タイプのプロトコルを開発する必要がある。
【0010】
この要求を満たすために、マルチキャストファイル配信用途に好適な1方向移送上でのファイル送達(FLUTE)プロトコルが考案された。FLUTEプロトコルは、IETFより2003年11月14日に発行のRFC3926「FLUTE−1方向移送上でのファイル送達(File Delivery over Unidirectional Transport)」に見ることができる。マルチキャストセッションでは、トラフィックの流れは幾分1方向的である。これは即ち、反対方向のデータの流れがあれば全て制限されるということである。こうした1方向的な使用は、1つの通信ソースが多数の受信側にデータを送信するブロードキャストまたはマルチキャスト用途では一般的である。
【0011】
FLUTEプロトコルの下で伝送されたデータは、HTTPおよびFTPプロトコルでのようにTCP上に実装されるのではなく、ユーザデータグラムプロトコル(User Datagram Protocol)(UDP)上に実装される。UDPの下では、エラーを含んだデータは通常再送信されない。データを正確に伝送するために、通常、FLUTEプロトコルは冗長においてデータを伝送し、エラー修正スキームを使用する。
【0012】
FLUTEプロトコルを使用することにより、ファイル送達セッション中に1または複数のファイルが転送される。ファイルはALCパケットと呼ばれる非同期層符号化(ALC)の形式のデータパケットにて運ばれる。各ファイルは、これの長さに応じて、1または複数のALCパケットにて識別される。ファイルはオブジェクトと呼ばれる。オブジェクトは、ファイル伝送テーブル(FDT)に含まれたファイル属性(file attributes)によって識別される。このファイル属性は、受信側にて、ALCパケットからオリジナルのファイルを再構築する上で信頼される。受信したファイルオブジェクトは、関連のファイル属性が正確に受信されるまでは処理されない。FDT受信の信頼性を高めるために、複写FDTインスタンスの間には、受信側へ送られたALCパケット内のペイロードデータが介在している。以前は、FDTファイルとコンテンツファイルは幾分併発的に伝送されていた。そのため、常に正常に受信されるわけではないコンテンツファイルがたとえ正確に受信された場合でも、受信側はFDTを正確に受信し、FDTからファイル属性を抽出し、その後、受信したコンテンツファイルを処理する必要がある。即ち、受信したファイルの復号とその後の表示の成功は、ALCパケットの処理に必要なファイル属性のダウンロードの成功に幾分同時に依存する。このような依存性によって遅延が生じることは不可避であり、また、多くの場合、コンテンツ表示の質に悪影響を及ぼす。さらに、ユーザが正確なファイル属性を持っていない場合には、必要なファイル属性の取得を試みようとして通信チャネルの入力を複数回繰り返すことが非常に多い。これの結果、利用可能な通信リソースの最も効率的な使用でなくなってしまう可能性がある。
【0013】
したがって、よりよい品質のブロードキャストのためのより効果的なスキームと、通信リソースをより経済的に利用するスキームとを提供する必要がある。
【発明の概要】
【0014】
ブロードキャストサービスを提供する通信システムでは、ユーザはブロードキャスト用のファイルにアクセスできる。ブロードキャストファイルのコンテンツは1つの通信セッション中に送信される。ブロードキャストファイルの処理に必要なファイル属性は、別の通信セッションで別個に送信される。こうして配列することにより、コンテンツファイルよりも先にファイル属性を受信することで、ブロードキャストファイルをより効率的にダウンロードおよび処理できるようになる。
【0015】
これらおよびこれ以外の特徴や利点は、添付の図面と以下の詳細な説明から当業者に明白となる。図面中、同様の部分には同様の参照符号を付している。
【図面の簡単な説明】
【0016】
【図1】図1は、ネットワークの地球規模の接続の概略図である。
【図2】図2は、本発明の例証的な実施形態に関与するノードおよびネットワークの概略図である。
【図3】図3は、階層順序にあるプロトコルのスタックを示す概略図である。
【図3A】図3Aは、FLUTEプロトコルのより詳細な概略図である。
【図4】図4は、FLUTEプロトコルの下で動作するCFD方法の方法論を示す概略図である。
【図5】図5は、本発明の例証的な実施形態に従って動作するCFD方法を示す概略図である。
【図6】図6は、異なる時間ウィンドウ中に実行されるファイルの伝送および表示を示す時間線図である。
【図7】図7は、本発明の例証的な実施形態による、ファイルの取り出しおよび処理を示すフローチャートである。
【図8】図8は、本発明の例証的な実施形態によるファイル伝送を示すフローチャートである。
【図9】図9は、例証的なコンパクトなALCデータパケットを示す概略図である。
【図10】図10は、無線通信上でのファイル伝送に適した別のコンパクトなパケットフォーマットを示す概略図である。
【図11】図11は、本発明の例証的な実施形態による、ブロードキャストファイルを受信および処理するように構成されたノードの回路の一部を示す概略図である。
【図12】図12は、本発明の例証的な実施形態による、ブロードキャストファイルを伝送するように構成されたノードの回路の一部の概略図である。
【発明を実施するための最良の形態】
【0017】
以下の説明は、全ての当業者が本発明を使用できるようにするために示される。また、以下の説明では説明の目的で詳細を述べている。当業者は、こうした詳細を使用しなくても本発明を実現できることを理解するはずである。別の場合では、不要な説明によって本発明を不明瞭化しないために、よく知られている構造および処理については詳述していない。そのため、本発明はここで示す実施形態に限定されるのではなく、ここで述べている原理および特徴と一致する最も広範囲に従うものである。
【0018】
図2は、本発明の例証的な実施形態の簡略化した概略図を示している。システム全体を参照符号40によって総体的に示している。図面を簡略化し説明を明瞭化するために、この通信システム40では2つのネットワーク42、44のみ示す。ネットワーク42、44は、イントラネットまたはインターネットのようなバックボーンネットワーク46で繋がれている。
【0019】
この実施形態では、ネットワーク42はサービスプロバイダによって操作されると仮定する。サービスプロバイダは、ネットワーク42にノード48をインストールする。この例では、ノード48をブロードキャスト・サービスディストリビュータ(BSD)と呼ぶ。コンテンツサーバ48は、ブロードキャストコンテンツと、さらにこれに関連する、サービスプロバイダによって提供されたブロードキャスト情報とを保持することができる。
【0020】
ネットワーク44では、バックボーンネットワーク46を介してサーバノード48によって提供されたサービスを含むサービスを受信できる加入者ノード50が存在する。この実施形態では、ノード50は無線装置として表されており、このノード50の例のいくつかには、パーソナル・デジタル・アシスタント(PDA)、モバイルコンピュータ、携帯電話がある。ネットワーク44は、米国のTIA/EIA(電気通信業界団体/米国電子工業会)を含む国際標準化機関である3GPP2(第3次世代パートナーシッププロジェクト2)によって説明するcdma2000規格のような無線技術をサポートする。ネットワーク40はこれ以外の標準、例えば、様々な欧州の標準実体が調整およびサポートする3GPP(第3世代パートナーシッププロジェクト)によって公表されたWCDMA(広帯域符号分割多重アクセス)標準をサポートできる点について留意されたい。別の例として、送リンク専用(FLO)ネットワークで使用する無線業界促進標準化における様々な実体の機関である転FLOフォーラムが開発した標準を挙げる。
【0021】
加入者ユニット50は、無線アクセスネットワーク(RAN)52を介してネットワーク44と通信する。RAN52は、複数の基地局(BS)66A〜66Nに接続した基地局制御装置/パケットデータ制御機能(BSC/PDF)54を含む。パケットデータ・サービスノード(PDSN)68とブロードキャスト・サービングノード(BSN)70がネットワーク44内で実現される。PDSN68とBSN70の両方は、ネットワーク44内のバックボーンネットワーク46とRAN52をインターフェースする機能を果たす。PDSN68が主にユニキャスト通信の利用に対応しているのに対し、BSN70はむしろマルチキャスト通信またはブロードキャスト通信を扱う場合向けにインストールされることが多い。本明細書では、「マルチキャスト」、「ブロードキャスト」という用語を相互交換可能な意味で使用している。
【0022】
ネットワーク44内には、BSN70に接続したブロードキャスト/マルチキャストサービス(BCMCS)コンテンツサーバ63と呼ばれる別のサーバも存在する。一般に、BCMCSコンテンツサーバ63は、ブロードキャストコンテンツと、これに関連した、コンテンツサーバ48から提供されたものと、バックボーンネットワーク46を介して転送されたものとを含む、ブロードキャストコンテンツのデータとを事前に記憶する。
【0023】
この例証的な実施形態では、いくつかのノード間での通信を、無線で実施されたものとして表している。しかし、常にこの限りではない点を理解すべきである。これ以外の様々な手段によるノード間の非無線通信も適用可能である。例えば、ノード50は無線装置でなく据置きコンピュータであったり、光リンクや従来の伝導ケーブルでネットワーク44と通信する他のサーバ通信であってもよい。
【0024】
この実施形態において、バックボーンネットワーク46がインターネットプロトコル(IP)をサポートすると仮定する。動作の詳細について説明する以前に、まず、階層の異なる多様なレベルのプロトコルを介して行われ、これらの相互関係がIPの下で動作するパケットデータ通信中におけるデータパケットの処理について大まかに説明する。
【0025】
ネットワーク通信の技術において、プロトコルは、国際標準化機構(ISO)と国際電信電話諮問委員会(ITU−T)が説明しているとおりの開放型システム間相互接続(OSI)モデルに従って階層化される。この目的は、マルチベンダ設備相互使用可能性の促進である。即ち、各レベルのプロトコル階層には独自の仕様がある。そのため、特定の階層レベルの仕様が満たされる限り、このレベルにおける製品の開発が別レベルの他の製品と互換することが保証される。
【0026】
図3は階層順序に並んだプロトコルのスタックを概略的に示しており、これは一般に「プロトコルスタック」と呼ばれ、この図では参照符号72を付している。IPプロトコルスタック72は、OSIモデルと類似するが完全に同一ではないインターネット技術標準化タスクフォース(IETF)モデルと一致した構造を有する。IETFモデルに従って、IPプロトコルスタック72は、層1〜5までの5つの層を有する。そのため、ノードから送信されたデータパケット、例えば図2に示すノード48や50は、プロトコルスタッック72で処理しなければならない。プロトコル72のスタックは、ソフトウェアまたはハードウェア、あるいはこれらの組み合わせの形式のノード内に構築される。同様に、同一のノードによって受信されたデータパケットは、同一のプロトコルスタック72を介し、逆の順序で処理されなければならない。
【0027】
一例を挙げて例証を行う。データパケットをノード、例えばノード48(図2)から送信するように処理する場合、このデータパケットはまず、例えば層5のようなアプリケーション層内のプロトコルの1つに従って作成される。層5は、ハイパーテキスト転送プロトコル(HTTP)、サービスメール転送プロトコル(SMTP)、ファイル転送プロトコル(FTP)、リアルタイム転送プロトコル(RTP)、1方向移送/非同期層符号化上でのファイル送達(FLUTE/ALC)プロトコルを含む。さらに、データパケットはVoIP(ヴォイスオーバ・インターネットプロトコル)セッションの積であると仮定する。そのため、層5内で、データパケットをRTPに従ってフォーマットする必要がある。
【0028】
例えば層5内のRTPによって生じたデータパケットのような、時間に敏感なデータパケットは、リアルタイムで処理する必要がある。詳細には、通常、欠陥パケットは再送信されず、他の接近中のデータパケットの伝送を妨害することがないよう単純にドロップされる。そのため、RTPデータパケットは、通常、移送層である層4内のユーザデータパケットプロトコル(UDP)を介して運ばれる。したがって、層5内のRTPからのデータパケットは、層4内のUDPに従って公式化される。
【0029】
一方、データパケットが層5内の別のプロトコル、例えばFTPから発生している場合には、通常、このデータパケットは層4内の移送制御プロトコル(TCP)を介して送信される。TCPの下では、データパケットの正確な送達は最も重要である。そのため、全体のデータ伝送処理が遅速化する可能性があっても、欠陥パケットは常に再送信される。
【0030】
この移送層である層4を通過したデータパケットには、セキュアポート番号や宛先ポート番号のような情報が追加される。
【0031】
移送層である層4を通過するデータパケットは、次に、処理のためにネットワーク層である層3へ送信される。この特定の場合には、層4から生じたデータパケットに、データパケットのソースアドレスと宛先アドレスを追加した状態にし、さらに、IPに従って再びフォーマットする必要がある。
【0032】
その後、データパケットをフレーム化して、リンク層である層2内に適したプロトコルに適合させる。電気電子学会(Institute of Electrical and Electronics Engineers)(IEEE)発行の文書第IEEE802.3で説明されているように、例えば、イーサーネット(登録商標)を介してサーバノード48をネットワークに接続した場合には、層2はイーサネット(登録商標)プロトコル形式となる。
【0033】
図5中のプロトコルスタック72の最下層は、物理層である層1であり、この層はデータパケットの送信を物理的に実現する。例えば、図2では、ノード48とネットワーク42の間の通信リンクが従来の有線リンクである場合に、物理層である層1は、両ノード48上のハードウェア回路とネットワーク42の物理インターフェース回路に関連する。ノード50とBS66Aの間の通信リンクがエアーインターフェースである場合には、図2の別の例のようになる。この場合は、物理層である層1は、エアースペースと、このエアースペースを介して信号のやり取りを行うRAN52のハードウェア回路とに関連する。
【0034】
次に再び図3を参照する。例証的なノード50が受信したデータパケットの場合(図2)、データパケットは同じプロトコルスタック72を介して処理されるが、しかしこの場合には、層1から層5の逆の順序で処理されなければならない。
【0035】
次に、システム40における例証的なブロードキャスト処理の動作について説明する。図2では、先述したように、ノード48、即ちBSDが、加入者にブロードキャストサービスを提供するサービスプロバイダによってネットワーク42にインストールされる。この場合、ノード50はこうした加入者の1人である。例えばこの場合、ノード50は別のネットワークからネットワーク44へのローミングであってよく、ネットワーク42を動作しているサービスプロバイダより入手可能な夜7時のニュースのようなニュースクリップのアクセスをシークすることができる。
【0036】
ネットワーク44がブロードキャストサービスをサポートする場合には、ネットワーク44には利用可能なサービスのブロードキャストチャネルが設けられていることが多い。利用可能なサービスの情報は、ダウンロード可能なファイル形式で編成できる。あるいは、この情報を、リアルタイム・ビューイング可能なデータの一定のストリームの形式で表すこともできる。
【0037】
この例証的な実施形態では、無線通信における多様な標準を統一する目的で、サービスプロバイダ、ハードウェアおよびソフトウェアベンダ、ネットワークオペレータその他を含む無線業界の様々な実体の共同体であるオープン・モバイル・アライアンス(OMA)が公表したブロードキャストサービス案内(SG)と類似した方法で、利用可能な複数のサービスをダウンロード可能なファイルとしてグループ化するものとする。SGの詳細は、OMAより発行の文書OMA−TS−BCAST−ServiceGuide−V1.〜@#$@@`で説明されている。
【0038】
これまで、ノード50のユーザは、ネットワーク44内にある場合、利用可能なサービスについてSGを参照する必要があった。このために、ネットワーク44からSGをダウンロードしなければならない。次に、ノード50のユーザはシークしたサービスをSGから選択して、このサービスを装備しているチャネルがSGに提供された時にこれに同調する。
【0039】
例えば音楽のダウンロードのようないくつかのサービスでは、ノード50のユーザはシークしたファイルを最初にダウンロードし、後にこのファイルを楽しむことができる。ニュースブロードキャストセッションのような別のサービスでは、シークしたファイルのコンテンツがダウンロードされ、これとほぼ同時に表示される。これは即ち、シークしたサービスと、このサービスに関連したファイルのダウンロードとがリアルタイムに提示されるということである。こうしたアプローチにはいくつか欠点がある。これはとりわけ、ファイルコンテンツの連続提示が、コンテンツ自体のダウンロードの成功のみでなく、コンテンツファイルの処理に必要なファイル属性のダウンロードの成功にも依存することによる。こうした依存性によって遅延が生じるのは不可避であり、また多くの場合、コンテンツ提示に関連したユーザの経験に悪影響を及ぼす。これに加え、信頼性の高いデータパケットの受信度を高めるために、通常は冗長データが送信される。この結果、以降でさらに説明している利用可能な通信リソースの最も効率的な使用が得られなくなる可能性がある。
【0040】
シークしたサービスのファイルのコンテンツが、FLUTE/ALCプロトコルを介して移送されるとする。正確なデータ移送を確実に得るために、従来は、FLUTE/ALCプロトコルと共にカルーセルファイル配信(CFD)方法が使用された。図3AはFLUTE/ALCプロトコルのより詳細な概略図を示している。これについては以降でより詳細に説明する。図4は、FLUTE/ALCプロトコルの下で動作するCFDスキームの方法論を示している。
【0041】
図4では、ファイルを参照符号74で表している。1片のマルチメディアコンテンツ、この例では例えばニュースクリップが、複数のファイルを備えていてよい。ファイル74内では、各ALCデータパケットがデータパケット#1〜#5の1つで表されている。確ファイル74の送達には、ファイル送達テーブル(FDT)78を設け、やはりALCプロトコル形式で構成されたALCデータパケットが関連している。
【0042】
FDT78には、データパケット#1〜#5の復号化に必要な多様なパラメータまたは属性が含まれている。こうしたパラメータは、ファイル名、ファイル識別(ID)、ファイルのソース場所(即ちURI)、表示時間、ファイルサイズ、コンテンツタイプ、符号化スキーム、転送エラー修正(FEC)タイプとFEC関連のパラメータ、さらに、適切であればセキュリティ関連のパラメータを備えていてよいが、しかしこれらのパラメータに限定されるものではない。
【0043】
CFD方法ではファイルは複数回伝送される。この例では、ファイル74はコンテンツパケット#1〜#5と、これに関連するFDT78とを含んでおり、第1パス73において1回目、次に第2パス75において2回目の伝送が実行される。第1パス73では、FDT78がコンテンツパケット#1〜#5よりも先に伝送される。第2パス75では、これと同一のFDT78が、コンテンツパケット#1〜#5の最後に伝送される。
【0044】
各ファイルを繰り返し伝送する1つの目的は、全ての受信者が確実に同じ時間にファイルを受信する必要を排除することである。即ち、ファイル受信のために受信者を同期する必要はない。
【0045】
各ファイルを繰り返し伝送する別の目的は、FECスキームがインストールされていない場合、あるいは、たとえインストールされていてもFEC機構の動作が失敗した場合に、データ移送中の正確性を確実にすることである。この目的は、CFD方法を、図4に示すシナリオA、B、Cと識別される3つのシナリオを包括するように設計することで達成される。この3つのシナリオA、B、C以外にも、失敗したファイルのダウンロードの宣言を行える。
【0046】
シナリオAでは、ノード50がファイル74のダウンロードを試みると仮定する。第1パス73の最中に、ノード50はFDT78の受信に成功する必要がある。第1パス73におけるFDT78のダウンロードがエラーなく成功する。次に、ノード50が後続のデータパケット#1〜#5を受信する。第1パス73において、データパケット#1〜#5全てのダウンロードも成功したと想定する。ファイル74全体を組み立てるために、ノード50は、第1パス73からダウンロードしたFDT78内の情報を使用して、全てのパケット#1〜#5内のデータを復号化することができる。
【0047】
シナリオBでは、第1パス73でのファイル74のダウンロードの最中に、FDTパケット78の取り出しが成功したと仮定する。第1パス内での、#3を除いた全てのコンテンツパケット#1〜#5の取り出しも成功したとする。実現されたFEC機構は機能しないと仮定する。この場合ノード50は、第1パス73において受信した関連する欠陥パケット#3を補正するために、第2パス75の最中に、第2パス75が同一のデータパケット#3を受信するまで待つ必要がある。その後、ノード50は、ファイル74を再構築するために、第1パスから入手したFDT78からの情報を使用して、全てのデータパケットを復号化することができる。
【0048】
シナリオCでは、全てのデータパケット#1〜#5が第1パス73内に正確にダウンロードされるが、ノードはFDT78を第1パス73内に正確に受信することができない。この場合には、ノード50は、第1パス73からの誤ったFDT78を補正して、ファイル74の全てのデータパケットを正確に復号できるよう、第2パス75が関連のFDT78を取り出すまで待たなくてはならない。
【0049】
望ましくない信号受信条件の下では、上のシナリオA、B、Cの部分で説明したFECの一番最初に追加のステップを実行しても、エラーのあるデータを修正することはできない可能性がある。すなわち、先に述べたように、ファイル74のダウンロードは失敗と宣言される可能性がある。シナリオBでは、データパケット#3が損失しても、表示中のファイル74の品質にしか影響が及ばないことがある。しかし、シナリオCでは、FDT78がなければファイル74全体の処理ができないため、FDT78の取り出しの失敗によってファイル74全体が損失しかねない。この場合には、ノード50は、次のカルーセル周期まで待つ必要がある。この周期は、後にFDT78取得の別の機会を得るだけのために、時間パス73、75で延長された期間のように非常に長くなる可能性がある。この場合には、さらなる時間の遅延と、通信チャネルの固定が不可避となる。この例のようにデバイス50が移動体装置である場合は、時間遅延の増加はデバイス50の電池の電力消費増加につながる。移動通信では、電池寿命の維持が非常に重要である。
【0050】
本発明の例証的な実施形態によれば、FDTとコンテンツデータパケットは、従来実施されていたようにインバンド方式で受信されない。代わりに、ファイル属性とコンテンツデータがアウトオブバンド方式で受信される。これについては以降で説明する。
【0051】
これ以降では、用語「インバンド方式」は、伝送チャネルを介し、さらに実質的に同一の伝送セッション内での情報の移送を意味するものとして解釈される。インバンド方式の情報移送の一例は、図4の伝送工程に図示し、説明しているとおりのものである。一方、用語「アウトバンド方式」は、図5に図示し、以降で説明する伝送工程によって例証されるように、こうした移送が同一の伝送チャネルを介して行われるか、あるいは別の伝送チャネルを介して行われるかに関係なく、多様な伝送セッションを介して、情報の移送を意味するものとして解釈される。
【0052】
次に図5を参照する。この実施形態では、データパケット#1〜#5のようなペイロードデータと比較して、先に述べたFDT78に含まれているファイル属性のようなファイル属性82が別々に、即ち、インバンド方式ではなくアウトバンド方式で送信される。
【0053】
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のダウンロードの成功によって決まってしまう状況を回避できる。
【0054】
伝送工程中の第1パス85において、図5の参照符号90で示す欠陥のあるデータパケット、例えばデータパケット#4がファイル84内に見付かり、さらに、インストールされたFEC機構ファイルがこの欠陥パケット#4を修正すると仮定した場合には、第2パス87内の関連するデータパケット#4を取り出して修復することができる。修復工程が失敗した場合には、表示中のファイル84に特定の品質劣化が生じる可能性がある。しかし、図4に示し、上述したような失敗したシナリオCでの状況が生じることは絶対にない。これの理由は、先述したように、先の通信セッション81の最中にFA82の受信が成功しているためである。
【0055】
上述した方法で動作する場合には、FDTの伝送用としてインバンドチャネルを固定する必要はない。そのため、コンテンツファイルの取り出しをより高い確実性にて行える。ファイル取得時間も実質的に短縮することができる。この結果、通信チャネル間のふくそうが容易化されるため、利用可能な通信リソースをより効率的に使用できるようになる。さらに、ノード50(図2)が移動体装置である場合には、ファイル取得時間が短いことは、コンテンツファイルのダウンロード中に、ノード50の電池の起動に要する時間が短くて済むことを意味する。したがって、電池電力を温存できる。
【0056】
図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内で定期的に更新することができる。
【0057】
先述したように、最初にいくつかのファイルをダウンロードしておき、後でユーザが選択した時間に実行することが可能である。この例には、音楽ファイルやソフトウェア更新用ファイルがある。最初にダウンロードしておくことができるが、しかし、特定の時間に表示させることが好ましいファイルもある。これの一例には、以下で説明するニュースブロードキャストセッションがある。いずれの場合でも、本発明の別の態様に従って、コンテンツファイルの取得および表示は同時に実行される必要はない。代わりに、ファイル取得をファイル表示工程前に別個に実行することができる。
【0058】
説明を簡単にするために、より具体的な例を例証する。次に再び図2を参照する。この例では、ノード50のユーザが、通常午後7時に、標準テレビブロードキャストを介して利用できるニュースブロードキャストを視聴したいと仮定する。ネットワーク44によってブロードキャストされたSG内では、これに関連した、午後7時のニュースクリップに関する情報が通常利用可能である。ネットワーク44は、ネットワーク42をバックボーンネットワーク46を介して提供しているサービスから取得した情報を有する。SG内では、2つの時間ウィンドウ、即ち「配信ウィンドウ(DW)」と「表示ウィンドウ(PW)」が指定される。図6はこうした配列を示す。
【0059】
DW内では時間ウィンドウが指定される。この時間ウィンドウ内では、午後7時のニュースセッションのファイルを受信するために、ノード50が起動される必要がある。時間ウィンドウは、この例においては例えば午後5時〜午後6時半であり、これは、ニュースファイルを受信するためにノード50の電源がオンにされる時間間隔である。一方、PWは、例えば午後7時〜午後7時半の間にダウンロードしたニュースセッションの表示時間を識別した。これは即ち、この時間スパン中に、ダウンロードしたファイルが午後7時のニュースとして表示されるということである。DWをPWから分離することの追加的利点に、加入者が、表示時間以前にファイルをダウンロードできるため、通常、ピーク時間帯にぶつかってしまう表示時間中におけるトラヒックチャネルの過負荷を回避できるということがある。DW中にネットワーク44内のトラヒック負荷が混雑している場合でも、それぞれのファイルダウンロードを受信側の受信機内へ少量ずつ行い、PWが開始する前に都合よく完了することができる。
【0060】
ノード50は、SGが提供した情報に基づいて、ニュースクリップを受信するために、午後5時25分〜午後5時37分の期間中に電源オンにされ、起動されると仮定する。適切なファイル圧縮技術を実現した場合、ダウンロードに要する時間はこの例では12分間であり、表示時間(この場合は30分間)よりも短い。
【0061】
前述のノード50のための方法を図7のフローチャートに示す。図8は、ネットワーク44によって実行されるこれと関連した方法である。
【0062】
本発明のさらに別の態様では、ペイロードデータの移送をさらにストリームライン化することができる。
【0063】
ファイルコンテンツをダウンロードするために、FLUTE/ALCプロトコルを採用できる。先述したように、データパケットがTCP移送層(図3)を介して移送されるFTPとは異なり、FLUTE/ALC内のデータパケットがUDP移送層へ運ばれる。伝送工程全体は遅速化するが、FTPはより1対1のアプリケーションへと調整され、エラーが生じたパケットも正常に再伝送される。UDPを介して運ばれるFLUTE/ALCプロトコルは、マルチキャストまたはブロードキャストアプリケーションに適するように設計される。エラーの生じたデータは正常に伝送されない。その代わりに、適切な転送エラー修正(FEC)スキームを採用することにより、データ伝送におけるエラーが縮小される。
【0064】
次に、参照符号96で全体的に表されるFLUTE/ALCプロトコルを示した図3Aを参照する。FLUTEプロトコルのパケットはALCプロトコルによって運ばれることで移送される。ALCプロトコルについては、2002年12月にIETFより発行された刊行物RFC3450「非同期層符号化(ACL)プロトコルの例示(Asynchronous Layered Coding (ALC) Protocol Instantiation))」」」」)で説明されている。ALCプロトコルは、マルチキャスト移送に提案された基本プロトコルの1つである。ALCが関与するデータ移送ではアップリングシグナリング、即ち受信機から送信機へのシグナリングが不要であり、信頼性の高いデータ取り出しを行うためにFECの使用が採用されている。ALCはまた、マルチレートふくそう制御(CC)97に階層型符号移送(Layered Coding Transport)(LCT)ビルディングブロック98を利用し、さらに、信頼性の高いコンテンツ送達のためにFECビルディングブロック99を利用する。LCTについては、2002年12月にIETFより発行された刊行物、RFC3451「階層型符号化移送(LCT)ビルディングブロック(Layered Coding Transport (LCT) Building Block)」にて説明されている。FECは、やはりIETFから発行されたRFC3453で説明されている。
【0065】
FLUTEプロトコルは、マルチキャストファイル送達へのALCの適用を表す。しかし、従来のFLUTE/ALCプロトコルは主に非移動環境用として設計されている。電池電力を温存する必要があり、エアーリンク帯域幅が貴重である無線環境では、ファイルダウンロード工程をさらにストリームライン化することが可能である。この目的を達成するために、ペイロード内の各データパケットをよりコンパクトに設計することができる。
【0066】
図9は、参照符号94で表されたコンパクトなALCデータパケットの一例を示しており、このALCデータパケットは、RFC3450に明記されているとおりの従来のALCパケットにより従うようにフォーマットされている。ALCパケットフォーマット94は、3GPP2が刊行文書3GPP TS 23.346で公表したブロードキャスト/マルチキャストサービス(MBMS)と同一になるように設計されている。データパケット84内に示されているフォーマットと文書3GPP TS 23.346に明記されたフォーマットとの主な違いは、ファイル記述情報のインバンド伝送が全くない、即ち、データパケット94のペイロードを処理するために必要なファイル属性が全くないことである。
【0067】
図10は、別の例証的なコンパクトなパケットフォーマットを参照符号96で示している。データパケット96は実質的にストリームライン化され、無線通信環境での使用に好適となる。とりわけ、ふくそう制御情報を設けずに済むようになる。無線環境と同様に、無線媒体は唯一のアクセス手段であり、異なるデータ速度での複数のアクセス手段を規制するふくそう制御が不要となる。図9に示すデータパケット94では、過負荷は16バイトである。図10に示すデータパケット96の場合には、過負荷はたった8バイトである。
【0068】
図11は、本発明の例証的な実施形態による、例えば図2のノード50のような装置のハードウェア実現の部分を概略的に示している。このハードウェア実現部分には参照符号100を付している。装置100は、例えば数例としてラップトップコンピュータ、PDA、携帯電話のような多様な形式で構築および組込むことができる。
【0069】
装置100は、数個の回路を繋ぐ中央データバス102を備えている。これらの回路はCPU(中央処理装置)または制御装置104、受信回路106、送信回路108、メモリユニット110を含んでいる。
【0070】
装置100が無線装置の一部である場合には、受信回路106と送信回路108を無線周波数(RF)回路に接続することができるが、これは図示していない。受信回路106は、受信した信号を、データバス102へ送信する前に処理およびバッファリングする。一方、送信回路108は、データバス102からのデータを、装置100へ送信する前に処理およびバッファリングする。CPU/制御装置104は、データバス102のデータ管理機能と、さらに、メモリユニット110の命令コンテンツの実行を含む汎用データ処理機能とを実施する。
【0071】
送信回路108と受信回路106を、図11に示すように別個に配置するのではなく、代替形としてCPU/制御装置104の一部とすることができる。
【0072】
メモリユニット110は、全体を参照符号101で示した1組の命令を含んでいる。この実施形態において、これらの命令は、とりわけ上述のFULTE/ALCプロトコルを処理することができるプロトコルスタック機能112のような部分を含んでいる。この1組の命令はまた、図7に図示し説明したような方法の実行が可能なブロードキャストクライアント機能114を含んでいる。
【0073】
この実施形態では、メモリユニット110はRAM(ランダムアクセスメモリ)回路である。例証的な命令部分112、114は、ソフトウェアルーチンまたはモジュールである。メモリユニット110は、揮発性または非揮発性タイプのいずれかであってよい別のメモリ回路(図示せず)に連結することができる。これの代替形として、メモリユニット110を他の回路タイプ、EEPROM(電気的に消去できるプログラム可能な読み出し専用メモリ)、EPROM(電気的にプログラム可能な読み出し専用メモリ)、ROM(読み出し専用メモリ)、ASIC(特定用途向け集積回路)、磁気ディスク、光学ディスク、また技術上よく知られているこれ以外のものによって作成することが可能である。
【0074】
図12は、図2に示したBSN装置70のようなブロードキャストサーバのハードウェア実現の部分を、参照符号120を付して概略的に示す。この装置120は、数個の回路を繋ぐ中央データバス122を備えている。これらの回路はCPU(中央処理装置)または制御装置124、受信回路126、送信回路128、データベース格納ユニット129、メモリユニット131を含んでいる。
【0075】
受信回路126、送信回路128は、装置120が繋がれたネットワークデータバス(図示せず)に接続できる。受信回路126は、ネットワークデータバス(図示せず)から受信した信号を、内部データバス122へルーティング前に、処理およびバッファリングする。送信回路128は、データバス122からのデータを、装置120へ送出する前に、処理およびバッファリングする。あるいは、送信回路128と受信回路126を総体的にインターフェース回路と呼ぶこともできる。CPU/制御装置124は、データバス122のデータ管理の任務と、メモリユニット131の命令コンテンツの実行を含む汎用データ処理機能委の任務を実施する。データベース格納ユニット129は、様々なパラメータとコンテンツファイルを含んだSGのようなデータを格納する。
【0076】
メモリユニット131は、参照符号121で全体的に示す1組の命令を含んでいる。この実施形態では、命令は、とりわけプロトコルスタック132およびブロードキャストホスト134の部分を含む。メモリユニット131は、上述したメモリ回路タイプで作成されているため、これ以上の説明の繰り返しは省略する。プロトコルスタック121およびブロードキャストホスト134のための機能は、図3、図8に示し、先述したような本発明による命令の組を含んでいる。
【0077】
さらに、図7、図8に示し、上述した工程を、技術上周知のあらゆるコンピュータ読み出し媒体上に収容されるコンピュータ読み出し可能な命令として符号化することも可能である点に留意されたい。本明細書および添付の請求項において、用語「コンピュータ読み出し可能な媒体」とは、それぞれ図11、図12に図示し説明したCPU/制御装置104、124のような任意のプロセッサに命令を提供し、実行する際に関与するあらゆる媒体を意味する。こうした媒体は、格納タイプのものであってよく、また、例えばそれぞれ図11、図12のメモリユニット110、131の記述において先述したような揮発性あるいは非揮発性の格納媒体の形態であってよい。このような媒体は伝送タイプであってもよく、また、同軸ケーブル、銅線、光ケーブルや、さらに、マシンまたはコンピュータによって読み出し可能な信号を運べる音響波あるいは電磁波を伝達するエアーインターフェースを含んでいてよい。
【0078】
最後に、この実施形態で説明したように、ノード、即ちBSD48は、サービスプロバイダのネットワーク42にインストールされたものとして記述されている。しかし、常にこの限りでなくてもよい。BSD48を、サービスプロバイダが所有しているものではない別のネットワークにインストールすることも可能である。さらに、例証的な実施形態で説明したアウトオブバンド伝送チャネルを、拡散スペクトル通信の技術において一般的に実施されるように論理的または物理的に区別することができる。これに加え、多種のアウトオブバンドセッションを、前述した時間分離ではなく異なるポート番号によって識別することもできる。そのため、例えば図5では、FDTを、第1送信セッションに関連した1つの宛先ポートを介して、層4のUDP(図3)上で伝送できる。また、第2伝送セッション中に、コンテンツファイルを、別の宛先ポート番号を介し、層4のUDP上で伝送することが可能である。これに加え、図7、図8のフローチャートが、音楽ファイルのようなファイルをユーザの選択でダウンロードおよび実行するためにも適用できる点を明白にしておくべきである。例えば、ユーザはSGからファイルを拾い集め、自分のファイル配信ウィンドウおよびファイル表示ウィンドウ上で決定を行うことができる。さらに、例証的な実施形態では、バックボーンネットワークはIPの下で動作されると説明している。IP以外のプロトコルの使用も可能である。例えば、FLOネットワークでは、FLOフォーラム(FLO Forum)が発行したfloforum2005.001の文書「FLOエアーインターフェース仕様書(FLO Air Interface Specification)」によるプロトコルの適用が可能である。FLOネットワークでは、SGではなく、関連する属性をシステム情報(SI)に入れることができる。これについての詳細は、FLO Forumが発行した文書floforum2006.005を参照できる。これに加え、本発明に関連して説明した論理ブロック、回路、アルゴリズムステップを、ハードウェア、ソフトウェア、ファームウェア内、あるいはこれらの組み合わせにおいて実現することができる。当業者は、本発明の範囲と精神から逸脱しない限り、形態および詳細に、ここで説明した変更やその他の変更を加えられることを理解するだろう。
【特許請求の範囲】
【請求項1】
通信システム内でブロードキャストのファイルをダウンロードする方法であって、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信することと、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信することと、
を備える方法。
【請求項2】
第1通信チャネルを介して前記ファイル属性を受信することと、
前記少なくとも1つのファイルを第2通信チャネルを介して受信することと、
を備える、請求項1に記載の方法。
【請求項3】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記方法はさらに、
前記ファイル属性を、第1ポート番号によって前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと、
前記少なくとも1つのファイルを、第2ポート番号によって前記IPの前記UDPを通して受信することと、
を備える、請求項1に記載の方法。
【請求項4】
前記第2通信セッション内で、前記ブロードキャストのために複数のファイルを連続的に受信することと、前記第2通信セッションよりも前の前記第1通信セッション内で前記複数のファイルを処理するために、前記ファイル属性を受信することとをさらに備える、請求項1に記載の方法。
【請求項5】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法はさらに、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を受信しないことを備える、請求項1に記載の方法。
【請求項6】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信することを備え、前記複数のファイルを処理するために前記複数のファイル間で共用される前記ファイル属性のいくつかを使用して、前記複数のファイルを処理することをさらに備える、請求項1に記載の方法。
【請求項7】
前記少なくとも1つのファイルを所定の時間に表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための前記ファイル属性時間情報を提供することをさらに備える、請求項1に記載の方法。
【請求項8】
通信システムにおけるブロードキャストのファイル送達方法であって、前記方法は、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを表示するためのファイル属性を送信することと、
第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信することと、
を備える方法。
【請求項9】
前記ファイル属性を第1通信チャネルを介して送信することと、
前記少なくとも1つのファイルを第2通信チャネルを介して送信することと、
をさらに備える、請求項8に記載の方法。
【請求項10】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記方法はさらに、
前記ファイル属性を、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して送信することと、
前記少なくとも1つのファイルを、第2ポート番号を介し、前記IPの前記UDPを通して送信することと、
を備える、請求項8に記載の方法。
【請求項11】
前記第2通信セッションにおいて、前記ブロードキャスト用に複数のファイルを連続して送信することと、前記第2通信セッションよりも前の前記第1通信セッションにおいて、前記複数のファイルを処理するために、前記ファイル属性を送信することとをさらに備える、請求項8に記載の方法。
【請求項12】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法は、前記少なくとも1つのファイルを処理するために、前記各データパケット内にファイル属性を提供しないことをさらに備える、請求項8に記載の方法。
【請求項13】
さらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信することと、またさらに、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供することとを備える、請求項8に記載の方法。
【請求項14】
前記ブロードキャストの前記少なくとも1つのファイルを表示するための、前記ファイル属性時間情報をさらに備える、請求項8に記載の方法。
【請求項15】
通信システム内でブロードキャストを受信するように構成された装置であって、前記装置は、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信する手段と、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する手段と、
を備える装置。
【請求項16】
第1通信チャネルを介して前記ファイル属性を受信する手段と、
第2通信チャネルを介して前記少なくとも1つのファイルを受信する手段と、
をさらに備える、請求項15に記載の装置。
【請求項17】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記装置はさらに、
第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を受信する手段と、
第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信する手段と、
を備える、請求項15に記載の装置。
【請求項18】
前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信する手段とをさらに備える、請求項15に記載の装置。
【請求項19】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記各データパケットは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項15に記載の装置。
【請求項20】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信する手段をさらに備え、前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して、前記複数のファイルを処理するための手段をさらに備える、請求項15に記載の装置。
【請求項21】
前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項15に記載の装置。
【請求項22】
通信システムにおいてブロードキャストのファイルを送達する装置であって、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を送信する手段と、
第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信する手段と、
を備える装置。
【請求項23】
第1通信チャネルを介して前記ファイル属性を送信する手段と、
第2通信チャネルを介して前記少なくとも1つのファイルを送信する手段と、
をさらに備える、請求項22に記載の装置。
【請求項24】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記装置はさらに、
第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を送信する手段と、
第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信する手段と、
を備える、請求項22に記載の装置。
【請求項25】
前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を送信する手段とをさらに備える、請求項22に記載の装置。
【請求項26】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記装置は、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を提供しない手段をさらに備えている、請求項22に記載の装置。
【請求項27】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信する手段をさらに備え、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供する手段をさらに備える、請求項22に記載の装置。
【請求項28】
前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項22に記載の装置。
【請求項29】
通信システム内のブロードキャストにおいて使用される装置であって、前記装置は、 プロセッサと、
前記プロセッサに結合したメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを含む装置。
【請求項30】
前記メモリユニットは、前記第1通信チャネルを介して前記ファイル属性を受信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して受信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項29に記載の装置。
【請求項31】
前記通信システムは、インターネットプロトコル(IP)をサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項32】
前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャスト 用に複数のファイルを連続的に受信するための、及び前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信するためのコンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項33】
前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項29に記載の装置。
【請求項34】
前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信するための、及び前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して前記複数のファイルを処理するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項35】
前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項29に記載の装置。
【請求項36】
通信システムにおいてブロードキャストのファイルを送達する装置であって、前記装置は、
プロセッサと、
前記プロセッサに結合されたメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて前記ブロードキャストの前記少なくとも1つのファイルを前記ファイル属性とは別に送信するための、コンピュータ読み出し可能な命令と、
を備える装置。
【請求項37】
前記メモリユニットはさらに、前記ファイル属性を第1通信チャネルを介して送信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。
【請求項38】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を、送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。
【請求項39】
前記メモリユニットは、前記IPの前記UDPと結合した前記IPの1方向移送上でのファイル送達(FLUTE)とを通して少なくとも1つのファイルを送信するためのコンピュータ読み出し可能な命令をさらに備える、請求項36に記載の装置。
【請求項40】
前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信するための、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための前記ファイル属性を送信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。
【請求項41】
前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含まない、請求項36に記載の装置。
【請求項42】
前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信するための、前記第1通信セッションにおいて前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。
【請求項43】
前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項36に記載の装置。
【請求項44】
コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体であって、前記命令は、
第1通信セッションにおいてブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信する命令と、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する命令と、
であるコンピュータ読み出し可能な媒体。
【請求項45】
第1通信チャネルを介して前記ファイル属性を受信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令をさらに備える、請求項44に記載のコンピュータ読み出し可能な媒体。
【請求項46】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記コンピュータ読み出し可能な媒体は、
第1ポート番号を介して、前記IPのユーザデータグラムプログラム(UDP)を通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令
をさらに備える、請求項44に記載のコンピュータ読み出し媒体。
【請求項47】
第1通信セッションにおいて、ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体。
【請求項48】
第1通信チャネルを介して前記ファイル属性を送信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。
【請求項49】
第1ポート番号を介して、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。
【請求項1】
通信システム内でブロードキャストのファイルをダウンロードする方法であって、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信することと、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信することと、
を備える方法。
【請求項2】
第1通信チャネルを介して前記ファイル属性を受信することと、
前記少なくとも1つのファイルを第2通信チャネルを介して受信することと、
を備える、請求項1に記載の方法。
【請求項3】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記方法はさらに、
前記ファイル属性を、第1ポート番号によって前記IPのユーザデータグラムプロトコル(UDP)を通して受信することと、
前記少なくとも1つのファイルを、第2ポート番号によって前記IPの前記UDPを通して受信することと、
を備える、請求項1に記載の方法。
【請求項4】
前記第2通信セッション内で、前記ブロードキャストのために複数のファイルを連続的に受信することと、前記第2通信セッションよりも前の前記第1通信セッション内で前記複数のファイルを処理するために、前記ファイル属性を受信することとをさらに備える、請求項1に記載の方法。
【請求項5】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法はさらに、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を受信しないことを備える、請求項1に記載の方法。
【請求項6】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信することを備え、前記複数のファイルを処理するために前記複数のファイル間で共用される前記ファイル属性のいくつかを使用して、前記複数のファイルを処理することをさらに備える、請求項1に記載の方法。
【請求項7】
前記少なくとも1つのファイルを所定の時間に表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための前記ファイル属性時間情報を提供することをさらに備える、請求項1に記載の方法。
【請求項8】
通信システムにおけるブロードキャストのファイル送達方法であって、前記方法は、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを表示するためのファイル属性を送信することと、
第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信することと、
を備える方法。
【請求項9】
前記ファイル属性を第1通信チャネルを介して送信することと、
前記少なくとも1つのファイルを第2通信チャネルを介して送信することと、
をさらに備える、請求項8に記載の方法。
【請求項10】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記方法はさらに、
前記ファイル属性を、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して送信することと、
前記少なくとも1つのファイルを、第2ポート番号を介し、前記IPの前記UDPを通して送信することと、
を備える、請求項8に記載の方法。
【請求項11】
前記第2通信セッションにおいて、前記ブロードキャスト用に複数のファイルを連続して送信することと、前記第2通信セッションよりも前の前記第1通信セッションにおいて、前記複数のファイルを処理するために、前記ファイル属性を送信することとをさらに備える、請求項8に記載の方法。
【請求項12】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記方法は、前記少なくとも1つのファイルを処理するために、前記各データパケット内にファイル属性を提供しないことをさらに備える、請求項8に記載の方法。
【請求項13】
さらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信することと、またさらに、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供することとを備える、請求項8に記載の方法。
【請求項14】
前記ブロードキャストの前記少なくとも1つのファイルを表示するための、前記ファイル属性時間情報をさらに備える、請求項8に記載の方法。
【請求項15】
通信システム内でブロードキャストを受信するように構成された装置であって、前記装置は、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を受信する手段と、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する手段と、
を備える装置。
【請求項16】
第1通信チャネルを介して前記ファイル属性を受信する手段と、
第2通信チャネルを介して前記少なくとも1つのファイルを受信する手段と、
をさらに備える、請求項15に記載の装置。
【請求項17】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記装置はさらに、
第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を受信する手段と、
第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信する手段と、
を備える、請求項15に記載の装置。
【請求項18】
前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に受信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信する手段とをさらに備える、請求項15に記載の装置。
【請求項19】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記各データパケットは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項15に記載の装置。
【請求項20】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信する手段をさらに備え、前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して、前記複数のファイルを処理するための手段をさらに備える、請求項15に記載の装置。
【請求項21】
前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項15に記載の装置。
【請求項22】
通信システムにおいてブロードキャストのファイルを送達する装置であって、
第1通信セッションにおいて、前記ブロードキャストの少なくとも1つのファイルを処理するためにファイル属性を送信する手段と、
第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを送信する手段と、
を備える装置。
【請求項23】
第1通信チャネルを介して前記ファイル属性を送信する手段と、
第2通信チャネルを介して前記少なくとも1つのファイルを送信する手段と、
をさらに備える、請求項22に記載の装置。
【請求項24】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記装置はさらに、
第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を送信する手段と、
第2ポート番号を介し、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信する手段と、
を備える、請求項22に記載の装置。
【請求項25】
前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信する手段と、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を送信する手段とをさらに備える、請求項22に記載の装置。
【請求項26】
前記少なくとも1つのファイルは複数のデータパケットを含んでおり、前記装置は、前記少なくとも1つのファイルを処理するための、前記各データパケット内にファイル属性を提供しない手段をさらに備えている、請求項22に記載の装置。
【請求項27】
前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信する手段をさらに備え、前記第1通信セッションにおいて前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供する手段をさらに備える、請求項22に記載の装置。
【請求項28】
前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備えている、請求項22に記載の装置。
【請求項29】
通信システム内のブロードキャストにおいて使用される装置であって、前記装置は、 プロセッサと、
前記プロセッサに結合したメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に前記ブロードキャストの前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを含む装置。
【請求項30】
前記メモリユニットは、前記第1通信チャネルを介して前記ファイル属性を受信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して受信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項29に記載の装置。
【請求項31】
前記通信システムは、インターネットプロトコル(IP)をサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項32】
前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャスト 用に複数のファイルを連続的に受信するための、及び前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための、前記ファイル属性を受信するためのコンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項33】
前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含んでいない、請求項29に記載の装置。
【請求項34】
前記メモリユニットはさらに、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを受信するための、及び前記複数のファイルを処理するために前記複数のファイル間で共用されている前記ファイル属性のいくつかを使用して前記複数のファイルを処理するための、コンピュータ読み出し可能な命令とを備える、請求項29に記載の装置。
【請求項35】
前記ファイル属性は、所定の時間に前記少なくとも1つのファイルを表示できるようにするために、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項29に記載の装置。
【請求項36】
通信システムにおいてブロードキャストのファイルを送達する装置であって、前記装置は、
プロセッサと、
前記プロセッサに結合されたメモリユニットとを備え、前記メモリユニットは、第1通信セッションにおいて前記ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて前記ブロードキャストの前記少なくとも1つのファイルを前記ファイル属性とは別に送信するための、コンピュータ読み出し可能な命令と、
を備える装置。
【請求項37】
前記メモリユニットはさらに、前記ファイル属性を第1通信チャネルを介して送信するための、及び前記少なくとも1つのファイルを第2通信チャネルを介して送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。
【請求項38】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記メモリユニットはさらに、第1ポート番号を介し、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を、送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令とを備える、請求項36に記載の装置。
【請求項39】
前記メモリユニットは、前記IPの前記UDPと結合した前記IPの1方向移送上でのファイル送達(FLUTE)とを通して少なくとも1つのファイルを送信するためのコンピュータ読み出し可能な命令をさらに備える、請求項36に記載の装置。
【請求項40】
前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャスト用に複数のファイルを連続的に送信するための、前記第2通信セッションよりも前の前記第1通信セッションにおいて前記複数のファイルを処理するための前記ファイル属性を送信するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。
【請求項41】
前記少なくとも1つのファイルは複数のデータパケットを含み、前記データパケットのそれぞれは、前記少なくとも1つのファイルを処理するためのファイル属性を含まない、請求項36に記載の装置。
【請求項42】
前記メモリユニットは、前記第2通信セッションにおいて前記ブロードキャストの複数のファイルを送信するための、前記第1通信セッションにおいて前記複数のファイルを処理するために、前記複数のファイル間で共用されている前記ファイル属性のいくつかを提供するための、コンピュータ読み出し可能な命令とをさらに備える、請求項36に記載の装置。
【請求項43】
前記ファイル属性は、前記ブロードキャストの前記少なくとも1つのファイルを表示するための時間情報を備える、請求項36に記載の装置。
【請求項44】
コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体であって、前記命令は、
第1通信セッションにおいてブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を受信する命令と、
第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを受信する命令と、
であるコンピュータ読み出し可能な媒体。
【請求項45】
第1通信チャネルを介して前記ファイル属性を受信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令をさらに備える、請求項44に記載のコンピュータ読み出し可能な媒体。
【請求項46】
前記通信システムはインターネットプロトコル(IP)をサポートし、前記コンピュータ読み出し可能な媒体は、
第1ポート番号を介して、前記IPのユーザデータグラムプログラム(UDP)を通して前記ファイル属性を受信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを受信するための、コンピュータ読み出し可能な命令
をさらに備える、請求項44に記載のコンピュータ読み出し媒体。
【請求項47】
第1通信セッションにおいて、ブロードキャストの少なくとも1つのファイルを処理するためのファイル属性を送信するための、及び第2通信セッションにおいて、前記ファイル属性とは別に、前記ブロードキャストの前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令を含んだコンピュータ読み出し可能な媒体。
【請求項48】
第1通信チャネルを介して前記ファイル属性を送信するための、及び第2通信チャネルを介して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。
【請求項49】
第1ポート番号を介して、前記IPのユーザデータグラムプロトコル(UDP)を通して前記ファイル属性を送信するための、及び第2ポート番号を介して、前記IPの前記UDPを通して前記少なくとも1つのファイルを送信するための、コンピュータ読み出し可能な命令をさらに含む、請求項47に記載のコンピュータ読み出し可能な媒体。
【図1】
【図2】
【図3】
【図3A】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図2】
【図3】
【図3A】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【公開番号】特開2011−151845(P2011−151845A)
【公開日】平成23年8月4日(2011.8.4)
【国際特許分類】
【外国語出願】
【出願番号】特願2011−66429(P2011−66429)
【出願日】平成23年3月24日(2011.3.24)
【分割の表示】特願2008−505621(P2008−505621)の分割
【原出願日】平成18年4月10日(2006.4.10)
【出願人】(595020643)クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】QUALCOMM INCORPORATED
【Fターム(参考)】
【公開日】平成23年8月4日(2011.8.4)
【国際特許分類】
【出願番号】特願2011−66429(P2011−66429)
【出願日】平成23年3月24日(2011.3.24)
【分割の表示】特願2008−505621(P2008−505621)の分割
【原出願日】平成18年4月10日(2006.4.10)
【出願人】(595020643)クゥアルコム・インコーポレイテッド (7,166)
【氏名又は名称原語表記】QUALCOMM INCORPORATED
【Fターム(参考)】
[ Back to top ]