(57)【特許請求の範囲】
【請求項１】
移動通信システムのための無線端末であって、
特定のＭＢＭＳサービスを受信している又は受信に興味を持つ複数の無線端末にカウンティング応答の送信を要求するカウンティング要求と、前記複数の無線端末が前記カウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定と、をネットワークから受信する受信部と、
前記カウンティング要求の受信に応じて、自無線端末が前記特定のＭＢＭＳサービスを受信している又は受信に興味を持つか否かを判断する制御部と、
自無線端末が前記特定のＭＢＭＳサービスを受信している又は受信に興味を持つことに応じて、前記共通リソースプールに含まれる無線リソースを用いて、前記カウンティング応答を前記ネットワークに送信する送信部と、を備え、
前記カウンティング要求は、複数のＭＢＭＳサービスのそれぞれのサービス識別子を含み、
前記共通リソース設定は、前記複数のＭＢＭＳサービスのそれぞれに対応する前記共通リソースプールからなる複数の共通リソースプールを示し、
前記制御部は、自無線端末が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子に対応する前記共通リソースプールを前記複数の共通リソースプールの中から選択し、
前記送信部は、前記選択した共通リソースプールに含まれる無線リソースを用いて前記カウンティング応答を前記ネットワークに送信する
無線端末。
【請求項２】
前記制御部は、前記共通リソースプールの中から一部の無線リソースをランダムに選択し、
前記送信部は、前記選択された一部の無線リソースを用いて、前記カウンティング応答を前記ネットワークに送信する
請求項１に記載の無線端末。
【請求項３】
前記制御部は、自無線端末で発生させた乱数又は自無線端末の固有識別子を取得し、
前記制御部は、前記乱数又は前記固有識別子に基づいて、前記カウンティング応答の送信が許可されるか否かを判断する
請求項１に記載の無線端末。
【請求項４】
前記受信部は、前記ネットワークから送信された所定値をさらに受信し、
前記制御部は、前記乱数又は前記固有識別子と、前記所定値とに基づいて、前記カウンティング応答の送信が許可されるか否かを判断する
請求項３に記載の無線端末。
【請求項５】
前記制御部は、自無線端末で発生させた乱数又は自無線端末の固有識別子を取得し、
前記制御部は、前記乱数又は前記固有識別子に基づいて、前記カウンティング応答の送信タイミングを決定する
請求項１に記載の無線端末。
【請求項６】
前記受信部は、前記ネットワークから送信された所定値をさらに受信し、
前記制御部は、前記乱数又は前記固有識別子と、前記所定値とに基づいて、前記カウンティング応答の送信タイミングを決定する
請求項５に記載の無線端末。
【請求項７】
前記送信部は、前記カウンティング応答として、前記複数の無線端末が前記カウンティング応答の送信に共通に用いる共通信号系列を前記ネットワークに送信する
請求項１に記載の無線端末。
【請求項８】
前記制御部は、自無線端末で発生させた乱数又は自無線端末の固有識別子を取得し、
前記送信部は、前記カウンティング応答として、前記乱数又は前記固有識別子を用いて選択された信号系列を前記ネットワークに送信する
請求項１に記載の無線端末。
【請求項９】
前記送信部は、前記無線端末が特定状態にある場合において、前記共通リソースプールの少なくとも一部を用いて前記カウンティング応答を前記ネットワークに送信し、
前記特定状態は、前記無線端末と前記ネットワークとの間で送受信されるシグナリングが抑制された状態である
請求項１に記載の無線端末。
【請求項１０】
前記送信部は、前記無線端末が前記特定状態から復旧するための要求メッセージを前記ネットワークに送信し、
前記要求メッセージは、前記無線端末がＭＢＭＳサービスを受信している又は受信に興味を持つことを示す情報を含む
請求項９に記載の無線端末。
【請求項１１】
移動通信システムのための基地局であって、
特定のＭＢＭＳサービスを受信している又は受信に興味を持つ複数の無線端末にカウンティング応答の送信を要求するカウンティング要求と、前記複数の無線端末が前記カウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定と、を送信する送信部と、
前記共通リソースプールに含まれる無線リソースを用いて前記複数の無線端末が送信する前記カウンティング応答を受信する受信部と、を備え、
前記カウンティング要求は、複数のＭＢＭＳサービスのそれぞれのサービス識別子を含み、
前記共通リソース設定は、前記複数のＭＢＭＳサービスのそれぞれに対応する前記共通リソースプールからなる複数の共通リソースプールを示し、
前記受信部は、前記複数の共通リソースプールのうち、前記複数の無線端末が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子に対応する前記共通リソースプールに含まれる無線リソースを用いて前記複数の無線端末が送信する前記カウンティング応答を受信する
基地局。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、移動通信システムのための無線端末及び基地局に関する。
【背景技術】
【０００２】
移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ  Ｇｅｎｅｒａｔｉｏｎ  Ｐａｒｔｎｅｒｓｈｉｐ  Ｐｒｏｊｅｃｔ）において、無線端末にマルチキャスト／ブロードキャストサービスを提供するＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ  Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ）が仕様化されている。ＭＢＭＳ用の無線伝送方式としては、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ  Ｂｒｏａｄｃａｓｔ  Ｓｉｎｇｌｅ  Ｆｒｅｑｕｅｎｃｙ  Ｎｅｔｗｏｒｋ）伝送及びＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）伝送の２つの方式がある。ＭＢＭＳは、同一の無線リソースを用いて複数の無線端末に同一サービスを提供するので、無線リソースの利用効率を高めることができる。
【発明の概要】
【０００３】
第１の特徴に係る無線端末は、特定のＭＢＭＳサービスを受信している又は受信に興味を持つ複数の無線端末にカウンティング応答の送信を要求するカウンティング要求と、前記複数の無線端末が前記カウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定と、をネットワークから受信する受信部と、前記カウンティング要求の受信に応じて、自無線端末が前記特定のＭＢＭＳサービスを受信している又は受信に興味を持つか否かを判断する制御部と、自無線端末が前記特定のＭＢＭＳサービスを受信している又は受信に興味を持つことに応じて、前記共通リソースプールに含まれる無線リソースを用いて、前記カウンティング応答を前記ネットワークに送信する送信部と、を備える。
【０００４】
第２の特徴に係る基地局は、特定のＭＢＭＳサービスを受信している又は受信に興味を持つ複数の無線端末にカウンティング応答の送信を要求するカウンティング要求と、前記複数の無線端末が前記カウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定と、を送信する送信部と、前記複数の無線端末が前記共通リソースプールを用いて送信する前記カウンティング応答を受信する受信部と、を備える。
【０００５】
第３の特徴に係る無線端末は、移動通信システムのための無線端末である。前記無線端末は、複数の無線端末が上りリンク信号の送信に共通に用いるべき共通リソースを示す共通リソース設定をネットワークから受信する受信部と、自無線端末の固有識別子を取得し、前記固有識別子に基づいて自無線端末が上りリンク信号の送信に用いる無線リソースを前記共通リソースの中から決定する制御部と、前記決定された無線リソースを用いて、上りリンク信号を前記ネットワークに送信する送信部と、を備える。
【図面の簡単な説明】
【０００６】
【図１】実施形態に係るＬＴＥシステムの構成を示す図である。
【図２】実施形態に係るＭＢＭＳのためのネットワーク構成を示す図である。
【図３】実施形態に係るＵＥ（無線端末）の構成を示す図である。
【図４】実施形態に係るｅＮＢ（基地局）の構成を示す図である。
【図５】実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。
【図６Ａ】実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図であって、論理チャネルとトランポートチャネルとの間のマッピングを示す図である。
【図６Ｂ】実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図であって、トランポートチャネルと物理チャネルとの間のマッピングを示す図である。
【図７】実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。
【図８】実施形態に係るＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態への遷移に係る動作を示す図である。
【図９】第１実施形態に係る動作例を示す図である。
【図１０】第１実施形態に係る共通リソースプールを示す図である。
【図１１】第２実施形態に係る動作例を示す図である。
【図１２】第２実施形態に係るカウンティング応答の送信可否判断を示す図である。
【図１３】第２実施形態に係るカウンティング応答の送信タイミングを示す図である。
【図１４】第３実施形態に係る動作例を示す図である。
【図１５】第３実施形態に係るサービス識別子（ＴＭＧＩ）と共通リソースプールとの対応関係を示す図である。
【発明を実施するための形態】
【０００７】
（移動通信システム）
実施形態に係る移動通信システムの構成について説明する。実施形態に係る移動通信システムは、３ＧＰＰで仕様が策定されているＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）システムである。図１は、実施形態に係るＬＴＥシステムの構成を示す図である。図２は、ＭＢＭＳのためのネットワーク構成を示す図である。
【０００８】
図１に示すように、ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ  Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ−ＵＭＴＳ  Ｔｅｒｒｅｓｔｒｉａｌ  Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ  Ｐａｃｋｅｔ  Ｃｏｒｅ）２０を備える。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。
【０００９】
ＵＥ１００は、移動型の通信装置であり、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。
【００１０】
Ｅ−ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ  Ｎｏｄｅ−Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理しており、自セルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。
【００１１】
ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。
【００１２】
ＭＢＭＳ向けのネットワークエンティティについて説明する。Ｅ−ＵＴＲＡＮ１０は、ＭＣＥ（Ｍｕｌｔｉ−Ｃｅｌｌ／Ｍｕｌｔｉｃａｓｔ  Ｃｏｏｒｄｉｎａｔｉｎｇ  Ｅｎｔｉｔｙ）１１を含む。ＭＣＥ１１は、Ｍ２インターフェイスを介してｅＮＢ２００と接続され、Ｍ３インターフェイスを介してＭＭＥ３００と接続される（図２参照）。ＭＣＥ１１は、ＭＢＳＦＮ無線リソース管理・割当等を行う。具体的には、ＭＣＥ１１は、ＭＢＳＦＮ伝送のスケジューリングを行う。これに対し、ＳＣ−ＰＴＭ伝送のスケジューリングはｅＮＢ２００により行われる。
【００１３】
ＥＰＣ２０は、ＭＢＭＳ  ＧＷ（ＭＢＭＳ  Ｇａｔｅｗａｙ）２１を含む。ＭＢＭＳ  ＧＷ２１は、Ｍ１インターフェイスを介してｅＮＢ２００と接続され、Ｓｍインターフェイスを介してＭＭＥ３００と接続され、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＢＭ−ＳＣ２２と接続される（図２参照）。ＭＢＭＳ  ＧＷ２１は、ｅＮＢ２００に対してＩＰマルチキャストのデータ伝送及びセッション制御等を行う。
【００１４】
ＥＰＣ２０は、ＢＭ−ＳＣ（Ｂｒｏａｄｃａｓｔ  Ｍｕｌｔｉｃａｓｔ  Ｓｅｒｖｉｃｅ  Ｃｅｎｔｅｒ）２２を含む。ＢＭ−ＳＣ２２は、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＭＢＭＳ  ＧＷ２１と接続され、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される（図２参照）。ＢＭ−ＳＣ２２は、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｇｒｏｕｐ  Ｉｄｅｎｔｉｔｙ）の管理・割当等を行う。
【００１５】
ＥＰＣ２０の外部のネットワーク（すなわち、インターネット）には、ＧＣＳ  ＡＳ（Ｇｒｏｕｐ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｓｅｒｖｉｃｅ  Ａｐｐｌｉｃａｔｉｏｎ  Ｓｅｒｖｅｒ）３１が設けられる。ＧＣＳ  ＡＳ３１は、グループ通信用のアプリケーションサーバである。ＧＣＳ  ＡＳ３１は、ＭＢ２−Ｕ及びＭＢ２−Ｃインターフェイスを介してＢＭ−ＳＣ２２と接続され、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される。ＧＣＳ  ＡＳ３１は、グループ通信におけるグループの管理及びデータ配信等を行う。
【００１６】
図３は、実施形態に係るＵＥ１００（無線端末）の構成を示す図である。図３に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。
【００１７】
受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部１３０に出力する。
【００１８】
送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００１９】
制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理を実行する。
【００２０】
図４は、実施形態に係るｅＮＢ２００（基地局）の構成を示す図である。図４に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。
【００２１】
送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換してアンテナから送信する。
【００２２】
受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換して制御部２３０に出力する。
【００２３】
制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各種の処理を実行する。
【００２４】
バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。
【００２５】
図５は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。図５に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されている。第１レイヤは物理（ＰＨＹ）レイヤを含む。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ  Ｄａｔａ  Ｃｏｎｖｅｒｇｅｎｃｅ  Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ  Ｒｅｓｏｕｒｃｅ  Ｃｏｎｔｒｏｌ）レイヤを含む。
【００２６】
物理レイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理レイヤとｅＮＢ２００の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。
【００２７】
ＭＡＣレイヤは、データの優先制御、ＨＡＲＱ（Ｈｙｂｒｉｄ  ＡＲＱ）による再送処理等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣレイヤは、スケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））、及びＵＥ１００への割当リソースブロックを決定する。
【００２８】
ＲＬＣレイヤは、ＭＡＣレイヤ及び物理レイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。
【００２９】
ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。
【００３０】
ＲＲＣレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッドモードであり、そうでない場合、ＵＥ１００はＲＲＣアイドルモードである。
【００３１】
ＲＲＣレイヤの上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）レイヤは、セッション管理及びモビリティ管理等を行う。
【００３２】
図６は、ＬＴＥシステムの下りリンクのチャネルの構成を示す図である。図６Ａは、論理チャネル（Ｄｏｗｎｌｉｎｋ  Ｌｏｇｉｃａｌ  Ｃｈａｎｎｅｌ）とトランポートチャネル（Ｄｏｗｎｌｉｎｋ  Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）との間のマッピングを示す。
【００３３】
図６Ａに示すように、ＰＣＣＨ（Ｐａｇｉｎｇ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ページング情報、及びシステム情報変更を通知するための論理チャネルである。ＰＣＣＨは、トランスポートチャネルであるＰＣＨ（Ｐａｇｉｎｇ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００３４】
ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、システム情報のための論理チャネルである。ＢＣＣＨは、トランスポートチャネルであるＢＣＨ（Ｂｒｏａｄｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）及びＤＬ−ＳＣＨ（Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００３５】
ＣＣＣＨ（Ｃｏｍｍｏｎ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＵＥ１００とｅＮＢ２００との間の送信制御情報のための論理チャネルである。ＣＣＣＨは、ＵＥ１００がネットワークとの間でＲＲＣ接続を有していない場合に用いられる。ＣＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３６】
ＤＣＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＵＥ１００とネットワークとの間の個別制御情報を送信するための論理チャネルである。ＤＣＣＨは、ＵＥ１００がＲＲＣ接続を有する場合に用いられる。ＤＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３７】
ＤＴＣＨ（Ｄｅｄｉｃａｔｅｄ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、データ送信のための個別論理チャネルである。ＤＴＣＨは、ＤＬ−ＳＣＨにマッピングされる。
【００３８】
ＳＣ−ＭＴＣＨ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、ＳＣ−ＰＴＭ伝送を用いてネットワークからＵＥ１００にデータを送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ  ｄｏｗｎｌｉｎｋ  ｃｈａｎｎｅｌ）である。
【００３９】
ＳＣ−ＭＣＣＨ（Ｓｉｎｇｌｅ  Ｃｅｌｌ  Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、１又は複数のＳＣ−ＭＴＣＨのためのＭＢＭＳ制御情報をネットワークからＵＥ１００に送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ  ｄｏｗｎｌｉｎｋ  ｃｈａｎｎｅｌ）である。ＳＣ−ＭＣＣＨは、ＳＣ−ＰＴＭを用いてＭＢＭＳを受信する又は受信に興味を持つＵＥ１００に用いられる。また、ＳＣ−ＭＣＣＨは、１つのセルに１つのみ存在する。「ＭＢＭＳの受信に興味を持つ」とは、例えば、ＭＢＭＳサービスを未だ受信していないものの、上位レイヤ（例えばアプリケーションレイヤ）からＭＢＭＳサービスを受信するよう設定された状態を意味する。
【００４０】
ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｏｎｔｒｏｌ  Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＣＣＨは、ネットワークからＵＥ１００へのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、トランスポートチャネルであるＭＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００４１】
ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ  Ｔｒａｆｆｉｃ  Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＴＣＨは、ＭＣＨにマッピングされる。
【００４２】
図６Ｂは、トランポートチャネル（Ｄｏｗｎｌｉｎｋ  Ｔｒａｎｓｐｏｒｔ  Ｃｈａｎｎｅｌ）と物理チャネル（Ｄｏｗｎｌｉｎｋ  Ｐｈｙｓｉｃａｌ  Ｃｈａｎｎｅｌ）との間のマッピングを示す。
【００４３】
図６Ｂに示すように、ＢＣＨは、ＰＢＣＨ（Ｐｈｙｓｉｃａｌ  Ｂｒｏａｄｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。
【００４４】
ＭＣＨは、ＰＭＣＨ（Ｐｈｙｓｉｃａｌ  Ｍｕｌｔｉｃａｓｔ  Ｃｈａｎｎｅｌ）にマッピングされる。ＭＣＨは、複数のセルによるＭＢＳＦＮ伝送をサポートする。
【００４５】
ＰＣＨ及びＤＬ−ＳＣＨは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ  Ｄｏｗｎｌｉｎｋ  Ｓｈａｒｅｄ  Ｃｈａｎｎｅｌ）にマッピングされる。ＤＬ−ＳＣＨは、ＨＡＲＱ、リンクアダプテーション、及び動的リソース割当をサポートする。
【００４６】
ＰＤＣＣＨは、ＰＤＳＣＨ（ＤＬ−ＳＣＨ、ＰＣＨ）のリソース割り当て情報及びＤＬ−ＳＣＨに関するＨＡＲＱ情報等を運搬する。また、ＰＤＣＣＨは、上りリンクのスケジューリンググラントを運ぶ。
【００４７】
図７は、ＬＴＥシステムの無線フレームの構成を示す図である。ＬＴＥシステムにおいて、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ  Ｃａｒｒｉｅｒ  Ｆｒｅｑｕｅｎｃｙ  Ｄｉｖｉｓｉｏｎ  Ｍｕｌｔｉｐｌｅ  Ａｃｃｅｓｓ）がそれぞれ適用される。
【００４８】
図７に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。
【００４９】
下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するためのＰＤＣＣＨとして用いられる領域である。各サブフレームの残りの部分は、主に下りリンクデータを伝送するためのＰＤＳＣＨとして使用できる領域である。また、下りリンクにおいて、ＭＢＳＦＮ伝送向けのサブフレームであるＭＢＳＦＮサブフレームが設定され得る。
【００５０】
上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するためのＰＵＣＣＨとして用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するためのＰＵＳＣＨとして使用できる領域である。
【００５１】
（特定状態）
特定状態について説明する。特定状態は、ＵＥ１００用のＳ１接続が維持されつつＵＥ１００用のシグナリングが抑制される状態である。Ｓ１接続は、Ｓ１ベアラと称されてもよい。Ｓ１接続は、Ｓ１インターフェイス上でｅＮＢ２００とＥＰＣ２０との間に確立される接続である。Ｓ１インターフェイスは、ユーザプレーン用のＳ１−Ｕインターフェイスと制御プレーン用のＳ１−ＭＭＥインターフェイスとを含む。Ｓ１接続は、Ｓ１−Ｕインターフェイス上でｅＮＢ２００とＳ−ＧＷ３００Ｕとの間に確立されるＳ１−Ｕ接続と、Ｓ１−Ｃインターフェイス上でｅＮＢ２００とＭＭＥ３００Ｃとの間に確立されるＳ１−ＭＭＥ接続と、を含んでもよい。
【００５２】
特定状態は、ＲＲＣコネクティッドモードの一状態又はＲＲＣアイドルモードの一状態であってもよい。或いは、特定状態は、ＲＲＣアイドルモード及びＲＲＣアイドルモードとは異なるＲＲＣ状態であってもよい。特定状態によれば、一般的なＲＲＣコネクティッドモードに比べてシグナリングが削減される。また、特定状態によれば、一般的なＲＲＣアイドルモードに比べてＵＥ１００が迅速にデータ通信を開始することができる。以下において、特定状態を「Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態（Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ  ｓｕｂｓｔａｔｅ）」と称する。
【００５３】
図８は、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態（特定状態）への遷移に係る動作を示す図である。図８の初期状態において、ＵＥ１００はＲＲＣコネクティッドモードであり、ＵＥ１００とｅＮＢ２００との間にＲＲＣ接続（ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。また、ｅＮＢ２００とＭＭＥ３００Ｃとの間にＳ１−ＭＭＥ接続（Ｓ１−ＭＭＥ  Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。ｅＮＢ２００とＳ−ＧＷ３００Ｕとの間にＳ１−Ｕ接続（Ｓ１−Ｕ  Ｃｏｎｎｅｃｔｉｏｎ）が確立されている。ＵＥ１００は、ｅＮＢ２００とのデータ通信を行う。
【００５４】
図８に示すように、ステップＳ１において、ｅＮＢ２００は、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態への遷移を指示する遷移指示（Ｒｅｑｕｅｓｔ  ｔｏ  Ｌｉｇｈｔ  Ｃｏｎｎ．）をＵＥ１００に送信する。
【００５５】
ステップＳ２において、ＵＥ１００は、遷移指示の受信に応じて、肯定応答（Ａｃｋ）メッセージをｅＮＢ２００に送信する。但し、ステップＳ２は必須ではなく、省略してもよい。
【００５６】
ステップＳ３において、ＵＥ１００及びｅＮＢ２００は、ＲＲＣ接続を維持又は解放する。
【００５７】
ステップＳ４において、ｅＮＢ２００及びＭＭＥ３００Ｃは、Ｓ１−ＭＭＥ接続を維持する。ステップＳ５において、ｅＮＢ２００及びＳ−ＧＷ３００Ｕは、Ｓ１−Ｕ接続を維持する。ステップＳ６において、ＵＥ１００は、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態に遷移し、ｅＮＢ２００とのデータ通信を中断する。
【００５８】
ｅＮＢ２００は、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態に遷移したＵＥ１００のコンテキスト情報（ＵＥコンテキスト）を破棄せずに維持する。ＵＥコンテキストは、ＵＥ１００に対する各種の設定及び能力等に関する情報を含む。各種の設定は、ＡＳ（Ａｃｃｅｓｓ  Ｓｔｒａｔｕｍ）の設定を含む。
【００５９】
Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００は、維持されているＳ１接続及びＵＥコンテキストを活用して、少ないシグナリングでｅＮＢ２００とのデータ通信を再開することができる。
【００６０】
第１のｅＮＢ２００のセルにおいてＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態に遷移したＵＥ１００は、第１のｅＮＢ２００のセルから第２のｅＮＢ２００のセルに移動してもよい。第２のｅＮＢ２００のセルにおいてＵＥ１００がデータ通信を再開する場合、第２のｅＮＢ２００は、ＵＥ１００のＵＥコンテキストを第１のｅＮＢ２００からＸ２インターフェイス上で取得し、取得したＵＥコンテキストをＵＥ１００とのデータ通信に利用してもよい。
【００６１】
Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００には、ＲＡＮベースページングが適用されてもよい。ＲＡＮベースページングは、Ｅ−ＵＴＲＡＮ１０（ｅＮＢ２００）によりページングが制御される所定ページングエリア単位でページングを行う。所定ページングエリアは、トラッキングエリアよりも狭いエリアである。所定ページングエリアを導入することにより、１のＵＥ１００に対してページングを行うセルの数を削減することができるため、シグナリングを削減することができる。以下において、このような所定ページングエリアを「ＲＡＮページングエリア」と称する。
【００６２】
一例として、ＲＡＮページングエリアは、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００のＳ１接続を維持する特定のｅＮＢ２００のセルと当該特定のｅＮＢ２００の周辺のｅＮＢ２００のセルとにより構成される。周辺のｅＮＢ２００は、特定のｅＮＢ２００とのＸ２インターフェイスを有するｅＮＢ２００であってもよい。特定のｅＮＢ２００は、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００宛てのデータ又はＮＡＳシグナリングをＭＭＥ／Ｓ−ＧＷ３００から受信すると、ＲＡＮベースページングを行うと判断し、周辺のｅＮＢ２００と共にＵＥ１００のページングを行う。当該ページングは、ＲＲＣページングメッセージを送信することにより行われてもよいし、ＵＥ１００宛てのデータをページングメッセージとして送信することにより行われてもよい。
【００６３】
（第１実施形態）
第１実施形態について説明する。第１実施形態において、ＲＲＣアイドルモードのＵＥ１００がネットワークからＭＢＭＳサービスを受信するシナリオを想定する。或いは、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００がネットワークからＭＢＭＳサービスを受信するシナリオを想定してもよい。
【００６４】
一般的なＬＴＥシステムにおいて、ネットワークは、ＭＢＭＳカウンティングプロシージャを用いて、特定のＭＢＭＳサービスを受信している又は受信に興味を持つＲＲＣコネクティッドモードのＵＥ１００の数をカウントすることができる。具体的には、ｅＮＢ２００は、ＲＲＣコネクティッドモードのＵＥ１００に対してカウンティング要求を送信する。カウンティング要求は、カウント対象のＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）のリストを含む。カウンティング要求を受信したＵＥ１００は、カウント対象のＭＢＭＳサービスを受信している又は受信に興味を持つか否かを判断する。ＵＥ１００は、ＵＥ１００が当該ＭＢＭＳサービスを受信している又は受信に興味を持つことに応じて、カウンティング応答をｅＮＢ２００に送信する。カウンティング応答は、カウント対象のＭＢＭＳサービスのうちＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスを示す情報を含む。ｅＮＢ２００は、カウント対象のＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００の数をカウントし、カウント結果をＭＣＥ１１に報告する。
【００６５】
一般的なカウンティング応答は、通常の上りリンク送信プロシージャを用いてＵＥ１００からｅＮＢ２００に送信される。具体的には、ＵＥ１００は、スケジューリング要求（ＳＲ）及び／又はバッファステータス報告（ＢＳＲ）をｅＮＢ２００に送信する。ｅＮＢ２００は、ＳＲ及び／又はＢＳＲに基づいて、ＵＥ１００に上りリンク無線リソース（すなわち、ＰＵＳＣＨリソース）をスケジューリングし、スケジューリング情報をＵＥ１００に送信する。ＵＥ１００は、スケジューリングされた上りリンク無線リソースを用いてカウンティング応答をｅＮＢ２００に送信する。
【００６６】
このような一般的なＭＢＭＳカウンティングプロシージャは、ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００には適用することができない。よって、ネットワークは、ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００におけるＭＢＭＳサービスの受信状況を把握することができない。また、一般的なＭＢＭＳカウンティングプロシージャにおいて、カウンティング応答の送受信は、複数のＵＥ個別シグナリング（専用シグナリング）を伴うため、シグナリングの増大を引き起こす懸念がある。
【００６７】
以下において、このような問題を解決することができる新規なＭＢＭＳカウンティングプロシージャについて説明する。
【００６８】
図９は、第１実施形態に係る動作例を示す図である。図９の初期状態において、ＵＥ１００はＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態である。図９においてＵＥ１００を１つのみ示しているが、実際にはｅＮＢ２００のカバレッジエリア内に複数のＵＥ１００が在圏していてもよい。
【００６９】
図９に示すように、ステップＳ１１において、ｅＮＢ２００（送信部２１０）は、カウント対象のＭＢＭＳサービス（特定のＭＢＭＳサービス）を受信している又は受信に興味を持つ複数のＵＥ１００にカウンティング応答の送信を要求するカウンティング要求を送信する。カウンティング要求は、ブロードキャスト又はマルチキャストで送信される。例えば、ｅＮＢ２００（送信部２１０）は、システム情報ブロック（ＳＩＢ）、ＳＣ−ＭＣＣＨ、又はＭＣＣＨを用いてカウンティング要求を送信する。カウンティング要求は、カウント対象のＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）のリストを含む。カウンティング要求は、ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００を対象とすることを示す情報を含んでもよい。
【００７０】
ステップＳ１２において、ｅＮＢ２００（送信部２１０）は、複数のＵＥ１００がカウンティング応答の送信に共通に用いるべき共通リソースプールを示す共通リソース設定を送信する。共通リソース設定は、ブロードキャスト又はマルチキャストで送信される。例えば、ｅＮＢ２００（送信部２１０）は、ＳＩＢ、ＳＣ−ＭＣＣＨ、又はＭＣＣＨを用いて共通リソース設定を送信する。共通リソース設定は、共通リソースプールを示す時間リソースパラメータ及び周波数リソースパラメータを含む。共通リソース設定は、カウンティング応答の送信電力を制御するための電力制御パラメータをさらに含んでもよい。時間リソースパラメータは、システムフレーム番号（ＳＦＮ）を示す情報、サブフレームを示す情報（ビットマップ）等を含んでもよい。周波数リソースパラメータは、リソースブロックの始点又は終点を示す情報、連続するリソースブロックの範囲（リソースブロック数）を示す情報等を含んでもよい。共通リソース設定は、共通リソースプールが提供される期間（又は、開始時間／終了時間）を含んでもよい。当該期間は、秒として定義されてもよく、フレーム番号（ＳＦＮ、サブフレーム等）で定義されてもよい。当該期間は、予め決められた値（例えば１０サブフレーム期間等）であってもよい。当該期間が存在する場合、ＵＥ１００は、当該期間内においてカウンティング応答を送信する。言い換えると、ＵＥ１００は、当該期間の経過後はカウンティング応答を送信しない。
【００７１】
ステップＳ１２は、ステップＳ１１の前に行われてもよいし、ステップＳ１３の後に行われてもよい。或いは、ステップＳ１２は、ステップＳ１１と同時に行われてもよい。この場合、カウンティング要求及び共通リソース設定は、１つのメッセージに含まれてもよい。
【００７２】
ＵＥ１００（受信部１１０）は、カウンティング要求及び共通リソース設定を受信する。
【００７３】
ステップＳ１３において、ＵＥ１００（制御部１３０）は、カウンティング要求の受信に応じて、カウント対象のＭＢＭＳサービスをＵＥ１００が受信している又は受信に興味を持つか否かを判断する。ここでは、カウント対象のＭＢＭＳサービスをＵＥ１００が受信している又は受信に興味を持つと仮定して説明を進める。
【００７４】
ステップＳ１４において、ＵＥ１００（制御部１３０）は、カウント対象のＭＢＭＳサービスを受信している又は受信に興味を持つことに応じて、共通リソースプールに含まれる一部の無線リソース（時間・周波数リソース）をランダムに選択する。
【００７５】
ステップＳ１５において、ＵＥ１００（送信部１２０）は、選択された一部の無線リソース（すなわち、ＰＵＳＣＨリソース）を用いて、カウンティング応答をｅＮＢ２００に送信する。カウンティング応答は、カウント対象のＭＢＭＳサービスのうちＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスを示す情報を含む。ここで、ＵＥ１００は、ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態を維持しつつ、カウンティング応答をｅＮＢ２００に送信可能である。
【００７６】
ｅＮＢ２００（受信部２２０）は、共通リソースプールに含まれる無線リソースを用いて複数のＵＥ１００が送信するカウンティング応答を受信する。複数のＵＥ１００間で無線リソースの衝突が発生した場合、ｅＮＢ２００（受信部２２０）は、衝突した無線リソースを用いて送信されたカウンティング応答の復号に失敗する。但し、ｅＮＢ２００は、カウンティング応答の再送を要求しないことに留意すべきである。これに対し、無線リソースの衝突が発生しない場合、ｅＮＢ２００（受信部２２０）は、衝突が発生した無線リソースを用いて送信されたカウンティング応答の復号に成功する。
【００７７】
ｅＮＢ２００（制御部２３０）は、カウンティング応答に基づいて、カウント対象のＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００の数をカウントし、カウント結果をＭＣＥ１１に報告する。ＭＣＥ１１（又はｅＮＢ２００）は、カウント結果に基づいて、ＭＢＭＳサービス（ＴＭＧＩ）ごとに、ユニキャスト伝送、ＭＢＳＦＮ伝送、及びＳＣ−ＰＴＭ伝送のうち何れを適用するか判断してもよい。一例として、ＭＣＥ１１（又はｅＮＢ２００）は、特定のＭＢＭＳサービス（ＴＭＧＩ）を受信している又は受信に興味を持つＵＥ１００の数が判定閾値を上回る場合、ＭＢＳＦＮ伝送又はＳＣ−ＰＴＭ伝送を用いて当該特定のＭＢＭＳサービスを提供すると判断する。ＭＣＥ１１（又はｅＮＢ２００）は、特定のＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００があるセルに偏っていれば、当該セルにおいて特定のＭＢＭＳサービスをＳＣ−ＰＴＭ伝送で送信すると判断してもよい。特定のＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００が非常に多くのセルに点在していれば、ＭＣＥ１１（又はｅＮＢ２００）は、これらのセルを含む１又は複数のＭＢＳＦＮエリアにおいて特定のＭＢＭＳサービスをＳＣ−ＰＴＭ伝送で送信すると判断してもよい。これらの状態の中間の状態、例えば、特定のＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００が複数のセル等にまたがって存在する場合、ＭＣＥ１１（又はｅＮＢ２００）は、当該複数のセルが１つのｅＮＢに収容されていればＳＣ−ＰＴＭを選択し、当該複数のセルが複数ｅＮＢにまたがっていればＭＢＳＦＮを選択してもよい。
【００７８】
第１実施形態によれば、ネットワークは、ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥ１００におけるＭＢＭＳサービスの受信状況を大まかに把握することができる。第１実施形態によれば、一般的なＭＢＭＳカウンティングプロシージャに比べて、カウンティング応答の送受信に伴うシグナリングを削減することができる。
【００７９】
図１０は、第１実施形態に係る共通リソースプールを示す図である。図１０において、時間方向の１つの区画は、１つの無線フレーム（又は１つのサブフレーム）を示す。
【００８０】
図１０に示すように、共通リソースプール（Ａ  ｓｅｔ  ｏｆ  ｒｅｓｏｕｒｃｅｓ）は、ｅＮＢ２００の上りリンク無線リソースの一部である。一例として、共通リソースプールは、複数のリソースブロック（ＰＲＢ：Ｐｈｙｓｉｃａｌ  Ｒｅｓｏｕｒｃｅ  Ｂｌｏｃｋ）からなる。ＵＥ＃１乃至＃６は、ｅＮＢ２００から受信するカウンティング要求及び共通リソース設定に基づいて、共通リソースプールに含まれるリソースブロックを用いてカウンティング応答をｅＮＢ２００に送信する。リソースブロックは、ランダムに選択される。
【００８１】
図１０の例において、ＵＥ＃１がリソースブロックＡを選択し、ＵＥ＃２がリソースブロックＢを選択し、ＵＥ＃３がリソースブロックＣを選択し、ＵＥ＃４乃至＃６がリソースブロックＤを選択している。すなわち、ＵＥ＃４乃至＃６間でリソースブロックの衝突が発生している。ｅＮＢ２００は、衝突が発生したリソースブロックＤを用いて送信されたカウンティング応答の復号に失敗する。これに対し、リソースブロックＡ、Ｂ、Ｃについては衝突が発生していないため、ｅＮＢ２００は、ＵＥ＃１乃至＃３のそれぞれのカウンティング応答の復号に成功する。
【００８２】
カウンティング応答の送信に用いるリソースブロックの数は、１つである場合に限らず、２以上の数であってもよい。カウンティング応答の送信に用いるリソースブロックの数は、共通リソース設定のパラメータの１つとしてｅＮＢ２００が設定してもよい。
【００８３】
ｅＮＢ２００又はＭＣＥ１１は、共通リソースプールのリソース量（すなわち、共通リソースプールのリソースブロック数）を決定してもよい。ＭＣＥ１１が共通リソースプールのリソース量を決定する場合、ＭＣＥ１１は、決定した共通リソースプールをｅＮＢ２００に通知する。ｅＮＢ２００は、決定された共通リソースプールを示す共通リソース設定を送信する。
【００８４】
ｅＮＢ２００又はＭＣＥ１１は、ＭＢＳＦＮ又はＳＣ−ＰＴＭを用いるか否かを判定するための判定閾値に比例して共通リソースプールのリソース量を決定してもよい。一例として、あるＭＢＭＳサービスに興味のあるＵＥの数が多数になった場合のみ、当該ＭＢＭＳサービスのＳＣ−ＰＴＭ伝送を行うという前提下では、共通リソースプールのリソース量を多くする。これにより、共通リソースプール内での衝突の回避に寄与することができる。
【００８５】
ｅＮＢ２００又はＭＣＥ１１は、ＲＲＣアイドルモードのＵＥの数及び／又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥの数が既知である場合には、これらのＵＥの数に比例して共通リソースプールのリソース量を決定してもよい。一例として、ＲＲＣアイドルモードのＵＥの数及び／又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態のＵＥの数が多い場合に、共通リソースプールのリソース量を多くする。
【００８６】
（第２実施形態）
第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態は、第１実施形態に係る動作を前提として、共通リソースプール内で衝突が発生する可能性を低下させることを可能とする実施形態である。
【００８７】
一例として、ＵＥ１００（制御部１３０）は、自身が発生させた乱数又は自身の固有識別子を取得する。固有識別子は、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）であってもよい。固有識別子は、Ｓ−ＴＭＳＩ（ＳＡＥ−Ｔｅｍｐｏｒａｒｙ  Ｍｏｂｉｌｅ  Ｓｕｂｓｃｒｉｂｅｒ  Ｉｄｅｎｔｉｔｙ）であってもよいし、電話番号であってもよい。固有識別子は、ｅＮＢ２００がＵＥ１００に割り当てた識別子であってもよい。このような識別子は、復旧用識別子（Ｒｅｓｕｍｅ  ＩＤ）であってもよいし、Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｉｏｎに遷移する時にｅＮＢから与えられた識別子（例えばセルＩＤ＋Ｃ−ＲＮＴＩ等）であってもよい。ＵＥ１００（制御部１３０）は、乱数又は固有識別子に基づいて、カウンティング応答の送信が許可されるか否かを判断する。
【００８８】
他の例として、ＵＥ１００（制御部１３０）は、乱数又は固有識別子に基づいて、カウンティング応答の送信タイミングを決定する。送信タイミングは、無線フレームを識別するシステムフレーム番号（ＳＦＮ）により定義されてもよい。送信タイミングは、サブフレームフレームを識別するサブフレーム番号により定義されてもよい。
【００８９】
ＵＥ１００（受信部１１０）は、ネットワーク（ｅＮＢ２００）から送信された所定値を受信してもよい。所定値は、乱数又は固有識別子が所定の条件を満たしたか否かを判定するための閾値又は変数であってもよい。所定値は、専用シグナリング、マルチキャストシグナリング（ＭＣＣＨ／ＳＣ−ＭＣＣＨ）、又はブロードキャストシグナリング（ＳＩＢ）によりｅＮＢ２００から送信されてもよい。ＵＥ１００（制御部１３０）は、乱数又は固有識別子と、所定値とに基づいて、カウンティング応答の送信が許可されるか否かを判断してもよい。ＵＥ１００（制御部１３０）は、乱数又は固有識別子と、所定値とに基づいて、カウンティング応答の送信タイミングを判断してもよい。
【００９０】
図１１は、第２実施形態に係る動作例を示す図である。ここでは、第１実施形態との相違点を主として説明し、重複する説明を省略する。図１１において、ステップＳ１３、Ｓ２１、Ｓ２２、Ｓ１４はこの順に行われなくてもよく、ステップＳ１３、Ｓ２１、Ｓ２２、Ｓ１４の順番を変更してもよい。ステップＳ２１及びステップＳ２２のうち一方のみを行ってもよい。
【００９１】
図１１に示すように、ステップＳ１１乃至Ｓ１３は第１実施形態と同様である。
【００９２】
ステップＳ２１において、ＵＥ１００（制御部１３０）は、自身のカウンティング応答の送信が許可されているか否かを判断する。
【００９３】
一例として、ＵＥ１００（制御部１３０）は、乱数（０〜１の範囲）を発生させ、ｅＮＢ２００から通知された閾値（０〜１の範囲）と乱数とを比較する。ＵＥ１００（制御部１３０）は、乱数が閾値条件を満たした場合に、カウンティング応答の送信が許可されていると判断し、カウンティング応答の送信機能を有効化する。「乱数が閾値条件を満たす」とは、乱数が閾値条件を超えたことであってもよいし、乱数が閾値条件を下回ったことであってもよい。ＵＥ１００（制御部１３０）は、乱数が閾値条件を満たさない場合に、カウンティング応答の送信が許可されていないと判断し、カウンティング応答の送信機能を無効化する。
【００９４】
他の例として、ＵＥ１００（制御部１３０）は、自身のＩＭＳＩを取得し、ｅＮＢ２００から通知された変数（”Ｎ”、”Ｔ”）により定義される条件をＩＭＳＩが満たすか否かを判断する。このような条件として、「（ＩＭＳＩ）  ｍｏｄ  （Ｎ）  ＝  （Ｔ）」という条件式を用いてもよい。当該条件式において、ＩＭＳＩそのものを用いることに代えて、ＩＭＳＩに基づく値（例えば、ＩＭＳＩ  ｍｏｄ  １０２４）を用いてもよい。当該条件式において、等式を用いることに代えて、不等式（＞、＜、≦、又は≧）を用いてもよい。ＵＥ１００（制御部１３０）は、ＩＭＳＩが条件を満たした場合に、カウンティング応答の送信が許可されていると判断し、カウンティング応答の送信機能を有効化する。ＵＥ１００（制御部１３０）は、ＩＭＳＩが条件を満たさない場合に、カウンティング応答の送信が許可されていないと判断し、カウンティング応答の送信機能を無効化する。
【００９５】
図１２は、カウンティング応答の送信可否判断を示す図である。ＵＥ＃１乃至＃６のそれぞれは、自身のカウンティング応答の送信が許可されているか否かを判断する。図１２の例において、ＵＥ＃１、＃３、及び＃４は条件を満たすが、ＵＥ＃２、＃５、及び＃６は条件を満たさない。この場合、ＵＥ＃１、＃３、及び＃４は、共通リソースプール内のリソースブロックを用いてカウンティング応答を送信する。ＵＥ＃２、＃５、及び＃６は、カウンティング応答の送信が禁止される。
【００９６】
ステップＳ２２において、ＵＥ１００（制御部１３０）は、自身のカウンティング応答の送信タイミングを決定する。ステップＳ２２は、ステップＳ２１でカウンティング応答の送信が許可された場合に限り行われてもよい。
【００９７】
一例として、ＵＥ１００（制御部１３０）は、自身のＩＭＳＩを取得し、ｅＮＢ２００から通知された変数（”Ｎ”）及びＩＭＳＩにより定義される条件を満たすＳＦＮを決定する。このような条件として、「（ＩＭＳＩ）  ｍｏｄ  （Ｎ）  ＝  （ＳＦＮ）  ｍｏｄ  （Ｎ）」という条件式を用いてもよい。当該条件式において、ＩＭＳＩそのものを用いることに代えて、ＩＭＳＩに基づく値（例えば、ＩＭＳＩ  ｍｏｄ  １０２４）を用いてもよい。ＵＥ１００（制御部１３０）は、条件を満たしたＳＦＮにおいてカウンティング応答を送信することを決定する。ＵＥ１００（制御部１３０）は、条件を満たさないＳＦＮにおいてカウンティング応答を送信しないことを決定する。他の例として、ＩＭＳＩに代えて乱数を用いてもよい。
【００９８】
図１３は、カウンティング応答の送信タイミングを示す図である。ＵＥ＃１乃至＃６のそれぞれは、ＵＥ＃１乃至＃６のそれぞれのカウンティング応答の送信タイミングをＩＭＳＩ（又は乱数）に基づいて決定する。図１３の例において、ＵＥ＃１及び＃２はＳＦＮ＃１をカウンティング応答の送信タイミングとして決定する。ＵＥ＃３及び＃４はＳＦＮ＃２をカウンティング応答の送信タイミングとして決定する。ＵＥ＃５及び＃６はＳＦＮ＃３をカウンティング応答の送信タイミングとして決定している。このように、複数のＵＥのカウンティング応答の送信タイミングを時間方向に分散させることができる。
【００９９】
ステップＳ２１及びＳ２２を併用してもよい。この場合、ＵＥ１００（制御部１３０）は、ステップＳ２２で決定した送信タイミング（ＳＦＮ）ごとに、ステップＳ２１の送信可否判断を行ってもよい。一例として、ＵＥ１００（制御部１３０）は、あるＳＦＮにおいてカウンティング応答を送信できなかった場合であって、カウンティング対象のＭＢＭＳサービスについてなお興味を有している場合に、次の送信機会（次の送信タイミング）でカウンティング応答の送信を再試行してもよい。但し、一旦カウンティング応答を送信した後は、そのような再試行を行ってはならない。
【０１００】
ステップＳ１４乃至Ｓ１５は第１実施形態と同様である。
【０１０１】
（第３実施形態）
第３実施形態について、第１及び第２実施形態との相違点を主として説明する。第３実施形態は、第１実施形態に係る動作を前提として、複数の共通リソースプールのそれぞれに特定のＭＢＭＳサービスを対応付ける実施形態である。
【０１０２】
第３実施形態において、カウンティング要求は、複数のＭＢＭＳサービスのそれぞれのサービス識別子（ＴＭＧＩ）を含む。共通リソース設定は、複数のＭＢＭＳサービスのそれぞれに対応する共通リソースプールからなる複数の共通リソースプールを示す。ＵＥ１００（制御部１３０）は、自身が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子に対応する共通リソースプールを複数の共通リソースプールの中から選択する。ＵＥ１００（送信部１２０）は、選択した共通リソースプールに含まれる無線リソースを用いてカウンティング応答をネットワーク（ｅＮＢ２００）に送信する。
【０１０３】
ＭＢＭＳサービスと共通リソースプールとを対応付けることより、共通リソースプール内で衝突が発生する可能性を低下させることができる。このような対応関係を導入することにより、カウンティング応答の情報量を削減することができる。一例として、カウンティング応答は、１ビットのフラグにより構成してもよい。ｅＮＢ２００は、共通リソースプールごとにカウンティング応答をカウントすることにより、各ＭＢＭＳサービスを受信している又は受信に興味を持つＵＥの数を把握する。
【０１０４】
一例として、ＵＥ１００（送信部１２０）は、カウンティング応答として、複数のＵＥがカウンティング応答の送信に共通に用いる共通信号系列を送信する。共通信号系列は、ＵＥ１００に事前設定されていてもよい。共通信号系列は、ｅＮＢ２００がＵＥ１００に設定してもよい。共通信号系列は、スケジューリング要求（ＳＲ）のような信号系列である。ｅＮＢ２００は、共通リソースプールごとに、カウンティング応答（共通信号系列）の受信電力を測定する。ｅＮＢ２００は、各共通リソースプールの受信電力に基づいて、当該共通リソースプールに対応するＭＢＭＳサービスを受信している又は受信に興味を持つＵＥの数を大まかに把握することができる。ｅＮＢ２００は、ターゲット電力と実際の受信電力との差分より、当該ＭＢＭＳサービスを受信している又は受信に興味を持つＵＥの数を大まかに把握してもよい。
【０１０５】
他の例として、ＵＥ１００（制御部１３０）は、自身で発生させた乱数又は自身の固有識別子を取得し、乱数又は識別子を用いて信号系列を選択する。ＵＥ１００（送信部１２０）は、カウンティング応答として、乱数又は識別子を用いて選択された信号系列（個別信号系列）を送信する。ｅＮＢ２００は、共通リソースプールごとに、カウンティング応答（個別信号系列）の数を判定することにより、当該共通リソースプールに対応するＭＢＭＳサービスを受信している又は受信に興味を持つＵＥの数を把握することができる。
【０１０６】
複数の共通リソースプールのそれぞれは、物理ランダムアクセスチャネル（ＰＲＡＣＨ）リソースとして設定されてもよい。この場合、ランダムアクセスプリアンブルをカウンティング応答として用いてもよい。共通リソースプールとして用いられるＰＲＡＣＨリソースは、リソース位置が定められた通常のＰＲＡＣＨリソースとは異なるＰＲＡＣＨリソースとして設定される。
【０１０７】
図１４は、第３実施形態に係る動作例を示す図である。ここでは、第１実施形態との相違点を主として説明し、重複する説明を省略する。図１４において、ステップＳ１３、Ｓ３１、Ｓ３２、Ｓ１４はこの順に行われなくてもよく、ステップＳ１３、Ｓ３１、Ｓ３２、Ｓ１４の順番を変更してもよい。上述した共通信号系列を用いる場合、ステップＳ３２を省略してもよい。上述した個別信号系列を用いる場合、ステップＳ１４を省略してもよい。
【０１０８】
図１４に示すように、ステップＳ１１乃至Ｓ１３は第１実施形態と同様である。但し、ステップＳ１１において、ｅＮＢ２００（送信部２１０）は、複数のＭＢＭＳサービスのそれぞれのサービス識別子（ＴＭＧＩ）を含むカウンティング要求を送信する。ステップＳ１２において、ｅＮＢ２００（送信部２１０）は、当該複数のＭＢＭＳサービスに対応する複数の共通リソースプールを示す共通リソース設定を送信する。ステップＳ１１又はＳ１２（又は他のシグナリング）において、ｅＮＢ２００（送信部２１０）は、サービス識別子（ＴＭＧＩ）と共通リソースプールとの対応関係を示す情報（すなわち、マッピング情報）を送信してもよい。或いは、カウンティング要求中のサービス識別子の並び順と、共通リソース設定中の共通リソースプールの並び順とを合わせることにより、対応関係を暗示的に示してもよい。サービス識別子と共通リソースプールとの対応関係は、１対１の関係である。但し、１対多の関係としてもよい。
【０１０９】
上述した共通信号系列を用いる場合、ｅＮＢ２００は、共通信号系列を示すパラメータをＵＥ１００に設定してもよい。ｅＮＢ２００は、共通信号系列の開ループ送信電力制御等に用いる送信電力パラメータ（例えば、ｅＮＢ２００におけるターゲット受信電力）をＵＥ１００に設定してもよい。上述した個別信号系列を用いる場合、ｅＮＢ２００は、個別信号系列及び／又はその送信電力を決定するためのパラメータをＵＥ１００に設定してもよい。これらのパラメータは、専用シグナリング、マルチキャストシグナリング（ＭＣＣＨ／ＳＣ−ＭＣＣＨ）、又はブロードキャストシグナリング（ＳＩＢ）によりｅＮＢ２００から送信されてもよい。
【０１１０】
ステップＳ３１において、ＵＥ１００（制御部１３０）は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）に対応する共通リソースプールを複数の共通リソースプールの中から選択する。カウンティング対象のＭＢＭＳサービスのうち複数のＭＢＭＳサービスをＵＥ１００が受信している又は受信に興味を持つ場合、ＵＥ１００（制御部１３０）は、当該複数のＭＢＭＳサービスに対応する複数の共通リソースプールを選択してもよい。
【０１１１】
ステップＳ３２において、ＵＥ１００（制御部１３０）は、ＵＥ１００で発生させた乱数又はＵＥ１００の固有識別子を用いて個別信号系列（例えば、プリアンブル系列）を選択する。プリアンブル系列は、ベース系列とサイクリックシフト量とにより決定される。一例として、ＵＥ１００（制御部１３０）は、「（ＩＭＳＩ）  ｍｏｄ  （ｍａｘ＃  ｏｆ  “ｖ”）」によりサイクリックシフト量を決定する。（ｍａｘ＃  ｏｆ  “ｖ”）は、サイクリックシフト量（サイクリックシフトパターン）の最大数である。ＵＥ１００（制御部１３０）は、「（ＩＭＳＩ）  ｍｏｄ  （ｍａｘ＃  ｏｆ  Ｉｎｄｅｘ）」により「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」を決定してもよい。（ｍａｘ＃  ｏｆ  Ｉｎｄｅｘ）は、「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」の最大数（例えば、６４）である。「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」は、プリアンブル送信のタイミング（ＳＦＮ）及びプリアンブルフォーマット（信号の長さ）に関するパラメータである。全ての「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」を候補とするのではなく、一部の「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」に候補を限定してもよい。一例として、「ＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘ」は、”Ａｎｙ”（ＴＳ  ３６．２１１のＴａｂｌｅ  ５．７．１−２を参照）だけに限定されてもよい。”Ａｎｙ”は、どのＳＦＮでも送信が可能な設定である。この場合、（ｍａｘ＃  ｏｆ  Ｉｎｄｅｘ）は４３等に限定される。また、この場合、決定されたＰＲＡＣＨ  Ｃｏｎｆｉｇ  Ｉｎｄｅｘはシフトする（例えば、Ｉｎｄｅｘが０の場合、ＴＳ  ３６．２１１のＴａｂｌｅ  ５．７．１−２のＩｎｄｅｘは３を示す）。このように制御する事で、信号受信に割り当てたリソースを有効活用することができる。より短時間でカウントを行うことができる。
【０１１２】
ステップＳ１４乃至Ｓ１５は第１実施形態と同様である。但し、ステップＳ１５において、ＵＥ１００（送信部１２０）は、ステップＳ３１で選択した共通リソースプールを用いて、共通信号系列又は個別信号系列をカウンティング応答としてネットワーク（ｅＮＢ２００）に送信する。
【０１１３】
図１５は、サービス識別子（ＴＭＧＩ）と共通リソースプールとの対応関係を示す図である。図１５に示すように、ＴＭＧＩ＃１乃至＃４に対応する４つの共通リソースプールが設定されている。ＵＥ＃１は、ＴＭＧＩ＃１、＃２、及び＃３の各ＭＢＭＳサービスを受信している又は受信に興味を持っており、ＴＭＧＩ＃１、＃２、及び＃３に対応する各共通リソースプールにおいてカウンティング応答を送信する。他のＵＥも同様に、他のＵＥが受信している又は受信に興味を持つＭＢＭＳサービスに対応する共通リソースプールにおいてカウンティング応答を送信する。なお、各共通リソースプールのリソース量は、上述した方法を用いて個別に設定されてもよい。
【０１１４】
（第３実施形態の変更例）
上述した第１乃至第３実施形態において、新たなカテゴリのＵＥ１００が存在するシナリオを考慮していなかった。新たなカテゴリのＵＥ１００は、システム送受信帯域の一部のみに送受信帯域幅が制限されるＵＥ１００である。本変更例では、このようなＵＥ１００に対して、ＭＢＭＳを用いたマルチキャスト／ブロードキャストによりファームウェア等の一括配信を行うシナリオを想定する。
【０１１５】
新たなＵＥカテゴリは、例えば、カテゴリＭ１及びＮＢ（Ｎａｒｒｏｗ  Ｂａｎｄ）−ＩｏＴカテゴリと称される。ここで、カテゴリＭ１は、ｅＭＴＣ（ｅｎｈａｎｃｅｄ  Ｍａｃｈｉｎｅ  Ｔｙｐｅ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）ＵＥである。また、ＮＢ−ＩｏＴ  ＵＥは、カテゴリＮＢ１である。カテゴリＭ１は、ＵＥ１００の送受信帯域幅を１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）に制限するとともに、繰り返し送信等を用いたカバレッジ強化（ＣＥ：Ｅｎｈａｎｃｅｄ  Ｃｏｖｅｒａｇｅ）技術をサポートする。ＮＢ−ＩｏＴカテゴリは、ＵＥ１００の送受信帯域幅を１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）にさらに制限するとともに、カバレッジ強化技術をサポートする。繰り返し送信は、複数のサブフレームを用いて同一のデータを繰り返し送信する技術である。一例として、ＬＴＥシステムのシステム帯域幅は１０ＭＨｚであり、そのうちの送受信帯域幅は９ＭＨｚ（すなわち、５０リソースブロックの帯域幅）である。一方、カテゴリＭ１のＵＥ１００は、６リソースブロックよりも広い帯域幅で送信される下りリンク無線信号を受信することができないため、通常のＰＤＣＣＨを受信することができない。このため、ＭＴＣ向けのＰＤＣＣＨであるＭＰＤＣＣＨ（ＭＴＣ−ＰＤＣＣＨ）が導入される。同様な理由で、ＮＢ−ＩｏＴ向けのＰＤＣＣＨであるＮＰＤＣＣＨ（ＮＢ−ＰＤＣＣＨ）が導入される。
【０１１６】
以下において、ＵＥ１００に必要とされるカバレッジ強化の度合いを「ＣＥレベル」と称する。「ＣＥレベル」は、少なくとも繰り返し送信における送信回数（すなわち、Ｒｅｐｅｔｉｔｉｏｎ回数）と関連する。
【０１１７】
本変更例において、複数の共通リソースプールのそれぞれにＣＥレベルを対応付ける。ｅＮＢ２００は、専用シグナリング、マルチキャストシグナリング（ＭＣＣＨ／ＳＣ−ＭＣＣＨ）、又はブロードキャストシグナリング（ＳＩＢ）により、共通リソースプールとＣＥレベルとの対応関係（マッピング情報）をＵＥ１００に設定してもよい。
【０１１８】
複数の共通リソースプールのそれぞれには、サービス識別子（ＴＭＧＩ）とＣＥレベルとが対応付けられていてもよい。一例として、ＴＭＧＩ＃１且つＣＥレベル＃１に対応する共通リソースプール＃１と、ＴＭＧＩ＃１且つＣＥレベル＃２に対応する共通リソースプール＃２と、・・・を設定してもよい。ｅＮＢ２００は、カウンティング要求を行う際に、カウンティング対象のＴＭＧＩ及びそのＴＭＧＩに対応するＣＥレベル毎のプール（共通リソース設定）をＵＥ１００に通知してもよい。或いは、ｅＮＢ２００は、ＳＣ−ＭＣＣＨ（もしくはＳＩＢ２０）で、ＴＭＧＩ毎の設定情報としてＣＥレベル毎のプール（共通リソース設定）をＵＥ１００に通知してもよい。
【０１１９】
ＵＥ１００は、自身のＣＥレベルを取得する。ＣＥレベルは、ＵＥ１００に事前設定されていてもよい。或いは、ＣＥレベルは、ＵＥ１００の状況に応じて可変であってもよい。一例として、ＵＥ１００は、ネットワークからの受信電力（ＲＳＲＰ：Ｒｅｆｅｒｅｎｃｅ  Ｓｉｇｎａｌ  Ｒｅｃｅｉｖｅｄ  Ｐｏｗｅｒ）と閾値との比較結果に応じて自身のＣＥレベルを決定する。閾値（のリスト）は、ネットワークからＵＥ１００に通知されてもよい。各閾値は、ＣＥレベルと対応付けられている。
【０１２０】
ＵＥ１００は、複数の共通リソースプールのうち、自身のＣＥレベルに対応する共通リソースプールを選択する。ＵＥ１００は、自身が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）に対応する複数の共通リソースプールを選択し、当該複数の共通リソースプールの中から自身のＣＥレベルに対応する共通リソースプールをさらに選択してもよい。所定のＣＥレベル（例えば、カバレッジ強化の必要が無いことを示すレベル）を有するＵＥ１００、若しくは通常のカバレッジエリアに在圏するＵＥ１００は、カウンティング応答を送信しなくてもよい。
【０１２１】
ｅＮＢ２００は、共通リソースプールごとに、カウンティング応答の数をカウントする、又はカウンティング応答の受信電力を測定する。これにより、ｅＮＢ２００（又はＭＣＥ１１）は、ＭＢＭＳサービスごとに、且つＣＥレベルごとに、ＵＥ１００の数を推定してもよい。ｅＮＢ２００（又はＭＣＥ１１）は、推定結果に基づいて、ＭＢＭＳサービスのＲｅｐｅｔｉｔｉｏｎ回数を決定してもよい。一例として、ｅＮＢ２００（又はＭＣＥ１１）は、あるＭＢＭＳサービスを受信している又は受信に興味を持つ複数のＵＥ１００についてＣＥレベルの分布から、最もＵＥ１００の数が多いＣＥレベル（或いは、ＵＥ１００の数が閾値を超えるＣＥレベル）を当該ＭＢＭＳサービスのＣＥレベルとして決定し、決定したＣＥレベルに対応するＲｅｐｅｔｉｔｉｏｎ回数等で当該ＭＢＭＳサービスをＳＣ−ＰＴＭで送信する。ｅＮＢ２００（又はＭＣＥ１１）は、あるＭＢＭＳサービスを受信している又は受信に興味を持つ複数のＵＥ１００について、カウンティング応答が得られた最高のＣＥレベル（例えば、Ｒｅｐｅｔｉｔｉｏｎ回数が最も多いＣＥレベル）を当該ＭＢＭＳサービスのＣＥレベルとして決定してもよい。
【０１２２】
（第４実施形態）
第４実施形態について、第１乃至第３実施形態との相違点を主として説明する。第４実施形態は、ＭＢＭＳサービスを受信中のＵＥ１００の移動を考慮した実施形態である。
【０１２３】
一例として、ＳＣ−ＰＴＭによりＭＢＭＳサービスを受信中のＵＥ１００が別のセルに移動した時に、移動先セルでＳＣ−ＰＴＭが提供されていないことがあり得る。この場合、ＵＥ１００は、ＭＢＭＳサービスを継続的に受信するためには、ＲＲＣコネクティッドモードに遷移する必要があり得る。
【０１２４】
上述したように、ＵＥ１００（送信部１２０）は、自身が特定状態（ＲＲＣアイドルモード又はＬｉｇｈｔ  Ｃｏｎｎｅｃｔｅｄ状態）にある場合において、共通リソースプールの少なくとも一部を用いてカウンティング応答をネットワークに送信する。第４実施形態において、ＵＥ１００（送信部１２０）は、自身が特定状態から復旧するための要求メッセージをネットワークに送信する。当該要求メッセージは、ＵＥ１００がＭＢＭＳサービスを受信している又は受信に興味を持つことを示す情報を含む。当該要求メッセージは、ＲＲＣ接続の確立を要求する「ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ」、ＲＲＣ接続の復旧を要求する「ＲＲＣ  Ｃｏｎｎｅｃｔｉｏｎ  Ｒｅｓｕｍｅ  Ｒｅｑｕｅｓｔメッセージ」、又は「Ｌｉｇｈｔ  Ｃｏｎｎｅｃｔｉｏｎ用のＡｃｔｉｖａｔｉｏｎ  Ｒｅｑｕｅｓｔメッセージ」の何れかである。
【０１２５】
要求メッセージは、その理由を示すＣａｕｓｅフィールドを有する。ＵＥ１００は、ＭＢＭＳサービスを受信している又は受信に興味を持つことを示す情報をＣａｕｓｅフィールドに含める。一般的に、Ｃａｕｓｅフィールドには、ｅｍｅｒｇｅｎｃｙ、ｈｉｇｈＰｒｉｏｒｉｔｙＡｃｃｅｓｓ、ｍｔ−Ａｃｃｅｓｓ、ｍｏ−Ｓｉｇｎａｌｌｉｎｇ、ｍｏ−Ｄａｔａ、ｄｅｌａｙＴｏｌｅｒａｎｔＡｃｃｅｓｓ、ｍｏ−ＶｏｉｃｅＣａｌｌの何れかが設定される。ｅＮＢ２００は、Ｃａｕｓｅフィールドの内容に基づいて、要求メッセージを処理する優先度を判断する。
【０１２６】
要求メッセージを受信したｅＮＢ２００は、ＭＢＭＳサービスを受信している又は受信に興味を持つことを示す情報が当該要求メッセージに含まれていることに応じて、当該要求メッセージを優先的に処理する。言い換えると、ｅＮＢ２００は、ＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００を優先的にＲＲＣコネクティッドモードに遷移させるよう制御する。この場合の優先度は、例えば、ｍｏ  ｄａｔａとｈｉｇｈ  ｐｒｉｏｒｉｔｙ  ａｃｃｅｓｓとの中間程度に設定することができる。
【０１２７】
（その他の実施形態）
第３実施形態の変更例において、ＣＥレベルがＵＥ１００の状況に応じて可変である一例を説明した。ＵＥ１００は、自身のＣＥレベルが変化した又はマルチキャスト受信（ＭＢＭＳ受信）に失敗したことに応じて、ｅＮＢ２００にその旨を通知してもよい。ＵＥ１００は、自身のＣＥレベルが変化した又はマルチキャスト受信（ＭＢＭＳ受信）に失敗し、且つ、依然として当該マルチキャスト受信に興味がある、及び／又は当該ＭＢＭＳサービスが進行中である場合に、当該通知を行ってもよい。ｅＮＢ２００は、当該通知により、当該ＭＢＭＳサービスのＲｅｐｅｔｉｔｉｏｎ回数等を変更してもよい。
【０１２８】
ＵＥ１００は、自身のＣＥレベルに基づいて、ｅＮＢ２００に対するＭＢＭＳ興味通知の送信を制御してもよい。ＭＢＭＳ興味通知（ＭＢＭＳ  ｉｎｔｅｒｅｓｔ  ｉｎｄｉｃａｔｉｏｎ）は、ＵＥ１００がＭＢＭＳサービスを受信している又は受信に興味を持つことを示すＲＲＣメッセージである。ＭＢＭＳ興味通知には、ＵＥ１００がＭＢＭＳサービスを受信している又は受信に興味を持つＭＢＭＳサービスの周波数、当該ＭＢＭＳサービスの受信をユニキャスト受信よりも優先するか否かを示す情報、当該ＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）のリスト、のうち少なくとも１つを含めることができる。ＵＥ１００は、自身のＣＥレベルをＭＢＭＳ興味通知に含めてもよい。ＵＥ１００は、カバレッジ強化（ＣＥ）が必要であると判断した場合に限り、ＭＢＭＳ興味通知をネットワークに送信してもよい。ｅＮＢ２００は、このような特殊なＭＢＭＳ興味通知の送信をＵＥ１００に要求（又は許可）してもよい。ｅＮＢ２００は、ＣＥレベルをＭＢＭＳ興味通知に含めるべきか否かを示す情報をＵＥ１００に送信してもよい。これらのｅＮＢ２００のシグナリングは、専用シグナリング、マルチキャストシグナリング（ＭＣＣＨ／ＳＣ−ＭＣＣＨ）、又はブロードキャストシグナリング（ＳＩＢ）であってもよい。ＵＥ１００は、ｅＮＢ２００からのシグナリングに従ってＭＢＭＳ興味通知をｅＮＢ２００に送信する。
【０１２９】
ｅＮＢ２００が行うと説明した処理の少なくとも一部をＭＣＥ１１及び／又はＭＭＥ３００が行ってもよい。ＭＣＥ１１は、ＭＭＥ３００からＣＥレベルを通知されてもよい。当該ＣＥレベルは、ＴＭＧＩと紐付いていてもよい。当該ＣＥレベルは、当該ＴＭＧＩが示すＭＢＭＳサービスに興味があるＵＥ１００のＣＥレベルのうち最も拡張が必要なＣＥレベル（例えば、Ｒｅｐｅｔｉｔｉｏｎ回数が最も多いＣＥレベル）であってもよい。ＭＣＥ１１（又はＭＭＥ３００）は、ＭＢＭＳサービスのセッション開始要求において、ｅＮＢ２００（又はＭＣＥ１１）に対して、当該ＭＢＭＳサービスのＲｅｐｅｔｉｔｉｏｎ回数を通知してもよい。
【０１３０】
上述した各実施形態に係るＭＢＭＳカウンティングプロシージャを一般的なＭＢＭＳカウンティングプロシージャと併用してもよい。一例として、一般的なＭＢＭＳカウンティングプロシージャにより特定のＭＢＭＳサービスを受信している又は受信に興味を持つＲＲＣコネクティッドモードのＵＥ数を把握し、当該ＲＲＣコネクティッドモードのＵＥ数に基づいて共通リソースプールのリソース量等を決定してもよい。
【０１３１】
上述した各実施形態における上りリンク送信動作をコンテンションベースの上りリンクデータ送信に適用してもよい。そのような変更例においては、カウンティング要求は用いられず、かつ、「カウンティング応答」を「上りリンク信号」と読み替える。より具体的には、「カウンティング応答」を「上りリンクデータ」と読み替えてもよい。そのような変更例は、次のように要約することができる。移動通信システムのための無線端末は、複数の無線端末が上りリンク信号の送信に共通に用いるべき共通リソースを示す共通リソース設定をネットワークから受信する受信部と、自無線端末の固有識別子を取得し、前記固有識別子に基づいて自無線端末が上りリンク信号の送信に用いる無線リソースを前記共通リソースの中から決定する制御部と、前記決定された無線リソースを用いて、上りリンク信号を前記ネットワークに送信する送信部と、を備える。ここで、前記制御部は、前記固有識別子に基づいて、自無線端末が上りリンク信号の送信に用いる時間リソース（例えば、サブフレーム）を決定してもよい。前記制御部は、前記固有識別子に基づいて、自無線端末が上りリンク信号の送信に用いる周波数リソース（例えば、ＮＢ−ＩｏＴにおける１８０ｋＨｚ（１リソースブロックの帯域幅）のキャリア）を決定してもよい。
【０１３２】
コンテンションベースの上りリンクデータ送信において、ＵＥ１００は、例えば、「ＩＭＳＩ  ｍｏｄ  ｘ  ＝  ０」となるサブフレームのみ、コンテンションベースＵＬ送信を行ってもよい。ここで、コンテンションベースＵＬ送信を許可するサブフレームが歯抜けの場合（例えば、有効サブフレームがパターンでＵＥ１００に指定されている場合）、開始サブフレーム番号から起算して、有効サブフレームだけをカウントしてもよい。すなわち、ＵＥ１００は、歯抜けの有効サブフレームのみを対象として、最初から順に０，１，２，３…番とみなしてもよい。ｅＮＢ２００は、コンテンションベース送信の許可識別子（例えば、ＳＩＢによる通知）、コンテンションベース送信の有効サブフレームのパターンを示すパラメータ（例えば、ｓｔａｒｔ  ｓｕｂｆｒａｍｅ  ｛ｓｔａｒｔ  ｏｆｆｓｅｔ｝、又はｂｉｔｍａｐ  ｐａｔｔｅｒｎ  ｛３，  ５，  ７，  １０，  １８｝等）をブロードキャスト又はマルチキャストでＵＥ１００に通知してもよい。上述したように、ＵＥの固有識別子としては、ＩＭＳＩに限らず、Ｒｅｓｕｍｅ  ＩＤ、Ｃ−ＲＮＴＩ、Ｓ−ＴＭＳＩを用いてもよい。ここではコンテンションベースの上りリンクデータ送信を時間方向に分散させる一例を説明したが、周波数方向への分散を行ってもよい。例えば、ＵＥ１００は、ＩＭＳＩ  ｍｏｄ  ｘ  ＝  ０を満たすｃａｒｒｉｅｒ（すなわち、ＮＢ−ＩｏＴにおける１８０ｋＨｚ（１リソースブロックの帯域幅））のみで上りリンク送信を行ってもよい。
【０１３３】
コンテンションベースの上りリンクデータ送信において、ＣＥ（Ｅｎｈａｎｃｅｄ  Ｃｏｖｅｒａｇｅ）に居るＵＥとＮＣ（Ｎｏｒｍａｌ  Ｃｏｖｅｒａｇｅ）に居るＵＥとで、別のリソース（サブフレーム及び／又は周波数）を割り当ててもよい（第３実施形態の変更例参照）。ＵＥ１００は、測定したＲＳＲＰがある閾値を超えたか否かに応じてＣＥに居るか否かを判定してもよい。ＵＥ１００は、繰り返し送信回数がある閾値を超えたか否かで判定してもよい。これらの閾値は、ｅＮＢ２００からＵＥ１００に対してブロードキャスト又はマルチキャストで通知されていてもよい。
【０１３４】
コンテンションベースの上りリンクデータ送信において、ＵＥ１００は、送信ＭＣＳ毎に又は繰り返し送信回数毎に異なるリソースを割り当てられてもよい。ＵＥ１００が送信ＭＣＳに応じて送信リソースを決定して上りリンク送信を行う場合、ｅＮＢ２００は、受信リソースに応じてデコード方式（ＭＣＳ）を変更してもよい。
【０１３５】
上述した各実施形態を別個独立に実施する場合に限らず、２以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の処理を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の処理を他の実施形態の一部の構成と置換してもよい。
【０１３６】
上述した各実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本開示はＬＴＥシステムに限定されない。ＬＴＥシステム以外の移動通信システムに本開示を適用してもよい。
【０１３７】
本願は米国仮出願第６２／３８１１４０号（２０１６年８月３０日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。
【図１】
0006751765.tif 000002
【図２】
0006751765.tif 000003
【図３】
0006751765.tif 000004
【図４】
0006751765.tif 000005
【図５】
0006751765.tif 000006
【図６Ａ】
0006751765.tif 000007
【図６Ｂ】
0006751765.tif 000008
【図７】
0006751765.tif 000009
【図８】
0006751765.tif 000010
【図９】
0006751765.tif 000011
【図１０】
0006751765.tif 000012
【図１１】
0006751765.tif 000013
【図１２】
0006751765.tif 000014
【図１３】
0006751765.tif 000015
【図１４】
0006751765.tif 000016
【図１５】
0006751765.tif 000017