(57)【要約】  ワイヤレス通信のための方法、装置、およびコンピュータプログラム製品が提供される。装置は、関心のあるファイルがサービス内で送信されることを決定し、関心のあるファイルをダウンロードできないことを決定し、ファイル配信イベントの終わりに対応する時間に関心のあるファイルの修復手順をトリガし、時間は、ブロードキャストされたスケジュール記述に含まれる1つまたは複数の情報要素から導出される。
2016526346.tif 000002
【特許請求の範囲】
【請求項１】
ユーザ機器(UE)のワイヤレス通信の方法であって、
関心のあるファイルがサービス内で送信されることを決定するステップと、
前記関心のあるファイルをダウンロードできないことを決定するステップと、
ファイル配信イベントの終わりに対応する時間に、前記関心のあるファイルの修復手順をトリガするステップであって、前記時間が、ブロードキャストスケジュール記述に含まれる情報要素から導出される、ステップと
を含む方法。
【請求項２】
前記ファイル配信イベントが、ファイルブロードキャストを含み、前記情報要素が、ファイルスケジュール要素を含み、前記時間が、前記ファイルブロードキャストの前記終わりに対応する、請求項1に記載の方法。
【請求項３】
前記ファイル配信イベントが、セッションブロードキャストを含み、前記情報要素が、セッションスケジュール要素を含み、前記時間が、前記セッションブロードキャストの前記終わりに対応する、請求項1に記載の方法。
【請求項４】
関心のあるファイルがサービス内で送信されることを決定するステップが、セッションのスケジュール記述に含まれるFDTロケータを介して取得されるファイル配信テーブル(FDT)に含まれる情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項５】
関心のあるファイルがサービス内で送信されることを決定するステップが、前記関心のあるファイルの前記ロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項６】
関心のあるファイルがサービス内で送信されることを決定するステップが、更新されたスケジュール記述に含まれる情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項７】
前記更新されたスケジュール記述がユニキャスト送信を介して取得される、請求項6に記載の方法。
【請求項８】
関心のあるファイルがサービス内で送信されることを決定するステップが、関心のあるセッションのスケジュール記述に含まれる情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項９】
前記情報要素がFDTロケータを含み、関心のあるファイルがサービス内で送信されることを決定するステップが、前記FDTにおける情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項１０】
関心のあるファイルがサービス内で送信されることを決定するステップが、最新のMD5ファイルについてクエリを行うことによって受信された情報に少なくとも部分的に基づく、請求項1に記載の方法。
【請求項１１】
関心のあるファイルがサービス内で送信されることを決定するステップが、前記ファイルの最新バージョンの識別子と、前記ファイルの以前のダウンロードバージョンとの比較に基づく、請求項1に記載の方法。
【請求項１２】
前記識別子がMD5署名を含む、請求項11に記載の方法。
【請求項１３】
関心のあるファイルがサービス内で送信されることを決定するステップが、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に基づく、請求項1に記載の方法。
【請求項１４】
ワイヤレス通信のための装置であって、
関心のあるファイルがサービス内で送信されることを決定するための手段と、
前記関心のあるファイルをダウンロードできないことを決定するための手段と、
ファイル配信イベントの終わりに対応する時間に、前記関心のあるファイルの修復手順をトリガするための手段であって、前記時間が、ブロードキャストスケジュール記述に含まれる情報要素から導出される、手段と
を含む装置。
【請求項１５】
前記ファイル配信イベントが、ファイルブロードキャストを含み、前記情報要素が、ファイルスケジュール要素を含み、前記時間が、前記ファイルブロードキャストの前記終わりに対応する、請求項14に記載の装置。
【請求項１６】
前記ファイル配信イベントが、セッションブロードキャストを含み、前記情報要素が、セッションスケジュール要素を含み、前記時間が、前記セッションブロードキャストの前記終わりに対応する、請求項14に記載の装置。
【請求項１７】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、セッションのスケジュール記述に含まれるFDTロケータを介して取得されるファイル配信テーブル(FDT)に含まれる情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項１８】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、前記関心のあるファイルの前記ロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項１９】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、更新されたスケジュール記述に含まれる情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２０】
前記更新されたスケジュール記述がユニキャスト送信を介して取得される、請求項19に記載の装置。
【請求項２１】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、関心のあるセッションのスケジュール記述に含まれる情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２２】
前記情報要素がFDTロケータを含み、関心のあるファイルがサービス内で送信されることを決定するための前記手段が、前記FDTにおける情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２３】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、最新のMD5ファイルについてのクエリを行うことによって受信された情報に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２４】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、前記ファイルの最新バージョンの識別子と、前記ファイルの以前のダウンロードバージョンとの比較に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２５】
前記識別子がMD5署名を含む、請求項24に記載の装置。
【請求項２６】
関心のあるファイルがサービス内で送信されることを決定するための前記手段が、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に、そのような決定のベースを置くように構成される、請求項14に記載の装置。
【請求項２７】
ワイヤレス通信のための装置であって、
メモリと、
前記メモリに結合された少なくとも1つのプロセッサと
を含み、前記少なくとも1つのプロセッサが、
関心のあるファイルがサービス内で送信されることを決定することと、
前記関心のあるファイルをダウンロードできないことを決定することと、
ファイル配信イベントの終わりに対応する時間に、前記関心のあるファイルの修復手順をトリガすることであって、前記時間が、ブロードキャストスケジュール記述に含まれる情報要素から導出される、トリガすることと
を行うように構成される
装置。
【請求項２８】
前記ファイル配信イベントが、ファイルブロードキャストを含み、前記情報要素が、ファイルスケジュール要素を含み、前記時間が、前記ファイルブロードキャストの前記終わりに対応する、請求項27に記載の装置。
【請求項２９】
前記ファイル配信イベントが、セッションブロードキャストを含み、前記情報要素が、セッションスケジュール要素を含み、前記時間が、前記セッションブロードキャストの前記終わりに対応する、請求項27に記載の装置。
【請求項３０】
前記プロセッサが、セッションのスケジュール記述に含まれるFDTロケータを介して取得されるファイル配信テーブル(FDT)に含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３１】
前記プロセッサが、関心のあるファイルの前記ロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づいて、前記関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３２】
前記プロセッサが、更新されたスケジュール記述に含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３３】
前記更新されたスケジュール記述がユニキャスト送信を介して取得される、請求項32に記載の装置。
【請求項３４】
前記プロセッサが、関心のあるセッションのスケジュール記述に含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３５】
前記情報要素がFDTロケータを含み、前記プロセッサが、前記FDTにおける情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３６】
前記プロセッサが、最新のMD5ファイルについてクエリを行うことによって受信された情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３７】
前記プロセッサが、前記ファイルの最新バージョンの識別子と、前記ファイルの以前のダウンロードバージョンとの比較に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項３８】
前記識別子がMD5署名を含む、請求項37に記載の装置。
【請求項３９】
前記プロセッサが、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に基づいて、関心のあるファイルがサービス内で送信されることを決定するように構成される、請求項27に記載の装置。
【請求項４０】
コンピュータプログラムであって、
関心のあるファイルがサービス内で送信されることを決定するためのコードと、
前記関心のあるファイルをダウンロードできないことを決定するためのコードと、
ファイル配信イベントの終わりに対応する時間に、前記関心のあるファイルの修復手順をトリガするためのコードであって、前記時間が、ブロードキャストスケジュール記述に含まれる情報要素から導出される、コードと
を含む
コンピュータプログラム。
【請求項４１】
前記ファイル配信イベントが、ファイルブロードキャストを含み、前記情報要素が、ファイルスケジュール要素を含み、前記時間が、前記ファイルブロードキャストの前記終わりに対応する、請求項40に記載のコンピュータプログラム。
【請求項４２】
前記ファイル配信イベントが、セッションブロードキャストを含み、前記情報要素が、セッションスケジュール要素を含み、前記時間が、前記セッションブロードキャストの前記終わりに対応する、請求項40に記載のコンピュータプログラム。
【請求項４３】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、セッションのスケジュール記述に含まれるFDTロケータを介して取得されるファイル配信テーブル(FDT)に含まれる情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項４４】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、前記関心のあるファイルの前記ロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項４５】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、更新されたスケジュール記述に含まれる情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項４６】
前記更新されたスケジュール記述がユニキャスト送信を介して取得される、請求項45に記載のコンピュータプログラム。
【請求項４７】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、関心のあるセッションのスケジュール記述に含まれる情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項４８】
前記情報要素がFDTロケータを含み、関心のあるファイルがサービス内で送信されることを決定するための前記コードが、前記FDTにおける情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項４９】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、最新のMD5ファイルについてクエリを行うことによって受信された情報に少なくとも部分的に基づく、請求項40に記載のコンピュータプログラム。
【請求項５０】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、前記ファイルの最新バージョンの識別子と、前記ファイルの以前のダウンロードバージョンとの比較に基づく、請求項40に記載のコンピュータプログラム。
【請求項５１】
前記識別子がMD5署名を含む、請求項50に記載のコンピュータプログラム。
【請求項５２】
関心のあるファイルがサービス内で送信されることを決定するための前記コードが、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に基づく、請求項40に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、2013年5月30日に出願された「Full File Repair Using Schedule Description Fragment In eMBMS」という表題の米国仮出願第61/829,202号、および2014年5月28日に出願された「Full File Repair Using Schedule Description Fragment In eMBMS」という表題の米国非仮出願第14/289,544号の利益を主張し、これらは全体が参照によって本明細書に明確に組み込まれる。
【０００２】
本開示は、一般に通信システムに関し、より詳細には、eMBMSを介して配信されるファイルのスケジュール記述フラグメントを使用した完全なファイル修復(たとえば、全ファイルのダウンロード)に関する。
【背景技術】
【０００３】
電話、ビデオ、データ、メッセージング、および放送などの様々な電気通信サービスを提供するために、ワイヤレス通信システムが広範囲に配備されている。通常のワイヤレス通信システムは、利用可能なシステムリソース(たとえば、帯域幅、送信電力)を共有することによって、複数のユーザとの通信をサポートすることが可能な多元接続技術を利用することができる。そのような多元接続技術の例には、符号分割多元接続(CDMA)システム、時分割多元接続(TDMA)システム、周波数分割多元接続(FDMA)システム、直交周波数分割多元接続(OFDMA)システム、シングルキャリア周波数分割多元接続(SC-FDMA)システム、および時分割同期符号分割多元接続(TD-SCDMA)システムが含まれる。
【０００４】
これらの多元接続技術は、様々なワイヤレスデバイスが自治体、国家、地域、さらには地球規模で通信することを可能にする共通プロトコルを提供するために、様々な電気通信規格において採用されている。新興の電気通信規格の一例は、Long Term Evolution(LTE)である。LTEは、第3世代パートナーシッププロジェクト(3GPP)によって公表されたUniversal Mobile Telecommunications System(UMTS)のモバイル規格に対する拡張セットである。LTEは、スペクトル効率を改善すること、コストを下げること、サービスを改善すること、新しいスペクトルを利用すること、ならびに、ダウンリンク(DL)上のOFDMA、アップリンク(UL)上のSC-FDMA、および多入力多出力(MIMO)アンテナ技術を使用して、他のオープン規格とより良く統合することによってモバイルブロードバンドインターネットアクセスをより良くサポートするように設計されている。しかしながら、モバイルブロードバンドアクセスに対する需要が増加し続けるのに伴い、LTE技術のさらなる改善が必要である。好ましくは、これらの改善は、他の多元接続技術、およびこれらの技術を利用する電気通信規格に適用可能であるべきである。
【発明の概要】
【課題を解決するための手段】
【０００５】
本開示の一態様では、方法、コンピュータプログラム製品、および装置が提供される。装置は、関心のあるファイルがサービス内に送信されることを決定し、関心のあるファイルをダウンロードできないことを決定し、ファイル配信イベントの終わりに対応する時間に関心のあるファイルの修復手順をトリガする。この時間は、ブロードキャストスケジュール記述に含まれる1つまたは複数の情報要素から導出される。一実装形態では、ファイル配信イベントは、ファイルブロードキャストを含み、情報要素は、ブロードキャストスケジュール記述に含まれるファイルスケジュール要素を含み、時間は、ファイルスケジュール要素の終了属性によって提供される、ファイルブロードキャストの終わりに対応する。別の実装形態では、ファイル配信イベントは、セッションブロードキャストを含み、情報要素は、ブロードキャストスケジュール記述に含まれるセッションスケジュール要素を含み、時間は、セッションスケジュール要素の停止属性によって提供される、セッションブロードキャストの終わりに対応する。
【図面の簡単な説明】
【０００６】
【図１】ネットワークアーキテクチャの一例を示す図である。
【図２】アクセスネットワークの一例を示す図である。
【図３】LTEにおけるDLフレーム構造の一例を示す図である。
【図４】LTEにおけるULフレーム構造の一例を示す図である。
【図５】ユーザプレーンおよび制御プレーン用の無線プロトコルアーキテクチャの一例を示す図である。
【図６】アクセスネットワーク中の発展型ノードBおよびユーザ機器の一例を示す図である。
【図７Ａ】マルチキャストブロードキャスト単一周波数ネットワークにおける発展型マルチメディアブロードキャストマルチキャストサービスチャネル構成の一例を示す図である。
【図７Ｂ】マルチキャストチャネルスケジューリング情報メディアアクセス制御の制御要素のフォーマットを示す図である。
【図８】セッション内のファイルスケジュールを含むセッションスケジュールの図である。
【図９】スケジュール記述フラグメントのXMLスキーマの図式図である。
【図１０】FDTロケーションURI属性を含むセッションスケジュールの図である。
【図１１】セッションスケジュールの図である。
【図１２】alternative-content-location属性およびavailability-time属性を含むファイルスケジュールの図である。
【図１３】ワイヤレス通信の方法のフローチャートである。
【図１４】例示的な装置における異なるモジュール/手段/構成要素間のデータフローを示す概念的なデータフロー図である。
【図１５】処理システムを利用する装置についてのハードウェア実装形態の一例を示す図である。
【発明を実施するための形態】
【０００７】
添付の図面に関して以下に記載する詳細な説明は、様々な構成の説明として意図されており、本明細書に記載される概念が実施され得る唯一の構成を表すことを意図していない。詳細な説明は、様々な概念の完全な理解を与えるために特定の詳細を含む。しかしながら、これらの概念がこれらの特定の詳細がなくても実施することができることは当業者に明らかであろう。いくつかの例では、そのような概念を曖昧にするのを防ぐために、よく知られた構造および構成要素がブロック図の形態において示されている。
【０００８】
次に、電気通信システムのいくつかの態様が、様々な装置および方法を参照して提示される。これらの装置および方法は、以下の発明を実施するための形態で説明され、様々なブロック、モジュール、構成要素、回路、ステップ、プロセス、アルゴリズムなど(「要素」と総称される)によって添付の図面に示される。これらの要素は、電子ハードウェア、コンピュータソフトウェア、またはそれらの任意の組合せを使用して実装され得る。そのような要素をハードウェアとして実装するか、またはソフトウェアとして実装するかは、具体的な適用例およびシステム全体に課された設計制約に依存する。
【０００９】
例として、要素、もしくは要素の任意の部分、または要素の任意の組合せは、1つまたは複数のプロセッサを含む「処理システム」で実装され得る。プロセッサの例としては、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ(DSP)、フィールドプログラマブルゲートアレイ(FPGA)、プログラマブル論理デバイス(PLD)、状態機械、ゲート論理、個別ハードウェア回路、および本開示全体にわたって説明される様々な機能を実行するように構成された他の適切なハードウェアがある。処理システム内の1つまたは複数のプロセッサは、ソフトウェアを実行し得る。ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、または他の名称で呼ばれるかどうかにかかわらず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するように広く解釈されるべきである。
【００１０】
したがって、1つまたは複数の例示的な実施形態では、記載される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せに実装することができる。ソフトウェアに実装される場合、機能は、コンピュータ可読媒体上の1つまたは複数の命令またはコードとして、記憶または符号化することができる。コンピュータ可読媒体は、コンピュータ記憶媒体を含む。記憶媒体は、コンピュータによってアクセスされ得る任意の利用可能な媒体であり得る。例として、それに限定されず、そのようなコンピュータ可読媒体は、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、電気消去可能プログラマブルROM(EEPROM)、コンパクトディスクROM(CD-ROM)もしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを搬送または記憶するために使用可能であり、コンピュータによってアクセス可能な他の任意の媒体を含むことができる。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、CD、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、およびフロッピー(登録商標)ディスクを含んでおり、ディスク(disk)は、通常、磁気的にデータを再生するが、ディスク(disc)は、レーザーで光学的にデータを再生する。前述の組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
【００１１】
図1は、LTEネットワークアーキテクチャ100を示す図である。LTEネットワークアーキテクチャ100は、発展型パケットシステム(EPS)100と呼ばれる場合がある。EPS100は、1つまたは複数のユーザ機器(UE)102、発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)104、発展型パケットコア(EPC)110、ホーム加入者サーバ(HSS)120、および事業者のインターネットプロトコル(IP)サービス122を含む場合がある。EPSは、他のアクセスネットワークと相互接続することができるが、簡単にするために、それらのエンティティ/インターフェースは図示されていない。図示のように、EPSはパケット交換サービスを提供するが、当業者が容易に諒解するように、本開示の全体を通して提示される様々な概念は、回線交換サービスを提供するネットワークに拡張され得る。
【００１２】
E-UTRANは、発展型ノードB(eNB)106および他のeNB108を含む。eNB106は、UE102に対してユーザプレーンプロトコル終端および制御プレーンプロトコル終端を提供する。eNB106は、バックホール(たとえば、X2インターフェース)を介して他のeNB108に接続される場合がある。eNB106は、基地局、ノードB、アクセスポイント、トランシーバ基地局、無線基地局、無線トランシーバ、トランシーバ機能、基本サービスセット(BSS)、拡張サービスセット(ESS)、または他の何らかの適切な用語で呼ばれる場合もある。eNB106は、UE102にEPC110へのアクセスポイントを提供する。UE102の例には、携帯電話、スマートフォン、セッション開始プロトコル(SIP)電話、ラップトップ、携帯情報端末(PDA)、衛星無線、全地球測位システム、マルチメディアデバイス、ビデオデバイス、デジタルオーディオプレーヤ(たとえば、MP3プレーヤ)、カメラ、ゲームコンソール、タブレット、または同様に機能する任意の他のデバイスが含まれる。UE102はまた、当業者により、移動局、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、または他の何らかの適切な用語で呼ばれる場合もある。
【００１３】
eNB106はEPC110に接続される。EPC110は、モビリティ管理エンティティ(MME)112、他のMME114、サービングゲートウェイ116、マルチメディアブロードキャストマルチキャストサービス(MBMS)ゲートウェイ124、ブロードキャストマルチキャストサービスセンタ(BM-SC)126、およびパケットデータネットワーク(PDN)ゲートウェイ118を含み得る。MME112は、UE102とEPC110との間のシグナリングを処理する制御ノードである。一般に、MME112は、ベアラおよび接続の管理を行う。すべてのユーザIPパケットは、サービングゲートウェイ116を介して転送され得、サービングゲートウェイ116自体は、PDNゲートウェイ118に接続される。PDNゲートウェイ118は、UEのIPアドレス割振りおよび他の機能を実現する。PDNゲートウェイ118は、事業者のIPサービス122に接続される。事業者のIPサービス122は、インターネット、イントラネット、IPマルチメディアサブシステム(IMS)、およびPSストリーミングサービス(PSS)を含む場合がある。BM-SC126は、MBMSユーザサービスのプロビジョニングおよび送達のための機能を実現することができる。BM-SC126は、コンテンツプロバイダのMBMS送信用のエントリポイントとして働くことができ、PLMN内のMBMSベアラサービスを認証し開始するために使用することができ、MBMS送信をスケジュールし送達するために使用することができる。MBMSゲートウェイ124は、特定のサービスをブロードキャストするマルチキャストブロードキャスト単一周波数ネットワーク(MBSFN)エリアに属するeNB(たとえば、106、108)に、MBMSトラフィックを配信するために使用することができ、セッション管理(開始/停止)およびeMBMS関連の課金情報を収集することに関与する場合がある。
【００１４】
図2は、LTEネットワークアーキテクチャにおけるアクセスネットワーク200の一例を示す図である。この例では、アクセスネットワーク200は、いくつかのセルラー領域(セル)202に分割される。1つまたは複数の低電力クラスeNB208は、セル202のうちの1つまたは複数と重なるセルラー領域210を有する場合がある。低電力クラスeNB208は、フェムトセル(たとえば、ホームeNB(HeNB))、ピコセル、マイクロセル、またはリモート無線ヘッド(RRH)であり得る。マクロeNB204は、各々がそれぞれのセル202に割り当てられ、セル202内のすべてのUE206にEPC110へのアクセスポイントを提供するように構成される。アクセスネットワーク200のこの例には集中型コントローラは存在しないが、代替構成では集中型コントローラが使用される場合がある。eNB204は、無線ベアラ制御、アドミッション制御、モビリティ制御、スケジューリング、セキュリティ、およびサービングゲートウェイ116への接続を含む、すべての無線関連機能に関与する。eNBは、1つまたは複数(たとえば、3つ)のセル(セクタとも呼ばれる)をサポートし得る。「セル」という用語は、この用語が使用される状況に応じて、eNBの最小のカバレージエリアおよび/または特定のカバレージエリアにサービスしているeNBサブシステムを指すことがある。さらに、「eNB」、「基地局」、および「セル」という用語は、本明細書では互換的に使用され得る。
【００１５】
アクセスネットワーク200によって利用される変調方式および多元接続方式は、導入されている特定の電気通信規格に応じて異なる場合がある。LTEの適用例では、DL上ではOFDMが使用され、UL上ではSC-FDMAが使用されて、周波数分割複信(FDD)と時分割複信(TDD)の両方をサポートする。当業者が以下の発明を実施するための形態から容易に諒解するように、本明細書に提示される様々な概念は、LTEの適用例に好適である。しかしながら、これらの概念は、他の変調技法および多元接続技法を採用する他の電気通信規格に容易に拡張することができる。例として、これらの概念は、Evolution-Data Optimized(EV-DO)またはUltra Mobile Broadband(UMB)に拡張され得る。EV-DOおよびUMBは、CDMA2000規格ファミリーの一部として第3世代パートナーシッププロジェクト2(3GPP2)によって公表されたエアインターフェース規格であり、CDMAを利用してブロードバンドインターネットアクセスを移動局に提供する。これらの概念はまた、広帯域CDMA(W-CDMA(登録商標))およびTD-SCDMAなどのCDMAの他の変形形態を利用するユニバーサル地上波無線アクセス(UTRA)、TDMAを利用するモバイル通信用グローバルシステム(GSM(登録商標))、ならびにOFDMAを利用する発展型UTRA(E-UTRA)、IEEE802.11(Wi-Fi)、IEEE802.16(WiMAX)、IEEE802.20、およびフラッシュOFDMに拡張することができる。UTRA、E-UTRA、UMTS、LTE、およびGSM(登録商標)については、3GPP団体による文書に記載されている。CDMA2000およびUMBについては、3GPP2団体による文書に記載されている。採用される実際のワイヤレス通信規格および多元接続技術は、特定の適用例およびシステムに課された全体的な設計制約に依存する。
【００１６】
eNB204は、MIMO技術をサポートする複数のアンテナを有する場合がある。MIMO技術を使用すると、eNB204が空間領域を活用して、空間多重化、ビームフォーミング、および送信ダイバーシティをサポートすることが可能になる。空間多重化は、同じ周波数上で同時にデータの様々なストリームを送信するために使用することができる。データストリームは、単一のUE206に送信してデータレートを増大させることができ、または、複数のUE206に送信して全体的なシステム容量を増大させることができる。これは、各データストリームを空間的にプリコーディングし(すなわち、振幅および位相のスケーリングを適用し)、次いで、空間的にプリコーディングされた各ストリームをDL上で複数の送信アンテナを介して送信することによって実現される。空間的にプリコーディングされたデータストリームは、異なる空間シグネチャとともにUE206に到達し、これにより、UE206の各々が、そのUE206に向けられた1つまたは複数のデータストリームを復元することが可能になる。UL上では、各UE206は、空間的にプリコーディングされたデータストリームを送信し、これにより、eNB204が、空間的にプリコーディングされた各データストリームのソースを識別することが可能になる。
【００１７】
空間多重化は、一般に、チャネル状態が良好であるときに使用される。チャネル条件があまり良好でないとき、送信エネルギーを1つまたは複数の方向に集中させるために、ビームフォーミングが使用され得る。これは、複数のアンテナを介した送信のためにデータを空間的にプリコーディングすることによって達成され得る。セルの縁部において良好なカバレージを達成するために、単一ストリームのビームフォーミング送信が、送信ダイバーシティと組み合わせて使用され得る。
【００１８】
以下の発明を実施するための形態では、DL上でOFDMをサポートするMIMOシステムを参照して、アクセスネットワークの様々な態様が記載される。OFDMは、OFDMシンボル内でいくつかのサブキャリアにわたってデータを変調するスペクトル拡散技法である。サブキャリアは、寸分違わない周波数で間隔があけられる。間隔は、受信機がサブキャリアからのデータを復元することを可能にする「直交性」をもたらす。時間領域では、OFDMシンボル間干渉をなくすために、ガードインターバル(たとえば、サイクリックプレフィックス)を各OFDMシンボルに追加することができる。ULは、SC-FDMAをDFT拡散OFDM信号の形式で使用して、高いピーク対平均電力比(PAPR)を補償することができる。
【００１９】
図3は、LTEにおけるDLフレーム構造の一例を示す図300である。フレーム(10ms)は、等しいサイズの10個のサブフレームに分割することができる。各サブフレームは、連続する2つの時間スロットを含む場合がある。リソースグリッドは、2つの時間スロットを表すために使用することができるが、各時間スロットはリソースブロックを含む。リソースグリッドは、複数のリソース要素に分割される。LTEでは、リソースブロックは、周波数領域における連続する12個のサブキャリアを含み、各OFDMシンボル内の通常のサイクリックプレフィックスの場合、時間領域における連続する7個のOFDMシンボル、すなわち84個のリソース要素を含む。拡張サイクリックプレフィックスの場合、リソースブロックは、時間領域内の連続する6つのOFDMシンボルを含み、72個のリソース要素を有する。R302、R304として示されたリソース要素のうちのいくつかは、DL基準信号(DL-RS)を含む。DL-RSは、(共通RSと呼ばれることもある)セル固有RS(CRS)302、およびUE固有RS(UE-RS)304を含む。UE-RS304は、対応する物理DL共有チャネル(PDSCH)がマッピングされるリソースブロック上のみで送信される。各リソース要素によって搬送されるビット数は、変調方式に依存する。したがって、UEが受信するリソースブロックが多いほど、かつ変調方式が高いほど、UE向けのデータレートは高くなる。
【００２０】
図4は、LTEにおけるULフレーム構造の一例を示す図400である。ULに利用可能なリソースブロックは、データセクションおよび制御セクションに区分化される場合がある。制御セクションは、システム帯域幅の2つの縁部に形成される場合があり、構成可能なサイズを有する場合がある。制御セクション内のリソースブロックは、制御情報を送信するためにUEに割り当てられる場合がある。データセクションは、制御セクションに含まれないすべてのリソースブロックを含む場合がある。このULフレーム構造により、データセクションは連続するサブキャリアを含むことになり、これにより、単一のUEが、データセクション内の連続するサブキャリアのすべてを割り当てられることが可能になり得る。
【００２１】
UEは、制御情報をeNBに送信するために、制御セクション内のリソースブロック410a、410bを割り当てられる場合がある。UEはまた、データをeNBに送信するために、データセクション内のリソースブロック420a、420bを割り当てられる場合がある。UEは、制御セクション内の割り当てられたリソースブロック上の物理UL制御チャネル(PUCCH)内で、制御情報を送信することができる。UEは、データセクション内の割り当てられたリソースブロック上の物理UL共有チャネル(PUSCH)内で、データのみ、またはデータと制御情報の両方を送信することができる。UL送信は、サブフレームの両方のスロットにまたがる場合があり、周波数にわたってホッピングする場合がある。
【００２２】
1組のリソースブロックは、初期システムアクセスを実行し、物理ランダムアクセスチャネル(PRACH)430内でUL同期を実現するために使用される場合がある。PRACH430は、ランダムシーケンスを搬送し、いかなるULデータ/シグナリングも搬送できない。各ランダムアクセスプリアンブルは、連続する6個のリソースブロックに対応する帯域幅を占有する。開始周波数は、ネットワークによって指定される。すなわち、ランダムアクセスプリアンブルの送信は、ある特定の時間リソースおよび周波数リソースに制限される。PRACHの場合、周波数ホッピングは存在しない。PRACHの試行は、単一のサブフレーム(1ms)内で、または少数の隣接するサブフレームのシーケンス内で搬送され、UEは、フレーム(10ms)当たり単一のPRACHの試行しか行うことができない。
【００２３】
図5は、LTEにおけるユーザプレーンおよび制御プレーン用の無線プロトコルアーキテクチャの一例を示す図500である。UEおよびeNBの無線プロトコルアーキテクチャは、レイヤ1、レイヤ2、およびレイヤ3という3つのレイヤで示される。レイヤ1(L1レイヤ)は最下位レイヤであり、様々な物理レイヤ信号処理機能を実装する。本明細書では、L1レイヤは物理レイヤ506と呼ばれる。レイヤ2(L2レイヤ)508は物理レイヤ506の上にあり、物理レイヤ506を介したUEとeNBとの間のリンクに関与する。
【００２４】
ユーザプレーンでは、L2レイヤ508は、媒体アクセス制御(MAC)サブレイヤ510、無線リンク制御(RLC)サブレイヤ512、およびパケットデータコンバージェンスプロトコル(PDCP)514サブレイヤを含み、これらはネットワーク側のeNBで終端する。図示されていないが、UEは、L2レイヤ508の上にいくつかの上位レイヤを有する場合があり、これらは、ネットワーク側のPDNゲートウェイ118で終端するネットワークレイヤ(たとえば、IPレイヤ)と、接続の他端(たとえば、遠端UE、サーバなど)で終端するアプリケーションレイヤとを含む。
【００２５】
PDCPサブレイヤ514は、異なる無線ベアラと論理チャネルとの間で多重化を行う。PDCPサブレイヤ514はまた、無線送信のオーバーヘッドを低減する上位レイヤのデータパケット用のヘッダ圧縮、データパケットを暗号化することによるセキュリティ、およびeNB間のUE用のハンドオーバのサポートを実現する。RLCサブレイヤ512は、上位レイヤのデータパケットのセグメント化および再アセンブリ、紛失したデータパケットの再送信、ならびに、ハイブリッド自動再送要求(HARQ)による順序の狂った受信を補償するデータパケットの並べ替えを実現する。MACサブレイヤ510は、論理チャネルとトランスポートチャネルとの間の多重化を実現する。MACサブレイヤ510は、UE間の1つのセルにおいて様々な無線リソース(たとえば、リソースブロック)を割り当てることの責任も負っている。MACサブレイヤ510は、HARQ動作の責任も負っている。
【００２６】
制御プレーンでは、UEおよびeNB用の無線プロトコルアーキテクチャは、制御プレーン用のヘッダ圧縮機能がないことを除き、物理レイヤ506およびL2レイヤ508について実質的に同じである。制御プレーンはまた、レイヤ3(L3レイヤ)内に無線リソース制御(RRC)サブレイヤ516を含む。RRCサブレイヤ516は、無線リソース(たとえば、無線ベアラ)を取得すること、および、eNBとUEとの間のRRCシグナリングを使用して下位レイヤを構成することを担う。
【００２７】
図6は、アクセスネットワーク中でUE650と通信しているeNB610のブロック図である。DLでは、コアネットワークからの上位レイヤパケットが、コントローラ/プロセッサ675に供給される。コントローラ/プロセッサ675は、L2レイヤの機能性を実装する。DLでは、コントローラ/プロセッサ675は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、論理チャネルとトランスポートチャネルとの間の多重化、ならびに、様々な優先順位基準に基づくUE650への無線リソース割振りを実現する。コントローラ/プロセッサ675はまた、HARQ動作、紛失したパケットの再送信、およびUE650へのシグナリングに関与する。
【００２８】
送信(TX)プロセッサ616は、L1レイヤ(すなわち、物理レイヤ)のための様々な信号処理機能を実施する。信号処理機能には、UE650での順方向誤り訂正(FEC)を容易にするコーディングおよびインタリービング、ならびに様々な変調方式(たとえば、2位相シフトキーイング(BPSK)、直交位相シフトキーイング(QPSK)、M位相シフトキーイング(M-PSK)、M直交振幅変調(M-QAM))に基づく信号コンスタレーションへのマッピングが含まれる。次いで、コーディングされ変調されたシンボルは、並列ストリームに分割される。次いで、各ストリームは、OFDMサブキャリアにマッピングされ、時間領域および/または周波数領域で基準信号(たとえば、パイロット)と多重化され、次いで、逆高速フーリエ変換(IFFT)を使用して一緒に結合されて、時間領域のOFDMシンボルストリームを搬送する物理チャネルを生成する。OFDMストリームは、空間的にプリコーディングされて、複数の空間ストリームを生成する。チャネル推定器674からのチャネル推定値は、コーディング方式および変調方式を決定するために、ならびに空間処理のために使用される場合がある。チャネル推定値は、UE650によって送信された基準信号および/またはチャネル状態フィードバックから導出される場合がある。次いで、各空間ストリームは、別個の送信機618TXを介して異なるアンテナ620に供給され得る。各送信機618TXは、送信用のそれぞれの空間ストリームでRFキャリアを変調し得る。
【００２９】
UE650で、各受信機654RXは、そのそれぞれのアンテナ652を介して信号を受信する。各受信機654RXは、RFキャリア上に変調された情報を復元し、この情報を受信(RX)プロセッサ656に供給する。RXプロセッサ656は、L1レイヤの様々な信号処理機能を実施する。RXプロセッサ656は、情報に対して空間処理を実行して、UE650に宛てられた任意の空間ストリームを復元し得る。複数の空間ストリームがUE650に宛てられた場合、それらは、RXプロセッサ656によって単一のOFDMシンボルストリームに合成される場合がある。次いで、RXプロセッサ656は、高速フーリエ変換(FFT)を使用して、OFDMシンボルストリームを時間領域から周波数領域に変換する。周波数領域信号は、OFDM信号のサブキャリアごとに別個のOFDMシンボルストリームを含む。各サブキャリア上のシンボル、および基準信号は、eNB610によって送信された最も可能性の高い信号コンスタレーションポイントを決定することによって、復元され復調される。これらの軟判定は、チャネル推定器658によって計算されたチャネル推定値に基づく場合がある。次いで、軟判定は復号されデインタリーブされて、物理チャネル上でeNB610によって元々送信されたデータおよび制御信号を復元する。次いで、データおよび制御信号は、コントローラ/プロセッサ659に供給される。
【００３０】
コントローラ/プロセッサ659は、L2レイヤを実装する。コントローラ/プロセッサは、プログラムコードおよびデータを記憶するメモリ660に関連付けることができる。メモリ660は、コンピュータ可読媒体と呼ばれる場合がある。ULでは、コントローラ/プロセッサ659は、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を実現して、コアネットワークからの上位レイヤパケットを復元する。次いで、上位レイヤパケットはデータシンク662に供給され、データシンク662はL2レイヤの上のすべてのプロトコルレイヤを表す。様々な制御信号も、L3処理のためにデータシンク662に提供することができる。コントローラ/プロセッサ659はまた、HARQ動作をサポートするために、確認応答(ACK)および/または否定応答(NACK)のプロトコルを使用する誤り検出に関与する。
【００３１】
ULでは、コントローラ/プロセッサ659に上位レイヤパケットを供給するために、データソース667が使用される。データソース667は、L2レイヤの上のすべてのプロトコルレイヤを代表する。eNB610によるDL送信に関連して記載された機能と同様に、コントローラ/プロセッサ659は、ヘッダ圧縮、暗号化、パケットのセグメント化および並べ替え、ならびに、eNB610による無線リソース割振りに基づく論理チャネルとトランスポートチャネルとの間の多重化を実現することによって、ユーザプレーンおよび制御プレーンのためのL2レイヤを実装する。コントローラ/プロセッサ659はまた、HARQ動作、紛失したパケットの再送信、およびeNB610へのシグナリングに関与する。
【００３２】
eNB610によって送信された基準信号またはフィードバックからチャネル推定器658によって導出されたチャネル推定値は、適切なコーディング方式および変調方式を選択し、空間処理を容易にするために、TXプロセッサ668によって使用される場合がある。TXプロセッサ668によって生成された空間ストリームは、別個の送信機654TXを介して異なるアンテナ652に供給され得る。各送信機654TXは、送信用のそれぞれの空間ストリームでRFキャリアを変調し得る。
【００３３】
UL送信は、UE650での受信機機能に関連して記載された方式と同様の方式で、eNB610で処理される。各受信機618RXは、それぞれのアンテナ620を通じて信号を受信する。各受信機618RXは、RFキャリア上に変調された情報を復元し、この情報をRXプロセッサ670に供給する。RXプロセッサ670は、L1レイヤを実装することができる。
【００３４】
コントローラ/プロセッサ675は、L2レイヤを実装する。コントローラ/プロセッサ675は、プログラムコードおよびデータを記憶するメモリ676に関連付けることができる。メモリ676は、コンピュータ可読媒体と呼ばれる場合がある。ULでは、コントローラ/プロセッサ675は、トランスポートチャネルと論理チャネルとの間の逆多重化、パケット再アセンブリ、暗号化解除、ヘッダ圧縮解除、制御信号処理を実現して、UE650からの上位レイヤパケットを復元する。コントローラ/プロセッサ675からの上位レイヤパケットは、コアネットワークに供給される場合がある。コントローラ/プロセッサ675はまた、HARQ動作をサポートするために、ACKおよび/またはNACKのプロトコルを使用する誤り検出に関与する。
【００３５】
図7Aは、MBSFNにおける発展型MBMS(eMBMS)チャネル構成の一例を示す図750である。セル752'内のeNB752は第1のMBSFNエリアを形成することができ、セル754'内のeNB754は第2のMBSFNエリアを形成することができる。eNB752、754は、各々他のMBSFNエリア、たとえば、合計8つまでのMBSFNエリアと関連付けることができる。MBSFNエリア内のセルは、予約セルに指定することができる。予約セルは、マルチキャスト/ブロードキャストコンテンツを供給しないが、セル752'、754'に時間同期され、MBSFNエリアへの干渉を制限するために、MBSFNリソース上の電力が規制される。MBSFNエリア内の各eNBは、同じeMBMSの制御情報およびデータを同期して送信する。各エリアは、ブロードキャストサービス、マルチキャストサービス、およびユニキャストサービスをサポートすることができる。ユニキャストサービスは、特定のユーザを対象とするサービス、たとえば、音声通話である。マルチキャストサービスは、あるグループのユーザによって受信され得るサービス、たとえば、サブスクリプションビデオサービスである。ブロードキャストサービスは、すべてのユーザによって受信され得るサービス、たとえば、ニュース放送である。図7Aを参照すると、第1のMBSFNエリアは、特定のニュース放送をUE770に供給することなどによって、第1のeMBMSブロードキャストサービスをサポートすることができる。第2のMBSFNエリアは、異なるニュース放送をUE760に供給することなどによって、第2のeMBMSブロードキャストサービスをサポートすることができる。各MBSFNエリアは、複数の物理マルチキャストチャネル(PMCH)(たとえば、15個のPMCH)をサポートする。各PMCHは、マルチキャストチャネル(MCH)に対応する。各MCHは、複数(たとえば、29個)のマルチキャスト論理チャネルを多重化することができる。各MBSFNエリアは、1つのマルチキャスト制御チャネル(MCCH)を有することができる。したがって、1つのMCHは、1つのMCCHおよび複数のマルチキャストトラフィックチャネル(MTCH)を多重化することができ、残りのMCHは、複数のMTCHを多重化することができる。
【００３６】
UEは、eMBMSサービスアクセスおよび対応するアクセス層構成の利用可能性を発見するために、LTEセルにキャンプオンすることができる。第1のステップで、UEは、システム情報ブロック(SIB)13(SIB13)を取得することができる。第2のステップで、UEは、SIB13に基づいて、MCCH上でMBSFNエリア構成メッセージを取得することができる。第3のステップで、UEは、MBSFNエリア構成メッセージに基づいて、MCHスケジューリング情報(MSI)MAC制御要素を取得することができる。SIB13は、(1)セルによってサポートされる各MBSFNエリアのMBSFNエリア識別子、(2)MCCH反復期間(たとえば、32、64、…、256フレーム)などMCCHを取得するための情報、MCCHオフセット(たとえば、0、1、…、10フレーム)、MCCH変更期間(たとえば、512、1024フレーム)、シグナリング変調および符号化方式(MCS)、反復期間およびオフセットによって示されるように、無線フレームのどのサブフレームがMCCHを送信することができるかを示すサブフレーム割振り情報、および(3)MCCH変更通知構成を示す。MBSFNエリアごとに1つのMBSFNエリア構成メッセージがある。MBSFNエリア構成メッセージは、(1)一時的モバイルグループ識別情報(TMGI)およびPMCH内の論理チャネル識別子によって識別される各MTCHのオプションのセッション識別子、(2)MBSFNエリアの各PMCHおよびエリアにおけるすべてのPMCHに割り振られたリソースの割振り期間(たとえば、4、8、…、256フレーム)を送信するための割り振られたリソース(すなわち、無線フレームおよびサブフレーム)、および(3)MSI MAC制御要素が送信されるMCHスケジューリング期間(MSP)(たとえば、8、16、32、…または1024無線フレーム)のいずれをも示す。
【００３７】
図7Bは、MSI MAC制御要素のフォーマットを示す図790である。MSI MAC制御要素は、各MSPに1度送られ得る。MSI MAC制御要素は、PMCHの各スケジューリング期間の第1のサブフレームにおいて送られ得る。MSI MAC制御要素は、PMCH内の各MTCHの停止フレームおよびサブフレームを示し得る。MBSFNエリア当たりPMCH当たり1つのMSIがあり得る。
【００３８】
図8は、eMBMSブロードキャストを介したセッションブロードキャストおよびファイルブロードキャストのスケジュールの一部の図800である。スケジュールは、1分の持続時間を有するいくつかの個々のセッションスケジュール802を含む。各セッションスケジュール802の間、1つまたは複数のファイル804がファイルスケジュール806に従ってブロードキャストされ得る。セッションスケジュール802およびファイルスケジュール806に関連した情報は、eMBMSサーバによってブロードキャストされるサービス告知に含まれ得る。ファイルスケジュール806に含まれる情報は、その間特定のファイル804がブロードキャストされるセッション内の特定の時間のブロックを指定することができる。
【００３９】
UEは、定期的に更新されるファイル804のバージョンを以前ダウンロードしている可能性があり、または、定期的にファイルをブロードキャストするサービスの加入者である可能性がある。たとえば、UEは、ファイルの開発者によって定期的に更新される、たとえばアプリケーション、オペレーティングシステムなど、特定のバージョンのファイルを有し得る、または、UEは、毎時など、定期的にニュース記事のファイルをブロードキャストするニュースサービスを定期購読することができる。一般的なeMBMSシナリオでは、ファイルの更新バージョン(または新しいファイル)は、ファイルのブロードキャストの前にUEによって受信されるサービス告知で提供される情報に従って、eMBMSサービスエリアにおいて最初にブロードキャストされ得る。たとえば、サービス告知は、一般的にセッションスケジュール802およびファイルスケジュール806に対応する情報を含むスケジュール記述フラグメントを含み得る。また、サービス告知は、ユニキャスト送信を介してUEによって受信され得る。ブロードキャストされるようにスケジュールされたファイルは、UEにとって「関心のあるファイル」とすることができる。たとえば、UE上のアプリケーションは、eMBMSサービスにおけるいくつかの基準を満たすファイルの受信への関心を表し得る。一般的な基準は、ファイル名またはディレクトリ内のファイルであり、例は、ニュースサービスの天気フォルダ内のすべてのファイルとすることができる。UEは、ファイルの最新バージョンでもよく、またはそうでなくてもよいファイルのバージョンを有していてもよく、またはそうでなくてもよい。
【００４０】
UEによるサービス告知の受信と関心のあるファイルのスケジュールされたeMBMSブロードキャストとの間の時間の間、UEは、eMBMSブロードキャストのサービス外またはカバレージ外になり得、したがって、関心のあるファイルを受信することができない場合がある。「カバレージ外」とは、UEがeMBMSブロードキャストのブロードキャストエリアの外にあるエリアに移動するケースを指す。「サービス外」とは、たとえば、信号強度が低すぎるので、UEは、ブロードキャストされた信号を確実に受信することができない、たとえばセルのフリンジエリアまたはセルのポケットなど、あるロケーションにUEがあるケースを指す。すなわち、UEが着信の伝送を復号するには信号が弱すぎる可能性がある。いずれの場合も、UEは、関心のあるファイルを受信せず、ファイルの部分的なデータもまったく受信しない可能性がある。さらに、UEは、一連のファイル、ファイルの可能な署名(FDTの場合MD5ハッシュの形)、および対応するトランスポートオプションを列挙する、ファイルに関連したファイル配信テーブル(FDT)インスタンスを受信しない場合がある。
【００４１】
以下は、UEが関心のあるファイルまたはその関連のFDTインスタンスを受信しないいくつかの例示的なシナリオである。
【００４２】
1)UEが別の周波数に同調される-サムは、彼女が彼女のデバイス上で生のバスケットボールの試合を視聴することができるリアルタイム「BBA Live」バスケットボールMBMSビデオサービスに加入している。リアルタイムサービスは、周波数帯域1を使用してMBMSを介してブロードキャストされる。サムのモバイルデバイスはまた、周波数帯域2上でブロードキャストされるMBMS Firmware Over the Air(OTA)サービスを介してソフトウェアアップデートを受信するように構成される。サムは、彼女のデバイスのためのファームウェアダウンロードがMBMS Firmware OTAサービスを介した配信のためにスケジュールされていた時間の間、彼女のデバイス上で生のBBAゲームを視聴していた。サムがゲームを視聴していた間、ファイルのためのブロードキャスト配信ウインドウを逃したが、デバイスは、ソフトウェアアップデートをファイル修復サーバから取り出す。
【００４３】
2)UEがオフにされている-トムは、1日中ニュース記事を定期的にブロードキャストする「CNN」ニュースサービスに加入しているニュースマニアである。トムは毎週仕事のためにボストンとサンディエゴとの間を定期的に通勤し、彼のフライト時に「機内モード」で電話を置いておくことにつとめている。フライトの間、トムの電話は、彼が機上にいる間、ブロードキャストされるニュース記事をダウンロードすることができない。トムは、着陸すると、「機内モード」を無効にし、彼のデバイスは、ファイル修復サーバから欠落したニュース記事をダウンロードし、ニュースフィードの遅れを取り戻し始めることができるようになる。
【００４４】
3)UEは、MBMSカバレージ外にあるが、良好なユニキャストカバレージ内にある-ベスは、eMBMSカバレージのないいくつかのエリア(たとえば、MBMS信号が弱い)において郵便を配達する郵便配達員である。彼女のGPSは、ルート選択のためにブロードキャストトラフィックアップデートに依存する。カバレージが低いエリアにいる間、ベスのGPSが最善の移動ルートを選択することができるように、デバイスは、ファイル修復サーバから欠落したトラフィックアップデートをダウンロードする。
【００４５】
UEが関心のあるファイルを受信しない場合、UEは、完全なファイル修復を実施し得る。「完全なファイル修復」は、ファイル修復サーバからの関心のあるファイルの完全なダウンロードに関する。eMBMSにおけるファイル修復は、現在、単方向トランスポート(FLUTE)プロトコルを介したファイル配信内のFDTインスタンスの満了時間によってトリガされる。既存のファイル修復手法は、デバイスが、eMBMSサーバを持つeMBMSベアラにアクセスし、ファイル修復を開始することが可能になる前に、FDTをダウンロードすることを必要とする。しかしながら、上記のシナリオでは、FDTは、UEでは利用できない。したがって、現在の完全なファイル修復技法は、FDTが受信されないファイルを回復することに適用できない。
【００４６】
eMBMSサービス告知におけるスケジュールフラグメントの追加で、UEは、必ずしもサービスにアクセスするとは限らず、したがってFDTを取得することなく、セッションおよびファイルスケジュールに気づいている場合がある。以下に、ファイルのスケジュールされた配信の間、ブロードキャストチャネルを介して、UEは、関心のあるファイルおよびファイルのFDTインスタンスを受信することができない場合、UEがファイル修復サーバから関心のあるファイルの完全なファイル修復を実施できるようにする3つのシナリオ(および他の類似のシナリオ)に適用可能な技法について述べる。開示された技法では、UEは、関連する配信手順記述フラグメントおよび/または関心のあるファイルのスケジュール記述フラグメントを取得することができる。これらは、UEがeMBMSカバレージ内にある間eMBMSサービス告知を介して、またはUEに対するユニキャスト送信を介して、UEによって取得され得る。たとえば、UEは、カバレージ外またはサービス外になる前に、および関心のあるファイルのブロードキャストの「欠落」前に、eMBMSサービスカバレージにいる間にサービス告知を受信することができる。あるいは、UEは、関心のあるファイルのブロードキャストの後、サービス告知を受信することができる。本明細書で使用する「ブロードキャストの欠落」とは、UEはeMBMSサービスを介して関心のあるファイルの送信を受信することができず、それによって、述べられたシナリオにおいて例示されるように、ファイルのFDTが受信されない例を指す。
【００４７】
図9は、スケジュール記述フラグメント902のXMLスキーマの図式図900である。スケジュール記述フラグメント902は、UEによって受信されるサービス告知に含まれ得る。スケジュール記述フラグメント902に含まれる情報に基づいて、UEは、関心のあるファイルが欠落しているかどうかを判断することが可能である。スケジュール記述フラグメント902は、関心のあるファイルがブロードキャストされるセッションのセッションスケジュール要素904を含み、関心のあるファイルのファイルスケジュール要素906を含み得る。ファイルスケジュール906が存在する場合、ファイルスケジュールは、ファイルバージョン情報を含み得る。たとえば、ファイルスケジュール906は、ファイルのバージョンを識別するファイルのメッセージダイジェスト5(MD5)908を有し得る。
【００４８】
UEは、関心のあるファイルが欠落しているかどうかを判断するために、関心のあるファイルに対応するファイル識別情報について、スケジュール記述フラグメント902を監視することができる。たとえば、セッションスケジュール要素904は、関心のあるファイルのブロードキャストスケジュールを提供することができる。ファイルスケジュール906は、ダウンロードのためにスケジュールされた関心のあるファイルのバージョンを識別する関心のあるファイルのMD5 908を含み得る。この情報に基づいて、UEは、関心のあるファイルが欠落し、完全なファイル修復を実施しなければならないかどうかを判断するために、それが現在有する関心のあるファイルのバージョンを、ダウンロードのためにスケジュールされたバージョンと比較する。しかしながら、いくつかの場合には、スケジュール記述フラグメント902は、関心のあるファイルが欠落しているかどうかを判断するのに十分な情報を含んでいない可能性がある。たとえば、ファイルスケジュール906がMD5を含んでいない可能性がある、またはファイルスケジュール906自体がスケジュール記述902に含まれていない可能性がある。
【００４９】
ファイルスケジュール906は利用可能であるかどうかに応じて、およびさらに、どんな情報がファイルスケジュールに含まれているかに応じて、関心のあるファイルが欠落しているかどうかを判断し、完全なファイル修復を実施するために、異なる技法が開示される。要約すれば、これらの技法では、UEは、関心のあるファイルが欠落しているかどうかを判断し、欠落している場合、スケジュール記述フラグメントに含まれる情報(たとえば、セッションスケジュールに含まれるファイル識別情報、ファイルスケジュールに含まれるファイルバージョン情報など)に基づいて、スケジュール記述フラグメントに含まれる、またはそれを介して取得される情報(たとえば、セッションスケジュールに直接含まれるファイル識別、およびUEをファイルバージョン情報に向けるロケーション情報など)に基づいて、追加のファイル情報のクエリに基づいて、またはシンボルベース修復サーバ、および従来のHTTPサーバからの関心のあるファイルの要求に基づいて、完全なファイル修復をトリガすることができる。
【００５０】
スケジュール記述におけるファイル情報に基づくファイル修復
【００５１】
引き続き図9を参照すると、UEは、スケジュール記述メタデータフラグメント902に含まれる情報のみに基づいて完全なファイル修復をトリガすることができる。スケジュール記述フラグメント902は、セッションスケジュール要素904、MD5 908を含むファイルスケジュール要素906、および再送信スケジュールを含み得る。この実装形態では、スケジュール記述フラグメント902は、セッションの終わりおよびファイル送信の終わりの一方または両方を決定するために使用され得る。ファイルがスケジュール記述におけるスケジュールされた送信の終わりに、ファイルがダウンロードされない場合、受信報告は、失敗を報告することもできる。
【００５２】
スケジュール記述フラグメント902は、セッションおよびファイルの送信について記述する。スケジュール記述フラグメント902は、セッションスケジュール要素(sessionSchedule)904およびファイルスケジュール要素(fileSchedule)906を含み得る。ファイルスケジュール要素906によって、UEは、関心のあるファイルが送信されるかどうかを判断することができる。さらに、ファイルスケジュール要素906内のMD5 908によって、UEは、UEが以前関心のあるファイルをすでにダウンロードしていた場合、関心のあるファイルの新しいバージョンが送信される、または送信されるようにスケジュールされるかどうかを判断することができる。
【００５３】
UEは、次のように、スケジュール記述フラグメント902における情報を使用して、完全なファイル修復を実施することができる。まず、UEは、ファイルスケジュール906に含まれるファイルが関心のあるファイルであることを決定する。たとえば、eMBMSカバレージ内にいる間、UEは、1つまたは複数のファイルの、たとえばセッションスケジュール904およびファイルスケジュール906など、ブロードキャスト情報を含むサービス告知を受信することができる。ブロードキャスト情報に基づいて、UEは、ブロードキャストされるファイルのうちの1つが関心のあるファイルであるかどうかを判断する。UEは、ファイルスケジュール906における関心のあるユニフォームリソース識別子(URI)910について、新しいファイルまたは更新されたMD5 908を調べることによってこの決定を行うことができる。
【００５４】
次に、関心のあるファイルのスケジュールブロードキャストの間、UEは、関心のあるファイルのダウンロードを開始するために対応するeMBMSベアラにアクセスしようと試みる。UEがeMBMSのサービス外もしくはカバレージ外である、またはファイルがeMBMSを介してブロードキャストされる周波数がUEにとってアクセス不可能である場合、UEは、関心のあるファイルをダウンロードすることができない。この場合、UEは、ファイルスケジュールの終わりまたはセッションスケジュールの終わりに完全なファイル修復をトリガすることができる。たとえば、UEは、ファイル送信時間の終わりに到達すると、完全なファイル修復を開始することができる。ファイル送信時間の終わりは、ファイルスケジュール要素806の終了属性812に含まれ得る。あるいは、UEは、関心のあるファイルを含むセッションの終わりに、完全なファイル修復を開始することができる。したがって、FDTインスタンスが受信されないときでも、UEは、ファイルスケジュールの終わりまたはセッションスケジュールの終わりにファイルの回復をトリガすることができる。
【００５５】
このようにして、この手順で、UEは、ファイルスケジュール情報に基づいて、関心のあるファイルがサービス内で送信されることを決定する。この目的で、UEは、ファイル情報がファイルスケジュールおよびオプションでセッションスケジュールも含むことを必要とする。UEは、ファイル情報において識別される任意のファイルが関心のあるファイルに対応するかどうかを判断するために、ファイル情報を処理する。たとえば、ファイル情報がニュースサービスの天気ディレクトリにおけるファイルを識別し、アプリケーションがそのようなファイルの受信をすでに要求している場合、UEは、関心のあるファイルのようなファイルを識別することになる。
【００５６】
次に、UEは、関心のあるファイルをダウンロードできないことを決定する。この目的で、UEは、関心のあるファイルのブロードキャストスケジュールを知っており、ファイルを受信するべきeMBMSベアラを確立しようと試みることができる。ベアラの確立が失敗した場合、またはスケジュール記述に従って、ファイルのブロードキャストの一部のもしくは総持続時間の間、複数のそのような試行が失敗した場合、UEは、関心のあるファイルをダウンロードできないことを決定することになる。別の可能な実装形態では、UEは、現在UEにあるファイルのバージョンを、スケジュール記述において告知されたセッションの間にブロードキャストされた関心のあるファイルのバージョンと比較することによって、スケジュールされたブロードキャストの後、関心のあるファイルをダウンロードできないことを決定することができる。バージョンが一致しない場合、UEは、関心のあるファイルをダウンロードできなかったと結論づけることができる。
【００５７】
次に、関心のあるファイルをダウンロードできなかった場合、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガすることができる。この目的で、UEは、関心のあるファイルがあるファイル修復サーバとの接続を確立し、ファイルを要求する。UEは、ユニキャスト送信を介してファイル修復サーバからファイルを受信することができる。
【００５８】
上記の一実装形態では、ファイル配信イベントは、ファイルブロードキャストを含み、情報要素は、ブロードキャストスケジュール記述902に含まれるファイルスケジュール要素906を含み、修復トリガの時間は、ファイルスケジュール要素906の終了属性912によって提供される、ファイルブロードキャストの終わりに対応する。別の実装形態では、UEは、関心のあるファイルのファイルスケジュール906を含むブロードキャストスケジュール記述902を取得し、ファイルスケジュールに含まれる終了属性912に基づく時間に関心のあるファイルの完全なファイル修復手順をトリガする。
【００５９】
別の実装形態では、ファイル配信イベントは、セッションブロードキャストを含み、情報要素は、ブロードキャストスケジュール記述902に含まれるセッションスケジュール要素904を含み、修復トリガの時間は、セッションスケジュール要素904の停止属性914によって提供される、セッションブロードキャストの終わりに対応する。また別の実装形態では、UEは、関心のあるファイルのセッションスケジュール904を含むブロードキャストスケジュール記述902を取得し、セッションスケジュールに含まれる停止属性914に基づく時間に関心のあるファイルの完全なファイル修復手順をトリガする。
【００６０】
FDTに基づくファイル修復(ファイルスケジュールが利用不可能)
【００６１】
前述のように、ファイルスケジュールは、スケジュール記述フラグメント902に含まれていない可能性がある。たとえば、いくつかの場合には、セッションの間にブロードキャストされるファイルの数が、ファイルスケジュールに含めるにはあまりにも多すぎる場合がある。これらの場合、UEは、関心のあるファイルが次回のセッションの間にブロードキャストされ得ることを、アプリケーションの優先度から決定することができる。UEがeMBMSを受信することが可能であるとき、UEは、セッションの始めにサービスを運ぶベアラをアクティブ化し、セッションの間に関心のあるファイルのすべてのファイル送信を受信し、セッションの終わりにベアラを非アクティブ化する。UEは、(完全なファイル修復が必要な場合)セッションの始めまたはセッションの間にベアラをアクティブ化することができないとき、セッションにおいてブロードキャストされるファイルのリストを取得することができず、したがって、関心のあるファイルがセッションに実際に含まれているかどうかを判断することができない。技法に従って、UEは、セッションスケジュール要素904に含まれるFDT情報に基づいてファイル情報を取得し、UEが1つまたは複数のファイルが関心のあるファイルであることを決定する場合、セッションの間のファイルブロードキャストの完全なファイル修復をトリガすることができる。
【００６２】
一構成では、および図10に関して、ファイル情報は、セッションスケジュール要素1004に含まれるFDTロケーションURI1002によって提供される。FDTロケーションURI1002は、ブロードキャスト開始時(開始属性1016によって示される)、ブロードキャスト終了時(停止属性1014によって示される)、またはブロードキャスト終了+オフセット時に利用可能であり得る。これは、ファイル修復ファイルが現在の標準的な動作プロトコルでファイル修復サーバにおいて利用可能であるときであるので、より後の利用可能性オプションが好ましい。
【００６３】
FDTロケーションURIは、ブロードキャストセッションの間に送信されるファイルのすべてを記述する情報を含むことができる。FDTロケーションURI1002は、sessionIndex1006によってパラメータ化されるテンプレートとすることができる。たとえば、FDTロケーションURI1002は、セッション番号によって分類されるファイル情報を含み得る。たとえば、URIは、セッション1では、http\\provider.com\filedeliveryservice\FDT1、セッション2では、http\\provider.com\filedeliveryservice\FDT2、セッション3では、http\\provider.com\filedeliveryservice\FDT3などとすることができる。
【００６４】
UEは、次のように、ファイルスケジュールが利用不可能であるとき、FDTに基づいて完全なファイル修復を実施することができる。まず、UEは、サービス告知において告知されるセッションスケジュールを有するブロードキャストサービスにおけるファイルにアプリケーションが関心を持っていることを決定する。たとえば、サービス告知に含まれる情報に基づいて、UEは、関心のあるファイルが対応するeMBMSベアラ上でブロードキャストされ得ることを決定することができる。
【００６５】
次に、UEは、ファイルのダウンロードを開始するためにeMBMSベアラにアクセスしようと試みる。eMBMS信号が弱いためにUEがサービス外である場合、またはUEがeMBMSブロードキャストのカバレージ外にある場合、またはUEはサービスがブロードキャストされる周波数に切り替えることができない場合、またはUEは任意の他の理由(ラジオリソース問題、非常に多くのベアラがアクティブであるなど)のためにeMBMSブロードキャストを受信することができない場合、UEは、関心のあるファイルをダウンロードすることができない。この場合、UEは、関心のあるファイルがセッションの間にブロードキャストされたかどうかを判断するために、セッションスケジュール1004のFDTlocationURI属性1002などのFDT情報についてクエリを行う。UEは、ブロードキャストセッションの終わり+オフセット時間まで待つ必要があり得、この場合、セッションの終わりは、セッションスケジュール1004の停止属性1014によって提供される。次に、FDT情報に基づいて、UEは、指定される場合、セッションおよびそれらのMD5におけるファイルを決定する。たとえば、UEは、ファイルのいずれかが新しい、またはファイルのいずれかがUEに存在するファイルのより新しいバージョンに対応するかどうかを判断するために、URIとしてリストされたファイルおよび各ファイルの対応するMD5バージョンを検討することができる。関心のあるファイルが見つかった(新しいファイル、またはファイルのより新しいバージョン)場合、UEは、関心のあるファイルの完全なファイル修復をトリガする。完全なファイル修復は、ブロードキャストセッションの終わりにトリガされ得る。ブロードキャストセッションの終わりは、セッションスケジュールに含まれる情報に基づいて決定され得る。
【００６６】
このようにして、この手順で、UEは、関心のあるファイルがサービス内で送信されることを決定する。この目的で、UEは、たとえば、FDTが位置する場所のロケーション情報を有するセッションスケジュールを有するスケジュール記述フラグメントを含むサービス告知などのファイルブロードキャスト情報を取得し、FDTにアクセスし、ファイルブロードキャスト情報において識別される任意のファイルがFDTにリストされる関心のあるファイルに対応するかどうかを決定することによって、この情報を処理することができる。セッションスケジュールに基づいて、UEは、関心のあるファイルがセッションの間にブロードキャストされ得ることを決定することができる。セッションスケジュールを介して取得されるFDTロケーション情報に基づいて、UEは、関心のあるファイルがセッションの間に実際にブロードキャストされたかどうかを判断することができる。上記の一実装形態では、UEは、セッションのスケジュール記述に含まれるFDTロケータ1002を介して取得されるFDTに含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定する。たとえば、FDTロケータ1002は、スケジュール記述フラグメントのセッションスケジュール1004要素にあり得る。別の実装形態では、UEは、関心のあるファイルのファイルスケジュール1004を含むブロードキャストスケジュール記述を取得し、セッションスケジュールに含まれるFDT URI1002に基づいて、関心のあるファイルのFDTを取り出す。
【００６７】
次に、UEは、関心のあるファイルをダウンロードできないことを決定する。このために、上述したように、UEは、ダウンロードを開始するために、eMBMSベアラにアクセスすることができないことを決定し、次いで、FDT情報についてのクエリを行う。
【００６８】
次に、関心のあるファイルをダウンロードできなかった場合、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガすることができる。この目的で、UEは、関心のあるファイルがあるファイル修復サーバとの接続を確立し、ファイルを要求する。UEは、ユニキャスト送信を介してファイル修復サーバからファイルを受信することができる。UEは、セッションスケジュール1004に含まれる停止属性1014に基づくある時間に関心のあるファイルの修復手順をトリガする。
【００６９】
スケジュール記述に基づくファイル修復(ファイルスケジュールが利用不可能)
【００７０】
ファイルスケジュール要素906がスケジュール記述フラグメント902に含まれない別の技法では、UEは、セッションスケジュール要素904からファイル情報を取得し、関心のあるファイルの完全なファイル修復をトリガすることができる。図11を参照すると、この手順では、セッションスケジュール要素1104への変更はない。主な違いは、セッションにアクセスできず、セッションにおいてブロードキャストされたファイルを記述する任意のFDTを取得することができないとき、UEは、ファイル修復サーバを介して利用可能なファイルのファイルスケジュールも含むより最新のスケジュール記述を取り出すことである。
【００７１】
この手順では、UEは、関心のあるファイルがブロードキャストされているセッションの間、スケジュール記述フラグメント902の最新バージョンについてクエリを行うことによって、ブロードキャストファイル情報についてeMBMSサーバに対するクエリを行うことができる。ブロードキャストファイル情報は、スケジュール記述フラグメント902の最新バージョンに含まれるファイルスケジュール906に含まれ得る。スケジュール記述フラグメント902は、ユニキャスト送信を介してUEによって受信され得る。一態様では、UEは、ユニバーサルサービス記述(USD)に含まれるサービス識別子によって、またはセッションスケジュール1104に含まれるセッションインデックス1106によって識別されるセッションのスケジュール記述についてクエリを行うことができる。別の態様では、ファイル修復が関連する配信手順フラグメントに従って許可される場合、UEは、ファイルスケジュール906を提供するスケジュール記述フラグメント902の最新バージョンを取得するために、ユニキャストチャネルを使用することができる。スケジュール記述フラグメントがサービス告知におけるURIによって識別され、一実施形態では、このファイルURIは、スケジュール記述フラグメントの更新バージョンをファイル修復サーバから取り出すために使用され得ることに留意されたい。
【００７２】
UEは、次のように、ファイルスケジュールが最初に利用不可能であるとき、スケジュール記述に基づいて完全なファイル修復を実施することができる。まず、UEは、サービス告知において告知されるセッションスケジュールを有するブロードキャストサービスにおいてキャプチャがアクティブであることを決定する。たとえば、サービス告知に含まれる情報に基づいて、UEは、関心のあるファイルが対応するeMBMSベアラ上でブロードキャストされ得ることを決定することができる。
【００７３】
次に、UEは、ファイルのダウンロードを開始するためにeMBMSベアラにアクセスしようと試みる。eMBMS信号が弱いためにUEがサービス外である場合、またはUEがeMBMSブロードキャストのカバレージ外にある場合、またはUEはサービスがブロードキャストされる周波数に切り替えることができない場合、またはUEは任意の他の理由(ラジオリソース問題、非常に多くのベアラがアクティブであるなど)のためにeMBMSブロードキャストを受信することができない場合、UEは、関心のあるファイルをダウンロードすることができず、潜在的にファイルをダウンロードすることができないことが確立される。この場合、ファイル修復が利用可能である場合、UEは、ファイルスケジュール906を含むセッションの更新されたスケジュール記述902についてクエリを行う。
【００７４】
次に、スケジュール記述902に基づいて、UEは、指定される場合、セッションおよびそれらのMD5におけるファイルを決定する。たとえば、UEは、ファイルのいずれかがUEに存在するファイルのより新しいバージョンに対応するかどうかを判断するために、ファイルスケジュール906において列挙されたファイルおよびMD5によって提供される対応するバージョンを検討することができる。関心のあるファイルが見つかった場合、UEは、関心のあるファイルの完全なファイル修復をトリガすることができる。修復は、最新の更新されたスケジュール記述フラグメント902によって提供されるセッション/ファイルスケジュールの終わりにトリガされ得る。
【００７５】
このようにして、この手順で、UEは、関心のあるファイルがサービスによって送信される、または送信されることになることを決定する。この目的で、UEは、たとえば、ファイル情報を有するセッションスケジュールを含むサービス告知の受信を介して、およびファイルバージョン情報を有するファイルスケジュールを有する更新されたセッションスケジュール904についてクエリを行うことによって、ファイルブロードキャスト情報を取得することができる。UEは、ブロードキャスト情報において識別される任意のファイルが関心のあるファイルに対応するかどうかを判断するために、ファイル情報を処理する。セッションスケジュールに基づいて、UEは、関心のあるファイルがセッションの間にブロードキャストされ得ることを決定することができる。ファイルスケジュール906に基づいて、UEは、関心のあるファイルがセッションの間にブロードキャストされたかどうかを判断することができる。したがって、UEは、ユニキャスト送信を介して取得され得る更新されたスケジュール記述に含まれる情報に基づいて、関心のあるファイルがサービスによって送信されることを決定する。
【００７６】
次に、UEは、関心のあるファイルをダウンロードできないことを決定する。このために、上述したように、UEは、ダウンロードを開始するために、eMBMSベアラにアクセスすることができないことを決定し、次いで、更新されたスケジュール記述についてのクエリを行う。
【００７７】
次に、関心のあるファイルをダウンロードできなかった場合、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガすることができる。この目的で、UEは、関心のあるファイルがあるファイル修復サーバとの接続を確立し、ファイルを要求する。UEは、ユニキャスト送信を介してファイル修復サーバからファイルを受信する。
【００７８】
セッションインデックスに基づくファイル修復(ファイルスケジュールが利用不可能)
【００７９】
スケジュール記述フラグメント902がファイルスケジュール要素906を提供することができない例に適用可能な別の技法では、UEは、スケジュール記述フラグメント902のセッションスケジュール要素904に含まれるセッションインデックス情報916に基づいて、関心のあるファイルの完全なファイル修復をトリガすることができる。
【００８０】
この手法では、セッションを一意に識別するセッションインデックス916は、スケジュール記述902における再送を識別するために使用され得る。たとえば、セッションインデックス916は、スケジュール記述における反復セッションを識別するために使用され得る。セッションインデックス916は、コンテンツに関連付けられる。現在のセッションが以前のセッションと同じファイルを運ぶ場合、セッションをブロードキャストするために同じインデックスが使用される。
【００８１】
ファイルスケジュールが利用不可能であるとき、セッションインデックス916に基づく完全なファイル修復のためのUEの挙動は、次のように行われる。まず、UEは,サービス告知において告知されるセッションスケジュールを有するサービスにおいてキャプチャがアクティブであることを決定する。たとえば、UEは、関心のあるファイルが対応するeMBMSベアラ上でブロードキャストされていることを決定することができる。
【００８２】
次に、現在のセッションインデックス916が関心のあるすべてのファイルが正常に受信された以前のセッションインデックスに一致することをUEが決定した場合、UEは、反復セッションにおいて任意のダウンロードを開始しない。現在のセッションインデックス916が関心のあるすべてのファイルが正常に受信された以前のセッションインデックスに一致しないことをUEが決定した場合、UEは、反復セッションにおいて完全なファイル修復を開始する。
【００８３】
このようにして、この手順で、UEは、関心のあるファイルがサービス内で送信されることを決定する。UEは、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に基づいて、関心のあるファイルがサービス内で送信されることを決定する。インデックスが一致しない場合、UEは、関心のあるファイルがあると結論づけることができる。次いで、UEは、関心のあるファイルをダウンロードできないことを決定する。これは、以前の技法について説明したように行われ得る。次いで、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガすることができる。これは、以前の技法について説明したように行われ得る。
【００８４】
暗黙的なFDTに基づくファイル修復(ファイルスケジュールにおいてMD5がない)
【００８５】
ファイルスケジュール要素906は利用可能であるが、ファイルバージョン情報を含まない、たとえば、MD5がないときの使用のための技法では、UEは、暗黙的なFDTロケーションに基づいて、関心のあるファイルを決定すると、完全なファイル修復をトリガし得る。スケジュール記述フラグメント902はファイルスケジュール要素906におけるファイルURIのためのMD5 908を提供しないので、UEは、URIに対応するファイルのバージョンを決定することができず、したがって、対応するファイルが関心のあるファイルであるかどうかを決定することができない。
【００８６】
このシナリオでは、UEは、次のように、暗黙的なFDTに基づいて完全なファイル修復を実施することができる。まず、UEは、ファイルスケジュール906に含まれるファイルが関心のあるファイルであることを決定する。たとえば、UEは、以前ファイルをダウンロードしたことに基づいて、ファイルスケジュール906において識別されたURI910が関心のあるファイルであることを決定することができる。
【００８７】
次に、UEは、関心のあるファイルのダウンロードを開始するために対応するeMBMSベアラにアクセスしようと試みる。UEがeMBMSのサービス外もしくはカバレージ外である、またはファイルがeMBMSを介してブロードキャストされる周波数がUEにとってアクセス不可能である場合、UEは、関心のあるファイルをダウンロードすることができない。ファイルスケジュール906に含まれるURI910は、関心のあるファイルのMD5を含むことができるFDT情報を含む。FDTロケーションは、ファイルURI、たとえば、URIの同じディレクトリに基づいて暗黙的であってもよいが、ファイル名は「FDT」である。UEは、関心のあるファイルのMD5を含むFDTをダウンロードする。次いで、UEは、ファイルスケジュールの終わりまたはセッションスケジュールの終わりにファイル修復をトリガすることができる。たとえば、UEは、ファイル送信時間の終わりに到達すると、関連する配信手順を開始することができる。ファイル送信時間の終わりは、ファイルスケジュール要素906の終了属性912に含まれ得る。あるいは、UEは、セッションの終わりに関連する配信手順を開始することができる。セッション時間の終わりは、セッションスケジュール要素804の停止属性814に基づいて決定され得る。
【００８８】
このようにして、この手順で、UEは、関心のあるファイルがサービス内で送信されることを決定する。UEは、関心のあるファイルのロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定する。たとえば、UEは、以前ファイルをダウンロードしたことに基づいて、ファイルスケジュール906において識別されたURI910が関心のあるファイルであることを決定することができる。次いで、UEは、関心のあるファイルをダウンロードできないことを決定する。これは、以前の技法について説明したように行われ得る。次いで、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガする。これは、以前の技法について説明したように行われ得る。
【００８９】
クエリに基づくファイル修復(ファイルスケジュールにおいてMD5がない)
【００９０】
ファイルスケジュール要素906は利用可能であるが、ファイルバージョン情報を含まない、たとえば、MD5がないときの使用のための別の技法では、UEは、クエリに基づいて、関心のあるファイルを決定すると、ファイル修復をトリガし得る。この場合、UEは、MD5情報を有していないので、ダウンロードのためにスケジュールされたファイルのバージョンを決定することができず、したがって、ブロードキャストのためのファイルスケジュールのいずれかが関心のあるファイルであるかどうかを決定することができない。しかしながら、UEは、ファイル修復サーバにおけるファイルの最新のMD5についてクエリを行うことができるクエリ手順が備えられている。
【００９１】
UEは、次のように、クエリに基づいて完全なファイル修復を実施することができる。まず、UEは、ファイルスケジュール906に含まれるファイルが関心のあるファイルであり得ることを決定する。たとえば、UEは、ファイルスケジュールにおける任意のファイルが以前UEによってダウンロードされたかどうかを判断するためにファイルスケジュールに列挙されたファイルと、そのファイルとを比較することができる。任意の以前ダウンロードされたファイルは、可能な関心のあるファイルと考えられる。
【００９２】
次に、UEは、関心のあるファイルのダウンロードを開始するために対応するeMBMSベアラにアクセスしようと試みる。UEがカバレージ外である、またはファイルがeMBMSを介してブロードキャストされる周波数がUEにとってアクセス不可能である場合、UEは、関心のあるファイルをダウンロードすることができない。この場合、UEは、ファイル修復サーバに、ファイルスケジュール906に含まれる可能な関心のあるファイルに関する最新のMD5情報を要求する。最新のMD5情報によって提供されるファイルバージョン情報が現在UEにおけるファイルのバージョンに一致しない場合、UEは、ファイルが関心のあるファイルであると結論づける。次いで、UEは、ファイルスケジュールの終わりまたはセッションスケジュールの終わりにファイル修復をトリガすることができる。たとえば、UEは、ファイル送信時間の終わりに到達すると、関連する配信手順を開始することができる。ファイル送信時間の終わりは、ファイルスケジュール要素906の終了属性912に含まれ得る。あるいは、UEは、セッションの終わりに関連する配信手順を開始することができる。セッション時間の終わりは、セッションスケジュール要素904の停止属性914に基づいて決定され得る。
【００９３】
このようにして、この手順で、UEは、関心のあるファイルがサービス内で送信されることを決定する。UEは、最新のMD5ファイルについてクエリを行うことによって受信された情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定する。次いで、UEは、関心のあるファイルをダウンロードできないことを決定する。これは、以前の技法について説明したように行われ得る。次いで、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガする。これは、以前の技法について説明したように行われ得る。
【００９４】
条件付き取得(Conditional Get)に基づくファイル修復(ファイルスケジュールにおいてMD5がない)
【００９５】
ファイルバージョン情報、たとえばMD5が利用不可能であるときの使用のための別の技法では、UEは、条件付き取得手順に基づいて関心のあるファイルを決定すると、ファイル修復をトリガすることができる。この場合、UEは、MD5情報を有していないので、ダウンロードのためにスケジュールされたファイルのバージョンを決定することができず、したがって、ブロードキャストのためのファイルスケジュールのいずれかが関心のあるファイルであるかどうかを決定することができない。ウェブサーバは、ファイルのタグ(「etags」)に基づいて、条件付き取得を可能にする。条件付き取得は、ファイルの最新バージョンを対象とし、ファイルのetagは、ファイルのMD5署名である。if-none-matchによる(従来のHTTPサーバでの)条件付き取得:「MD5_Of_Latest_Version_onUE」は、etagが同じままであることに基づいて、新しいバージョンが利用可能である場合、ファイルを返し、またはファイルに対する変更がない場合、「Not Modified」を返すことになる。
【００９６】
UEは、次のように、条件付き取得に基づいて完全なファイル修復を実施することができる。まず、UEは、ファイルスケジュール906に含まれるファイルが関心のあるファイルであること、およびファイルがUEによって以前ダウンロードされたことを決定する。たとえば、UEは、ファイルスケジュールにおける任意のファイルが以前UEによってダウンロードされたかどうかを判断するためにファイルスケジュール906に列挙されたファイルと、そのファイルとを比較することができる。任意の以前ダウンロードされたファイルは、可能な関心のあるファイルと考えられる。
【００９７】
次に、UEは、関心のあるファイルのダウンロードを開始するために対応するベアラにアクセスしようと試みる。UEがカバレージ外である、またはファイルがeMBMSを介してブロードキャストされる周波数がUEにとってアクセス不可能である場合、UEは、関心のあるファイルをダウンロードすることができない。次いで、UEは、ファイルスケジュールの終わりまたはセッションスケジュールの終わりにファイル修復をトリガすることができる。たとえば、UEは、ファイル送信時間の終わりに到達すると、関連する配信手順を開始することができる。ファイル送信時間の終わりは、ファイルスケジュール要素806の終了属性812に含まれ得る。あるいは、UEは、セッションの終わりに関連する配信手順を開始することができる。セッション時間の終わりは、セッションスケジュール要素804の停止属性814に基づいて決定され得る。
【００９８】
完全なファイル修復の一部としてファイルをダウンロードするときに、UEは、条件付き取得を行い、サーバにおけるファイルのetagがUEにおけるファイルの現行バージョンのMD5とは異なる場合のみ、ファイルを要求する。これを行うために、従来のHTTPファイル修復サーバにおけるファイルのetagは、httpサーバによって現在サービスされているファイルバージョンのMD5に設定される。
【００９９】
したがって、この手順で、UEは、関心のあるファイルがサービス内で送信されることを決定する。UEは、関心のあるファイルが、ファイルの最新バージョンの識別子、たとえばMD5署名と、ファイルの以前のダウンロードバージョンとの比較に基づいて、サービス内で送信されることを決定する。次いで、UEは、関心のあるファイルをダウンロードできないことを決定する。これは、以前の技法について説明したように行われ得る。次いで、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復手順をトリガすることができる。これは、以前の技法について説明したように行われ得る。
【０１００】
スケジュール記述フラグメントによる従来のHTTPサーバサポートに基づくファイル修復
【０１０１】
現在のLTE仕様3GPP TS 26.346、バージョン12.1、セクション3.5.1において、FDTは、「xs:anyURI」値を介してファイル修復サーバリソースに対する参照を提供する「Alternate-Content-Location-1」および「Alternate-Content-Location-2」要素を含み得る。少なくとも1つの「Alternate-Content-Location-1」要素は、バイト範囲ベースのファイル修復がネットワークによってサポートされることになっている場合、FDTに存在する。「Base-URL-1」および「Base-URL-2」要素は、存在するとき、それぞれ任意の「Alternate-Content-Location-1」または「Alternate-Content-Location-2」要素に含まれる相対参照を分解するベースのURLを提供する。「Availability-Time」属性は、存在するとき、到達可能であり、機能的である場合、ファイル修復サーバが要求された修理データを返すことをUEが予想することができるUTC時間標準に従って絶対時間をUEに知らせるための方法を提供する。
【０１０２】
完全なファイル修復のための2つのオプションは、スケジュール記述フラグメント手法による従来のHTTPサーバサポートが提供され得る。第1のオプションでは、FDTで概説されるように、従来のHTTPサーバロケーションを取得するために、FDTに基づいてファイル修復に関して上記で説明したように、FDT検索が使用され得る。第2のオプションでは、図12に示されるように従来のHTTPサーバをサポートするために、類似のサポートがセッションスケジュール1204において追加されている。この拡張は、クエリに基づく上記の完全なファイル修復、および条件付き取得に基づく完全なファイル修復で最適に働く。
【０１０３】
図13は、ワイヤレス通信の方法のフローチャート1300である。この方法はUEによって実行され得る。ステップ1302で、UEは、関心のあるファイルがサービス内で送信されることを決定する。UEによるそのような決定は、スケジュール記述フラグメントに含まれる、またはそれを介して取得される情報に基づき得る。UEは、セッションのスケジュール記述に含まれるFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定し得る。UEは、関心のあるファイルのロケータから暗黙的に決定されたFDTロケータを介して取得されるFDTに含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定し得る。UEは、更新されたスケジュール記述に含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定し得る。更新されたスケジュール記述は、ユニキャストを介して取得され得る。
【０１０４】
UEは、関心のあるセッションのスケジュール記述に含まれる情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定する。情報要素はFDTロケータでもよく、UEは、関心のあるファイルがFDTにおける情報に少なくとも部分的に基づいてサービス内で送信されることを決定することができる。UEは、最新のMD5ファイルについてクエリを行うことによって受信された情報に少なくとも部分的に基づいて、関心のあるファイルがサービス内で送信されることを決定し得る。UEは、関心のあるファイルが、ファイルの最新バージョンの識別子と、ファイルの以前のダウンロードバージョンとの比較に基づいて、サービス内で送信されることを決定し得る。識別子は、MD5署名でもよい。UEは、以前のセッションの間にブロードキャストされたファイルに関連したインデックスと、現在のセッションの間にブロードキャストされたファイルに関連したインデックスとの間の比較に基づいて、関心のあるファイルがサービス内で送信されることを決定し得る。
【０１０５】
ステップ1304で、UEは、関心のあるファイルをダウンロードできないことを決定する。一構成では、UEは、UEがブロードキャストセッションの終わりに関心のあるファイルを受信したかどうかを確かめることによって、関心のあるファイルをダウンロードできなかったことを決定する。UEは、セッションスケジュール要素に含まれる情報に少なくとも部分的に基づいてブロードキャストセッションの終わり、ならびに、ファイルスケジュール(たとえば、MD5)に含まれる、またはファイルスケジュールを介して(たとえば、FDTlocationURIを介して)取得される情報に少なくとも部分的に基づいて、関心のあるファイルのバージョン識別を認識する。したがって、ブロードキャストセッションの終わりに、UEは、現在UEにおけるファイルのバージョンを、セッションの間にブロードキャストされた関心のあるファイルのバージョンと比較する。バージョンが一致しない場合、UEは、関心のあるファイルをダウンロードできなかったと結論づけることができる。
【０１０６】
ステップ1306で、UEは、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復をトリガし、時間は、スケジュール記述に含まれる情報要素から導出される。一実施形態では、ファイル配信イベントは、ファイルブロードキャストを含み、情報要素は、ファイルスケジュール要素を含み、修復トリガの時間は、ファイルブロードキャストの終わりに対応する。別の実装形態では、ファイル配信イベントは、セッションブロードキャストを含み、情報要素は、セッションスケジュール要素を含み、修復トリガの時間は、セッションブロードキャストの終わりに対応する。
【０１０７】
図14は、例示的な装置1402の中の様々なモジュール/手段/構成要素の間のデータフローを示す概念的なデータフロー図1400である。装置はUEであり得る。装置1402は、サービス内で送信されるファイルに対応するサーバからファイル情報(たとえば、スケジュール記述、セッションスケジュール、ファイルスケジュール)を受信する受信モジュール1404、関心のあるファイルがサービス内で送信されることを決定する関心のあるファイルモジュール1406、関心のあるファイルをダウンロードできないことを決定するダウンロード失敗1408、およびファイル配信イベントの終わりに対応する時間に関心のあるファイルの修復をトリガするファイル修復トリガモジュール1410を含み、時間は、スケジュール記述に含まれる情報要素から導出される。
【０１０８】
装置は、上記の図13のフローチャート内のアルゴリズムのステップの各々を実行する追加のモジュールを含む場合がある。したがって、図13の上述されたフローチャート内の各ステップは、モジュールによって実行される場合があり、装置は、それらのモジュールの1つまたは複数を含む場合がある。モジュールは、指定されたプロセス/アルゴリズムを実行するように明確に構成されるか、指定されたプロセス/アルゴリズムを実行するように構成されたプロセッサによって実施されるか、プロセッサによる実施のためにコンピュータ可読媒体内に記憶されるか、またはそれらの何らかの組合せである、1つまたは複数のハードウェア構成要素であり得る。
【０１０９】
図15は、処理システム1514を利用する装置1402'についてのハードウェア実装形態の一例を示す図1500である。処理システム1514は、バス1524によって全体的に表されたバスアーキテクチャで実装される場合がある。バス1524は、処理システム1514の特定の適用例および全体的な設計制約に応じて、任意の数の相互接続するバスおよびブリッジを含む場合がある。バス1524は、プロセッサ1504、モジュール1404、1406、1408、1410、およびコンピュータ可読媒体1506によって表される、1つまたは複数のプロセッサおよび/またはハードウェアモジュールを含む様々な回路を互いにリンクさせる。バス1524は、当業界でよく知られているタイミングソース、周辺機器、電圧レギュレータ、および電源管理回路などの様々な他の回路とリンクすることもでき、したがって、さらに何らか説明されることはない。
【０１１０】
処理システム1514は、トランシーバ1510に結合される場合がある。トランシーバ1510は、1つまたは複数のアンテナ1520に結合される。トランシーバ1510は、伝送媒体上の様々な他の装置と通信するための手段を提供する。トランシーバ1510は、1つまたは複数のアンテナ1520から信号を受信して、受信された信号から情報を抽出して、抽出された情報を処理システム1514に提供する。加えて、トランシーバ1510は、処理システム1514から情報を受信して、受信された情報に基づいて、1つまたは複数のアンテナ1520に印加される信号を生成する。処理システム1514は、コンピュータ可読媒体1506に結合されたプロセッサ1504を含む。プロセッサ1504は、コンピュータ可読媒体1506上に記憶されたソフトウェアの実行を含む全般的な処理を担う。ソフトウェアは、プロセッサ1504によって実行されると、任意の特定の装置の上記で説明した様々な機能を処理システム1514に実行させる。コンピュータ可読媒体1506は、ソフトウェアを実行するときにプロセッサ1504によって操作されるデータを記憶するために使用されてもよい。処理システムはさらに、モジュール1404、1406、1408、および1410のうちの少なくとも1つを含む。モジュールは、コンピュータ可読媒体1506に存在する/記憶される、プロセッサ1504において動作するソフトウェアモジュール、プロセッサ1504に結合された1つもしくは複数のハードウェアモジュール、またはそれらの何らかの組合せであり得る。処理システム1514は、UE650の構成要素であり得、メモリ660、ならびに/または、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659のうちの少なくとも1つを含み得る。
【０１１１】
一構成では、ワイヤレス通信のための装置1402/1402'は、関心のあるファイルがサービス内で送信されることを決定するための手段と、関心のあるファイルをダウンロードできないことを決定するための手段と、ファイル配信イベントの終わりに対応する時間に、関心のあるファイルの修復をトリガするための手段とを含み、時間は、スケジュール記述に含まれる1つまたは複数の情報要素から導出される。
【０１１２】
上記の手段は、装置1402の上記のモジュール、および/または上記の手段によって列挙された機能を実行するように構成された装置1402'の処理システム1514のうちの1つまたは複数であり得る。上記に記載されたように、処理システム1514は、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659を含む場合がある。したがって、一構成では、上記の手段は、上記の手段によって列挙された機能を実行するように構成された、TXプロセッサ668、RXプロセッサ656、およびコントローラ/プロセッサ659であり得る。
【０１１３】
開示されたプロセスにおけるステップの特定の順序または階層は、例示的な手法の一例であることを理解されたい。設計上の選好に基づいて、プロセスにおけるステップの特定の順序または階層は再構成され得ることを理解されたい。さらに、いくつかのステップは、組み合わされるか、または省略される場合がある。添付の方法クレームは、様々なステップの要素を例示的な順序で提示したものであり、提示された特定の順序または階層に限定されることは意図されない。
【０１１４】
前述の説明は、当業者が本明細書に説明された様々な態様を実施することを可能にするように与えられる。これらの態様の様々な修正形態は、当業者に容易に明らかになり、本明細書に定められた一般的な原理は、他の態様に適用することができる。したがって、特許請求の範囲は本明細書に示された態様に限定されるものではなく、文言通りの特許請求の範囲に整合するすべての範囲を与えられるべきであり、単数の要素への言及は、そのように明記されていない限り、「唯一無二の」を意味するものではなく、「1つまたは複数の」を意味するものである。「例示的」という言葉は、「例、事例、または例示としての役割を果たす」ことを意味するように本明細書で使用される。「例示的な」ものとして本明細書で説明するいずれの態様も、必ずしも他の態様よりも好ましいか、または有利であると解釈されるわけではない。特に別段の定めがない限り、「いくつか(some)」という用語は、1つまたは複数を指す。たとえば「A、B、またはCのうちの少なくとも1つ」、「A、B、およびCのうちの少なくとも1つ」、ならびに「A、B、C、またはそれらの任意の組合せ」などの組合せは、A、B、および/またはCの任意の組合せを含み、Aの倍数、Bの倍数、またはCの倍数を含み得る。具体的には、たとえば「A、B、またはCのうちの少なくとも1つ」、「A、B、およびCのうちの少なくとも1つ」、ならびに「A、B、C、またはそれらの任意の組合せ」などの組合せは、Aのみ、Bのみ、Cのみ、AおよびB、AおよびC、BおよびC、またはAおよびBおよびCとすることができ、任意のそのような組合せは、A、B、またはCの1つまたは複数のメンバーを含み得る。当業者には既知である、または後に当業者に既知になる本開示全体にわたって説明する様々な態様の要素に対するすべての構造的および機能的等価物は、参照により本明細書に明確に組み込まれ、請求項によって包含されるものとする。その上、本明細書に開示されたものは、そのような開示が特許請求の範囲に明示的に説明されているかにかかわらず、公衆にささげられることが意図されるものではない。いかなるクレーム要素も、要素が「ための手段」という語句を使用して明確に列挙されていない限り、ミーンズプラスファンクションとして解釈されるべきではない。
【符号の説明】
【０１１５】
100  LTEネットワークアーキテクチャ
102  ユーザ機器(UE)
104  発展型UMTS地上波無線アクセスネットワーク(E-UTRAN)
106  eNB
108  eNB
110  発展型パケットコア(EPC)
112  モビリティ管理エンティティ(MME)
114  他のMME
116  サービングゲートウェイ
118  パケットデータネットワーク(PDN)ゲートウェイ
120  ホーム加入者サーバ(HSS)
122  事業者のインターネットプロトコル(IP)サービス
124  マルチメディアブロードキャストマルチキャストサービス(MBMS)ゲートウェイ
126  ブロードキャストマルチキャストサービスセンタ(BM-SC)
200  アクセスネットワーク
202  セル
204  マクロeNB
206  UE
208  低電力クラスeNB
210  セルラー領域
302  セル固有RS(CRS)
304  UE固有RS(UE-RS)
410  リソースブロック
420  リソースブロック
430  物理ランダムアクセスチャネル(PRACH)
506  物理レイヤ
508  レイヤ2(L2レイヤ)
510  媒体アクセス制御(MAC)サブレイヤ
512  無線リンク制御(RLC)サブレイヤ
514  パケットデータコンバージェンスプロトコル(PDCP)
516  RRCサブレイヤ
610  eNB
616  送信(TX)プロセッサ
618  送信機
620  アンテナ
650  UE
652  アンテナ
654  受信機
656  受信(RX)プロセッサ
658  チャネル推定器
659  コントローラ/プロセッサ
660  メモリ
662  データシンク
667  データソース
668  TXプロセッサ
670  RXプロセッサ
674  チャネル推定器
675  コントローラ/プロセッサ
676  メモリ
752  eNB
752'  セル
754  eNB
754'  セル
802  セッションスケジュール
804  ファイル
806  ファイルスケジュール
812  終了属性
814  停止属性
902  スケジュール記述フラグメント
904  セッションスケジュール要素
906  ファイルスケジュール要素
908  メッセージダイジェスト5(MD5)
912  終了属性
914  停止属性
916  セッションインデックス情報
1002  FDTロケーションURI
1004  セッションスケジュール要素
1016  開始属性
1104  セッションスケジュール要素
1106  セッションインデックス
1204  セッションスケジュール
1402  装置
1404  受信モジュール
1406  関心のあるファイルモジュール
1408  ダウンロード失敗
1410  ファイル修復トリガモジュール
1504  プロセッサ
1506  コンピュータ可読媒体
1510  トランシーバ
1514  処理システム
1520  アンテナ
1524  バス
【図１】
2016526346.tif 000003
【図２】
2016526346.tif 000004
【図３】
2016526346.tif 000005
【図４】
2016526346.tif 000006
【図５】
2016526346.tif 000007
【図６】
2016526346.tif 000008
【図７Ａ】
2016526346.tif 000009
【図７Ｂ】
2016526346.tif 000010
【図８】
2016526346.tif 000011
【図９】
2016526346.tif 000012
【図１０】
2016526346.tif 000013
【図１１】
2016526346.tif 000014
【図１２】
2016526346.tif 000015
【図１３】
2016526346.tif 000016
【図１４】
2016526346.tif 000017
【図１５】
2016526346.tif 000018
【国際調査報告】
2016526346.tif 000019
2016526346.tif 000020