JP2015501093A - Ｍｂｍｓユーザサービス用のスケジュール情報を配信するための技術 - Google Patents

Abstract

ＭＢＭＳユーザサービス用のスケジュール情報を配信するための技術を提示する。本技術の方法の実装例は、繰り返し生じるイベントの形式でＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール情報を提供するステップを含む。当該スケジュールは、追加的または代替的に、開始／停止リストの形式で記述されうる。また、ユーザサービス記述（ＵＳＤ）と、当該ＵＳＤに（例えば、ＵＲＩのような識別子を介して）リンクされたスケジュール情報とが、モバイルクライアントに配信される。

Description

本開示は、全体として、マルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ：Multimedia Broadcast/Multicast Service）に関するものである。特に、ＭＢＭＳユーザサービス用のスケジュール情報を配信するための技術を提供する。本技術は、方法、コンピュータプログラムまたは装置の形式で実現されうる。

ＭＢＭＳは、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）によって規定された、ポイント・ツー・マルチポイント（ＰＴＭ：Point-To-Multipoint）のコンテンツ配信サービスである。ＭＢＭＳは、セルラ通信ネットワークにおいて複数の受信者に対する効率的な配信を可能にする。コンテンツは、コンテンツストリーム（例えば、モバイルＴＶまたは無線プログラム）またはコンテンツファイル（例えば、ニュース更新情報）の形式で配信されうる。

ＭＢＭＳ及び進化型ＭＢＭＳ（ｅＭＢＭＳ：evolved MBMS）の態様は、非特許文献１に定義されている。ＭＢＭＳに関する、特に、セルラ通信ネットワークに関連するＭＢＭＳアーキテクチャに関する更なる情報は、非特許文献２に示されている。当該文献において議論されているように、ＭＢＭＳアーキテクチャの中央コンポーネントは、いわゆるブロードキャスト・マルチキャスト・サービスセンタ（ＢＭ−ＳＣ：Broadcast Multicast Service Center）である。

ＭＢＭＳは、機能的に、ＭＢＭＳベアラサービスと、ＭＢＭＳユーザサービスとに分割される。図１は、ＭＢＭＳベアラサービスとＭＢＭＳユーザサービスとの関係を概略的に示している。

図１の下半分に示されるＭＢＭＳベアラサービスは、概して、マルチキャスト・ベアラまたはブロードキャスト・ベアラに基づいて、インターネットプロトコル（ＩＰ）レイヤより下のＭＢＭＳ送信手順に取り組む。個別のＭＢＭＳベアラサービスは、一時モバイルグループ識別子（ＴＭＧＩ：Temporary Mobile Group Identity）によって識別される。ＢＭ−ＳＣによって、単一の、グローバルに固有のＴＭＧＩが、ＭＢＭＳベアラサービスごとに割り当てられる。ＭＢＭＳベアラサービスを介したコンテンツ配信は、ＰＴＭまたはポイント・ツー・ポイント（ＰＴＰ：Point-To-Point）送信を伴いうる。

図１の上半分に占め有れるＭＢＭＳユーザサービスは、概して、例えば、サービスのストリーミングのためのリアルタイムプロトコル（ＲＴＰ）、及びファイル配信サービスのためのＦＬＵＴＥプロトコル（Internet Engineering Task Force, IETF, RFC 3926を参照。）に基づいて、アプリケーション・レイヤまたはサービス・レイヤ・プロトコル及び手順に取り組む。ＦＬＵＴＥコンテンツ配信セッションは、セッション記述プロトコル（ＳＤＰ：Session Description Protocol）ファイルにおいて定義されており、当該ファイルは、モバイルファイル配信をモバイルクライアントが受信することを可能にするパラメータを含む。このようなパラメータには、典型的には、ＩＰマルチキャストアドレス、ユーザ・データグラム・プロトコル（ＵＤＰ）ポート及びＴＭＧＩが含まれる。

現時点では、ＦＬＵＴＥ配信セッション・コンセプトの、詳細なタイミング及び／または位置情報部分は存在しない。一例として、非特許文献１においていわゆるユーザ装置（ＵＥ）とも称されるモバイルクライアントが、ＭＢＭＳベアラが開始された際にＭＢＭＳサービスエリア内にいるという保証はない。更に、ＭＢＭＳ受信機は、ＭＢＭＳ通知チャネル（即ち、ＭＢＭＳ制御チャネル、ＭＣＣＨ）を継続的にモニタリングして、ＭＣＣＨ上でＴＭＧＩによって知らされる、次回の（upcoming）ファイル配信セッションを待たなければならない。ＭＣＣＨの継続的なモニタリングは、モバイルクライアントにとってバッテリーの放電につながり、それにより、モバイルクライアントの動作時間を減少させることになる。

非特許文献３及び４では、ＭＢＭＳ送信の電力効率の良いモニタリングの問題について議論されている。それらにおいて確認されるように、関心があるアクティブＭＢＭＳベアラについてのＭＣＣＨの継続的なモニタリングと、ＭＢＭＳデータの、関連する不必要な受信は、モバイルクライアントの電力消費を増加させる。この点について、非特許文献４では、関心があるＭＢＭＳベアラが確実に非アクティブである場合に、モバイルクライアントがＭＣＣＨのモニタリングを非アクティブ化（deactivate）できるように、スケジュール情報を追加することが提案されている。具体的には、ＦＬＵＴＥファイル配信テーブル（ＦＤＴ：FLUTE File Delivery Table）に、各ファイルのブロードキャストがスケジューリングされる際に（startTime及びendTimeと称される２つのパラメータによって）時間ウィンドウを記述すべきことが提案されている。

ＦＬＵＴＥ ＦＤＴにおけるスケジュール情報の送信は、いくつかの欠点を被ることが分かっている。例えば、ＦＤＴにおけるタイミングは、ＦＬＵＴＥセッション内の（これは、帯域内情報に対してオンラインの、と称される。）ファイルにのみ適用可能である。その結果、異なる複数のＦＬＵＴＥフローにわたる（例えば、サービスクラスによって識別されるような）コンテンツのタイミングを、適切に記述することはできない。

3GPP Technical Specification (TS) 26.346. F. Hartung et al., "Delivery of Broadcast Services in 3G Net-works", IEEE Transactions on Broadcasting, Vol. 53, No. 1, March 2007, p. 188 to 199. TDoc S4-110448 (TSG-SA#64 meeting, 11 to 15 April 2011, San Diego, CA, USA). TDoc S4-110621 (TSG-SA#65 meeting, 15 to 19 August 2011, Kista, Sweden).

したがって、ＭＢＭＳユーザサービスに関連するスケジュール情報を効率的に配信することが必要である。

一態様によれば、ユーザサービス記述（ＵＳＤ）が提供されるマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービスのためのスケジュール情報を配信する方法が提示され、本方法は、ＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール情報を提供するステップであって、スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されている、当該ステップと、 ＵＳＤとスケジュール情報とをユーザ装置（ＵＥ）に配信するステップであって、ＵＳＤが、スケジュール情報へのリファレンスまたはリンクを有する、当該ステップと、を含む。

スケジュール情報及びＵＳＤは、一緒にまたは個別に配信されうる。一実装例で、スケジュール情報は、サービス告知手順の間に配信される。ＵＳＤは、同様に、ソース告知手順の間に、または他の任意の手順において配信されてもよい。

一つの変形例で、スケジュール情報は、帯域外で配信される。他の変形例で、ＭＢＭＳを介して帯域内で配信される。このような変形例で、スケジュール情報は、ＭＢＭＳデータとともに、または、代替的にはＭＢＭＳデータなしで配信されてもよい。ＭＢＭＳデータとともに帯域内で配信されるスケジュール情報は、古い（期限切れの）スケジュール情報を上書きしてもよい。

スケジュール情報は、（ＵＳＤのような）他の情報との関係で識別可能であってもよい。一例として、スケジュール情報は、多目的インターネットメール拡張（ＭＩＭＥ：Multipurpose Internet Mail Extensions）タイプによって識別されてもよい。

スケジュール情報は、更新期間または更新時間を特定してもよい。更新期間または更新時間は、経過した場合に、更新されたスケジュール情報をＵＥにフェッチさせてもよい。フェッチは、ユニキャスト（即ち、ＰＴＰ）の通信手順を介して実行されてもよい。更新時間が使用される場合、当該更新時間は、帯域内でのスケジュール情報の更新の受信に応じてリフレッシュされてもよい。

スケジュール情報は、任意のフォーマットを有しうる。一例として、スケジュール情報は、拡張マークアップ言語（ＸＭＬ）フォーマットで提供されてもよい。

ＵＳＤは、１つ以上のＭＢＭＳセッションに対して有効であってもよい。一例として、ＭＢＭＳユーザサービスセッションに含まれる複数のＭＢＭＳセッションに対して有効であってもよい。

上述のように、スケジュール情報は、ＭＢＭＳユーザサービスのためのスケジュールを記述する。当該スケジュールは、ＭＢＭＳユーザサービスセッションに含まれる複数のＭＢＭＳセッションを反映してもよい。

当該複数のＭＢＭＳセッションは、ＭＢＭＳダウンロードセッションであってもよい。一実装例では、ＭＢＭＳダウンロードセッションは、ＦＬＵＴＥプロトコルによって管理または制御されてもよい。

スケジュール情報に記述されるスケジュールは、ＵＥがいつＭＢＭＳ受信の準備を行う必要があるかをシグナリングしてもよい。対応するシグナリングは、ＭＢＭＳ受信が間近ではない場合にＵＥを電力節約モードにするために使用されてもよい。

スケジュール情報の配信は、受信位置情報の配信を伴ってもよい。受信位置情報は、ＭＢＭＳ受信のための特定の領域を識別してもよい。

一実装例では、スケジュール情報及びＵＳＤは、個別の項目としてＵＥに配信されうる。このため、ＵＳＤは、スケジュール情報自体を含まずに、当該スケジュール情報に対するリファレンスまたはリンクのみを含んでいてもよい。一例として、スケジュール情報及びＵＳＤは、個別のフラグメント、インスタンス、エレメント及びファイルのうちの少なくとも１つで配信されてもよい。一般に、スケジュール情報及びＵＳＤのいずれかまたは両方は、それ特有のファイルとして配信されてもよい。

他の態様によれば、ＵＳＤが提供されるＭＢＭＳユーザサービスのためのスケジュール情報を判定する、ＵＥによって実行される方法が提示され、本方法は、ＵＳＤとスケジュール情報とを受信するステップであって、スケジュール情報が、ＭＢＭＳユーザサービスのためのスケジュールを記述しており、スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されており、ＵＳＤが、前記スケジュール情報へのリファレンスまたはリンクを有する、当該ステップと、ＵＳＤからリファレンスまたはリンクを介してＭＢＭＳユーザサービスのためのスケジュール情報を判定するステップと、を含む。

他の態様に係る方法は、スケジュール情報に基づいて受信の準備を行うステップを追加的に含んでもよい。受信の準備を行うステップは、ＭＢＭＳセッションのためのＭＣＣＨのモニタリングを開始するステップを含んでもよい。追加的にまたは代替的に、受信の準備を行うステップは、ＵＥのＭＢＭＳチップセットをアクティブ化するステップを含んでもよい。

開始されたＭＢＭＳユーザサービスは、スケジュール情報に基づいて、ＵＥによって中断されてもよい。一例として、開始されたＭＢＭＳユーザサービスを中断するステップは、ＭＣＣＨのモニタリングを停止するステップを含んでもよい。代替的にまたは追加的に、開始されたＭＢＭＳユーザサービスを中断するステップは、ＵＥのＭＢＭＳチップセットを非アクティブ化するステップを含んでもよい。

本明細書で提示する技術は、ソフトウェアの形式、ハードウェアの形式、またはソフトウェア／ハードウェアアプローチの組み合わせを用いて、実現されうる。ソフトウェアの態様に関しては、コンピュータプログラムが（例えば、コンピューティング・デバイスの）プロセッサ上で実行された場合に、本明細書で提示される各ステップを実行するためのプログラムコード部分を含むコンピュータプログラムが提供される。メモリチップ、ＣＤ−ＲＯＭ、ハードディスク等の、コンピュータプログラムは、コンピュータで読み取り可能な記憶媒体に格納されてもよい。また、コンピュータプログラムは、そのような記憶媒体に対するネットワーク・コネクションを介したダウンロード用に提供されてもよい。

また、ＵＳＤが提供されるＭＢＭＳユーザサービスのためのスケジュール情報を配信する装置が提供され、当該装置は、ＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール情報を提供するよう構成された機能部であって、スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されている、当該機能部と、ＵＳＤとスケジュール情報とをＵＥに配信するよう構成された機能部であって、ＵＳＤが、スケジュール情報へのリファレンスまたはリンクを有する、当該機能部と、を備える。

本装置は、スケジュール情報を種々の方法で配信するよう構成されうる。一例として、スケジュール情報は、サービス告知手順の間に配信されうる。追加的にまたは代替的には、スケジュール情報は、帯域外で、またはＭＢＭＳを介して帯域内で、配信されてもよい。特に後者の場合、スケジュール情報は、ＭＢＭＳデータとともに（または代替的には、そのようなデータなしで）配信されてもよい。

スケジュール情報は、１つ以上の追加のパラメータを特定しうる。一例として、スケジュール情報は、更新期間または更新時間を特定しうる。

更に他には、ＵＳＤが提供されるＭＢＭＳユーザサービスのためのスケジュール情報を判定するＵＥが提供され、当該ＵＥは、ＵＳＤとスケジュール情報とを受信するよう構成された機能部であって、スケジュール情報が、ＭＢＭＳユーザサービスのためのスケジュールを記述しており、スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されており、ＵＳＤが、スケジュール情報へのリファレンスまたはリンクを有する、当該機能部と、ＵＳＤからリファレンスまたはリンクを介してＭＢＭＳユーザサービスのためのスケジュール情報を判定するよう構成された機能部と、を備える。

また、本明細書で提示される、スケジュール情報を提供する装置と、ＵＥと、を備えるＭＢＭＳシステムが提供される。当該ＭＢＭＳシステムは、ＭＢＭＳ及びｅＭＢＭＳ仕様のいずれかに適合してもよい。

本明細書に示す技術の他の態様、詳細及び利点は、図面とともに、例示的な実施形態についての以下の説明から明らかになる。

ＭＢＭＳベアラサービス及びＭＢＭＳユーザサービスの概要を概略的に示す図。 単一のＴＭＧＩに関連付けられた複数のＭＢＭＳセッションを概略的に示す図。 、 ＭＢＭＳサービスエリアとＵＥとの間の、可能性のある地理的関係を示す図。 スケジュール情報配信器及びスケジュール情報受信者についての第１の装置の実施形態を示す図。 図４のスケジュール情報配信器及びスケジュール情報受信者を動作させる方法の実施形態を示す図。 スケジュール情報配信器及びスケジュール情報受信者についての第２の装置の実施形態を示す図。 図４または図６のようなスケジュール情報受信者についての、より詳細な装置の実施形態を示す図。

例示的な実施形態についての以下の説明では、限定ではなく説明を目的として、本明細書に示す技術の深い理解を提供するために、シグナリングステップについての具体的な系列のような具体的な詳細を説明している。本技術がこれらの具体的な詳細から離れた他の実施形態においても実施可能であることは、当業者には明らかになろう。

また、プログラムされるプロセッサとの併用で機能するソフトウェア、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit）、デジタルシグナルプロセッサ（ＤＳＰ：Digital Signal Processor）、または汎用コンピュータを使用して、以下の部分で説明されるサービス、機能及びステップが実現されうることは、当業者に理解されよう。また、以下の実施形態は主として方法及び装置との関連で記述されるものの、そこに示される技術は、コンピュータプログラムで実施されうるとともに、コンピュータプロセッサ及び当該プロセッサに結合したメモリを備えるシステムでも実施されうることも、理解されよう。なお、当該メモリは、本明細書で開示するサービス、機能及びステップをプロセッサに実行させる１つ以上のプログラムを用いてエンコードされる。

以下では、まず、本明細書で示す技術の実施形態を実施可能なＭＢＭＳシステムの特定の態様について説明する。以下で説明するＭＢＭＳシステムは、機能的には上述の図１に図示されるように実現されうる。

非特許文献１では、ＭＢＭＳユーザサービス及びＭＢＭＳユーザサービスセッション（第４．２節を参照。）と、ＭＢＭＳセッション（ブロードキャストセッション及びマルチキャストセッションは、第３．１節に定義されている。）と、を区別している。ＭＢＭＳセッションは、ＭＢＭＳベアラ識別子（即ち、ＴＭＧＩ）と、ＭＢＭＳセッションが開始された特定のＭＢＭＳサービスエリアと、によって定義される。ＭＢＭＳベアラ上のＭＢＭＳセッションは、ＭＢＭＳセッション開始手順（MBMS Session Start Procedure）によって開始され、ＭＢＭＳセッション停止手順を用いて非アクティブ化される。

以下の実施形態の一部では、「配信セッション（Delivery Session）」という用語は、ＭＢＭＳユーザサービスセッションに対する同義語として使用される。配信セッションは、そのような実施形態との関連で、（例えば、ＦＬＵＴＥプロトコルに基づく）「ＭＢＭＳダウンロードセッション（MBMS Download Sessions）」に限定されうる。配信セッションのタイミング（即ち、t-line）は、従来は、ＭＢＭＳセッションのタイミングに関する何らの情報も提供していない（配信セッションは、一般に、複数のＭＢＭＳセッションに対して及びうる。）

配信セッションは、ＵＳＤファイルと一緒にＳＤＰファイルによって定義される。ＳＤＰファイルは、コンテンツを配信するために使用されるＭＢＭＳベアラを識別するＴＭＧＩを含む。ＳＤＰファイルは、本明細書でＵＥとも称されるモバイルクライアントに対して、サービス告知（ＳＡ：Service Announcement）の期間に提供される

ＭＢＭＳベアラサービスの定義は、ＭＢＭＳ通知フェーズ（MBMS Notification Phase）を含み、これは、ネットワークが、ＭＢＭＳサービスエリア（対象ブロードキャストエリア）の内部のＵＳに、間近の（imminent）ＭＢＭＳ送信（非特許文献１を参照。）に関して知らせることを可能にする。上記で示したように、ＭＢＭＳベアラは、ＴＭＧＩによって識別され、ＴＭＧＩは、グループ識別子と見なすことができる。ＭＣＣＨは、特定のセルにおけるアクティブなＭＢＭＳベアラに関する情報を搬送する。ネットワークは、ＵＥがＭＣＣＨを常に読み取る必要がないように、ＭＣＣＨのあらゆる変更を明示的に知らせる。ＵＥは、関心があるＴＭＧＩを、サービス・レイヤまたはアプリケーション・レイヤで配布されるサービス告知（Service Announcement）から把握している。

ＭＢＭＳベアラサービスを使用するＭＢＭＳセッションは、ＭＢＭＳセッション開始及び停止手順を使用して、ＢＭ−ＳＣから開始または停止されうる。無線ネットワークは、ＭＢＭＳセッション開始及び停止の結果として、ＭＣＣＨのコンテンツを変更する。ＭＢＭＳセッションは、特定のＭＢＭＳサービスエリアにおいて開始されうる。ＭＢＭＳサービスエリアは、モバイル通信ネットワーク（例えば、特定の公衆陸上モバイルネットワーク（ＰＬＭＮ：Public Land Mobile Network））よりも狭い場合がある。ＵＥは、ＭＢＭＳサービスエリア内に位置する場合、ＭＢＭＳベアラを介してＭＢＭＳセッションのＭＢＭＳデータの受信のみが可能である。

ＭＢＭＳセッションは、例えば、ライブビデオ及びファイル配布のサービスのために使用されうる。両タイプのサービスは、時間で制限される場合があるとともに、ある地理的領域において（即ち、ＭＢＭＳサービスエリア内）のみ利用可能である場合もある。サービス告知情報（ＳＤＰファイル及びＵＳＤファイル）は、従来、ＭＢＭＳセッションがいつ開始または停止されるのかに関するタイミング情報を含んでいなかった。ＳＤＰファイルは、ＭＢＭＳベアラがアクティブである時間よりもずっと長い時間、有効であってもよいことに留意されたい。また、ＳＤＰファイルは、継続的なＭＢＭＳセッション（非特許文献１の第５節を参照。）を使用したデータ配信を記述してもよい。この状況の結果として、ＵＥは、（ＴＭＧＩによって識別される）関心があるＭＢＭＳベアラが開始されたか否かを判定するために、ＭＢＭＳ ＭＣＣＨを継続的にモニタリングしなければならない。

上述のように、ＭＢＭＳサービス告知情報（ＳＤＰ及びＵＳＤファイル）は、１つ以上のＭＢＭＳセッション（即ち、継続的なＭＢＭＳセッション）について有効であってもよい。これは、（ＴＭＧＩによって識別される）ＭＢＭＳベアラが、ＴＭＧＩ番号Ｘ（「ＴＭＧＩ ＃Ｘ」）のＭＢＭＳベアラ上のフラグメント化されたＭＢＭＳセッションに対して、図２に示すように、何回か開始及び停止されうることを意味する。図２では、例えば、１４００ｈと１６００ｈとの間の２回のその後の土曜日に、ＭＢＭＳセッションは２回開始されている。そのＭＢＭＳベアラのコンテンツに関心があるＵＥは、従来、このスケジュールについて認識していなかった。３ＧＰＰ仕様によれば、それらのＵＥは、ＭＢＭＳベアラの開始について、ＭＣＣＨを継続的にモニタリングしなければならない。このようなモニタリングは、明らかに、バッテリーの電力を不必要に消費する。

また、ＵＥは、ＭＢＭＳセッションがアクティブである間にＵＥがＭＢＭＳサービスエリア内に位置している場合にのみ、当該ＭＢＭＳサービスエリアについて認識している。この場合、ＵＥは、ＭＣＣＨ上で関心のあるサービスのＴＭＧＩを見つけ出す。ＵＥがＭＢＭＳサービスエリア外に位置している場合、またはＭＢＭＳセッションがアクティブではない場合、ＵＥは、ＭＢＭＳサービスエリアを認識していない。

図３Ａ及び図３Ｂは、これらのシナリオを示している。図３ＡのＵＥは、ＭＢＭＳサービスエリア内に位置している。ＴＭＧＩ ＃ＸのＭＢＭＳセッションがアクティブである場合、ＵＥは、ＭＣＣＨ上でＴＭＧＩ ＃Ｘを見つけ出し、関連するコンテンツを受信することが可能である。ＭＢＭＳセッションがアクティブではない場合、ＵＥは、トラフィックを全く受信していない理由を決定することはできない。ＵＥがＭＢＭＳサービスエリア外に位置しているか、または、ＴＭＧＩ ＃ＸのＭＢＭＳベアラが開始されていないことを理由として、当該ＵＥは、ＭＢＭＳトラフィックを受信しない。

図３のＵＥは、ＭＢＭＳサービスエリア外に位置している。当該ＵＥは、やはり、ＴＭＧＩ ＃ＸのＭＢＭＳベアラのコンテンツを受信していない理由を決定することはできない。

「ＭＢＭＳセッションがアクティブである間に、ＵＥがＭＢＭＳサービスエリア内に位置している」確率は、サービスタイプ及びユーザの挙動に依存する。例えば、ＵＥのユーザが郊外または地方のエリアに住んでいる場合、当該ＵＥがＭＢＭＳサービスエリア内に位置している頻度は低い。

下記の実施形態に示す一態様は、ＵＥ上で開始されたＭＢＭＳユーザサービスが、関心のあるＭＢＭＳベアラについてのＭＣＣＨのモニタリングを「中断している（pausing）」というコンセプトに基づいている。そのために、以下でより詳細に説明するように、ネットワークが、スケジュールと、オプションとして受信位置情報とを、ＵＥに提供する。

図４は、２つの装置４００，４２０の実施形態を含むＭＢＭＳシステムの一実施形態を示している。具体的には、スケジュール（またはタイミング）情報を配信するための（以下ではスケジュール情報配信器（ＳＩＤ：Schedule Information Deliv-erer）とも称される）装置４００と、ここでは当該スケジュール情報を受信するためのモバイルクライアントとして構成されたＵＥ４２０と、が描かれている。スケジュール情報は、ＭＢＭＳユーザサービスのために提供される。ＭＢＭＳユーザサービス、またはそのセッションは、非特許文献１（例えば、第５節を参照。）に大まかに記載されているように、ＵＳＤに関連付けられている。

図４に示すように、ＳＩＤ４００は、スケジュール情報プロビジョニング機能４０２と、ＵＥ４２０と通信可能な配信機能４０６とを備える。ＳＩＤ４００は、ＢＭ−ＳＣの一部として、またはＢＭ−ＳＣの形式で、実現されうる。一方、ＵＥ４２０は、ＳＩＤ４００の配信機能４０６と通信可能な受信機能４２２とを備える。更に、判定機能４２４がＵＥ４２０に備わっている。

ＳＩＤ４００の配信機能４０６は、スケジュール情報及びＵＳＤを、ＵＥ４２０の受信機能４２２に配信するよう構成される。一実装例では、ＵＳＤとスケジュール情報との両方は、情報の別々の項目として配信されるものの、サービス告知手順の間に一緒に配信される。他の実装例では、ＵＳＤとスケジュール情報とは、異なる時点に配信されうる。また、代替的な手順が配信のために用いられてもよい。

以下では、図５のフロー図５００を参照して、ＳＩＤ４００及びＵＥ４２０の動作をより詳細に説明する。

最初のステップ５２０で、ＳＩＤ４００の情報プロビジョニング機能４０２は、ＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール（またはタイミング）情報を提供する。当該スケジュールは、１つ以上の繰り返し生じる（re-occurring）イベントの形式で記述される。当該スケジュールは、１つ以上の開始／停止リストの形式で、追加的にまたは代替的に記述される。

ステップ５２０の後、ＳＩＤ４００の配信機能４０６は、ステップ５３０で、ＵＳＤ及びスケジュール情報を、情報の異なる項目として（オプションとしては、間隔を空けた時点に、即ち、個別に）ＵＥ４２０に配信する。当該配信は、ＦＬＵＴＥプロトコル（図１を参照。）を介して、次回のまたは前回開始されたＭＢＭＳダウンロードセッションに対して生じうる。

ステップ５３０で配信されるＵＳＤは、スケジュール情報に対するリファレンスまたはリンクを有する。ここで、ＵＳＤは、スケジュール情報それ自体は含まないものの、リファレンスまたはリンク（例えば、プレーン識別子（plain identifier）、ユニフォーム・リソース識別子（ＵＲＩ：Uniform Resource Identifier）等）を含む。当該リファレンスまたはリンクは、ＵＥ４２０が、スケジュール情報及び他の部分を識別または判定することを可能にする。このため、スケジュール情報は、ＵＳＤに含まれている、またはＵＳＤとともに送信される必要はなく、また、ＵＳＤ及びスケジュール情報は、同時に配信される必要はない。また、このアプローチは、（このようなケースでは、ＵＳＤは再度配信される必要はないため）スケジュール情報の容易な更新を可能にする。

配信ステップ５３０は、少なくともＵＳＤが関係する限り、サービス告知手順との関連で生じうる。スケジュール情報は、同様にサービス告知手順の間に、またはそれより後の時点に、帯域内（ＭＢＭＳを介して、オプションとしてＭＢＭＳデータとともに）または帯域外で配信されうる。

ＵＳＤ及びスケジュール情報は、図５のステップ５４０によって示されるように、ＵＳ４２０の受信機能４２２によって、同時にまたは異なる時点に受信される。更なるステップ５５０で、判定機能４２４は、ＵＳＤからのリンクまたはリファレンスを用いてスケジュール情報（の位置）を判定する。これと関連して、判定機能４２４は、ＵＳＤから（例えば、共通識別子を用いて）スケジュール情報を参照（逆参照）してもよい。

図５に示されていない更なるステップでは、ＵＥ４２０は、スケジュール情報のコンテンツを処理しうる。このような処理との関連で、ＵＥ４２０は、スケジュール情報に基づいて受信の準備を行いうる（例えば、ＵＥ４２０は、ＵＥのＭＢＭＳチップセットをアクティブ化することによって、または別の方法で、ＭＢＭＳセッションについてＭＣＣＨのモニタリングを開始してもよい。）。また、ＵＥ４２０は、スケジュール情報に基づいて（例えば、ＭＣＣＨのモニタリングを停止することによって、ＵＥ４２０のＭＢＭＳチップセットを非アクティブ化することによって、またはその両方によって）、開始されたＭＢＭＳユーザサービスを中断しうる。ＵＥ４２０は、１つ以上のそれらの手順を実行するよう構成された適切な機能（図示せず）を備えうる。

図６は、ＳＩＤ４００及びＵＥ４２０についての２つの代替的な装置の実施形態を示している。本実施形態では、ＵＳＤ及びスケジュール情報は、専用のファイル（またはファイルの一部分）を介して配信される。追加としてまたは代替的には、ＵＳＤ、リンク（またはリファレンス）及びスケジュール情報のうちの少なくとも１つは、非特許文献１（例えば、第５節を参照。）に定義されているようなメタデータ・フラグメントを含みうるか、またはメタデータ・フラグメントの形式で配信されうる。

図６に示されるように、ＳＩＤ４００は、情報ファイルプロビジョニング機能６０２、参照機能６０４、及びＵＥ４２０を通信可能な配信機能６０６を備える。ＳＩＤ４００の情報ファイルプロビジョニング機能６０２は、情報ファイルを提供するよう構成される。情報ファイルは、スケジュール（またはタイミング）情報を含む。ＳＩＤ４００の参照機能６０４は、ＵＳＤファイルから情報ファイルを参照する。そのために、ＵＳＤファイルと情報ファイルとは、互いに関連付けられているか、またはリンクされている。ＳＩＤ４００の配信機能６０６は、ＵＳＤファイルだけでなく情報ファイルをＵＥ４２０に配信するよう構成されている。一実装例では、両ファイルは、サービス告知手順の間に一緒に配信される。他の実装例では、それらのファイルは個別に配信されうる。

ＵＥ４２０は、ＳＩＤ４００の配信機能６０６と通信可能な受信機能４２２を同様に備える。更に、参照機能４２４がＵＥ４２０に備えられている。参照機能４２４は、ＵＳＤファイルからのリンクまたはリファレンスを用いてスケジュール情報を判定するために、ＵＳＤファイルから情報ファイルを参照（逆参照）する。このように、当該参照機能は、図４の判定機能４２４と機能的に対応している。

以下では、図４、図５及び図６に大まかに示される装置及び方法の実施形態をより詳細に説明する。具体的には、まず（オプションの位置情報と部分的に組み合わせて）、（オプションである）スケジュールファイル、スケジュール情報及びスケジュールについてのより詳細な実施形態を提示する。その後、スケジュール情報（及びオプションの位置情報）を処理及び利用するための種々の実施形態を説明する。

ＭＢＭＳユーザサービスのスケジュールは、概して、期間の形式で（ユーザサービスは、Ｘ秒後に再びモニタリングを開始しなければならない）、繰り返し生じるイベントの形式で（ユーザサービスは、１４００ｈと１６００ｈとの間の土曜日ごとに、関連するＭＢＭＳベアラをモニタリングしなければならない）、または、開始／停止リストの形式で、情報ファイル内に記述されうる。

図４及び図６に示すようなＵＥ４２０は、ＭＢＭＳサービスエリアからいつでも離れる可能性があるため（図３Ｂを参照）、（以下ではスケジュールファイルとも称されうる）情報ファイルは、「最小更新期間」を記述していてもよい。最小更新期間が経過し、かつ、ＵＥ４２０がＭＢＭＳデータとともに帯域内で更新情報を全く受信していない場合、ＵＥ４２０は、ユーザサービス用の更新されたスケジュール情報をフェッチ（fetch）するためにユニキャスト（即ち、ＰＴＰ）を使用しうるか、または使用しなければならない。更新メカニズムの意図は、ＵＥ４２０がＭＢＭＳサービスエリアから離れたとしても、上記ソリューションが機能し続けるようにすることである。

オプションの受信位置情報は、ここでは、セルＩＤ（Cell ID）または位置エリアコード（ＬＡＣ：Location Area Code）に基づきうる。セルＩＤ及びＬＡＣの両方は、アイドルモードにあるＵＥによって受信可能である。最新の電話機のオペレーティングシステムは、位置をモニタリングするためのアプリケーション・プログラミング・インタフェース（ＡＰＩ）（例えば、アンドロイドではCellLocation API）を提供する。受信位置情報は、セルＩＤまたはＬＡＣのリストの形式で記述可能であり、この場合、ＭＢＭＳユーザサービスは、データ配信用のＭＢＭＳベアラ（即ち、ＭＢＭＳサービスエリア）を使用する。

ＭＢＭＳサービスエリアは、非常に広く、地域全体をカバーしうる。このため、ＭＢＭＳサービスエリアが非常に広い場合、（受信位置情報を有する）ファイルは、非常にサイズが大きくなりうる。大きなファイルの問題を克服するためのソリューションは、受信位置記述ファイルを複数の部分に分割することを許容して、更新領域を記述することであり、即ち、ＵＥ４２０が記述された領域から離れた場合に、ＵＥ４２０は当該ＵＥ自体の位置を提供する受信位置ファイルを更新しなければならない。

スケジュール及び受信位置情報ファイルは、
・サービス告知の間に、ユーザサービス記述（ＵＳＤ）ファイルからのリファレンスとして、
・ＭＢＭＳデータとともに帯域内で、
ＵＥ４２０に配信されてもよい。

スケジュール及び受信位置情報ファイルは、例示的なＭＩＭＥタイプ「application/mbms schedule-and-rx-location+xml」によって識別されてもよい。ＭＢＭＳダウンロード受信機（即ち、ＵＥ４２０）が当該ＭＩＭＥタイプを有するファイルを見つけた場合、当該受信機は、スケジュール及び受信位置情報ファイルをそれに応じて処理する。

スケジュール及び受信位置情報ファイルの例は、例示的なＸＭＬフォーマットにより、以下で与えられる。

ここでは、scheduleエレメントは、開始及び期間情報、即ち、いつＵＥがＭＢＭＳ受信の準備（ＭＢＭＳセッションについてのＭＣＣＨのモニタリングの開始）を行わなければならないのか、を提供する。明示的なリストではなくスケジュールを記述するための他の代替案が存在する。

ｎｔｐタイムスタンプ 3529490400 は、１１月５日、土曜日、１４００ｈ（ＣＥＴ）に相当する。ｎｔｐタイムスタンプ 3530095200 は、１１月１２日、土曜日、１４００ｈ（ＣＥＴ）に相当する。ｎｔｐタイムスタンプ 3530304000 は、１１月１５日、００００ｈ（ＣＥＴ）に相当し、これは、ＵＥが遅くとも更新情報を受信すべきであった時間である（なお、その値は、ＵＥが帯域内で更新情報を受信した際にリフレッシュされる）。

ReceptionLocationエレメントは、粗粒（coarse-grain）の受信位置情報（LAC）と、微粒（fine-grain）の受信位置情報（Cell）とを提供する。

上記の実施形態は、一例として、以下のように例示的な３ＧＰＰ環境において実装されうる。

ＴＳ ２６．３４６（非特許文献１）は、関連するＭＢＭＳセッションのスケジュールと、更に受信位置情報とを記述した、オプションの「スケジュール及び受信位置」情報ファイルによって拡張されうる。これにより、ＵＥ４２０は、開始されたＭＢＭＳユーザサービスを中断する（必要がない場合にＭＢＭＳユーザサービスのＴＭＧＩについてのＭＣＣＨモニタリングを停止する）ことが可能になる。スケジュール情報を提供することのみが可能であり、また、位置情報を提供することのみが可能である必要がある。言い換えれば、位置情報は、例えば、オプションであってもよく、このため省略されてもよい（スケジュール情報を有する「ピュアな」情報ファイルを生じさせる）。

スケジュール及び受信位置情報ファイルは、ＭＢＭＳを介して帯域内で、またはＨＴＴＰを介して帯域外で受信可能となるように、それ特有のファイルであってもよいか、またはそれ特有のファイルである必要がある。当該ファイルは、ＵＳＤからリンクされてもよく、また、ＭＢＭＳデータによって帯域内で更新（上書き）されてもよい。

スケジュール及び受信位置情報ファイルは、更新を可能にしてもよいか、または更新を可能にする必要がある。少なくともタイマーに基づく更新メカニズムが存在してもよいか、または存在する必要がある。

以下では、例示的な３ＧＰＰシステムに関連して、他のいくつかの実施形態を説明する。この説明は、本明細書で説明しているような全体的な特徴に沿った他のシステムに対して一般化されうることが、理解されるべきである。３ＧＰＰに関連して、本開示は、図４及び図６のＵＥ４２０（ユーザ端末）がどのようにモバイルファイル・ブロードキャスト配信を効率的に受信するのかについてのメカニズムを提案する。以下の実施形態は、情報ファイルによって受信されるようなスケジュール情報及び受信位置情報の少なくともいずれかを（例えば、図４、図５及び図６を参照。）、どのように利用できるのかについてのシナリオを、部分的に提示する。

ここで、ユーザ端末または電話機という用語は、データネットワークにおいてデータの送信及び受信が可能な任意のＵＥ４２０の一般化である。特に、電話機は、（ＭＢＭＳダウンロード配信方法としても知られる）ＭＢＭＳファイル配信の受信が可能である必要がある。

一般論として、ＵＥ４２０は、ＭＢＭＳ受信部分を非アクティブ化するよう構成されており、特に、次回のマルチキャスト送信を知らせるよう構成された制御チャネルのモニタリングを、ＵＥ４２０上のアプリケーションが一般にこのサービスのマルチキャスト受信用に登録されていたとしても非アクティブ化するよう構成されている。特に、モニタリングの非アクティブ化及びアクティブ化は、（例えば、図４、図５及び図６を参照して上述したように）スケジュール及び受信位置情報に基づいている。

マルチキャスト送信は、例えば３ＧＰＰ ＭＢＭＳセッションに関しては、ＭＢＭＳベアラ上で提供される。上記で説明したように、ＭＢＭＳセッションは、ＴＭＧＩ（図２を参照。）のような、グループを識別可能な任意の識別子によって識別されうる。ＴＭＧＩは、サービス告知手順の間に提供されうる。更に、ＭＢＭＳセッションの一部は、ユーザにとって特に関心のあるものとして識別されうる。これは、３ＧＰＰに関しては、関心のあるＴＭＧＩを用いて行われうる。

一実施形態では、上記の制御チャネルはＭＣＣＨである。次回のマルチキャスト送信は、ＭＣＣＨ上の情報にわたって、関連するトラフィックチャネルに関連付けられたＴＭＧＩをリストすることによって、ＭＣＣＨ上で通知される。以下では、ＭＣＣＨモニタリングまたはＭＢＭＳモニタリングという用語はこの観点で使用される。

上記で説明したように、本実施形態では、関心のあるサービスのための次回のマルチキャスト送信が確実に存在しない際（時間）及び場所（位置）で、ＵＥ４２０が、マルチキャスト制御情報の受信を非アクティブ化（これにより、ＭＣＣＨモニタリングを非アクティブ化）できるようにすることを提案する。一般に、この手順は、関心のあるグループ識別子（例えば、ＴＭＧＩ）についてＵＥ４２０が連続的にＭＣＣＨをモニタリングすることを避けるために、ＵＥ４２０が、上記のマルチキャスト送信を受信することに関心がある少なくとも１つのアプリケーションを含む場合に適用される。

上記で説明したように、ＵＥ４２０が、詳細なスケジューリング及び受信エリア情報（またはその更新情報）を受信可能であることを提案する。これは、ＭＢＭＳファイル配信方法の一部として、またはハイパーテキスト転送プロトコル（ＨＴＴＰ）を用いて、実現されうる。

一変形例では、ファイルが（例えば、ＦＬＵＴＥプロトコルによって搬送される）ＭＢＭＳダウンロード配信を介して受信される場合、配信方法ハンドラ（Delivery Method Handler）が、任意の利用可能かつ望ましい方法に基づいて、例えば、固有のＭＩＭＥタイプまたは周知のファイル名／ＵＲＩを用いて、受信ファイルを識別することを提案する。上記の情報は、ＭＣＣＨチャネルをアクティブ化及び非アクティブ化するために転送されうる。

ＵＥ４２０は、その（大まかな）位置を、任意の利用可能かつ望ましい方法に基づいて、例えば、位置エリアコード（ＬＡＣ）またはセルＩＤに基づいて、あるいはシステムによって提供される地理座標（Geo-Coordinates）にさえ基づいて、把握しうる。あるいは、ＵＥ４２０は、位置情報を決定するために、グローバル・ポジショニング・システム（ＧＰＳ）または他の任意の衛星ベースのポジショニング・システムを用いうる。ＵＥ４２０内のスケジュール及び受信位置処理（Schedule and Reception Location Handling）機能は、関心のあるサービスのためのＭＢＭＳ受信についてのアクティブ化または非アクティブ化の必要性を、連続的に（またはタイマーを通して）モニタリングしうる。

更に、スケジュール情報が、サービスのためのＭＢＭＳモニタリングをアクティブ化及び非アクティブ化することを示す場合に、ＵＥ４２０が、まず、位置情報をチェックし、現在の位置においてＭＢＭＳ受信が可能であるか否かをチェックすることを提案する。

これにより、ＵＥ４２０は、カバレッジ内に位置していないことが確実である場合、特に、サービス用のスケジュール情報において示されるような、当該サービスに対して計画されたファイル配信トラフィックがほとんど存在しない場合に、（例えば、ＭＢＭＳチップセットに関する）ＭＢＭＳ受信部分を非アクティブ化するよう構成されうる。

他の変形例では、通信システムのＵＥ４２０は、提示した方法に対して適応しうる。この場合、ＵＥ４２０は、１つ以上のサービスのためのスケジュール及び受信位置情報に基づいて、ＭＣＣＨモニタリングをアクティブ化及び非アクティブ化するよう構成された処理エンティティを備えうる。更に、スケジュール及び受信位置情報ファイル（またはその更新情報）を処理するよう構成された処理エンティティを有することを提案する。当該エンティティは、スケジュール及び受信位置処理機能によって実現されうる。

図７に示される一実施形態では、ＵＥ４２０が、（それぞれ、レイヤ１（ＰＨＹ）、レイヤ２（ＲＬＣ／ＭＡＣ）、レイヤ３（ＲＲＣ）を処理する）１つ以上のＭＢＭＳチップセット４３０と、ＭＢＭＳミドルウェア４３２（ＭＢＭＳダウンロード配信方法処理以下のＩＰレイヤ）と、１つ以上のＭＢＭＳ使用可能アプリケーション４３４とを備えることを提案する。ＭＢＭＳ無線チップセット４３０は、モデムとも称され、他の無線関連機能と統合されうる。スケジュール及び受信位置処理機能４３６は、望ましくは、ミドルウェア４３２内に位置付けられる。スケジュール及び受信位置処理機能４３６は、図４及び図６を参照して上述した受信機能４２２及び参照機能４２４を備えうる。代替的な実装例では、参照機能４２４が、スケジュール及び受信位置処理機能４３６にとどまる一方で、受信機能４２２は、ＭＢＭＳ無線チップセット４３０によって完全にまたは部分的に実現されうる。

一実装例によれば、ＭＢＭＳミドルウェア４３２は、（スケジュール及び受信位置処理機能４３６によって処理される）スケジュール及び受信位置情報に基づいて、（特に、関心のあるＴＭＧＩについての、ＭＣＣＨのモニタリングの非アクティブ化に関して）ＭＢＭＳチップセット４３０を制御（アクティブ化／非アクティブ化）できるようにされる。「関心のある（複数の）ＴＭＧＩ」は、関心のあるマルチキャスト送信またはＭＢＭＳセッションを固有に示す。これにより、ＵＥ４２０（例えば、電話機）が、ＭＣＣＨモニタリングを避けることで（ＭＢＭＳ物理チャネルを受信しないことで）バッテリーを節約することが可能になる。このように、情報を処理してそれに応じてＭＢＭＳチップセット４３０を制御（これにより、ＭＢＭＳ物理チャネルの受信を制御）するよう構成されたスケジュール及び受信位置処理機能４３６のような、個別のミドルウェア機能を提供することを提案する。

図７は、クライアント側のプロトコルスタック（電話機）と、更に汎用ＭＢＭＳミドルウェア機能とを示している。ＭＢＭＳミドルウェア４３２は、ＦＬＵＴＥ（ＲＦＣ ３９２６）、及び、オプションとして、Ｒａｐｔｏｒ、ＬＤＰＣまたはリードソロモンＦＥＣのような、アプリケーション・レイヤの前方誤り訂正（ＦＥＣ：Forward Error Correction）等の、いくつかの新たなプロトコルを実装する。ＭＢＭＳミドルウェア４３２は、ＨＴＴＰ、転送制御プロトコル（ＴＣＰ）及びＵＤＰ等の利用可能なプロトコルと、位置情報等の利用可能な機能とを再利用しうる。ＭＢＭＳミドルウェア・プロトコル及び機能を、通信及びＧＵＩ処理用の汎用機能も含む、Ａｎｄｒｏｉｄのようなオペレーティングシステム（ＯＳ）に統合することが可能であってもよい。

ＨＴＴＰのような既存の（ユニキャスト）プロトコルは、（無線モデムとも称される）ユニキャスト無線チップセット４３８の既存のユニキャスト機能を使用する。ＦＬＵＴＥ等の新たなＭＢＭＳ／ブロードキャスト・プロトコルは、既存のユニキャストチップの拡張として実現されるか、または個別のチップセットとしてさえ実現されうる、新たなＭＢＭＳ関連チップセット／モデム機能を使用する。

汎用ミドルウェア機能は、制御機能を使用して無線プロトコルを制御する。ＭＢＭＳのケースでは、ミドルウェア４３２は、ＭＢＭＳベアラの受信をアクティブ化または非アクティブ化し、当該ＭＢＭＳベアラは、（少なくとも１つのサービスに対して、やはり固有に関連付けられている）ＴＭＧＩによって識別される。ミドルウェア４３２が（サービス告知を通じてＵＥ４２０に対して提供された、ＴＭＧＩを通じて識別される）ＭＢＭＳベアラの受信をアクティブ化する場合、無線レイヤは、現在受け入れられているセルからの、関心のあるＭＢＭＳベアラの存在をモニタリングするために、ＭＣＣＨの受信をアクティブ化する。

ＴＭＧＩがＭＣＣＨ上ですぐに見つからない場合、チップセット４３０は、ＭＣＣＨを連続的に受信して、関心のある（複数の）ＴＭＧＩの入手可能性をモニタリングしてもよい。

一実施形態では、ネットワーク内に位置している（図４及び図６のＳＩＤ４００のような）制御ノードが、クライアントに対して、マルチキャスト配信ファイルに関する詳細なスケジューリング及び受信エリア情報を（オプションとして、サービスごとに個別に）提供するよう構成されることを提案する。

一実施形態では、制御ノードが、詳細なスケジューリング情報と、更にＭＢＭＳブロードキャスト・カバレッジ情報（または端末の視点からの受信エリア）とを提供することを提案し、当該カバレッジ情報は、電話機（例えば、ＭＢＭＳミドルウェア４３２）におけるＭＢＭＳダウンロード配信方法の実装を処理する能力を有するユーザ端末で自動的に処理される。

一実施形態では、（例えば、スケジュール及び受信位置処理機能内の）制御ノードが、スケジュール情報を生成するために、マルチキャスト配信に関する情報を使用することを提案する。例えば、オペレータは、夜間にのみコンテンツを配信するために、ファイル配信セッションを使用してもよい。更に、毎晩のキャッシュ・フィル（cache fill）または週末のスポーツイベントのような一部のＭＢＭＳサービスは、固定のスケジュールを有している。

また、制御ノードは、対象ブロードキャストエリアに関する情報を有するように構成されてもよい。

他の一実施形態では、任意の利用可能かつ望ましい方法で、例えば、繰り返し生じるイベント、開始／期間リスト、開始／停止リスト、または非アクティブ化期間も提供することによって、送信のスケジューリングが示され、端末が、受信したスケジュールに従って、ＭＢＭＳ受信機（ＭＢＭＳ物理チャネルを受信するためのチップセット部分）をアクティブ化／非アクティブ化することを提案する。

他の一実施形態では、通信システムの（図４及び図６のＳＩＤ４００のような）制御ノードは、提示した方法に対して適応しうる。この場合、制御ノードは、ブロードキャスト・カバレッジ及びサービス時間を含む、ＭＢＭＳファイル配信に関する情報を受信するための受信機と、スケジューリング情報及びＭＢＭＳブロードキャスト・カバレッジ情報を生成するための処理ユニットとともに、スケジューリング情報をユーザ（即ち、ＵＥ４２０）に向けて送信するための（図４または図６のそれぞれの配信機能４０６または６０６のような）送信機と、を備える。

以下では、３ＧＰＰシステムに関連して、実施形態のより詳細な例を説明する。しかし、この説明が、基本的なコンセプトの下で説明されるような全体的な特徴に沿った他のシステムに対して一般化されうることが、理解されるべきである。

本明細書で提示する一態様は、詳細なスケジューリングを提供するとともに、オプションで、ＭＢＭＳファイル配信方法の一部として受信エリア情報を提供するものである。本発明は、次回の送信が確実に存在しない際（時間）、及びオプションで、次回の送信が確実に存在しない場合（位置）に、図４及び図６のＵＥ４２０のような端末がＭＢＭＳ受信をオフにする（これにより、ＭＣＣＨモニタリングをオフにする）ことができるようにするものである。毎晩のキャッシュ・フィルまたは週末のスポーツイベントのような一部のＭＢＭＳサービスは、固定のスケジュールと、既知の対象ブロードキャストエリアとを有している。

（上述の情報ファイルの実装例としての）専用のスケジューリング及び受信位置フラグメントは、関連する配信手順の記述のように帯域内で配布されうるか、または、ＭＢＭＳ ＵＳＤ内でデフォルトとして提供されうる。スケジューリング及び受信位置フラグメントは、スケジューリング情報、受信位置情報、またはその両方のみを含みうる。

ＭＢＭＳファイル配信クライアントは、帯域内の受信の場合、専用かつ周知のＭＩＭＥタイプに基づいて、スケジュール及び受信位置フラグメントを識別する。当該フラグメントは、他の任意のファイルのように受信されるが、その後にＭＢＭＳファイル配信クライアントによって処理され、上位レイヤのアプリケーションに転送されることはない。

スケジュール及び受信位置フラグメントのコンテンツは、ＸＭＬフォーマットであってもよい（上記で提示した疑似コードの例を参照。）。汎用のフラグメントは、日に１回、週に１回、または月に１回のように繰り返し生じるスケジュールのような、種々のスケジュールフォーマットを含んでいてもよい。あるいは、スケジュール情報は、１つ以上の開始時間及び期間として記述されてもよい。ＭＢＭＳクライアント（ミドルウェア４３２）は、受信または更新された際にスケジューリング情報を処理し、ＭＢＭＳ受信機（チップセット４３０）をアクティブ化／非アクティブ化する必要がある。

受信位置情報がフラグメント内に定義されている場合も、ＭＢＭＳ受信機は、アクティブ化の前に、説明したカバレッジエリア内に電話機が位置するか否かをチェックする必要がある。電話機は、それ自体の位置を、ＭＢＭＳ受信の間にモニタリングして、カバレッジの外に移動する際にＭＢＭＳ受信機（チップセット４３０）を非アクティブ化する必要がある。

上記で説明したように、受信位置情報は、無線アクセスシステムによって常に提供される位置エリアコード（ＬＡＣ）またはセルＩＤとして記述されてもよい。

フラグメントは、当該フラグメントの最大の有効性を受信機に伝える有効性情報を含んでいてもよい。サービスのカバレッジエリア内の端末（図３Ａを参照。）は、スケジュール及び受信位置情報の更新情報を頻繁に受信しうる。しかし、カバレッジの外の端末（図３Ｂを参照。）は、何らのカバレッジ情報も受信しえないし、また、システムがカバレッジエリアを変更することを決定した際には誤った情報を有する可能性がある。

フラグメント更新リクエストの間に、システムがスケジュール及び受信位置フラグメントを調整しうるように、端末は、それ自体のＬＡＣまたはセルＩＤを提供しうるか、または提供する必要がある。特に、受信位置情報（ブロードキャスト対象エリア）の記述が多い可能性があり、システムは、関連する部分のみを提供してもよい。

新たな端末機能（スケジュール及び受信位置処理機能４３６、図７及びそれ以下を参照。）は、ＭＢＭＳサービスごとに利用可能なスケジュール及び受信位置情報に基づく、ＭＣＣＨモニタリングのアクティブ化及び非アクティブ化に関与する（それにより、ＭＢＭＳ物理チャネルの受信のアクティブ化及び非アクティブ化につながる）。当該機能は、スケジュール及び受信位置情報ファイル（またはその更新情報）を、サービスに関連付けられたＭＢＭＳダウンロード配信方法を通じて、またはＨＴＴＰを使用して、受信する。ＭＢＭＳダウンロード配信方法を介して受信される（例えば、ＦＬＵＴＥプロトコルによって搬送される）場合、配信方法ハンドラ（Delivery Method Handler）は、例えば、固有のＭＩＭＥタイプ、固有のファイル名またはＵＲＩに基づいて、ファイルを識別し、それを、あらゆるサービスについての情報を処理する、またはサービスごとの情報を個別に処理するスケジュール及び受信位置処理機能４３６に転送する。

スケジュール及び受信位置処理機能４３６は、（タイマーベースの）タイムアウトに基づいて、（スケジュール及び受信位置情報ファイルの有効性が記述されたエリアを離れる）位置に基づいて、またはその両方に基づいて、スケジュール及び受信位置情報ファイルを更新してもよい。関心のある１つ以上のＴＭＧＩについてのＭＣＣＨモニタリングの非アクティブ化は、あらゆるＭＢＭＳ物理チャネルの受信の停止につながりうる。

例示的な実施形態についての上述の説明から明らかとなったように、本明細書で提示した技術は、ＭＢＭＳの受信がシステムによって予測されない期間に、及びオプションとして、ＭＢＭＳの受信がシステムによって予測されない位置で、図４及び図６のＵＥ４２０のような端末がバッテリーを節約することを可能にする。

本明細書で開示した技術の多くの効果が上記の説明から十分に理解されることになると考えられるとともに、本発明の範囲を逸脱することなく、またはその効果の全てを犠牲にすることなく、例示的な実施形態の形式、構造及び構成で、種々の変更が行われうることが明らかとなる。本明細書で示した技術は多くの方法で変化させることが可能であるため、本発明は、以下の請求項の範囲によってのみ限定されることはないものと認識されることになる。

Claims (32)

1. ユーザサービス記述（ＵＳＤ）が提供されるマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービスのためのスケジュール情報を配信する方法であって、本方法は、
   前記ＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール情報を提供するステップ（520）であって、前記スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されている、前記ステップと、
   前記ＵＳＤと前記スケジュール情報とをユーザ装置（ＵＥ）（420）に配信するステップ（530）であって、前記ＵＳＤが、前記スケジュール情報へのリファレンスまたはリンクを有する、前記ステップと、
   を含むことを特徴とする方法。
2. 前記スケジュール情報は、サービス告知手順の間に配信されることを特徴とする請求項１に記載の方法。
3. 前記スケジュール情報は、帯域外で配信されることを特徴とする請求項１または２に記載の方法。
4. 前記スケジュール情報は、ＭＢＭＳを介して帯域内で配信されることを特徴とする請求項１に記載の方法。
5. 前記スケジュール情報は、ＭＢＭＳデータとともに配信されることを特徴とする請求項４に記載の方法。
6. 前記ＭＢＭＳデータとともに帯域内で配信される前記スケジュール情報は、古いスケジュール情報を上書きすることを特徴とする請求項５に記載の方法。
7. 前記ＵＳＤは、サービス告知手順の間に配信されることを特徴とする請求項１から６のいずれか１項に記載の方法。
8. 前記スケジュール情報は、ＭＩＭＥタイプによって識別されることを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 前記スケジュール情報は、更新期間または更新時間を特定することを特徴とする請求項１から８のいずれか１項に記載の方法。
10. 前記更新期間または前記更新時間は、経過した場合に、更新されたスケジュール情報を前記ＵＥ（420）にフェッチさせることを特徴とする請求項９に記載の方法。
11. 前記更新時間は、帯域内でのスケジュール情報の更新の受信に応じてリフレッシュされることを特徴とする請求項９または１０に記載の方法。
12. 前記スケジュール情報は、拡張マークアップ言語（ＸＭＬ）フォーマットで提供されることを特徴とする請求項１から１１のいずれか１項に記載の方法。
13. 前記ＵＳＤは、ＭＢＭＳユーザサービスセッションに含まれる複数のＭＢＭＳセッションに対して有効であることを特徴とする請求項１から１２のいずれか１項に記載の方法。
14. 前記スケジュールは、ＭＢＭＳユーザサービスセッションに含まれる複数のＭＢＭＳセッションを反映することを特徴とする請求項１から１３のいずれか１項に記載の方法。
15. 前記複数のＭＢＭＳセッションは、ＭＢＭＳダウンロードセッションであることを特徴とする請求項１３または１４に記載の方法。
16. 前記スケジュールは、前記ＵＥ（420）がいつＭＢＭＳ受信の準備を行う必要があるかをシグナリングすることを特徴とする請求項１から１５のいずれか１項に記載の方法。
17. 前記スケジュール情報の配信は、受信位置情報の配信を伴うことを特徴とする請求項１から１６のいずれか１項に記載の方法。
18. 前記スケジュール情報及び前記ＵＳＤは、個別の項目として前記ＵＥに配信されることを特徴とする請求項１から１７のいずれか１項に記載の方法。
19. 前記スケジュール情報及び前記ＵＳＤの少なくとも１つは、ファイルの形式で前記ＵＥに配信されることを特徴とする請求項１から１８のいずれか１項に記載の方法。
20. ユーザサービス記述（ＵＳＤ）が提供されるマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービスのためのスケジュール情報を判定する、ユーザ装置（ＵＥ）によって実行される方法であって、
    前記ＵＳＤとスケジュール情報とを受信するステップ（540）であって、前記スケジュール情報が、前記ＭＢＭＳユーザサービスのためのスケジュールを記述しており、前記スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されており、前記ＵＳＤが、前記スケジュール情報へのリファレンスまたはリンクを有する、前記ステップと、
    前記ＵＳＤから前記リファレンスまたはリンクを介して前記ＭＢＭＳユーザサービスのための前記スケジュール情報を判定するステップ（550）と、
    を含むことを特徴とする方法。
21. 前記スケジュール情報に基づいて受信の準備を行うステップを更に含むことを特徴とする請求項２０に記載の方法。
22. 受信の準備を行う前記ステップは、ＭＢＭＳセッションのためのＭＢＭＳ制御チャネル（ＭＣＣＨ）のモニタリングを開始するステップを含むことを特徴とする請求項２１に記載の方法。
23. 受信の準備を行う前記ステップは、前記ＵＥ（420）のＭＢＭＳチップセット（430）をアクティブ化するステップを含むことを特徴とする請求項２１または２２に記載の方法。
24. 前記スケジュール情報に基づいて、開始されたＭＢＭＳユーザサービスを中断するステップを更に含むことを特徴とする請求項２０から２３のいずれか１項に記載の方法。
25. 開始されたＭＢＭＳユーザサービスを中断する前記ステップは、ＭＢＭＳ制御チャネル（ＭＣＣＨ）のモニタリングを停止するステップを含むことを特徴とする請求項２４に記載の方法。
26. 開始されたＭＢＭＳユーザサービスを中断する前記ステップは、前記ＵＥ（420）のＭＢＭＳチップセット（430）を非アクティブ化するステップを含むことを特徴とする請求項２４または２５に記載の方法。
27. 請求項１から２６のいずれか１項に記載の方法の各ステップをコンピュータに実行するためのコンピュータプログラム。
28. コンピュータで読み取り可能な記憶媒体に格納されることを特徴とする請求項２７に記載のコンピュータプログラム。
29. ユーザサービス記述（ＵＳＤ）が提供されるマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービスのためのスケジュール情報を配信する装置（400）であって、
    前記ＭＢＭＳユーザサービスのためのスケジュールを記述したスケジュール情報を提供するよう構成された機能部（402;602）であって、前記スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されている、前記機能部と、
    前記ＵＳＤと前記スケジュール情報とをユーザ装置（ＵＥ）（420）に配信するよう構成された機能部（406;606）であって、前記ＵＳＤが、前記スケジュール情報へのリファレンスまたはリンクを有する、前記機能部と、
    を備えることを特徴とする装置。
30. サービス告知手順の間に、
    帯域外で、
    ＭＢＭＳを介して帯域内で、及び
    ＭＢＭＳデータとともに、
    のうちの１つ以上の方法に従って、前記スケジュール情報を配信するよう構成されていることを特徴とする請求項２９に記載の装置。
31. 前記スケジュール情報は、更新期間または更新時間を特定することを特徴とする請求項２９または３０に記載の装置。
32. ユーザサービス記述（ＵＳＤ）が提供されるマルチメディア・ブロードキャスト／マルチキャストサービス（ＭＢＭＳ）ユーザサービスのためのスケジュール情報を判定するユーザ装置（ＵＥ）（420）であって、
    前記ＵＳＤとスケジュール情報とを受信するよう構成された機能部（422）であって、前記スケジュール情報が、前記ＭＢＭＳユーザサービスのためのスケジュールを記述しており、前記スケジュールが、１つ以上の繰り返し生じるイベント及び１つ以上の開始／停止リストの少なくともいずれかの形式で記述されており、前記ＵＳＤが、前記スケジュール情報へのリファレンスまたはリンクを有する、前記機能部と、
    前記ＵＳＤから前記リファレンスまたはリンクを介して前記ＭＢＭＳユーザサービスのための前記スケジュール情報を判定するよう構成された機能部（424）と、
    を備えることを特徴とするユーザ装置。

Images