JP2014060777A - マルチメディアブロードキャストマルチキャストサービス（ｍｂｍｓ）のサービスのフィードバックのための方法および装置 - Google Patents

Abstract

【課題】マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスのフィードバックを提供するための方法および装置が、説明される。
【解決手段】無線送受信ユニット（ＷＴＲＵ）が、ＭＢＭＳ制御チャネルを介してＭＢＭＳサービス問い合わせメッセージを受信し、ＭＢＭＳサービス応答を送信することができる。ＭＢＭＳサービス問い合わせメッセージおよびＭＢＭＳサービス応答メッセージは、無線リソースコントローラのメッセージである可能性がある。ＭＢＭＳサービス問い合わせメッセージは、ＭＢＭＳサービス識別子を含む可能性があり、ＭＢＭＳサービス識別子は、ＷＴＲＵが受信しているまたは受信することを意図しているＭＢＭＳのサービスを識別する。
【選択図】図２

Description

本発明は、無線通信に関する。

関連出願の相互参照
本出願は、２０１０年７月２８日に出願された米国仮出願第６１／３６８，５４１号、２０１０年８月１３日に出願された米国仮出願第６１／３７３，６６１号、および２０１１年７月２６日に出願された米国非仮出願第１３／１９０，９８７号の利益を主張するものであり、これらの内容は、参照により本明細書に援用される。

ＬＴＥ（ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ）リリース９（Ｒ９）において、ＬＴＥ無線送受信ユニット（ＷＴＲＵ）にマルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスを提供するためのＭＢＭＳの特徴および動作メカニズムの中核的な組が、規定された。この中核的な組は、単一のソースからマルチキャストサービスエリア内の受信者のマルチキャストグループへのマルチメディアコンテンツ（例えば、公共のメディアもしくはニュースサービスのテキスト、音声、スポーツもしくはエンターテインメント、またはテレビ（ＴＶ）放送の画像もしくは映像）の単方向のポイントツーマルチポイント送信を可能にする。ＬＴＥ Ｒ９において、マルチキャストサービスは、混合したセルの環境で提供される。

混合したＭＢＭＳのセルは、ＬＴＥのセルの時間および周波数リソースを用いて通常のユニキャストのオペレーション（通常のＷＴＲＵのサービス）とＭＢＭＳのオペレーションの両方をサポートする。ユニキャストおよびＭＢＭＳの送信オペレーションは異なり、したがって、それらのオペレーションは、時分割式に通常のサブフレームおよびＭＢＭＳ単一周波数ネットワーク（ＭＢＭＳ ｓｉｎｇｌｅ ｆｒｅｑｕｅｎｃｙ ｎｅｔｗｏｒｋ）（ＭＢＳＦＮ）サブフレームとして分けられる。よって、ダウンリンク（ＤＬ）において、ユニキャストデータは、ＭＢＳＦＮサブフレームのいずれにおいても送信されず、ＭＢＭＳのサービスは、通常のサブフレームのいずれにおいても送信されない。

ＬＴＥ Ｒ９において、ＭＢＭＳシステムは、ＭＢＭＳの運用者がＭＢＭＳに関心のあるＷＴＲＵから実際のＭＢＭＳのサービスの受信状態およびサービス加入状態を得るためにいかなるフィードバック情報のメカニズムも提供または促進しない。ＭＢＭＳのＷＴＲＵがＭＢＭＳのサービスプロバイダと通信することを可能にするアップリンク（ＵＬ）のチャネル、ＵＬのＭＢＭＳメッセージ、ＭＢＭＳ情報要素（ＩＥ）、またはＭＢＭＳ信号は、規定されていない。

ＬＴＥリリース１０（Ｒ１０）においては、ＭＢＭＳのサービスのブロードキャスト全般および／または特定のＭＢＭＳのサービスのブロードキャストの組に関するＭＢＭＳに関心のあるＷＴＲＵおよびユーザの受信の意思がどうであるかと、ＷＴＲＵ／ユーザがその時点で受信しているＭＢＭＳのサービスが何であるかとについての情報をサービスプロバイダが収集するためのＭＢＭＳのフィードバックおよびレポートメカニズムが必要とされる。

マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供するための方法および装置が、説明される。無線送受信ユニット（ＷＴＲＵ）が、ＭＢＭＳ制御チャネルを介してＭＢＭＳサービス状態問い合わせメッセージ（ＭＢＭＳ ｓｅｒｖｉｃｅ ｓｔａｔｕｓ ｑｕｅｒｙ ｍｅｓｓａｇｅ）を受信し、ＭＢＭＳサービス状態応答（ＭＢＭＳ ｓｅｒｖｉｃｅ ｓｔａｔｕｓ ｒｅｓｐｏｎｓｅ）を送信する。ＭＢＭＳサービス状態問い合わせメッセージおよびＭＢＭＳサービス状態応答メッセージは、無線リソースコントローラのメッセージである可能性がある。ＭＢＭＳサービス状態問い合わせメッセージは、ＭＢＭＳサービス識別子（ＭＢＭＳ ｓｅｒｖｉｃｅ ｉｄｅｎｔｉｆｉｅｒ）のリストを含む可能性があり、ＭＢＭＳサービス識別子は、ＷＴＲＵが受信しているまたは受信することを意図しているＭＢＭＳのサービスを識別することができる。ＷＴＲＵは、ＭＢＭＳサービス識別子インデックス値（ＭＢＭＳ ｓｅｒｖｉｃｅ ｉｄｅｎｔｉｆｉｅｒ ｉｎｄｅｘ ｖａｌｕｅ）を有するレポートを生成することができ、各ＭＢＭＳサービス識別子インデックス値は、ＷＴＲＵが現在受信しているかまたは受信することを意図している元の問い合わせのリスト内のＭＢＭＳのサービスに対応するサービス識別子の位置を示すことができる。ＭＢＭＳサービス状態問い合わせメッセージは、単独で、またはＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとともに受信される可能性がある。ＷＴＲＵは、事前に決定された期限または設定された期限以内にＭＢＭＳサービス状態応答メッセージを送信する必要がある可能性がある。

より詳細な理解が、添付の図面と併せて例として与えられる以下の説明から得られるであろう。
１つまたは複数の開示された実施形態が実装され得る例示的な通信システムのシステム図である。 図１Ａに示された通信システム内で使用され得る例示的な無線送受信ユニット（ＷＴＲＵ）のシステム図である。 図１Ａに示された通信システム内で使用され得る例示的な無線アクセスネットワークおよび例示的なコアネットワークのシステム図である。 マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態をレポートするための信号フロー図である。 アイドルモードのＷＴＲＵに関するＭＢＭＳのサービスの状態をレポートするための信号フロー図である。

図１Ａは、１つまたは複数の開示された実施形態が実装され得る例示的な通信システム１００の図である。通信システム１００は、複数の無線ユーザに音声、データ、映像、メッセージング、放送などのコンテンツを提供する多元接続システムである可能性がある。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有によってそのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）などの１つまたは複数のチャネルアクセス方法を使用することができる。

図１Ａに示されるように、通信システム１００は、無線送受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０、およびその他のネットワーク１１２を含み得るが、開示された実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境内で動作および／または通信するように構成された任意の種類のデバイスである可能性がある。例として、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されることができ、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、ページャ、セルラ電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサー、家庭用電化製品などを含み得る。

通信システム１００は、基地局１１４ａおよび基地局１１４ｂも含み得る。基地局１１４ａ、１１４ｂのそれぞれは、コアネットワーク１０６、インターネット１１０、および／またはネットワーク１１２などの１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェースをとるように構成された任意の種類のデバイスである可能性がある。例として、基地局１１４ａ、１１４ｂは、無線基地局（ＢＴＳ）、Ｎｏｄｅ−Ｂ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータなどである可能性がある。基地局１１４ａ、１１４ｂはそれぞれ単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互に接続された基地局および／またはネットワーク要素を含み得ることが理解されるであろう。

基地局１１４ａは、ＲＡＮ１０４の一部であることができ、ＲＡＮ１０４は、その他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示せず）も含み得る。基地局１１４ａおよび／または基地局１１４ｂは、セルと呼ばれる場合がある特定の地理的領域（図示せず）内で無線信号を送信および／または受信するように構成され得る。セルは、セルのセクタにさらに分割され得る。例えば、基地局１１４ａに関連するセルは、３つのセクタに分割され得る。したがって、一実施形態において、基地局１１４ａは、３つのトランシーバ、すなわち、セルの各セクタに対して１つのトランシーバを含み得る。別の実施形態において、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を使用することができ、したがって、セルの各セクタに対して複数のトランシーバを利用する可能性がある。

基地局１１４ａ、１１４ｂは、任意の好適な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）である可能性がある無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信することができる。無線インターフェース１１６は、任意の好適な無線アクセス技術（ＲＡＴ）を用いて確立され得る。

より具体的には、上述のように、通信システム１００は、多元接続システムである可能性があり、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ−ＦＤＭＡなどの１つまたは複数のチャネルアクセススキームを使用する可能性がある。例えば、ＲＡＮ１０４内の基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を用いて無線インターフェース１１６を確立することができるＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）ＵＴＲＡ（Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線技術を実装することができる。ＷＣＤＭＡは、ＨＳＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＰＡ＋（Ｅｖｏｌｖｅｄ ＨＳＰＡ）などの通信プロトコルを含み得る。ＨＳＰＡは、ＨＳＤＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｄｏｗｎｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）および／またはＨＳＵＰＡ（Ｈｉｇｈ−Ｓｐｅｅｄ Ｕｐｌｉｎｋ Ｐａｃｋｅｔ Ａｃｃｅｓｓ）を含み得る。

別の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）および／またはＬＴＥ−Ａ（ＬＴＥ−Ａｄｖａｎｃｅｄ）を用いて無線インターフェース１１６を確立することができるＥ−ＵＴＲＡ（Ｅｖｏｌｖｅｄ ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ）などの無線技術を実装することができる。

その他の実施形態において、基地局１１４ａおよびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１６（すなわち、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ−ＤＯ、ＩＳ−２０００（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ２０００）、ＩＳ−９５（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ９５）、ＩＳ−８５６（Ｉｎｔｅｒｉｍ Ｓｔａｎｄａｒｄ ８５６）、ＧＳＭ（登録商標）（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、ＥＤＧＥ（Ｅｎｈａｎｃｅｄ Ｄａｔａ ｒａｔｅｓ ｆｏｒ ＧＳＭ Ｅｖｏｌｕｔｉｏｎ）、ＧＥＲＡＮ（ＧＳＭ ＥＤＧＥ）などの無線技術を実装することができる。

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またアクセスポイントである可能性があり、事業所、家庭、車両、キャンパスなどの局所的な地域で無線接続を容易にするための任意の好適なＲＡＴを利用することができる。一実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立するためのＩＥＥＥ８０２．１１などの無線技術を実装することができる。別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立するためのＩＥＥＥ８０２．１５などの無線技術を実装することができる。さらに別の実施形態において、基地局１１４ｂおよびＷＴＲＵ１０２ｃ、１０２ｄは、セルラに基づくＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ−Ａなど）を利用してピコセルまたはフェムトセルを確立することができる。図１Ａに示されたように、基地局１１４ｂは、インターネット１１０への直接的なコネクションを有する可能性がある。したがって、基地局１１４ｂは、コアネットワーク１０６を介してインターネット１１０にアクセスするように要求されない可能性がある。

ＲＡＮ１０４は、コアネットワーク１０６と通信している可能性があり、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に音声、データ、アプリケーション、および／またはＶｏＩＰ（ｖｏｉｃｅ ｏｖｅｒ ｉｎｔｅｒｎｅｔ ｐｒｏｔｏｃｏｌ）サービスを提供するように構成された任意の種類のネットワークである可能性がある。例えば、コアネットワーク１０６は、呼制御、課金サービス、モバイルの位置に基づくサービス、プリペイド電話、インターネット接続、映像配信などを提供し、および／またはユーザ認証などの高レベルのセキュリティ機能を実行することができる。図１Ａには示されていないが、ＲＡＮ１０４および／またはコアネットワーク１０６は、ＲＡＮ１０４と同じＲＡＴ、または異なるＲＡＴを使用するその他のＲＡＮと直接的または間接的に通信している可能性があることが理解されるであろう。例えば、Ｅ−ＵＴＲＡ無線技術を利用している可能性があるＲＡＮ１０４に接続されることに加えて、コアネットワーク１０６は、ＧＳＭ無線技術を使用する別のＲＡＮ（図示せず）とも通信している可能性がある。

コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０、および／またはその他のネットワーク１１２にアクセスするためのゲートウェイとしても働くことができる。ＰＳＴＮ１０８は、ＰＯＴＳ（ｐｌａｉｎ ｏｌｄ ｔｅｌｅｐｈｏｎｅ ｓｅｒｖｉｃｅ）を提供する回線交換電話ネットワークを含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイートの伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、およびインターネットプロトコル（ＩＰ）などの共通の通信プロトコルを使用する相互に接続されたコンピュータネットワークおよびデバイスの全世界的なシステムを含み得る。ネットワーク１１２は、その他のサービスプロバイダによって所有および／または運用される有線または無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴ、または異なるＲＡＴを使用する可能性がある１つまたは複数のＲＡＮに接続された別のコアネットワークを含み得る。

通信システム１００のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部またはすべては、マルチモード機能を含む可能性があり、すなわち、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含む可能性がある。例えば、図１Ａに示されたＷＴＲＵ１０２ｃは、セルラに基づく無線技術を使用することができる基地局１１４ａと、およびＩＥＥＥ８０２無線技術を使用することができる基地局１１４ｂと通信するように構成され得る。

図１Ｂは、例示的なＷＴＲＵ１０２のシステム図である。図１Ｂに示されたように、ＷＴＲＵ１０２は、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカー／マイクロホン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、取り外し不可能なメモリ１３０、取り外し可能なメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、およびその他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、実施形態に準拠したまま、上述の要素の任意の部分的な組み合わせを含み得ることが理解されるであろう。

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、通常のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のその他の種類の集積回路（ＩＣ）、状態機械などである可能性がある。プロセッサ１１８は、信号の符号化、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境で動作することを可能にする任意のその他の機能を実行することができる。プロセッサ１１８は、トランシーバ１２０に結合されることができ、トランシーバ１２０は、送信／受信要素１２２に結合されることができる。図１Ｂはプロセッサ１１８およびトランシーバ１２０を別個のコンポーネントとして示すが、プロセッサ１１８およびトランシーバ１２０は、電子的なパッケージまたはチップに一緒に統合され得ることが理解されるであろう。

送信／受信要素１２２は、無線インターフェース１１６を介して基地局（例えば、基地局１１４ａ）に信号を送信するか、または基地局（例えば、基地局１１４ａ）から信号を受信するように構成され得る。例えば、一実施形態において、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナである可能性がある。別の実施形態において、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成されたエミッタ／ディテクタである可能性がある。さらに別の実施形態において、送信／受信要素１２２は、ＲＦ信号と光信号の両方を送信および受信するように構成され得る。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成され得ることが理解されるであろう。

加えて、送信／受信要素１２２は、図１Ｂにおいて単一の要素として示されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含み得る。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用することができる。したがって、一実施形態において、ＷＴＲＵ１０２は、無線インターフェース１１６を介して無線信号を送信および受信するために２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。

トランシーバ１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成され得る。上述のように、ＷＴＲＵ１０２は、マルチモード機能を有する可能性がある。したがって、トランシーバ１２０は、ＷＴＲＵ１０２が例えばＵＴＲＡおよびＩＥＥＥ８０２．１１などの複数のＲＡＴを介して通信することを可能にするための複数のトランシーバを含み得る。

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカー／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニットまたは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されることができ、それらからユーザ入力データを受信することができる。プロセッサ１１８は、スピーカー／マイクロホン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。さらに、プロセッサ１１８は、取り外し不可能なメモリ１３０および／または取り外し可能なメモリ１３２などの任意の種類の好適なメモリからの情報にアクセスし、それらのメモリにデータを記憶することができる。取り外し不可能なメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードディスク、または任意のその他の種類のメモリストレージデバイスを含み得る。取り外し可能なメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカードなどを含み得る。その他の実施形態において、プロセッサ１１８は、サーバまたはホームコンピュータ（図示せず）などの、ＷＴＲＵ１０２に物理的に置かれていないメモリからの情報にアクセスし、そのメモリにデータを記憶することができる。

プロセッサ１１８は、電源１３４から電力を受け取ることができ、ＷＴＲＵ１０２内のその他のコンポーネントに電力を分配し、および／またはその電力を制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に給電するための任意の好適なデバイスである可能性がある。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されることができ、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度および緯度）を提供するように構成され得る。ＧＰＳチップセット１３６からの情報に加えて、またはＧＰＳチップセット１３６からの情報の代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）から無線インターフェース１１６を介して位置情報を受信し、および／または２つ以上の近隣の基地局から受信されている信号のタイミングに基づいてそのＷＴＲＵ１０２の位置を判定することができる。ＷＴＲＵ１０２は、実施形態に準拠したまま、任意の好適な位置判定方法によって位置情報を取得することができることが理解されるであろう。

プロセッサ１１８は、その他の周辺機器１３８にさらに結合されることができ、その他の周辺機器１３８は、追加的な特徴、機能、および／または有線もしくは無線接続を提供する１つまたは複数のソフトウェアおよび／またはハードウェアモジュールを含み得る。例えば、周辺機器１３８は、加速度計、電子コンパス、衛星トランシーバ、デジタルカメラ（写真または動画用）、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）ポート、振動デバイス、テレビトランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、ＦＭ（ｆｒｅｑｕｅｎｃｙ ｍｏｄｕｌａｔｅｄ）ラジオユニット、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲームプレーヤーモジュール、インターネットブラウザなどを含み得る。

図１Ｃは、一実施形態によるＲＡＮ１０４およびコアネットワーク１０６のシステム図である。上述のように、ＲＡＮ１０４は、無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ−ＵＴＲＡ無線技術を使用する可能性がある。ＲＡＮ１０４は、コアネットワーク１０６とも通信している可能性がある。

ＲＡＮ１０４はｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃを含む可能性があるが、ＲＡＮ１０４は、実施形態に準拠したまま、任意の数のｅＮｏｄｅ−Ｂを含み得ることが理解されるであろう。ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、無線インターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つまたは複数のトランシーバをそれぞれが含み得る。一実施形態において、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、ＭＩＭＯ技術を実装することができる。したがって、ｅＮｏｄｅ−Ｂ１４０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、ＷＴＲＵ１０２ａから無線信号を受信することができる。

ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれは、特定のセル（図示せず）に関連付けられることができ、無線リソース管理の決定、ハンドオーバの決定、アップリンクおよび／またはダウンリンクにおけるユーザのスケジューリングなどを処理するように構成されることができる。図１Ｃに示されるように、ｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃは、Ｘ２インターフェースを介して互いに通信することができる。

図１Ｃに示されるコアネットワーク１０６は、モビリティ管理ゲートウェイ（ＭＭＥ）１４２、サービングゲートウェイ１４４、およびパケットデータネットワーク（ＰＤＮ）ゲートウェイ１４６を含み得る。上述の要素のそれぞれはコアネットワーク１０６の一部として示されているが、これらの要素のうちの任意の要素は、コアネットワークの運用者以外の主体によって所有および／または運用される可能性があることが理解されるであろう。

ＭＭＥ１４２は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅ−Ｂ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続されることができ、制御ノードとして働くことができる。例えば、ＭＭＥ１４２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの最初のアタッチ中の特定のサービングゲートウェイの選択などの役割を担う可能性がある。ＭＭＥ１４２は、ＲＡＮ１０４と、ＧＳＭまたはＷＣＤＭＡなどのその他の無線技術を使用するその他のＲＡＮ（図示せず）との間の切り替えのための制御プレーンの機能も提供することができる。

サービングゲートウェイ１４４は、Ｓ１インターフェースを介してＲＡＮ１０４内のｅＮｏｄｅＢ１４０ａ、１４０ｂ、１４０ｃのそれぞれに接続され得る。概して、サービングゲートウェイ１４４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からユーザのデータパケットをルーティングおよび転送することができる。サービングゲートウェイ１４４は、ｅＮｏｄｅＢ間のハンドオーバ中にユーザプレーンのアンカーになること、ダウンリンクのデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングを引き起こすこと、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなどのその他の機能も実行することができる。

サービングゲートウェイ１４４は、ＰＤＮゲートウェイ１４６にも接続されることができ、ＰＤＮゲートウェイ１４６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがインターネット１１０などのパケット交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスの間の通信を容易にすることができる。

コアネットワーク１０６は、その他のネットワークとの通信を容易にすることができる。例えば、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃがＰＳＴＮ１０８などの回線交換ネットワークにアクセスできるようにして、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスの間の通信を容易にすることができる。例えば、コアネットワーク１０６は、コアネットワーク１０６とＰＳＴＮ１０８の間のインターフェースとして働くＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、またはそのようなＩＰゲートウェイと通信することができる。さらに、コアネットワーク１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、その他のサービスプロバイダによって所有および／または運用されるその他の有線または無線ネットワークを含み得るネットワーク１１２にアクセスできるようにすることができる。

マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）はダウンリンク（ＤＬ）のサービスであり、シグナリングまたはコンテンツデータが、ＭＢＭＳ単一周波数ネットワーク（ＭＢＳＦＮ）サブフレームで送信される。利用可能なＭＢＭＳのチャネルは、制御情報のためのマルチキャスト制御チャネル（ＭＣＣＨ）と、ＭＢＭＳのサービスのデータ送信のためのマルチキャストトラフィックチャネル（ＭＴＣＨ）とを含む。ＭＣＣＨとＭＴＣＨの両方は、物理マルチキャストチャネル（ＰＭＣＨ）上のマルチキャストチャネル（ＭＣＨ）にマッピングされる。ＰＭＣＨのサブフレーム構造は、ＬＴＥにおける通常のユニキャストサブフレームと異なる。

ＬＴＥリリース９（Ｒ９）のＭＢＭＳの設計においては、ＭＢＭＳに対応したまたはＭＢＭＳに関心のあるＷＴＲＵが任意のＭＢＭＳに関連する情報をネットワーク運用者に送信することを可能にするためのアップリンク（ＵＬ）のチャネル、メッセージ、または信号は規定されていない。したがって、ＭＢＭＳのプロバイダ／運用者は、ＷＴＲＵからいかなるフィードバックも受信することができない可能性がある。

ＭＢＭＳのユーザおよびＭＢＭＳに対応したＷＴＲＵの観点から見ると、ＭＢＭＳのユーザは、最初に、通常の電話の加入サービス、インターネットの加入サービス、またはその他の電子的なプログラムの加入サービスなどの何らかの手段を通じてＭＢＭＳのサービスに加入する。ＭＢＭＳのユーザは、上記の加入から所望のＭＢＭＳのサービスの識別情報を含む関心のあるＭＢＭＳのサービスの情報を取得することができる。

ＭＢＭＳのサービスは、特定のテレビ（ＴＶ）番組／ＴＶ局のコンテンツ、特定のニュースまたはスポーツイベントなどを意味する可能性がある。ＭＢＭＳのユーザは、２つ以上のＭＢＭＳのサービスに加入することができ、それぞれのサービスは、より上位のレイヤからアクセス層のプロトコルの動作へのＭＢＭＳのサービスの識別情報によって表される。

受信動作中のＭＢＭＳに関心のあるＷＴＲＵに関して、ＭＢＳＦＮサブフレーム、ＭＣＨのスケジューリングおよび送信機会、ならびにＭＣＣＨチャネルの制御およびスケジューリングの設定が、システム情報ブロック（ＳＩＢ）タイプ１３から判定される。

有効なＭＢＭＳのユーザの加入を有する場合、ＭＢＭＳに関心のあるＷＴＲＵは、ＭＣＣＨメッセージと呼ばれることがあり、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとしても知られる可能性がある無線リソース制御（ＲＲＣ）メッセージを介してＭＣＣＨチャネルを通じてＭＢＭＳサービス告知（ＭＢＭＳ ｓｅｒｖｉｃｅ ａｎｎｏｕｎｃｅｍｅｎｔ）、サービススケジュール、およびサービスデータセッションの送信チャネル（ＭＴＣＨ）へのマッピング情報を取得することができる。

ＭＢＭＳに関心のあるＷＴＲＵは、以前は動的スケジューリング情報（ｄｙｎａｍｉｃ ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏｒｍａｔｉｏｎ）（ＤＳＩ）と呼ばれていたＭＢＭＳスケジューリング情報（ＭＢＭＳ Ｓｃｈｅｄｕｌｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）（ＭＳＩ）を介してサービス／ＭＴＣＨのスケジューリングの取り決めからサブフレームの詳細までをさらに知る。ＭＳＩは、それぞれのＭＣＨのスケジューリング期間のはじめに媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）として送信され得る。

サービスに固有のチャネルのスケジューリングならびに変調および符号化スキーム（ＭＣＳ）が分かると、ＷＴＲＵは、ＭＡＣプロトコルデータユニット（ＰＤＵ）から適切なＭＢＳＦＮサブフレームの加入しているＭＢＭＳのサービスのデータを受信し、復号することができる。次いで、ＷＴＲＵは、ユーザの加入に応じてユーザに関する加入しているＭＢＭＳのサービスのデータをフィルタリングし、所望のＭＢＭＳのサービスのコンテンツをユーザアプリケーションに転送することができる。

ＬＴＥ Ｒ９、ＬＴＥリリース１０（Ｒ１０）、およびリリース１１（Ｒ１１）のＭＢＭＳの特徴およびメカニズムの所与のこれらの中核的な組は、ＭＢＭＳを受信するＷＴＲＵおよびＭＢＭＳに関心のあるＷＴＲＵからのＭＢＭＳのサービスの状態のフィードバック情報を（ネットワーク側の）ＭＢＭＳの運用者が得るための規定を含む。（ＭＢＭＳカウンティング（ｃｏｕｎｔｉｎｇ）と呼ばれることがある）ＷＴＲＵからフィードバックされるこの情報は、運用者が、サービス効率がより良くなるために、およびサービス受信の統計を向上させるために、特定のＭＢＭＳのサービスに関するＭＢＳＦＮの送信をアクティブ化すること、継続すること、または非アクティブ化することの中から選択を行うことを可能にすることができる。例えば、現在のＭＢＭＳのサービスを受信するかまたは受信することに関心のある十分なＷＴＲＵが存在する場合、サービスが開始または継続することができ、そうでない場合、サービスは停止される可能性がある。

いくつのＷＴＲＵが現在行われているＭＢＭＳのサービスを受信しているかを判定するために、ネットワークは、ＭＢＭＳに関する現在のＭＣＣＨメッセージ、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを使用し、対象のそれぞれのサービスに関して、ＷＴＲＵのレポートを要請するために、そのメッセージのＳｅｓｓｉｏｎＩｎｆｏＬｉｓｔ情報要素（ＩＥ）にレポートインジケータ（ｒｅｐｏｒｔ−ｉｎｄｉｃａｔｏｒ）を含めることができる。ブール値のインジケータ（はい／いいえ）が、ネットワークが受信状態を求める各サービスに関して含まれ得る。行われているサービスのみが、ＭＣＣＨに含まれる。要求は、ＭＣＣＨを受信する各ＷＴＲＵが、示された（１つまたは複数の）サービスを受信しているかどうかに関するものである。

レポートするＷＴＲＵの総数を制御するために、ネットワークがＷＴＲＵに直接問い合わせるか、または確率因子（バックオフ）方式（ｐｒｏｂａｂｉｌｉｔｙ ｆａｃｔｏｒ（ｂａｃｋｏｆｆ） ｓｃｈｅｍｅ）などの何らかのフィルタ技術が使用され得るかのいずれかである。

ＭＢＭＳのサービスの状態をレポートするＷＴＲＵに関して、ＷＴＲＵのサービスの状態のレポートは、ＭＢＭＳのサービスごとであり、複数のサービスの状態が一度にレポートされる可能性があり、レポートは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージに記載された（１つまたは複数の）サービスに関して構築される可能性がある。

レポートするための通常のＷＴＲＵのメカニズムは、ＲＲＣメッセージ、ＭＡＣ ＣＥ、レイヤ１（Ｌ１）信号であるか、またはＲＲＣメッセージに付加されるＭＢＭＳのサービスの状態のＩＥを形成することによる可能性があるが、詳細は知られていない。レガシーデバイスに対するそのようなメカニズムの影響は、最小限にされるべきである（そのようなメカニズムは、レガシーデバイスの受信状態がネットワークに分からないままである場合、許容できる可能性がある）。新しいＬＴＥ Ｒ１０のメカニズムのすべては、（Ｒ８またはＲ９の）ＭＢＭＳに対応または未対応のレガシーＷＴＲＵに影響を与えてはならない。下位互換性がない場合は、その他のメカニズムが使用され得る。

本明細書において説明されるのは、高度で詳細なレベルのＭＢＭＳのサービスの状態のフィードバックメカニズム、手順、どのようにしてネットワークがＭＢＭＳのサービスの状態を問い合わせることができるか、およびどのようにしてＷＴＲＵがネットワークのポーリング（ｐｏｌｌ）／要求／問い合わせに対して応答／レポートすることができるかの詳細な組み立てである。２つの例示的なアプローチが本明細書において説明されるが、本明細書に記載の原理、メカニズム、手順、方法、およびフォーマットは、これらのアプローチの両方で交換可能であり、再使用可能である可能性があり、これらのアプローチに依存せずに使用される可能性がある。開示された方法、メカニズム、特徴、または要素の組み合わせが、１つまたは複数の実施形態で使用され得る。

一例において、ネットワークが何らかのＭＢＭＳのサービスの受信に関連する状態に関してＤＬにおいて問い合わせることができ、関連するＷＴＲＵがＵＬにおいて状態で応答することができるような問い合わせおよび応答のアプローチが、使用される可能性がある。場合によっては、応答は、定義されたタイムフレーム内で送信される必要がある可能性がある。問い合わされる状態は、行われているＭＢＭＳのサービス、近いうちに送信される予定のサービス、およびＷＴＲＵが加入しているＭＢＭＳのサービスのうちの１つまたは複数を含む可能性がある。ネットワークは、特定のサービスの受信状態および／または受信の意思に関して受信された結果を集計する可能性がある。別の場合、基地局が、特定のサービスの受信状態および／または受信の意思に関して受信された結果を集計する可能性がある。

別の例において、ＭＢＭＳに関心のあるＷＴＲＵが、ネットワークのポーリングに応答して、すべてのそれらのＷＴＲＵが加入しているＭＢＭＳのサービス、それらのＷＴＲＵが現在受信しているサービス、およびそれらのＷＴＲＵが受信することに関心があるサービスのうちの１つまたは複数をレポートすることができるような全般的なＷＴＲＵのＭＢＭＳのサービスの状態をレポートするアプローチが、使用され得る。ＭＢＭＳのサービスの運用者（またはネットワーク）は、これらのレポートのうちの１つまたは複数に関するポーリングを設定することができる。ネットワークは、そのネットワークのＭＢＭＳのサービスのプログラムの計画を調整するためにＭＢＭＳのサービスの状態に関するポーリングを設定することができる。ＭＢＭＳに関心のあるＷＴＲＵは、ネットワークがポーリングを設定した場合に、それらのＷＴＲＵのサービスの状態のレポートを送ることができる。用語「ＭＢＭＳに関心のあるＷＴＲＵ」は、アクティブなＭＢＭＳのサービスのうちの１つもしくは複数を現在受信している、および／または加入しているＭＢＭＳのサービスの可用性に関してＭＢＭＳの設定の機会を現在監視しているＷＴＲＵを指す可能性がある。

図２は、ＭＢＭＳのサービスの状態のフィードバックまたはレポートメカニズムに関する例示的な高レベルの信号フロー図を示す。本明細書において説明されるように、接続モードのＷＴＲＵとアイドルモードのＷＴＲＵとは、異なる処理の詳細を経るが、図２は、両方のモードで実行される汎用的な処理を示す。無線通信システム２００は、ＷＴＲＵ２０５と、基地局２１０と、マルチセル／マルチキャスト調整エンティティ（ｍｕｌｔｉ−ｃｅｌｌ／ｍｕｌｔｉｃａｓｔ ｃｏｏｒｄｉｎａｔｉｏｎ ｅｎｔｉｔｙ）（ＭＣＥ）などのネットワークエンティティ２１５とを含む可能性がある。ネットワークエンティティ２１５は、特定のＭＢＭＳのサービスをアクティブ化および非アクティブ化することが適切であるか否かを知るために、ＭＢＭＳサービス状態問い合わせメッセージを形成し（２２０）、スケジューリングし（２２５）、基地局２１０に送信する（２３０）ことができ、そして今度は、基地局２１０が、ＷＴＲＵ２０５に通知を送信し（２３５）、その後に、ＭＣＣＨを介してＭＢＭＳサービス状態問い合わせメッセージを転送することができる。次いで、ＷＴＲＵ２０５が、ＭＢＭＳサービス状態応答を準備し（２４５）、基地局２１０に送信する（２５０）ことができる。次に、基地局２１０が、応答するＷＴＲＵのそれぞれからの応答を収集し、集計する（２５５）ことができ、それから、結果の応答をネットワークエンティティ（２１５）に送信する（２６０）ことができる。

本明細書において説明されるのは、問い合わせおよび応答のアプローチに関する詳細である。具体的には、ＭＢＭＳのサービスの状態に関するネットワークの問い合わせおよびＷＴＲＵのレポートが、本明細書において開示される。Ｒ１０以後のＬＴＥのＭＢＭＳのサービスに関しては、ネットワークのＭＢＭＳの運用者は、フィードバック情報のために一部のＭＢＭＳのサービスの状態に関してＷＴＲＵに問い合わせを行うことができ、次に、ＷＴＲＵが、その問い合わせに、それらのＷＴＲＵのＭＢＭＳの受信または意思の状態で応答することができる。

本明細書において説明されるのは、問い合わせおよび応答のアプローチのためのＭＢＭＳのサービスの問い合わせのカテゴリーである。これらの問い合わせは、送信のため、もしくはプログラムの調整のために特定のＭＢＭＳのサービスをいつ開始、継続もしくは停止すべきか、または開始、継続もしくは停止すべきであるかどうかを判定するために、ＭＢＭＳをサポートするネットワークまたはネットワークのＭＢＭＳの運用者に役立つ可能性がある。用語、ネットワークのＭＢＭＳの運用者が本明細書の例で使用されているが、この用語は、ＭＢＭＳのフィードバック情報を必要とする可能性があるネットワークエンティティを指す可能性がある。

ＭＢＭＳサービスの状態の以下のカテゴリーのうちの１つまたは複数が、ＭＢＭＳの運用者によって問い合わされる可能性がある（以降、問い合わせカテゴリー）。例示的な問い合わせカテゴリーは、「ＷＴＲＵが、現在アクティブ状態で送信されているＭＢＭＳのサービスのうちのどれを現在受信しているか」である可能性がある。別の例示的な問い合わせカテゴリーは、「ＷＴＲＵが、近いうちに送信される予定のＭＢＭＳのサービスのうちのどれを受信することを意図しているか」である可能性がある。ＭＢＭＳのサービスは、現在送信されているＭＢＭＳのサービス、および／または現在送信されていないＭＢＭＳのサービスを含み得る。別の例示的な問い合わせカテゴリーは、「ＭＢＭＳのサービスのうちのどれがＭＢＭＳに関心のあるＷＴＲＵによって加入されているか」である可能性がある。別の例示的な問い合わせカテゴリーは、「ＭＢＭＳのサービスのうちのどれが、過去の特定の期間内に提供され、ＷＴＲＵによって受信されたか」である可能性がある。その他の問い合わせカテゴリーが、異なる用語および問い合わせの語句とともに使用される可能性がある。例えば、上記の例示的な問い合わせカテゴリーにおける用語は、交換可能であり、さまざまに組み合わされる可能性がある。

本明細書において説明されるのは、ネットワークによるＭＢＭＳのサービスの状態の問い合わせのための方法およびメカニズムである。必要なとき、ネットワークのＭＢＭＳの運用者は、問い合わせのメッセージまたはサービスの問い合わせのＩＥをＭＢＭＳのＷＴＲＵのすべてに送信することができる。

問い合わせは、以下の項目のより多くのうちの１つを含み得る。例えば、問い合わせは、ＷＴＲＵの現在の受信状態が要求され得るＭＢＭＳのサービスのリストを含む可能性がある。ＭＢＭＳのサービスのリストは、例えば、それらのＭＢＭＳのサービスのサービス識別情報（サービスＩＤ）などによって識別され得る。別の例において、問い合わせは、ＷＴＲＵの現在の受信状態、意図される受信状態、および加入状態のうちの１つまたは複数が要求され得るＭＢＭＳのサービスのそれぞれの問い合わせるカテゴリーのインジケータ（ｑｕｅｒｙｉｎｇ ｃａｔｅｇｏｒｙ ｉｎｄｉｃａｔｏｒ）をともなうＭＢＭＳのサービスのリストを含み得る。ＭＢＭＳのサービスのリストは、例えば、それらのＭＢＭＳのサービスのサービスＩＤなどによって識別され得る。

別の例において、ＷＴＲＵのＭＢＭＳのサービスの状態が要求され得る問い合わせに、１つまたは複数のサービスの問い合わせカテゴリーのインジケータが、含まれる可能性がある。この場合、サービスＩＤまたは同等のもの、要求から省略される可能性がある。別の例において、ＭＢＭＳのサービスのそれぞれに関するＷＴＲＵのＭＢＭＳのサービスの状態が状態の（１つまたは複数の）特定のカテゴリーに関して要求され得るそれらのＭＢＭＳのサービスのリストにそれぞれが関連付けられた（すなわち、ＭＢＭＳのサービスのリストが後に続く）１つまたは複数のサービスの問い合わせカテゴリーのインジケータ。ＭＢＭＳのサービスのリストは、例えば、それらのＭＢＭＳのサービスのサービスＩＤなどによって識別され得る。

ＭＢＭＳのサービスの問い合わせは、問い合わせおよびＷＴＲＵの応答を改善するのに役立つ可能性があるその他の関連するパラメータも含み得る。これは、以下のうちの１つまたは複数を含み得る。例えば、ＭＢＭＳのサービスの問い合わせは、ＷＴＲＵの応答が送信されるように要求され、ＷＴＲＵによってネットワークに送信され得る有効タイマー（ｖａｌｉｄｉｔｙ ｔｉｍｅｒ）などの時間の範囲のパラメータを含む可能性がある。別の例において、ＭＢＭＳのサービスの問い合わせは、要求が過去の履歴的な状態に関する（過去の履歴的な状態を含める）ものである場合に、ＷＴＲＵが要求された状態をどれだけ時間をさかのぼってレポートすべきかに関する時間の範囲のパラメータを含む可能性がある。

別の例において、ＭＢＭＳのサービスの問い合わせは、ＷＴＲＵの応答が送信され得るＭＢＳＦＮエリア（ＭＢＳＦＮ−ａｒｅａ）または何らかのその他のエリアの定義などのエリアの範囲のパラメータを含み得る。別の例において、ＭＢＭＳのサービスの問い合わせは、目標とする応答の情報を識別するためにＷＴＲＵが応答に含めることができる特定の問い合わせタグ番号（ｑｕｅｒｙ ｔａｇ ｎｕｍｂｅｒ）または問い合わせＩＤを含み得る。別の例において、ＭＢＭＳのサービスの問い合わせは、目標とする応答の情報を識別するためにＷＴＲＵが応答に含めることができるある形態のタイムスタンプまたはインジケータを含み得る。

別の例において、ＭＢＭＳのサービスの問い合わせは、信号強度、信号品質、または関係のあるＭＢＭＳのサービスに関連するか、またはＷＴＲＵのＭＢＭＳの受信に関して１つにまとめられた値としてかいずれかの受信誤り率のレポートなどの受信品質を問い合わせる品質パラメータを含み得る。この例の変更形態において、上述の量に関する品質の閾値を超えるかまたはその品質の閾値未満であるかのいずれかの受信されているサービスに関する追加的なフィードバックをレポートするようにＷＴＲＵが要求されるように、上述の量に関する品質の閾値が含まれ得る。

ＭＢＭＳのサービスの問い合わせは、応答するＷＴＲＵによって生成されるサービスの問い合わせの応答の容量を制限するためのフィルタリングパラメータも含み得る。そのようなパラメータの例は、Ｎの値に対するＷＴＲＵ−ＩＤの関係が、ＷＴＲＵが要求に応答するかどうかおよび／またはＷＴＲＵが要求にいつ応答するかを決定するような数Ｎである可能性がある。例として、Ｎが１以上の整数である場合、ＷＴＲＵが問い合わせにいつ応答するについての決定は、自身のＷＴＲＵ−ＩＤ ｍｏｄ Ｎ＝（Ｎ−１）であるＷＴＲＵが問い合わせの応答を送信しない可能性があるか、または自身のＷＴＲＵ−ＩＤ ｍｏｄ Ｎ＝（Ｎ−１）であるＷＴＲＵだけが応答を送信する可能性があることである可能性がある。

別の例において、ＷＴＲＵ−ＩＤモジュロＮの値は、どのサブフレームにおいてＷＴＲＵが要求に応答することができるかを決定する可能性がある。

本明細書において説明されるのは、ダウンリンクにおけるＭＢＭＳのサービスの問い合わせの送信のために使用され得る方法、メカニズム、およびメッセージである。具体的には、ＭＢＭＳのサービスの状態の問い合わせは、以下のメカニズムまたは形態のうちの１つまたは複数でＭＢＭＳに関心のあるＷＴＲＵに送信され得る。

例えば、新しいＲＲＣメッセージ「ＭＢＭＳサービス状態問い合わせ（ＭＢＭＳ Ｓｅｒｖｉｃｅ Ｓｔａｔｕｓ Ｑｕｅｒｙ）」が、問い合わせのためにＭＣＣＨを介してＭＢＳＦＮサブフレームで送信されることができる。このＲＲＣメッセージは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージと同じようにまたは異なるようにスケジューリングされることができ、スケジューリングされたＭＢＳＦＮサブフレームでセルにおいて送信されることができる。代替的に、ＭＢＭＳサービス状態問い合わせは、必要なときには、（事前に決定されるか、または設定される）ある期間内に周期的にＭＣＣＨを介してＭＢＳＦＮサブフレームで送信されるようにスケジューリングされることができる。代替的に、問い合わせメッセージは、（シグナリング空間のオーバーヘッドを抑えるために）ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージと同じ周期性、ならびに同じフレームオフセットおよび同じサブフレーム番号の構成を用いて送信するようにスケジューリングされることができる。既存のＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージが新しい問い合わせメッセージと同時に送信される可能性がある場合、レガシーＷＴＲＵに影響を与えないために、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎが、新しい問い合わせメッセージに優先する。

別のスケジューリングの例において、問い合わせメッセージは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージと同じ周期性および同じオフセットを用いるが、ただし、異なるサブフレーム番号を用いて送信するようにスケジューリングされることができる。別のスケジューリングの例において、問い合わせメッセージは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージと同じ周期性および同じ（１つまたは複数の）サブフレーム番号を用いるが、ただし、異なるフレームオフセットを用いて送信するようにスケジューリングされることができる。別のスケジューリングの例において、問い合わせメッセージは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとは異なる周期性を用い、同じまたは異なるフレームオフセットを用いるが、ただし、同じサブフレーム番号を用いて送信するようにスケジューリングされることができる。

別のメカニズムにおいては、新しいＭＢＭＳ無線ネットワーク一時識別情報（ＭＢＭＳ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｔｙ）、例えば、ＭＢＭＳ問い合わせ（（ＭＱ）−ＲＮＴＩ）が、（送信の通知（２３５）として図２に示されるように）次の修正期間または事前に定義された時間の境界における新しいＭＢＭＳサービス状態問い合わせメッセージの到着を示すように物理ダウンリンク制御チャネル（ＰＤＣＣＨ）に追加され得る。ＭＱ−ＲＮＴＩに対して、ＤＬ制御情報（ＤＣＩ）フォーマット１Ｃが、ＭＢＭＳ ＲＮＴＩ（Ｍ−ＲＮＴＩ）と同様の方法で使用され得る。同様のＭ−ＲＮＴＩのアプローチによるその他のフォーマットも、使用され得る。ＭＱ−ＲＮＴＩは、ＤＣＩフォーマットの巡回冗長検査（ＣＲＣ）をスクランブルするために使用されることができる。

一例において、ＭＱ−ＲＮＴＩは、ＭＢＳＦＮエリアのビットマップを含むことができ、このビットマップ内の１つまたは複数のビットは、対応する（１つまたは複数の）ＭＢＳＦＮエリアを示すことができ、それらの（１つまたは複数の）ＭＢＳＦＮエリアから、およびそれらの（１つまたは複数の）ＭＢＳＦＮエリアに関して問い合わせが到着する。別の例において、ＭＱ−ＲＮＴＩは、ＭＢＭＳに関心のあるＷＴＲＵに対する直接の問い合わせとして単独で使用され得る。つまり、ＭＱ−ＲＮＴＩの（例えば、フォーマット１Ｃの、またはその他のフォーマットのうちの１つの）ＤＣＩは、（１つもしくは複数の）問い合わせるＭＢＭＳのサービスＩＤまたはそれらと同等のものおよび問い合わせカテゴリーのうちの１つまたは複数を運ぶことができる。別の例において、ＭＱ−ＲＮＴＩは、１つもしくは複数の特定の問い合わせカテゴリーの問い合わせのために、または全般的な状態の問い合わせのポーリングのために使用されることができ、これらの両方は、本明細書においてさらに検討される。

ＭＱ−ＲＮＴＩのＤＣＩは、ＷＴＲＵがＭＱ−ＲＮＴＩを監視すべき位置を知ることができるような周期性、フレームオフセット、およびサブフレーム番号でスケジューリングされることができる。

例えば、ＭＱ−ＲＮＴＩは、ＭＱ−ＲＮＴＩのスケジューリングパラメータ、すなわち、周期性、オフセット、およびサブフレーム番号のネットワークシグナリングを省略し、ＷＴＲＵの動作上のオーバーヘッドを最小にするために、Ｍ−ＲＮＴＩに関するものと同じ周期性、同じフレームオフセット、および同じサブフレーム番号を用いて送信するようにスケジューリングされることができる。

代替的に、ＭＱ−ＲＮＴＩは、Ｍ−ＲＮＴＩの同じ周期性およびフレームオフセットを用いるが、ただし、異なるサブフレーム番号を用いて送信するようにスケジューリングされることができる。ＭＱ−ＲＮＴＩのためのサブフレーム番号は、ネットワークシグナリングで明示的に指定される可能性があり、またはＭ−ＲＮＴＩのためのＭＢＳＦＮサブフレームの次のＭＢＳＦＮサブフレームまたは異なるオフセット番号への設定として事前に決定される可能性がある。例えば、Ｍ−ＲＮＴＩのスケジューリングにおいては、周期性およびオフセットを含む計算が、フレーム番号を生成することができる（フレームは１０個のサブフレームを含み得る）。フレーム内の１０個のサブフレームの中で、６個ものサブフレームが、ＭＢＭＳの使用のために割り当てられ得る（ＭＢＳＦＮサブフレームとも呼ばれる）。したがって、これらのＭＢＳＦＮサブフレームが、Ｍ−ＲＮＴＩおよびＭＱ−ＲＮＴＩの送信に利用可能である。例示のみを目的として、サブフレーム＃１、＃２、＃３、＃６、＃７、および＃８がＭＢＳＦＮサブフレームに割り当てられることができ、Ｍ−ＲＮＴＩがサブフレーム＃２で送信されている可能性がある場合、ＭＱ−ＲＮＴＩは、サブフレーム＃３で送信される可能性がある。

別のメカニズムにおいては、Ｍ−ＲＮＴＩの使用が、（送信の通知（２３５）として図２に示される）ＭＢＭＳサービス状態問い合わせメッセージの到着に関する通知として働くように修正され得る。以下の方法のうちの１つが、使用され得る。

例えば、Ｍ−ＲＮＴＩ信号がＭＢＭＳのサービスの状態の問い合わせの到着に関するものである可能性があるかどうかを示すために、追加のビットが、Ｍ−ＲＮＴＩのＰＤＣＣＨのＤＣＩフォーマット（例えば、フォーマット１Ｃ）の予約情報ビット領域に定義されることができる（このようにして、Ｍ−ＲＮＴＩは、問い合わせとエリアの構成の変更との両方に関する通知として働くことができる）。

別の例において、既存のＭ−ＲＮＴＩのＤＣＩフォーマット（例えば、フォーマット１Ｃ）が使用されることができ、現在のＭＢＳＦＮエリアＩＤのビットマップのすべてのビットが同一の値に設定される可能性があり、すなわち、ビットマップのビットがすべて「０」またはすべて「１」に設定される可能性がある。この場合、既存のフォーマットが、問い合わせと構成の変更との両方に関する通知が同時に起こらないことを前提として再使用されることができる。

別のメカニズムにおいて、ＬＴＥ Ｒ１０以上のＭＢＭＳのＷＴＲＵによって読まれることができる本明細書で定義されたＭＱ−ＲＮＴＩは、代替的に、ＭＢＭＳのサービスの状態の問い合わせを目的とする追加的なＭＢＭＳのサービスの状態の問い合わせのパラメータを有するＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージの到着を示すために使用され得る。そのような設定では、レガシーＷＴＲＵは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージがＭＢＭＳのサービスの状態の問い合わせのために変わったとしても影響を受けない。

ＭＱ−ＲＮＴＩは、以下のＭＱ−ＲＮＴＩの内容のうちの１つまたは複数を有する可能性がある。一例において、ＭＱ−ＲＮＴＩのＤＣＩは、ＭＢＳＦＮエリアのビットマップを含むことができ、このビットマップ内の１つまたは複数のビットは、対応する（１つまたは複数の）ＭＢＳＦＮエリアを示すことができ、それらの（１つまたは複数の）ＭＢＳＦＮエリアから、および／またはそれらの（１つまたは複数の）ＭＢＳＦＮエリアに関して問い合わせ（または本明細書に記載のメッセージ変更）が到着する。

別の例において、ＭＱ−ＲＮＴＩのＤＣＩは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎの元の内容、すなわち、ＭＢＭＳのサービスの問い合わせに関連しない内容が変わることになるか否かを示すインジケータを含み得る。この場合、Ｒ１０以上のＭＢＭＳのＷＴＲＵは、ＭＱ−ＲＮＴＩを読むことができる。

別の例において、インジケータは、それがＭＢＭＳのサービスの問い合わせであるのか（例えば、値「１」もしくは「０１」）、ＭＢＳＦＮエリアの構成であるのか（例えば、反転値「０」もしくは「００」）、それともそれらの両方であるのか（例えば、値「１１」もしくは２つのインジケータビットが全く存在しないこと）を（１つまたは複数の）インジケータビットが示すように、ビットマップと一緒に使用され得る。その場合、ビットマップ内のビットの位置が、どの（１つまたは複数の）ＭＢＳＦＮエリアに対して問い合わせおよび／または構成が適用できる可能性があるのかを示すことができる。

別の例において、問い合わせと構成の変更との両方が示される場合、問い合わせおよび構成の変更が当てはまる（１つまたは複数の）ＭＢＳＦＮエリアを示すために別々のビットマップが使用される可能性がある。

別のメカニズムにおいて、Ｍ−ＲＮＴＩおよびＤＣＩに対する本明細書において開示された変更は、代替的に、ＭＢＭＳのサービスの状態の問い合わせを目的とする（追加的なＭＢＭＳのサービスの状態の問い合わせのパラメータを有する）ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージの到着を示すために使用され得る。

例えば、ＬＴＥ Ｒ１０以上のＭＢＭＳのＷＴＲＵは、修正されたＭ−ＲＮＴＩのＤＣＩフォーマットを読むとき、Ｍ−ＲＮＴＩのＤＣＩがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示すことを（例えば、ＤＣＩ内の追加的なビット、またはビットマップの同一のビット値の設定によって）認識することができ、当該メッセージを取得してＭＢＭＳのサービスの状態の問い合わせについて知ることができる。レガシーＷＴＲＵは、修正されたＤＣＩフォーマットを認識しない可能性があり、そのＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを取得しない可能性がある。当該メッセージを取得しないＷＴＲＵは、ネットワークが開始したＭＢＭＳの状態の問い合わせのアクションによって影響を受けない。

別のメカニズムにおいては、ＭＢＭＳのサービスの状態の問い合わせのための１つの新しいＲＲＣのＩＥまたは新しい複数のＩＥが、定義される可能性がある。ＩＥは、ネットワークが、例えば、加入、現在の受信、および意図される受信などのＭＢＭＳのサービスの状態についてＷＴＲＵに問い合わせたいときに、既存のＭＣＣＨメッセージ、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎに付加され得る。

この場合、（１つまたは複数の）ＭＢＭＳサービス問い合わせＩＥ（ＭＢＭＳ−ｓｅｒｖｉｃｅ−ｑｕｅｒｙ ＩＥ）が、ＭＣＣＨメッセージ、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎに含められることができ、Ｍ−ＲＮＴＩが、ＭＢＭＳに関心のあるＷＴＲＵにＭＣＣＨメッセージの変更について通知することができる。それに応じて、ＭＢＭＳに関心のあるＷＴＲＵは、新しいＭＣＣＨメッセージ、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎを読み、問い合わせの性質を知るおよび／または判定することができる。

問い合わせの内容が存在しない場合にそのセクションまたは部分が空のまま残されることができるように、新しいＭＢＭＳサービス状態問い合わせＩＥ（ＭＢＭＳ Ｓｅｒｖｉｃｅ Ｓｔａｔｕｓ Ｑｕｅｒｙ ＩＥ）が、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎの抽象構文記法１（ＡＳＮ．１）フォーマットで配置または定義される可能性がある。

その（１つまたは複数の）新しいＩＥは、「近いうちに受信する関心」および「加入状態」を問い合わされるＭＢＭＳのサービスのサービス識別情報またはそれらと同等のものを含み得る。新しいＩＥは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳ−ＳｅｓｓｉｏｎＩｎｆｏＬｉｓｔ ＩＥに既に記載されているＭＢＭＳのサービスを含み得るが、それらのＭＢＭＳのサービスは既に含まれているので、含む必要はない。サービス識別情報または同等のものがある範囲内で数値的に連続している値を有する場合、本明細書に記載の簡潔なシグナリング方法が使用され得る。

その（１つまたは複数の）新しいＩＥは、問い合わされたサービスのそれぞれに関するか、サービスのグループに関するか、またはサービスのすべてに関する状態の問い合わせのインジケータを含み得る。

その（１つまたは複数の）新しいＩＥは、既存のＩＥ ＭＢＭＳ−ＳｅｓｓｉｏｎＩｎｆｏＬｉｓｔに記載されたＭＢＭＳのサービスに関する状態の問い合わせカテゴリーのインジケータを含み得る。

別のメカニズムにおいては、新しいＭＡＣ ＣＥが、ＭＢＭＳのサービスの問い合わせの転送のために定義され得る。ＭＢＭＳのサービスの問い合わせは、以下の方法のうちの１つまたは複数で、ＭＢＳＦＮサブフレームにおいてＭＡＣ ＣＥ ＤＬとして送信され得る。例えば、ＭＢＭＳ問い合わせＭＡＣ ＣＥ（ＭＢＭＳ Ｑｕｅｒｙ ＭＡＣ ＣＥ）が、ＭＣＣＨおよび／またはＭＴＣＨの送信が行われるＭＢＳＦＮサブフレームのうちのいずれかで送信され得る。

別の例において、ＭＢＭＳ問い合わせＭＡＣ ＣＥは、周期性、例えば、ＭＣＨサブフレーム割り当てパターン（ＭＣＨ ｓｕｂｆｒａｍｅ ａｌｌｏｃａｔｉｏｎ ｐａｔｔｅｒｎ）（ＭＳＡＰ）の周期またはより長い周期で送信するようにスケジューリングされることができる。ＭＢＭＳ問い合わせＭＡＣ ＣＥは、当該周期の最初のサブフレームもしくは最後のサブフレームで送信されるか、または当該周期内の（事前に決定されるか、または設定される）特別なオフセットで送信され得る。代替的に、ＭＢＭＳ問い合わせＭＡＣ ＣＥは、当該周期の最後のＭＴＣＨの送信サブフレームの直後のサブフレームで送信され得る。代替的に、ＭＢＭＳ問い合わせＭＡＣ ＣＥは、その周期の最後のＭＴＣＨの送信（サブフレーム）と一緒に送信され得る。

ＭＢＭＳのサービスの状態の問い合わせのためのＭＡＣ ＣＥが送信されるとき、ＭＢＳＦＮサブフレーム全体は、ＳＩＢ１３で定義されたシグナリングのＭＣＳを用いて符号化され得る。

別のメカニズムにおいては、新しい種類のページングが、ＭＢＭＳのサービスの問い合わせを転送するために定義され得る。新しいＲＮＴＩ、例えば、ＭＢＭＳページング（ＭＰ）−ＲＮＴＩが、この新しい種類のページングメッセージの到着を示すために定義されることができる。ＭＰ−ＲＮＴＩは、ＤＣＩフォーマット１Ａまたは任意のその他の適用可能なフォーマットを使用することができる。ＭＰ−ＲＮＴＩは、ＭＢＭＳサービス問い合わせメッセージ（ＭＢＭＳ Ｓｅｒｖｉｃｅ Ｑｕｅｒｙ ｍｅｓｓａｇｅ）が同じＴＴＩ（ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｉｎｇ ｉｎｔｅｒｖａｌ）の送信で到着していることを通知することを目的とするページングメッセージの種類を識別することができる。

新しい種類のページングメッセージは、マルチセル／マルチキャスト調整エンティティ（ＭＣＥ）によって引き起こされ、ＭＢＳＦＮエリアの下のＭＢＭＳに関心のあるＷＴＲＵのすべてによって受信され得る。これは、ネットワークが、ＭＣＣＨチャネルを現在リスニングしておらず、および／またはＭＢＳＦＮサブフレームを現在監視していないＷＴＲＵに問い合わせを行うことを可能にすることができる。新しい種類のページングメッセージは、通常のページング機会に、または必要なときに通常のページング機会のサブセットで、通常のページングメッセージの一部として送信され得る。つまり、新しい種類のページングメッセージは、両方が同じＴＴＩで送信される場合は、通常のページングメッセージに付加されることができる。

ページングメッセージは、ＭＢＭＳのサービスの状態の問い合わせのための本明細書において定義された（１つまたは複数の）ＲＲＣのＩＥを運ぶことができる。ページングメッセージの問い合わせは、近いうちに送信される予定であるＭＢＭＳのサービスのために最も有用である可能性があり、その使用に制限される可能性がある。ＭＢＭＳのサービスに加入したＷＴＲＵは、そのような近いうちのＭＢＭＳのサービスを受信することに対するそれらのＷＴＲＵの関心を示す本明細書に記載のメカニズムを使用してこのページングに応答することができる。

ページングメッセージは、問い合わせを含む代わりに、ＭＣＣＨで到着することになる問い合わせに応答するためにＭＣＣＨチャネルをリスニングするようにＷＴＲＵに指示することができる。ＷＴＲＵは、適切なときにＭＣＣＨを読み、問い合わせに応答することによってページングに応答することができる。

ＭＰ−ＲＮＴＩのフォーマット１ＡのＤＣＩの予約フィールド（例えば、「ＨＡＲＱプロセス番号」）が、ＭＣＣＨで到着することになる問い合わせに応答するためにＭＣＣＨチャネルをリスニングするようにＷＴＲＵに指示するために使用され得る。ＷＴＲＵは、適切なときにＭＣＣＨを読み、問い合わせに応答することによってＭＰ−ＲＮＴＩの受信に応答することができる。

本明細書において説明されるのは、簡潔なサービス識別情報のリストのシグナリングのためのメカニズムである。問い合わせるサービスの識別情報またはそれらと同等のものの値がある範囲内で数値的に連続している場合、サービスＩＤのリストが、以下のシグナリング方法のうちの１つによって表されることができる。例えば、開始サービスＩＤ値に範囲の値を足したものが、使用され得る。この場合、開始サービスＩＤ値５５５０および範囲の値２０は、連続するサービス識別情報５５５０および５５５１から５５７０を示すことができる。別の例において、開始サービスＩＤ値にシグナリング内のビットマップを足したものが、使用され得る。連続するビットマップのビットの位置が、開始サービスＩＤ値から数が増していく連続するサービスＩＤ値を表すことができ、ビットマップ内の「１」の位置の値が、導出されたＩＤ値によるサービスに関する問い合わせを表すことができる。この場合、開始サービスＩＤ値５５５０およびビットマップ＜左から右に＞「１１００１１００１１００１１００」は、ＩＤ５５５０、５５５１、５５５２、５５５５、５５５６、５５５９、５５６０、５５６３、５５６４を有するサービスの問い合わせを示すことができる。

本明細書において説明されるのは、ＭＢＭＳのサービスの状態の問い合わせのＷＴＲＵの受信のためのメカニズムおよび方法である。ＭＢＭＳに関心のあるＷＴＲＵは、問い合わせを発見および受信し、必要に応じて問い合わせに応答するために、以下の問い合わせインジケータの機会（ｑｕｅｒｙ ｉｎｄｉｃａｔｏｒ ｏｃｃａｓｉｏｎ）または問い合わせメッセージの機会（ｑｕｅｒｙ ｍｅｓｓａｇｅ ｏｃｃａｓｉｏｎ）のうちの１つまたは複数を監視する必要がある可能性がある。

１つのメカニズムにおいて、ＭＱ−ＲＮＴＩがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示すために定義され得る場合、ＷＴＲＵは、ＭＱ−ＲＮＴＩの出現に関してＭＢＳＦＮサブフレームを監視することができ、ＭＱ−ＲＮＴＩが発見される場合、ＷＴＲＵは、次にＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信して問い合わせの詳細を知ることができる。

別のメカニズムにおいて、Ｍ−ＲＮＴＩが本明細書において説明されたように修正され、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示すようにやはり定義される場合、ＷＴＲＵは、Ｍ−ＲＮＴＩを監視することができる。Ｍ−ＲＮＴＩが発見され、そのＭ−ＲＮＴＩがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示す場合、ＷＴＲＵは、次にＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信して問い合わせの詳細を知ることができる。

別のメカニズムにおいて、新しいＭＢＭＳサービス状態問い合わせメッセージおよびＭＱ−ＲＮＴＩが新しいメッセージの到着を示すために定義される場合、ＷＴＲＵは、ＭＱ−ＲＮＴＩの出現に関してＭＢＳＦＮサブフレームを監視することができ、ＭＱ−ＲＮＴＩが発見される場合、ＷＴＲＵは、次にＭＢＭＳサービス状態問い合わせメッセージを受信して問い合わせの詳細を知ることができる。ＭＱ−ＲＮＴＩのＤＣＩフォーマットが問い合わせるサービスのリスト（例えば、識別情報）および／または問い合わせカテゴリーを直接運ぶ場合、ＷＴＲＵは、問い合わせメッセージの取得が完了していると見なすことができる。

別のメカニズムにおいて、新しい問い合わせメッセージが定義され、Ｍ−ＲＮＴＩがそのメッセージの送信を示すために定義される場合、ＷＴＲＵは、ＭＢＳＦＮサブフレーム上でＭ−ＲＮＴＩを探すことができ、Ｍ−ＲＮＴＩが受信され、新しい問い合わせビットがＤＣＩフォーマットにおいて設定されているか、または代替的に、Ｍ−ＲＮＴＩが受信され、ＤＣＩフォーマットのビットマップのビットがすべて同一の値を設定されている場合、ＷＴＲＵは、新しい問い合わせメッセージが送信される予定であることを理解することができる。ＷＴＲＵは、次に新しい問い合わせメッセージを取得することができる。

別のメカニズムにおいて、（１つまたは複数の）新しい問い合わせのＩＥがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージにおいて定義され、Ｍ−ＲＮＴＩがそのＩＥの送信を示すために使用される場合、ＷＴＲＵは、ＭＢＳＦＮサブフレーム上でＭ−ＲＮＴＩを探すことができ、Ｍ−ＲＮＴＩが受信され、新しい問い合わせビットがＤＣＩフォーマットにおいて設定されているか、または代替的に、Ｍ−ＲＮＴＩが受信され、ＤＣＩフォーマットのビットマップのビットがすべて同一の値を設定されている場合、ＷＴＲＵは、メッセージのその（１つまたは複数の）新しいＩＥが送信されるものと理解することができる。ＷＴＲＵは、次にＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージからその（１つまたは複数の）新しい問い合わせのＩＥを取得することができる。

別のメカニズムにおいて、サービスの状態を問い合わせるための新しいＭＡＣ ＣＥが定義される場合、ＷＴＲＵは、新しいＭＢＭＳサービス状態問い合わせＭＡＣ ＣＥ（ＭＢＭＳ ｓｅｒｖｉｃｅ ｓｔａｔｕｓ ｑｕｅｒｙ ＭＡＣ ＣＥ）の送信に関してＭＢＳＦＮサブフレームの機会を監視することができる。

別のメカニズムにおいて、新しいＭＰ−ＲＮＴＩ、およびページングメッセージ内の問い合わせＩＥが定義される場合、ＷＴＲＵは、ＭＰ−ＲＮＴＩの出現に関して通常のページング機会（またはそれらの機会のサブセット）を監視することができる。ＭＰ−ＲＮＴＩが発見される場合、ＷＴＲＵは、次にページングメッセージ内の問い合わせＩＥを取り出すことができる。

別のメカニズムにおいて、新しいＭＰ−ＲＮＴＩが定義され、ページングメッセージが問い合わせが今度のＭＣＣＨに存在することを示す場合、ＷＴＲＵは、ＭＰ−ＲＮＴＩの出現に関して通常のページング機会（またはそれらの機会のサブセット）を監視することができる。ＭＰ−ＲＮＴＩが発見される場合、ＷＴＲＵは、次にページングメッセージを読むことができ、そのページングメッセージが問い合わせが今度のＭＣＣＨに存在することを示す場合、ＷＴＲＵは、次にＭＣＣＨから問い合わせを取得することができる。

別のメカニズムにおいて、新しいＭＰ−ＲＮＴＩが定義され、そのＭＰ−ＲＮＴＩが、問い合わせが今度のＭＣＣＨに存在することを示す場合、ＷＴＲＵは、ＭＰ−ＲＮＴＩの出現に関して通常のページング機会（またはそれらの機会のサブセット）を監視することができる。ＭＰ−ＲＮＴＩが発見されると、ＷＴＲＵは、次にＭＣＣＨから問い合わせを取得することができる。

本明細書において説明されるのは、ＷＴＲＵが問い合わせの応答を生成するための方法、および応答のフォーマットの例である。ＷＴＲＵがＭＢＭＳのサービスの状態の問い合わせを受信する場合、ＷＴＲＵは、そのＷＴＲＵの現在のＭＢＭＳのサービスの状態に基づいて、問い合わせに関連する問い合わされたＭＢＭＳのサービスに関して、問い合わせの応答メッセージ、問い合わせの応答の情報要素、または問い合わせの応答のＭＡＣ ＣＥを生成することができる。ＷＴＲＵの応答は、以下の応答の種類のうちの１つまたは複数であるか、または以下の応答の種類のうちの１つまたは複数を含む可能性がある。

例示的な応答において、サービスの問い合わせカテゴリーが特定のＭＢＭＳのサービスに関して印を付けられている場合、問い合わせまたは問い合わせカテゴリー内のサービスのグループまたはサービスのすべてがＷＴＲＵによって理解され、特定のサービスに関するＷＴＲＵの応答は、はいまたはいいえである可能性がある。これは、１ビットのはい／いいえインジケータによって表され得る。この場合、カテゴリーが「加入している」であり、問い合わせがサービスまたはサービスの（１つもしくは複数の）グループのリストを含む場合、ＷＴＲＵの加入に基づいて、ＷＴＲＵは、各サービスに関して、はいまたはいいえと応答することができる。

別の例示的な応答において、１つまたは複数のサービスが特定の問い合わせカテゴリーを付けずにＷＴＲＵに問い合わされる場合、ＷＴＲＵは、問い合わされたサービスに関するサービス状態インジケータ（ｓｅｒｖｉｃｅ−ｓｔａｔｕｓ−ｉｎｄｉｃａｔｏｒ）を含めることができる。このサービス状態インジケータは、サービスの問い合わせカテゴリーと同様に定義されることができる。例えば、この値は、以下のうちの１つまたは複数である可能性がある。１）加入していない、または関心がない、２）加入している、３）現在受信している（加入していることも示唆する）、４）「受信することに関心がある」（加入していることも示唆する）、５）ＭＢＭＳのサービスに加入したＷＴＲＵが、サービスを「受信することに関心がある」とも見なされることができる、６）受信していない、または代替的に、加入していることを示す値が、加入している、かつ受信していないことを表すために使用され得る、７）受信することに関心がない、または代替的に、加入していることを表す値が、加入している、かつ受信していない、かつ受信することに関心がないことを表すために使用され得る。この場合、ＷＴＲＵは、問い合わせに記載されたすべてのサービスに対してか、または特定のＷＴＲＵに関連するサービス（例えば、ＷＴＲＵが加入した、ＷＴＲＵが受信することに関心がある、もしくはＷＴＲＵが現在受信しているサービス）のみに対してかのいずれかにサービス状態インジケータを生成する可能性がある。

別のメカニズムにおいて、問い合わせの応答の期限が事前に決定されるかまたは設定される場合、ＷＴＲＵは、定義された期限内に応答を生成し、送信する必要がある可能性がある。ＷＴＲＵは、期限が過ぎている場合は応答しない可能性がある。

別のメカニズムにおいて、ＷＴＲＵは、エリアの範囲が事前に決定されるかまたは設定される場合は、設定されたエリアの範囲内でのみ応答を生成する可能性がある。

別のメカニズムにおいて、ＷＴＲＵは、そのＷＴＲＵに関連する問い合わせタグ番号などのその他の問い合わせパラメータが設定されている場合、そのその他の問い合わせパラメータに応答する必要がある可能性がある。

別のメカニズムにおいて、ＷＴＲＵは、フィルタリングパラメータが設定されている場合、そのＷＴＲＵが応答を生成する必要があるかどうかを判定するためのフィルタリング手順を実行する可能性がある。

別のメカニズムにおいて、ＷＴＲＵは、そのＷＴＲＵが問い合わされたサービスに関していかなる肯定的な応答の状態の指示も持たない場合、問い合わせに応答する必要が全くない可能性がある。例えば、要求がＷＴＲＵが受信していないサービスのリストに関する受信状態に関するものである場合、ＷＴＲＵは、すべての状態の指示がいいえであるので、要求に応答しない可能性がある。

別のメカニズムにおいて、ＷＴＲＵは、品質情報（要求に応じて、または必要に応じて）、ＷＴＲＵの位置情報（要求に応じて、または必要に応じて）などのその他のパラメータを応答に含めることができる。

問い合わせがどのように形成されるかに基づいて問い合わせの応答を生成するためにＷＴＲＵが使用する可能性がある手順に関して、一部のさらなる詳細および例が、ここで与えられる。以下のうちの１つまたは複数が、本明細書に記載の応答の種類に加えて適用できる可能性がある。

一例において、いかなる問い合わせカテゴリーもともなわずに問い合わされた（サービスＩＤまたはそれらと同等のものによって示される可能性がある）ＭＢＭＳのサービスのリストに関して、ＷＴＲＵの応答は、サービスＩＤまたは同等のものをサービスに関するサービス状態インジケータとともに含む可能性があり、すなわち、ＷＴＲＵがＭＢＭＳのサービスを現在受信している場合、ＷＴＲＵは、サービスＩＤに関する現在受信中のインジケータを含める可能性がある。

上記の例に関して、ＷＴＲＵは、サービスＩＤと状態の値との対に対して以下の最適化技術のうちの１つまたは複数を使用することもできる。１つの最適化技術を使用して、ＷＴＲＵは、元の問い合わせのリスト内のサービス識別情報の順番の（したがって、対応するサービスに対する）サービス状態インジケータのリストのみを生成し、レポートする可能性がある（サービスＩＤは元の問い合わせのリスト内のサービス状態インジケータの位置によって示唆される）。

別の最適化技術を使用して、ＷＴＲＵは、サービスＩＤインデックスとサービス状態インジケータとの対を生成し、レポートする可能性がある。サービスＩＤインデックス値は、元の問い合わせのリスト内のサービスＩＤ（したがって、サービス）の位置を示す。このようにして、ＷＴＲＵは、サービスの一部がＷＴＲＵに関連がない場合は、それらのサービスに応答することを省くことができる。言い換えると、ＷＴＲＵは、サービスＩＤインデックスまたはサービスＩＤインデックス値を有するレポートを生成することができ、サービスＩＤインデックスまたはサービスＩＤインデックス値は、交換可能なように使用される可能性がある。ＷＴＲＵは、サービス状態インジケータが問い合わせにおいて明らかに示唆されている場合、サービス状態インジケータを省略する可能性がある。

別の最適化技術を使用して、ＷＴＲＵは、元の問い合わせのリスト内のサービス（またはサービスＩＤ）に対応する順序づけられた位置を有するビットマップを生成し、レポートすることができる。ビットマップ内のそれぞれの「１」の位置は、それに関連するサービス状態インジケータを関連する問い合わされたサービスに対する応答として有する。

別の例において、特定の問い合わせカテゴリーを用いて問い合わされた（例えば、サービスＩＤまたはそれと同等のものによって示される）ＭＢＭＳのサービスのリストに関して、ＷＴＲＵは、問い合わされたサービスに対するサービスＩＤまたは同等のものおよびはい／いいえインジケータを含めることができる。ＷＴＲＵは、この例に対して以下の最適化技術のうちの１つまたは複数をやはり使用することができる。第１の最適化技術を使用して、ＷＴＲＵは、シグナリングの効率を最適化するために、元の問い合わせのリスト内のサービス識別情報の順番の（したがって、対応する問い合わされたサービスに対する）はい／いいえインジケータのリストのみを生成し、レポートすることができる。

別の最適化技術を使用して、ＷＴＲＵは、サービスＩＤインデックスとはい／いいえインジケータとの対を生成し、レポートすることができる。サービスＩＤインデックス値は、元の問い合わせのリスト内のサービスＩＤ（したがって、サービス）の位置を示す。このようにして、ＷＴＲＵは、サービスの一部がＷＴＲＵに関連がない場合は、それらのサービスに応答することを省くことができる。

別の最適化技術を使用して、ＷＴＲＵは、元の問い合わせのリスト内のサービス（またはサービスＩＤ）に対応する順序づけられた位置を有するビットマップを生成し、レポートすることができる。ビットマップ内のそれぞれの「１」の位置は、それに関連するはい／いいえインジケータを関連する問い合わされたサービスに対する応答として有する。

別の例において、サービス識別子または同等のものをともなわない１つまたは複数の問い合わせカテゴリーからなる問い合わせに関して、ＷＴＲＵは、ＷＴＲＵが問い合わせカテゴリーに対して肯定的な状態を現在有するサービスのサービス識別情報（または同等のもの）が後に続く問い合わせカテゴリーインジケータを含めることができ、すなわち、問い合わせカテゴリーが現在受信されているサービスに関するものである場合、ＷＴＲＵは、そのＷＴＲＵが現在受信しているサービスに関するサービス識別情報を提供する。問い合わせに１つの問い合わせカテゴリーのみが存在する場合、ＷＴＲＵは、単に、肯定的な状態を持つサービス識別情報を提供することができる。

別の例において、各カテゴリーに対するサービス識別情報のリストが後に続く１つまたは複数の問い合わせカテゴリーからなる問い合わせに関して、ＷＴＲＵは、問い合わせのリスト内のサービス識別情報の順番である可能性がある、レポート内のサービス識別情報（または同等のもの）およびはい／いいえインジケータのリストが後に続く問い合わせカテゴリーインジケータを含めることができる。ＷＴＲＵは、サービスＩＤとはい／いいえインジケータとの対のリストに対して以下の最適化技術のうちの１つまたは複数を使用することもできる。第１の最適化技術を使用して、ＷＴＲＵは、元の問い合わせのリスト内のサービス識別情報の順番の（したがって、問い合わされたサービスに対応する）はい／いいえインジケータのリストのみを生成することができる。

別の最適化技術を使用して、ＷＴＲＵは、サービスＩＤインデックスとはい／いいえとの対のリストを生成することができる。サービスＩＤインデックス値は、元の問い合わせのリスト内のサービスＩＤ（したがって、サービス）の位置を示す。

別の最適化技術を使用して、ＷＴＲＵは、元の問い合わせのリスト内のサービス（またはサービスＩＤ）に対応する順序づけられた位置を有するビットマップを生成することができる。ビットマップ内のそれぞれの「１」の位置は、それに関連するはい／いいえインジケータを関連する問い合わされたサービスに対する応答として有する可能性がある。

本明細書において説明されるのは、ＷＴＲＵの問い合わせの応答で使用され得るセキュリティ署名である。ＭＢＭＳのサービスの状態の問い合わせ、サービスの状態のポーリング、または任意の形態のＭＢＭＳのフィードバック情報に応答するアイドルモードのＷＴＲＵの（および場合によっては接続モードのＷＴＲＵの）セキュリティの理由で、（ＷＴＲＵ−ＩＤの形態によって表される）ＷＴＲＵに関する、（ＭＢＭＳのサービス加入者ＩＤの形態によって表される）ＭＢＭＳユーザに関する、またはこれら２つの識別情報の組み合わせに関する証明の署名が、適切な符号化を用いてＩＥとして生成されることができる。ＷＴＲＵは、この証明のＩＥをＵＬの応答メッセージ、（１つもしくは複数の）応答のＩＥ、または応答のＭＡＣ−ＣＥにさえも含めることができる。これは、ＭＢＭＳの運用者が、ＷＴＲＵおよび／またはＭＢＭＳの加入者ＩＤを識別するのを助けることができる。

本明細書において説明されるのは、ＭＢＭＳのサービスの状態の問い合わせに対するＷＴＲＵの応答メカニズムである。ＷＴＲＵは、以下のＵＬのメカニズムのうちの１つまたは複数を使用して、ＷＴＲＵのＭＢＭＳのサービスの問い合わせの応答を送信することができる。

１つのメカニズムにおいて、非アクセス層（ＮＡＳ）またはＲＲＣの新しい特定のＵＬのメッセージが、定義される可能性がある。接続モードで動作中のＷＴＲＵに関して、ＷＴＲＵは、問い合わせの応答の目的で、ＷＴＲＵのＲＲＣ＿ＣＯＮＮＥＣＴＥＤ状態の動作中の任意の時間にそのＮＡＳまたはＲＲＣメッセージを送信することができる。この場合のネットワークの応答は、必要とされない。

アイドルモードのＷＴＲＵが問い合わせの応答にレポートするために、ＷＴＲＵは、アイドルモードのＷＴＲＵがＲＲＣコネクションを確立した後、（ＮＡＳアタッチのように）ＬＴＥ ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに便乗してＮＡＳメッセージを送ることができる。基地局は、ＮＡＳの部分（問い合わせの応答）をＭＣＥまたはＭＢＭＳサービスノードにディスパッチまたは転送することができる。

ＷＴＲＵは、以下の方法のうちの１つを用いて、ＲＲＣコネクションが確立された後にＲＲＣメッセージを送信することができる。１つの方法において、ＷＴＲＵは、そのＲＲＣメッセージをＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅに載せることができる。別の方法において、ＷＴＲＵは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを、ＭＢＭＳのサービスの問い合わせの応答を含むＲＲＣメッセージで置き換えることができる。別の方法において、ＷＴＲＵは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを送信した後に（例えば、直後に）そのＲＲＣメッセージを別のメッセージとしてネットワークに送信することができる。

ＲＲＣコネクションの原因がＭＢＭＳの問い合わせの応答を送信するためだけであった場合、基地局は、応答が受信された後にＲＲＣコネクションを解放することができる。基地局は、問い合わせの応答をＭＣＥに転送する役割を担うことができる。

別のメカニズムにおいては、ＭＢＭＳのサービスの問い合わせの応答のために（１つまたは複数の）ＲＲＣレベルのＩＥが定義されることができる。応答をレポートする接続モードのＷＴＲＵに関して、ＷＴＲＵは、応答が形成され、サポートするＵＬのＲＲＣメッセージが存在すると直ちに、問い合わせ応答ＩＥ（ｑｕｅｒｙ−ｒｅｓｐｏｎｓｅ−ＩＥ）をサポートするＲＲＣのＵＬのメッセージのうちのいずれかにＩＥを含めることができる。例えば、応答のＩＥを運ぶことができるアップリンクのＲＲＣメッセージは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｃｏｎｆｉｇｕｒａｔｉｏｎＣｏｍｐｌｅｔｅ、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｅｓｔａｂｌｉｓｈｍｅｎｔＣｏｍｐｌｅｔｅ、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅ、ＵＥＣａｐａｂｉｌｉｔｙＩｎｆｏｒｍａｔｉｏｎ、ＭｅａｓｕｒｅｍｅｎｔＲｅｐｏｒｔメッセージなどを含み得る。

応答をレポートするアイドルモードのＷＴＲＵに関して、ＷＴＲＵは、応答のＩＥをＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに含めることができる。この方法またはその他の方法に関連して、ＷＴＲＵが「ＭＢＭＳの状態をレポートする」ための新しい原因コード（ｃａｕｓｅ ｃｏｄｅ）が定義され得る。アイドルモードのＷＴＲＵは、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージでこの原因コードを使用して、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答が目的である可能性があることを示すことができる。

ＷＴＲＵは、フォーマットされた問い合わせの応答のＩＥをネットワークへのＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに含めることができる。したがって、基地局は、コネクションの確立およびメッセージまたはＩＥがＭＢＭＳのサービスの問い合わせの応答に使用される可能性があることを（原因コードから）知ることができる。基地局は、問い合わせの応答をＭＣＥに転送した後、ＲＲＣコネクションを解放することができる。

図３は、ＭＢＭＳのサービスの状態をレポートするアイドルモードのＷＴＲＵに関する例示的な信号フロー図を示す。無線通信システム３００は、ＷＴＲＵ３０５、基地局３１０、およびＭＣＥ３１５を含み得る。ＷＴＲＵ３０５は、アイドルモードであり、アクティブなＭＢＭＳアプリケーションを有する３０８。ＭＣＥ３１５は、ＭＢＭＳサービス状態問い合わせメッセージを基地局３１０に送信することができ（３２０）、そして今度は、基地局３１０が、そのＭＢＭＳサービス状態問い合わせメッセージをＭＣＣＨを介してＷＴＲＵ３０５に転送することができる（３２５）。次に、ＷＴＲＵ３０５は、ＭＢＭＳサービス状態応答を準備し３３０、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｑｕｅｓｔメッセージを、ランダムアクセスチャネルを介して基地局３１０に送信することができる（３３５）。この要求に関して識別される原因は、「ＭＢＭＳの状態を報告する」コードまたはそれに類するものである可能性がある。原因コードの結果として、基地局３１０は、モビリティ管理エンティティ（ＭＭＥ）またはパケットデータネットワークゲートウェイ／サービングゲートウェイ（Ｐ／Ｓ−ＧＷ）に対していかなるアクションも行わない可能性がある（３４０）。次いで、基地局３１０は、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐメッセージを、制御チャネルを介してＷＴＲＵ３０５に送信することができる（３４５）。

ＷＴＲＵ３０５は、個別制御チャネルを介して基地局３１０に送信され得るＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに応答のＩＥを含めることができる（３５０）。次に、基地局３１０は、応答のＩＥによるＭＢＭＳのサービスの状態の報告をＭＣＥ３１５に送信することができる（３５５）。

「ＭＢＭＳの状態を報告する」原因コードが送信されたので、基地局３１０は、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答をレポートするために使用されたことを知ることができる。そのとき、基地局３１０は、ＲＲＣコネクションを解放する（すなわち、ＷＴＲＵのコネクションを切断する）ことができ（３６０）、ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅメッセージを、個別制御チャネルを介してＷＴＲＵ３０５に送信することができ（３６５）、次いで、ＷＴＲＵ３０５は、アイドルモードに戻る（３７０）。

別のメカニズムにおいては、問い合わせの応答のＭＡＣ ＣＥが、ＵＬ方向で定義されることができ、したがって、接続モードのＷＴＲＵは、十分な空きがある場合にＷＴＲＵのＵＬの送信機会のいずれかでＭＢＭＳの問い合わせの応答を送信することができる（これは、接続モードのＷＴＲＵのためのＵＬの送信の機会を増やすことができる）。この場合には、十分な空きとは、ネットワークによって割り当てられたアップリンクの送信の許可が、送信の機会に十分なＵＬの送信のデータ空間またはリソースを割り当てたかどうかを指す可能性がある。

別のメカニズムにおいては、アイドルモードのＷＴＲＵが問い合わせの応答を送信するためにＲＲＣコネクションを確立する代わりに、ＷＴＲＵは、ＮＡＳまたはＲＲＣのＵＬの機会が来るまでアイドルモードのＷＴＲＵの応答を遅らせる可能性がある。これは、ＮＡＳの周期的なトラッキングエリア更新（ＴＡＵ）またはその他のＮＡＳ／ＲＲＣの周期的なＵＬのメッセージの送信機会を指す。

例えば、ＷＴＲＵは、ＭＢＭＳのレポートに関する問い合わせの応答のＮＡＳのＩＥまたはＲＲＣのＩＥを構築し、それをＮＡＳのＴＡＵまたはその他のＮＡＳメッセージに付加することができる。ＷＴＲＵは、周期的なＴＡＵの時間に、またはその他のＮＡＳの周期的な更新メッセージの機会に送信されるＲＲＣ ＵＬＩｎｆｏｒｍａｔｉｏｎＴｒａｎｓｆｅｒメッセージにそのＩＥを付加することもできる。

別の例においては、ＷＴＲＵは、ＭＢＭＳのサービスの応答が生成される時間の後の次の周期的なＴＡＵの機会の知識に基づいて「遅延」方法を使用すべきかどうかを判定することができる。「ＴＡＵの時間までの遅延」が事前に定義された時間未満であるか、またはネットワークの問い合わせ／ポーリングの周期以内である場合、遅延方法が、応答をやはり行いながらネットワークのトラフィックおよびＲＡＣＨの衝突を減らすために使用されることができる。

本明細書において説明されるのは、サービスの受信の開始／停止の追跡レポートのためのメカニズムである。ＷＴＲＵ／ユーザがサービスの受信状態についてのネットワークの問い合わせに応答した後、ＷＴＲＵ／ユーザが、特定のＭＢＭＳのサービスの受信状態を変更し得る可能性がある。例えば、ＷＴＲＵは、前に受信していない、関心がない、もしくは加入していないとレポートしたサービスを受信し始める可能性があり、またはＷＴＲＵは、前に受信しているとレポートしたサービスの受信を停止する可能性があり、またはＷＴＲＵは、異なるサービスに関してこれらの組み合わせを実行する、すなわち、受信中の１つのサービスを停止し、前は単に関心があるかもしくは加入しているだけであった別のサービスを開始する可能性がある。

これらの場合、ＷＴＲＵが受信状態の変更の即時レポートをネットワークプロバイダに送信することが有用である可能性がある。ＷＴＲＵが、時間がまだ設定されたまたはデフォルトの追跡レポート時間範囲（ｆｏｌｌｏｗ−ｕｐ−ｒｅｐｏｒｔ−ｔｉｍｅ−ｒａｎｇｅ）内にある場合に受信状態の変更をレポートすることがやはり有益である可能性がある。

（上記のレポート時間範囲の定義を用いて、または上記のレポート時間範囲の定義を用いずに）即時レポートの根拠となり得るその他の条件は、関連するＭＢＭＳサービスが即時開始／停止イベントレポート（ｐｒｏｍｐｔ−ｓｔａｒｔ／ｓｔｏｐ−ｅｖｅｎｔ−ｒｅｐｏｒｔ）を必要とすることをネットワークが示すこと、ＷＴＲＵがこのサービスの状態を前にレポートしていること、またはそれらの両方を含む可能性がある。

接続モードのＷＴＲＵは、ＭＢＭＳ問い合わせ応答ＩＥ（ＭＢＭＳ−ｑｕｅｒｙ−ｒｅｓｐｏｎｓｅ−ＩＥ）をサポートするＲＲＣのＵＬのメッセージのうちのいずれかのＭＢＭＳ問い合わせ応答ＩＥを用いて、または問い合わせの応答のためのＭＡＣ ＣＥ ＵＬでこのイベントをレポートすることができる。

アイドルモードのＷＴＲＵは、本明細書で既に説明されたアイドルモードのためのメカニズムを用いてこのイベントをレポートすることができる。

ＷＴＲＵがＭＢＭＳのサービスの状態を過剰に頻繁に送信し、潜在的にネットワークトラフィックをオーバーフローさせることを防ぐために、禁止タイマーがＷＴＲＵにおいて構成され得る。タイマーは、状態のレポートが送信されるたびに設定またはリセットされることができる。ＷＴＲＵは、禁止タイマーが切れるまで別の状態のレポートを送信しない可能性がある。サービスが過剰に頻繁に切り替わって状態の報告を引き起こすことを防ぐために、サービス選択安定化タイマー（ｓｅｒｖｉｃｅ ｓｅｌｅｃｔｉｏｎ ｓｔａｂｉｌｉｚｅ ｔｉｍｅｒ）がＷＴＲＵにおいて構成され得る。タイマーは、サービスの選択／削除が行われるたびに設定またはリセットされることができる。状態のレポートを引き起こすことは、安定化タイマーが切れるまで控えられる。

タイマーは、事前に決定されるか、またはネットワークが即時開始／停止イベントレポートを構成もしくは有効化するときにネットワークによって構成されることができる。

本明細書において説明されるのは、ＷＴＲＵの全般的なＭＢＭＳのサービスの状態のレポートのためのメカニズムである。ＭＢＭＳのサービスの状態を取得する別の方法は、ネットワークが、エリア内のＷＴＲＵによるすべてのＭＢＭＳのサービスに対する全般的な関心に関してポーリングすることである可能性がある。

全般的なＭＢＭＳのサービスの状態のレポートのポーリングは、ネットワークによってアクティブ化され得るか、またはＭＢＭＳに関心のあるＷＴＲＵに対して定義された混合したセルにおけるデフォルトの動作モードである可能性がある。

全般的なレポートのモードは、システム情報内、またはＭＣＣＨメッセージ内、またはＭＱ−ＲＮＴＩもしくはＭ−ＲＮＴＩに関連するＤＣＩフォーマットなどのＤＣＩフォーマット内のフラグを設定することによってネットワークによりアクティブ化されることができる。フラグは、定義されたレポート期間に関連付けられることができ、この定義されたレポート期間内に、ＷＴＲＵはそのＭＢＭＳのサービスの状態を、例えば、その期間内に一回、レポートすることができる。フラグの代わりに、またはフラグに加えて、ポーリングがポーリングタグ番号（ｐｏｌｌ−ｔａｇ−ｎｕｍｂｅｒ）として存在する可能性があり、ＷＴＲＵは、ＷＴＲＵのレポートと一緒にこのポーリングタグ番号を送信することができる。アクティブ化は、ポーリングインジケータ（フラグもしくはポーリングタグ番号）を取り除くことによって、メッセージ（ＭＣＣＨメッセージ）で、またはＭ−ＲＮＴＩもしくはＭＱ−ＲＮＴＩに関連するＤＣＩフォーマットなどのＤＣＩフォーマットで非アクティブ化インジケータを送信することによって明示的にオフにされ得る。

全般的なレポートの要求は、仕様がＭＢＭＳのＷＴＲＵにそのサービスの状態を適切な機会にレポートするように求める可能性があるデフォルトのアクションである可能性がある。

接続モードのＷＴＲＵに関して、ＭＢＭＳのサービスの状態のレポートは、ＷＴＲＵのＭＢＭＳの受信がアクティブである場合、すなわち、サービスが現在受信されているか、またはサービスの送信がＭＣＣＨメッセージの変化を監視することによって探索されている場合に適用できる可能性がある。ＭＢＭＳのサービスの状態のレポートは、ＭＢＭＳの受信（および／または監視）がアクティブである場合にアイドルモードのＷＴＲＵにも適用され得る。

全般的なレポートは、ＷＴＲＵのＭＢＭＳの受信または監視がアクティブでない場合は必要とされない可能性がある。

本明細書において説明されるのは、サービスの状態のレポートの時間の範囲およびエリアの範囲に対処するためのメカニズムである。全般的なＭＢＭＳのサービスの状態（またはその他のポーリングされる状態）のレポートは、時間の範囲および／またはＭＢＳＦＮエリアの範囲を有する可能性がある。

例えば、ＷＴＲＵは、全般的なＭＢＭＳの状態のレポートを事前に定義されたもしくは設定された期間ごとに、またはアクティブ化フラグもしくはその他のポーリングの指示があるごとに一回実行する可能性がある。ＷＴＲＵは、指定された期間を示すためにレポートにタイムスタンプおよび／またはポーリングタグ番号を付加することができる。タイムスタンプおよび／またはポーリングタグ番号の値は、システム情報（ＳＩ）、ＭＣＣＨメッセージ、またはＭＱ−ＲＮＴＩもしくはＭ−ＲＮＴＩに関連するＤＣＩフォーマットで示され得る。

別の例において、ＷＴＲＵは、１つのＭＢＳＦＮエリアごとにサービスの状態をレポートする可能性がある。概して、これは、ＷＴＲＵがＭＢＭＳのサービスを受信しているか、またはＭＢＭＳのサービスを受信することを意図するＭＢＳＦＮエリアである可能性がある。ＷＴＲＵは、ＭＢＳＦＮエリアＩＤをそのＷＴＲＵの全般的なＭＢＭＳの状態のレポートに付加する可能性もある。ＷＴＲＵがＭＢＳＦＮエリアを変更しているか、またはＷＴＲＵがＭＢＳＦＮエリアを変更することを意図する場合、ＷＴＲＵは、その全般的なＭＢＭＳのサービスの状態を新しいエリアにレポートする可能性がある。

別の例において、ＷＴＲＵは、そのＭＢＭＳのサービスの状態（すなわち、加入状態、受信状態、または受信の意思）が、自動的な加入の期限切れおよび有効化された新しい加入を含め、変わった場合に、そのＷＴＲＵの全般的なＭＢＭＳの状態のレポートを更新することができる。ＷＴＲＵは、レポートにおいて更新の目的を示す必要がある可能性がある。

本明細書において説明されるのは、全般的なＭＢＭＳのサービスの状態のレポートの内容である。全般的なＭＢＭＳのサービスのレポートにおいて、ＷＴＲＵは、以下、すなわち、１）ＷＴＲＵ／ユーザによるすべての加入しているＭＢＭＳのサービス、２）ＷＴＲＵが現在受信しているＭＢＭＳのサービス、または３）ＷＴＲＵ／ユーザが「受信することに関心がある」ＭＢＭＳのサービスのうちの１つまたは複数をレポートする可能性がある。別個のレポートが、状態のそれぞれの種類に対して使用される可能性がある。１つのレポートが、複数の状態の種類をレポートするために使用される可能性がある。

ポーリングが上記の状態の種類のうちの１つに関するものである可能性がある場合、ＷＴＲＵは、サービスＩＤのリストの形態でレポートを送信することができる。ネットワークのポーリングが２つ以上の状態の種類に関するものである場合、ＷＴＲＵは、以下の形式のうちの１つまたは複数で、すなわち、１）それらのＷＴＲＵに関連するＭＢＭＳのサービスに関するサービスＩＤもしくは同等のものおよびサービス状態インジケータのリストの形式で、または２）ポーリングされた問い合わせカテゴリーに関するサービス識別情報のリストをともなう（すなわち、そのリストが後に続く）問い合わせカテゴリーでレポートすることができる。

ＷＴＲＵは、ＭＢＭＳの運用者がレポートを収集および評価することを容易にするためのその他のレポートパラメータと一緒に以下のうちの１つまたは複数をレポートすることもできる。例えば、レポートは、受信された信号＋干渉対雑音比（ＳＩＮＲ）、基準信号受信品質（ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ ｒｅｃｅｉｖｅｄ ｑｕａｌｉｔｙ）（ＲＳＲＱ）、受信されたブロック誤り率（ＢＬＥＲ）、および／またはその他の高レベルの品質インジケータなどの現在直面している受信品質を含み得る。レポートは、例えば、ＷＴＲＵの位置情報も含み得る。

本明細書において説明されるのは、全般的なＭＢＭＳの状態のレポートのレポートメカニズムである。ＷＴＲＵは、以下のメカニズムのうちの１つまたは複数を使用して、全般的なＭＢＭＳの状態のレポートを送信することができる。１つのメカニズムにおいては、ＵＬの特別なＭＢＭＳのレポートのメッセージが、ＮＡＳまたはＲＲＣプロトコルのレベルでこの全般的なレポートのために定義され得る。例えば、接続モードのＷＴＲＵは、新しいＮＡＳまたはＲＲＣメッセージが任意の時間に状態のレポートを送信するために使用され得るようなアプローチを使用することができる。アイドルモードのＷＴＲＵは、ＭＢＭＳのサービスの状態のレポートのための新しいＮＡＳメッセージがＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに載せられることができるか、またはＭＢＭＳのサービスの状態のレポートのための新しいＲＲＣメッセージがＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに模せられることができるか、ＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージを置き換えることができるか、もしくはＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージの直後に送信されることができるようなアプローチを使用し得る。

別のメカニズムにおいては、ＭＢＭＳのレポートのＩＥの特別な組が、ＮＡＳまたはＲＲＣのＵＬのメッセージのうちの１つまたは複数に付加されるように定義され得る。この場合、接続モードのＷＴＲＵは、ＷＴＲＵが当該ＩＥをサポートする任意のＵＬのＲＲＣメッセージに（１つまたは複数の）レポートのＩＥを含めることができるようなアプローチを使用し得る。アイドルモードのＷＴＲＵは、ＷＴＲＵがＲＲＣＣｏｎｎｅｃｔｉｏｎＳｅｔｕｐＣｏｍｐｌｅｔｅメッセージに（１つまたは複数の）レポートのＩＥを含めることができるようなアプローチを使用し得る。

別のメカニズムにおいて、ＷＴＲＵは、ＮＡＳまたはＲＲＣのＵＬの機会があるまでアイドルモードのＷＴＲＵの応答を遅らせることができる。

別のメカニズムにおいては、ＵＬの特別なＭＡＣ ＣＥが、この全般的なレポートのために定義され得る。この場合、接続モードのＷＴＲＵは、新しく定義されたＭＡＣ ＣＥで全般的なＭＢＭＳの状態のレポートを送信するためのアプローチを使用し得る。

実施形態

１．マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供する、無線送受信ユニット（ＷＴＲＵ）によって実施される方法であって、ＭＢＭＳ制御チャネルを介してＭＢＭＳサービス状態問い合わせメッセージを受信するステップを含む、方法。

２．ＭＢＭＳサービス状態応答メッセージを送信するステップをさらに含む実施形態１に記載の方法。

３．ＭＢＭＳサービス状態問い合わせメッセージおよびＭＢＭＳサービス状態応答メッセージは、無線リソースコントローラのメッセージである実施形態１から２のいずれか１つに記載の方法。

４．ＭＢＭＳサービス問い合わせメッセージはＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとともに受信される実施形態１から３のいずれか１つに記載の方法。

５．ＭＢＭＳサービス状態問い合わせメッセージは少なくともＭＢＭＳサービス識別子のリストを含む実施形態１から４のいずれか１つに記載の方法。

６．ＭＢＭＳサービス識別子は、ＷＴＲＵが受信しているかまたは受信することを意図しているＭＢＭＳサービスのカウンティングまたは問い合わせのためのものである実施形態１から５のいずれか１つに記載の方法。

７．ＭＢＭＳサービス識別子インデックス値を有するレポートを生成するステップであって、各ＭＢＭＳサービス識別子インデックス値は、ＷＴＲＵが受信しているかまたは受信することを意図しているＭＢＭＳサービスに対応するカウンティングまたは問い合わせリスト内のサービス識別子の位置を示す、生成するステップをさらに含む実施形態１から６のいずれか１つに記載の方法。

８．ＭＢＭＳサービス状態応答メッセージは、事前に決定された期限または設定された期限のうちの少なくとも１つの範囲内で送信される実施形態１から７のいずれか１つに記載の方法。

９．ＷＴＲＵは、ＭＢＭＳサービス状態問い合わせメッセージがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージと一緒に受信されることを条件として、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを最初に復号する実施形態１から８のいずれか１つに記載の方法。

１０．マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供するための、ネットワークにおいて実施される方法であって、ＭＢＭＳサービス状態問い合わせメッセージを形成するステップを含む、方法。

１１．ＭＢＭＳサービス状態問い合わせメッセージの送信をスケジューリングするステップをさらに含む実施形態１０に記載の方法。

１２．ＭＢＭＳ制御チャネルを介してＭＢＭＳサービス状態問い合わせメッセージを送信するステップをさらに含む実施形態１０から１１のいずれか１つに記載の方法。

１３．ＭＢＭＳサービス状態応答メッセージを受信するステップをさらに含む実施形態１０から１２のいずれか１つに記載の方法。

１４．ＭＢＭＳサービス問い合わせメッセージはＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとともに送信される実施形態１０から１３のいずれか１つに記載の方法。

１５．ＭＢＭＳサービス状態問い合わせメッセージは少なくともＭＢＭＳサービス識別子のリストを含み、さらに、ＭＢＭＳサービス識別子は、ＷＴＲＵが受信しているかまたは受信することを意図しているＭＢＭＳサービスのカウンティングまたは問い合わせのためのものである実施形態１０から１４のいずれか１つに記載の方法。

１６．マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供する、無線送受信ユニット（ＷＴＲＵ）によって実施される方法であって、アイドルモードでＭＢＭＳサービス状態問い合わせメッセージを受信するステップを含む、方法。

１７．ＭＢＭＳサービス状態応答を準備するステップをさらに含む実施形態１から９および１６のいずれか１つに記載の方法。

１８．接続モードで無線リソース制御（ＲＲＣ）のコネクション要求メッセージを送信するステップをさらに含む実施形態１から９および１６から１７のいずれか１つに記載の方法。

１９．ＲＣＣのコネクションセットアップメッセージを受信するステップをさらに含む実施形態１から９および１６から１８のいずれか１つに記載の方法。

２０．ＲＣＣのコネクションセットアップ完了メッセージを送信するステップをさらに含む実施形態１から９および１６から１９のいずれか１つに記載の方法。

２１．ＲＣＣのコネクション解放メッセージを受信し、アイドルモードに戻るステップをさらに含む実施形態１から９および１６から２０のいずれか１つに記載の方法。

２２．ＲＲＣのコネクション要求メッセージは、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答を目的とすることを示す原因コードを含む実施形態１から９および１６から２１のいずれか１つに記載の方法。

２３．ＲＣＣのコネクションセットアップ完了メッセージは、フォーマットされた問い合わせの応答の情報要素（ＩＥ）を含む実施形態１から９および１６から２２のいずれか１つに記載の方法。

２４．ＲＲＣコネクションは、問い合わせの応答のＩＥを転送した後に切断される実施形態１から９および１６から２３のいずれか１つに記載の方法。

２５．接続モードのＷＴＲＵが任意のＷＴＲＵのＵＬの送信機会にＭＢＭＳの問い合わせの応答を送信することができるように、問い合わせの応答の媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）が、アップリンク（ＵＬ）方向で定義される実施形態１から９および１６から２４のいずれか１つに記載の方法。

２６．マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供する、無線送受信ユニット（ＷＴＲＵ）によって実施される方法であって、アイドルモードでＭＢＭＳサービス状態問い合わせメッセージを受信するステップを含む、方法。

２７．ＭＢＭＳのレポートに関する問い合わせの応答の非アクセス層（ＮＡＳ）の情報要素（ＩＥ）または無線リソース制御（ＲＣＣ）のＩＥを生成することによってＭＢＭＳサービス状態応答を準備するステップをさらに含む実施形態１から９および１６から２６のいずれか１つに記載の方法。

２８．ＮＡＳのトラッキングエリア更新（ＴＡＵ）メッセージに当該ＩＥを付加するステップをさらに含む実施形態１から９および１６から２７のいずれか１つに記載の方法。

２９．ＴＡＵメッセージを送信するステップをさらに含む実施形態１から９および１６から２８のいずれか１つに記載の方法。

３０．ＲＣＣのコネクションセットアップメッセージを受信するステップをさらに含む実施形態１から９および１６から２９のいずれか１つに記載の方法。

３１．ＲＣＣのコネクションセットアップ完了メッセージを送信するステップをさらに含む実施形態１から９および１６から３０のいずれか１つに記載の方法。

３２．ＲＣＣのコネクション解放メッセージを受信し、アイドルモードに戻るステップをさらに含む実施形態１から９および１６から３１のいずれか１つに記載の方法。

３３．ＴＡＵメッセージは、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答を目的とすることを示す原因コードを含む実施形態１から９および１６から３２のいずれか１つに記載の方法。

３４．ＲＣＣのコネクションセットアップ完了メッセージは、フォーマットされた問い合わせの応答の情報要素（ＩＥ）を含む実施形態１から９および１６から３３のいずれか１つに記載の方法。

３５．ＲＲＣコネクションは、問い合わせの応答のＩＥを転送した後に切断される実施形態１から９および１６から３４のいずれか１つに記載の方法。

３６．接続モードのＷＴＲＵが任意のＷＴＲＵのＵＬの送信機会にＭＢＭＳの問い合わせの応答を送信することができるように、問い合わせの応答の媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）が、アップリンク（ＵＬ）方向で定義される実施形態１から９および１６から３５のいずれか１つに記載の方法。

３７．ＭＢＭＳ問い合わせ無線ネットワーク一時識別情報（ＭＢＭＳ ｑｕｅｒｙ ｒａｄｉｏ ｎｅｔｗｏｒｋ ｔｅｍｐｏｒａｒｙ ｉｄｅｎｔｉｔｙ）（ＭＱ−ＲＮＴＩ）がＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージの到着を示す実施形態１から９および１６から３６のいずれか１つに記載の方法。

３８．ＭＱ−ＲＮＴＩのダウンリンク制御情報（ＤＣＩ）はＭＢＳＦＮエリアのビットマップを含む実施形態１から９および１６から３７のいずれか１つに記載の方法。

３９．ＭＱ−ＲＮＴＩのＤＣＩは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎの元の内容が変わることになるかどうかを示す実施形態１から９および１６から３８のいずれか１つに記載の方法。

４０．インジケータおよびビットマップは、それがＭＢＭＳのサービスの問い合わせであるのか、ＭＢＳＦＮエリアの構成であるのか、それともそれらの両方であるのかを示す実施形態１から９および１６から３９のいずれか１つに記載の方法。

４１．問い合わせが当てはまり、構成の変更が当てはまるＭＢＳＦＮエリアを示すために別々のビットマップが使用される実施形態１から９および１６から４０のいずれか１つに記載の方法。

４２．Ｍ−ＲＮＴＩが、ＭＢＭＳのサービスの状態の問い合わせを目的とするＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージの到着を示すために使用される実施形態１から９および１６から４１のいずれか１つに記載の方法。

４３．ＤＣＩが、ＭＢＭＳのサービスの状態の問い合わせを目的とするＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージの到着を示すために使用される実施形態１から９および１６から４２のいずれか１つに記載の方法。

４４．ＭＱ−ＲＮＴＩがＭＢＭＳのサービスの状態の問い合わせを示すために定義されていることを条件に、ＭＱ−ＲＮＴＩの出現に関してＭＢＳＦＮサブフレームを監視するステップをさらに含む実施形態１から９および１６から４３のいずれか１つに記載の方法。

４５．ＭＱ−ＲＮＴＩが発見されることを条件に、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信して問い合わせの詳細について知るステップをさらに含む実施形態１から９および１６から４４のいずれか１つに記載の方法。

４６．ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示すためにＭ−ＲＮＴＩが修正され、定義されていることを条件に、Ｍ−ＲＮＴＩを監視するステップをさらに含む実施形態１から９および１６から４５のいずれか１つに記載の方法。

４７．Ｍ−ＲＮＴＩが発見され、そのＭ−ＲＮＴＩがＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージのＭＢＭＳのサービスの状態の問い合わせを示すことを条件に、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージを受信して問い合わせの詳細について知るステップをさらに含む実施形態１から９および１６から４６のいずれか１つに記載の方法。

４８．マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供するための方法であって、アイドルモードの無線送受信ユニット（ＷＴＲＵ）がＭＢＭＳサービス状態問い合わせメッセージを受信するステップを含む、方法。

４９．ＷＴＲＵがＭＢＭＳサービス状態応答を準備するステップをさらに含む実施形態１から９および１６から４８のいずれか１つに記載の方法。

５０．接続モードのＷＴＲＵが無線リソース制御（ＲＲＣ）のコネクション要求メッセージを送信するステップをさらに含む実施形態１から９および１６から４９のいずれか１つに記載の方法。

５１．ＷＴＲＵがＲＣＣのコネクションセットアップメッセージを受信するステップをさらに含む実施形態１から９および１６から５０のいずれか１つに記載の方法。

５２．ＷＴＲＵがＲＣＣのコネクションセットアップ完了メッセージを送信するステップをさらに含む実施形態１から９および１６から５１のいずれか１つに記載の方法。

５３．ＷＴＲＵがＲＣＣのコネクション解放メッセージを受信し、アイドルモードに戻るステップをさらに含む実施形態１から９および１６から５２のいずれか１つに記載の方法。

５４．ＲＲＣのコネクション要求メッセージは、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答を目的とすることを示す原因コードを含む実施形態１から９および１６から５３のいずれか１つに記載の方法。

５５．ＲＣＣのコネクションセットアップ完了メッセージは、フォーマットされた問い合わせの応答の情報要素（ＩＥ）を含む実施形態１から９および１６から５４のいずれか１つに記載の方法。

５６．ＲＲＣコネクションは、問い合わせの応答のＩＥを転送した後に切断される実施形態１から９および１６から５５のいずれか１つに記載の方法。

５７．接続モードのＷＴＲＵが任意のＷＴＲＵのＵＬの送信機会にＭＢＭＳの問い合わせの応答を送信することができるように、問い合わせの応答の媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）が、アップリンク（ＵＬ）方向で定義される実施形態１から９および１６から５６のいずれか１つに記載の方法。

５８．ＷＴＲＵが、ＭＢＭＳのレポートに関する問い合わせの応答の非アクセス層（ＮＡＳ）の情報要素（ＩＥ）または無線リソース制御（ＲＲＣ）のＩＥを生成することによってＭＢＭＳサービス状態応答を準備するステップをさらに含む実施形態１から９および１６から５７のいずれか１つに記載の方法。

５９．ＷＴＲＵがＮＡＳのトラッキングエリア更新（ＴＡＵ）メッセージに当該ＩＥを付加するステップをさらに含む実施形態１から９および１６から５８のいずれか１つに記載の方法。

６０．ＷＴＲＵがＴＡＵメッセージを送信するステップをさらに含む実施形態１から９および１６から５９のいずれか１つに記載の方法。

６１．ＷＴＲＵがＲＣＣのコネクションセットアップメッセージを受信するステップをさらに含む実施形態１から９および１６から６０のいずれか１つに記載の方法。

６２．ＷＴＲＵがＲＣＣのコネクションセットアップ完了メッセージを送信するステップをさらに含む実施形態１から９および１６から６１のいずれか１つに記載の方法。

６３．ＷＴＲＵがＲＣＣのコネクション解放メッセージを受信し、アイドルモードに戻るステップをさらに含む実施形態１から９および１６から６２のいずれか１つに記載の方法。

６４．ＴＡＵメッセージは、コネクションの確立がＭＢＭＳのサービスの問い合わせの応答を目的とすることを示す原因コードを含む実施形態１から９および１６から６３のいずれか１つに記載の方法。

６５．ＲＣＣのコネクションセットアップ完了メッセージは、フォーマットされた問い合わせの応答の情報要素（ＩＥ）を含む実施形態１から９および１６から６４のいずれか１つに記載の方法。

６６．ＲＲＣコネクションは、問い合わせの応答のＩＥを転送した後に切断される実施形態１から９および１６から６５のいずれか１つに記載の方法。

６７．接続モードのＷＴＲＵが任意のＷＴＲＵのＵＬの送信機会にＭＢＭＳの問い合わせの応答を送信することができるように、問い合わせの応答の媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）が、アップリンク（ＵＬ）方向で定義される実施形態１から９および１６から６６のいずれか１つに記載の方法。

６８．実施形態１から６７のいずれか１つに記載の方法を実行するように構成された装置。

６９．送信機と、受信機と、実施形態１から９および１６から６７のいずれか１つに記載の方法を実行するように構成されたプロセッサとを含む無線送受信ユニット（ＷＴＲＵ）。

７０．送信機と、受信機と、実施形態１から６７のいずれか１つに記載の方法を実行するように構成されたプロセッサとを含むネットワーク。

７１．送信機と、受信機と、実施形態１から６７のいずれか１つに記載の方法を実行するように構成されたプロセッサとを含むシステム。

特徴および要素が特定の組み合わせで上で説明されているが、当業者は、各特徴または要素が、単独で、またはその他の特徴および要素との任意の組み合わせで使用され得ることを理解するであろう。加えて、本明細書に記載の方法は、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実装され得る。コンピュータ可読媒体の例は、（有線または無線接続を介して送信される）電子的な信号と、コンピュータ可読ストレージ媒体とを含む。コンピュータ可読ストレージ媒体の例は、読み出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび取り外し可能なディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびデジタルバーサタイルディスク（ＤＶＤ）などの光媒体を含むがこれらに限定されない。ソフトウェアに関連するプロセッサが、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために使用され得る。

Claims (3)

1. マルチメディアブロードキャストマルチキャストサービス（ＭＢＭＳ）のサービスの状態のフィードバックを提供する、無線送受信ユニット（ＷＴＲＵ）によって実施される方法であって、
   ＭＢＭＳ制御チャネルを介してＭＢＭＳサービス状態問い合わせメッセージを受信するステップと、
   ＭＢＭＳサービス識別子インデックス値を有するレポートを生成するステップであって、各ＭＢＭＳサービス識別子インデックス値は、前記ＷＴＲＵが受信しているかまたは受信することを意図しているＭＢＭＳサービスに対応するカウンティングまたは問い合わせリスト内のサービス識別子の位置を示す、生成するステップと、
   前記レポートを含むＭＢＭＳサービス状態応答メッセージを送信するステップと
   を含むことを特徴とする方法。
2. 前記ＭＢＭＳサービス状態問い合わせメッセージおよび前記ＭＢＭＳサービス状態応答メッセージは、無線リソースコントローラメッセージであることを特徴とする請求項１に記載の方法。
3. 前記ＭＢＭＳサービス問い合わせメッセージは、ＭＢＳＦＮＡｒｅａＣｏｎｆｉｇｕｒａｔｉｏｎメッセージとともに受信されることを特徴とする請求項１に記載の方法。

Images