JP6670944B2 - 無線端末及び基地局 - Google Patents

Description

本発明は、移動通信システムのための無線端末及び基地局に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）において、無線端末にマルチキャスト／ブロードキャストサービスを提供するＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）が仕様化されている。ＭＢＭＳ用の無線伝送方式としては、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ Ｂｒｏａｄｃａｓｔ Ｓｉｎｇｌｅ Ｆｒｅｑｕｅｎｃｙ Ｎｅｔｗｏｒｋ）伝送及びＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）伝送の２つの方式がある。

一方、人が介在することなく通信を行うＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）サービスを対象とした無線端末が検討されている。このような無線端末は、低コスト化、カバレッジ広域化、及び低消費電力化を実現することが求められる。このため、３ＧＰＰにおいて、システム送受信帯域の一部のみに送受信帯域幅を制限した新たな無線端末のカテゴリが仕様化されている。このような新たなカテゴリの無線端末には、繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）を含むカバレッジ強化技術が適用される。

一実施形態に係る無線端末は、繰り返し送信を含むカバレッジ強化技術を用いて基地局から配信されるＭＢＭＳサービスを受信する受信部と、所定のイベントが発生したか否かを判断する制御部と、前記所定のイベントが発生したことに応じて、前記無線端末が必要とするカバレッジ強化レベルに関する通知を前記基地局に送信する送信部と、を備える。前記所定のイベントは、前記通知の送信を前記基地局から要求されたこと、又は前記ＭＢＭＳサービスを正常に受信できないことである。

一実施形態に係る基地局は、ＭＢＭＳサービスに適用すべきカバレッジ強化レベルに関する通知をネットワーク装置から受信する受信部と、前記通知に基づいて、繰り返し送信を含むカバレッジ強化技術を用いて前記ＭＢＭＳサービスを配信する制御部と、を備える。

一実施形態に係る無線端末は、サービングセルとして用いるセルを選択するセル再選択動作を行う制御部を備える。繰り返し送信を含むカバレッジ強化技術が前記無線端末に必要とされる場合、前記制御部は、無線品質に基づくランキングにより前記セルを選択する。前記カバレッジ強化技術が前記無線端末に必要とされる場合であっても、前記無線端末がＭＢＭＳサービスを受信している又は受信に興味を持つ場合には、前記制御部は、前記ランキングを用いることなく、前記ＭＢＭＳサービスが配信される周波数に属する前記セルを優先的に選択する。

実施形態に係るＬＴＥシステムの構成を示す図である。 実施形態に係るＭＢＭＳに係るネットワーク構成を示す図である。 実施形態に係るＵＥ（無線端末）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 実施形態に係るＳＣ−ＰＴＭの動作例を示す図である。 実施形態に係るＳＩＢ２０を示す図である。 実施形態に係るＳＣ−ＭＣＣＨ中のＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。 実施形態に係るｅＭＴＣ ＵＥ向けの下りリンク物理チャネルを示す図である。 実施形態に係るｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。 第１実施形態の動作パターン１の一例を示す図である。 第１実施形態の動作パターン２の一例を示す図である。 第１実施形態に係る共通リソースの第１の例を示す図である。 第１実施形態に係る共通リソースの第２の例を示す図である。 第１実施形態に係る共通リソースの第２の例を示す図である。 第１実施形態に係る共通リソースの第３の例を示す図である。 第２実施形態の動作例を示す図である。 第３実施形態の動作例を示す図である。

（移動通信システム）
実施形態に係る移動通信システムの構成について説明する。実施形態に係る移動通信システムは、３ＧＰＰで仕様が策定されているＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）システムである。図１は、実施形態に係るＬＴＥシステムの構成を示す図である。図２は、ＭＢＭＳに係るネットワーク構成を示す図である。

図１に示すように、ＬＴＥシステムは、無線端末（ＵＥ：Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）１００、無線アクセスネットワーク（Ｅ−ＵＴＲＡＮ：Ｅｖｏｌｖｅｄ−ＵＭＴＳ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）１０、及びコアネットワーク（ＥＰＣ：Ｅｖｏｌｖｅｄ Ｐａｃｋｅｔ Ｃｏｒｅ）２０を備える。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ＬＴＥシステムのネットワークを構成する。

ＵＥ１００は、移動型の通信装置である。ＵＥ１００は、自身が在圏するセル（サービングセル）を管理するｅＮＢ２００との無線通信を行う。

Ｅ−ＵＴＲＡＮ１０は、基地局（ｅＮＢ：ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）２００を含む。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００は、１又は複数のセルを管理する。ｅＮＢ２００は、ｅＮＢ２００が管理するセルとの接続を確立したＵＥ１００との無線通信を行う。ｅＮＢ２００は、無線リソース管理（ＲＲＭ）機能、ユーザデータ（以下、単に「データ」という）のルーティング機能、モビリティ制御・スケジューリングのための測定制御機能等を有する。「セル」は、無線通信エリアの最小単位を示す用語として用いられる。「セル」は、ＵＥ１００との無線通信を行う機能又はリソースを示す用語としても用いられる。

ＥＰＣ２０は、モビリティ管理エンティティ（ＭＭＥ）及びサービングゲートウェイ（Ｓ−ＧＷ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。

次に、ＭＢＭＳ向けのネットワークエンティティについて説明する。Ｅ−ＵＴＲＡＮ１０は、ＭＣＥ（Ｍｕｌｔｉ−Ｃｅｌｌ／Ｍｕｌｔｉｃａｓｔ Ｃｏｏｒｄｉｎａｔｉｎｇ Ｅｎｔｉｔｙ）１１を含む。ＭＣＥ１１は、Ｍ２インターフェイスを介してｅＮＢ２００と接続され、Ｍ３インターフェイスを介してＭＭＥ３００と接続される（図２参照）。ＭＣＥ１１は、ＭＢＳＦＮ無線リソース管理・割当等を行う。具体的には、ＭＣＥ１１は、ＭＢＳＦＮ伝送のスケジューリングを行う。これに対し、ＳＣ−ＰＴＭ伝送のスケジューリングはｅＮＢ２００により行われる。

ＥＰＣ２０は、ＭＢＭＳ ＧＷ（ＭＢＭＳ Ｇａｔｅｗａｙ）２１を含む。ＭＢＭＳ ＧＷ２１は、Ｍ１インターフェイスを介してｅＮＢ２００と接続され、Ｓｍインターフェイスを介してＭＭＥ３００と接続され、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＢＭ−ＳＣ２２と接続される（図２参照）。ＭＢＭＳ ＧＷ２１は、ｅＮＢ２００に対してＩＰマルチキャストのデータ伝送及びセッション制御等を行う。

また、ＥＰＣ２０は、ＢＭ−ＳＣ（Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ Ｃｅｎｔｅｒ）２２を含む。ＢＭ−ＳＣ２２は、ＳＧ−ｍｂ及びＳＧｉ−ｍｂインターフェイスを介してＭＢＭＳ ＧＷ２１と接続され、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される（図２参照）。ＢＭ−ＳＣ２２は、ＴＭＧＩ（Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｇｒｏｕｐ Ｉｄｅｎｔｉｔｙ）の管理・割当等を行う。

ＥＰＣ２０の外部のネットワーク（すなわち、インターネット）には、ＧＣＳ ＡＳ（Ｇｒｏｕｐ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ Ａｐｐｌｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）３１が設けられてもよい。ＧＣＳ ＡＳ３１は、グループ通信用のアプリケーションサーバである。ＧＣＳ ＡＳ３１は、ＭＢ２−Ｕ及びＭＢ２−Ｃインターフェイスを介してＢＭ−ＳＣ２２と接続され、ＳＧｉインターフェイスを介してＰ−ＧＷ２３と接続される。ＧＣＳ ＡＳ３１は、グループ通信におけるグループの管理及びデータ配信等を行う。

図３は、実施形態に係るＵＥ１００（無線端末）の構成を示す図である。図３に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

受信部１１０は、制御部１３０の制御下で各種の受信を行う。受信部１１０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。受信機は、ベースバンド信号を制御部１３０に出力する。

送信部１２０は、制御部１３０の制御下で各種の送信を行う。送信部１２０は、アンテナ及び送信機を含む。送信機は、制御部１３０が出力するベースバンド信号（送信信号）を無線信号に変換する。送信機は、無線信号をアンテナから送信する。

制御部１３０は、ＵＥ１００における各種の制御を行う。制御部１３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）と、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、音声・映像信号の符号化・復号を行うコーデックを含んでもよい。プロセッサは、後述する各種の処理を実行する。

図４は、実施形態に係るｅＮＢ２００（基地局）の構成を示す図である。図４に示すように、ｅＮＢ２００は、送信部２１０、受信部２２０、制御部２３０、及びバックホール通信部２４０を備える。

送信部２１０は、制御部２３０の制御下で各種の送信を行う。送信部２１０は、アンテナ及び送信機を含む。送信機は、制御部２３０が出力するベースバンド信号（送信信号）を無線信号に変換する。送信機は、無線信号をアンテナから送信する。

受信部２２０は、制御部２３０の制御下で各種の受信を行う。受信部２２０は、アンテナ及び受信機を含む。受信機は、アンテナが受信する無線信号をベースバンド信号（受信信号）に変換する。受信機は、ベースバンド信号を制御部２３０に出力する。

制御部２３０は、ｅＮＢ２００における各種の制御を行う。制御部２３０は、プロセッサ及びメモリを含む。メモリは、プロセッサにより実行されるプログラム、及びプロセッサによる処理に用いられる情報を記憶する。プロセッサは、ベースバンドプロセッサと、ＣＰＵと、を含む。ベースバンドプロセッサは、ベースバンド信号の変調・復調及び符号化・復号等を行う。ＣＰＵは、メモリに記憶されるプログラムを実行して各種の処理を行う。プロセッサは、後述する各種の処理を実行する。

バックホール通信部２４０は、Ｘ２インターフェイスを介して隣接ｅＮＢと接続され、Ｓ１インターフェイスを介してＭＭＥ／Ｓ−ＧＷ３００と接続される。バックホール通信部２４０は、Ｘ２インターフェイス上で行う通信及びＳ１インターフェイス上で行う通信等に用いられる。バックホール通信部２４０は、Ｍ１インターフェイス上で行う通信及びＭ２インターフェイス上で行う通信にも用いられ得る。

図５は、ＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。図５に示すように、無線インターフェイスプロトコルは、ＯＳＩ参照モデルの第１レイヤ乃至第３レイヤに区分されており、第１レイヤは物理（ＰＨＹ）レイヤである。第２レイヤは、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）レイヤ、ＲＬＣ（Ｒａｄｉｏ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）レイヤ、及びＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）レイヤを含む。第３レイヤは、ＲＲＣ（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｃｏｎｔｒｏｌ）レイヤを含む。

物理レイヤは、符号化・復号、変調・復調、アンテナマッピング・デマッピング、及びリソースマッピング・デマッピングを行う。ＵＥ１００の物理レイヤとｅＮＢ２００の物理レイヤとの間では、物理チャネルを介してデータ及び制御信号が伝送される。

ＭＡＣレイヤは、データの優先制御、ＨＡＲＱ（Ｈｙｂｒｉｄ ＡＲＱ）による再送処理等を行う。ＵＥ１００のＭＡＣレイヤとｅＮＢ２００のＭＡＣレイヤとの間では、トランスポートチャネルを介してデータ及び制御信号が伝送される。ｅＮＢ２００のＭＡＣレイヤは、スケジューラを含む。スケジューラは、上下リンクのトランスポートフォーマット（トランスポートブロックサイズ、変調・符号化方式（ＭＣＳ））、及びＵＥ１００への割当リソースブロックを決定する。

ＲＬＣレイヤは、ＭＡＣレイヤ及び物理レイヤの機能を利用してデータを受信側のＲＬＣレイヤに伝送する。ＵＥ１００のＲＬＣレイヤとｅＮＢ２００のＲＬＣレイヤとの間では、論理チャネルを介してデータ及び制御信号が伝送される。

ＰＤＣＰレイヤは、ヘッダ圧縮・伸張、及び暗号化・復号化を行う。

ＲＲＣレイヤは、制御信号を取り扱う制御プレーンでのみ定義される。ＵＥ１００のＲＲＣレイヤとｅＮＢ２００のＲＲＣレイヤとの間では、各種設定のためのメッセージ（ＲＲＣメッセージ）が伝送される。ＲＲＣレイヤは、無線ベアラの確立、再確立及び解放に応じて、論理チャネル、トランスポートチャネル、及び物理チャネルを制御する。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がある場合、ＵＥ１００はＲＲＣコネクティッド状態である。ＵＥ１００のＲＲＣとｅＮＢ２００のＲＲＣとの間に接続（ＲＲＣ接続）がない場合、ＵＥ１００はＲＲＣアイドル状態である。

ＲＲＣレイヤの上位に位置するＮＡＳ（Ｎｏｎ−Ａｃｃｅｓｓ Ｓｔｒａｔｕｍ）レイヤは、セッション管理及びモビリティ管理等を行う。

図６は、ＬＴＥシステムの下りリンクのチャネルの構成を示す図である。図６（ａ）は、論理チャネル（Ｄｏｗｎｌｉｎｋ Ｌｏｇｉｃａｌ Ｃｈａｎｎｅｌ）とトランポートチャネル（Ｄｏｗｎｌｉｎｋ Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ）との間のマッピングを示す。

図６（ａ）に示すように、ＰＣＣＨ（Ｐａｇｉｎｇ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、ページング情報、及びシステム情報変更を通知するための論理チャネルである。ＰＣＣＨは、トランスポートチャネルであるＰＣＨ（Ｐａｇｉｎｇ Ｃｈａｎｎｅｌ）にマッピングされる。

ＢＣＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、システム情報のための論理チャネルである。ＢＣＣＨは、トランスポートチャネルであるＢＣＨ（Ｂｒｏａｄｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）及びＤＬ−ＳＣＨ（Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）にマッピングされる。

ＣＣＣＨ（Ｃｏｍｍｏｎ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、ＵＥ１００とｅＮＢ２００との間の送信制御情報のための論理チャネルである。ＣＣＣＨは、ＵＥ１００がネットワークとの間でＲＲＣ接続を有していない場合に用いられる。ＣＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。

ＤＣＣＨ（Ｄｅｄｉｃａｔｅｄ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、ＵＥ１００とネットワークとの間の個別制御情報を送信するための論理チャネルである。ＤＣＣＨは、ＵＥ１００がＲＲＣ接続を有する場合に用いられる。ＤＣＣＨは、ＤＬ−ＳＣＨにマッピングされる。

ＤＴＣＨ（Ｄｅｄｉｃａｔｅｄ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）は、データ送信のための個別論理チャネルである。ＤＴＣＨは、ＤＬ−ＳＣＨにマッピングされる。

ＳＣ−ＭＴＣＨ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、ＳＣ−ＰＴＭ伝送を用いてネットワークからＵＥ１００にデータを送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ ｄｏｗｎｌｉｎｋ ｃｈａｎｎｅｌ）である。

ＳＣ−ＭＣＣＨ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、ＳＣ−ＰＴＭ伝送のための論理チャネルである。ＳＣ−ＭＴＣＨは、１又は複数のＳＣ−ＭＴＣＨのためのＭＢＭＳ制御情報をネットワークからＵＥ１００に送信するための１対多チャネル（ｐｏｉｎｔ−ｔｏ−ｍｕｌｔｉｐｏｉｎｔ ｄｏｗｎｌｉｎｋ ｃｈａｎｎｅｌ）である。ＳＣ−ＭＣＣＨは、ＳＣ−ＰＴＭを用いてＭＢＭＳを受信する又は受信に興味を持つＵＥ１００に用いられる。また、ＳＣ−ＭＣＣＨは、１つのセルに１つのみ存在する。

ＭＣＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｏｎｔｒｏｌ Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＣＣＨは、ネットワークからＵＥ１００へのＭＴＣＨ用のＭＢＭＳ制御情報の送信のために用いられる。ＭＣＣＨは、トランスポートチャネルであるＭＣＨ（Ｍｕｌｔｉｃａｓｔ Ｃｈａｎｎｅｌ）にマッピングされる。

ＭＴＣＨ（Ｍｕｌｔｉｃａｓｔ Ｔｒａｆｆｉｃ Ｃｈａｎｎｅｌ）は、ＭＢＳＦＮ伝送のための論理チャネルである。ＭＴＣＨは、ＭＣＨにマッピングされる。

図６（ｂ）は、トランポートチャネル（Ｄｏｗｎｌｉｎｋ Ｔｒａｎｓｐｏｒｔ Ｃｈａｎｎｅｌ）と物理チャネル（Ｄｏｗｎｌｉｎｋ Ｐｈｙｓｉｃａｌ Ｃｈａｎｎｅｌ）との間のマッピングを示す。

図６（ｂ）に示すように、ＢＣＨは、ＰＢＣＨ（Ｐｈｙｓｉｃａｌ Ｂｒｏａｄｃａｓｔ Ｃｈａｎｎｅｌ）にマッピングされる。

ＭＣＨは、ＰＭＣＨ（Ｐｈｙｓｉｃａｌ Ｍｕｌｔｉｃａｓｔ Ｃｈａｎｎｅｌ）にマッピングされる。ＭＣＨは、複数のセルによるＭＢＳＦＮ伝送をサポートする。

ＰＣＨ及びＤＬ−ＳＣＨは、ＰＤＳＣＨ（Ｐｈｙｓｉｃａｌ Ｄｏｗｎｌｉｎｋ Ｓｈａｒｅｄ Ｃｈａｎｎｅｌ）にマッピングされる。ＤＬ−ＳＣＨは、ＨＡＲＱ、リンクアダプテーション、及び動的リソース割当をサポートする。

ＰＤＣＣＨは、ＰＤＳＣＨ（ＤＬ−ＳＣＨ、ＰＣＨ）のリソース割り当て情報及びＤＬ−ＳＣＨに関するＨＡＲＱ情報等を運搬する。また、ＰＤＣＣＨは、上りリンクのスケジューリンググラントを運ぶ。

図７は、ＬＴＥシステムの無線フレームの構成を示す図である。ＬＴＥシステムにおいて、下りリンクにはＯＦＤＭＡ（Ｏｒｔｈｏｇｏｎａｌ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）、上りリンクにはＳＣ−ＦＤＭＡ（Ｓｉｎｇｌｅ Ｃａｒｒｉｅｒ Ｆｒｅｑｕｅｎｃｙ Ｄｉｖｉｓｉｏｎ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ）がそれぞれ適用される。

図７に示すように、無線フレームは、時間方向に並ぶ１０個のサブフレームで構成される。各サブフレームは、時間方向に並ぶ２個のスロットで構成される。各サブフレームの長さは１ｍｓであり、各スロットの長さは０．５ｍｓである。各サブフレームは、周波数方向に複数個のリソースブロック（ＲＢ）を含み、時間方向に複数個のシンボルを含む。各リソースブロックは、周波数方向に複数個のサブキャリアを含む。１つのシンボル及び１つのサブキャリアにより１つのリソースエレメント（ＲＥ）が構成される。また、ＵＥ１００に割り当てられる無線リソース（時間・周波数リソース）のうち、周波数リソースはリソースブロックにより特定でき、時間リソースはサブフレーム（又はスロット）により特定できる。

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するためのＰＤＣＣＨとして用いられる領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するためのＰＤＳＣＨとして使用できる領域である。また、下りリンクにおいて、ＭＢＳＦＮ伝送向けのサブフレームであるＭＢＳＦＮサブフレームが設定され得る。

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するためのＰＵＣＣＨとして用いられる領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するためのＰＵＳＣＨとして使用できる領域である。

（セル再選択動作の概要）
ＲＲＣアイドル状態にあるＵＥ１００は、開始条件が満たされた場合に、現在のサービングセルに隣接する隣接セルの品質を測定し、選択条件を満たすセルの中からサービングセルとして用いるセルを選択する。

第１に、開始条件は、以下に示す通りである。

（Ａ１）現在のサービングセルの周波数の優先度よりも高い優先度を有する周波数：
ＵＥ１００は、高い優先度を有する周波数の品質を常に測定する。

（Ａ２）現在のサービングセルの周波数の優先度と等しい優先度又は低い優先度を有する周波数：
ＵＥ１００は、現在のサービングセルの品質が所定閾値を下回った場合に、等しい優先度又は低い優先度を有する周波数の品質を測定する。

第２に、選択条件は、以下に示す通りである。

（Ｂ１）隣接セルの周波数の優先度が現在のサービングセルの優先度よりも高い：
ＵＥ１００は、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）に亘ってＳｑｕａｌ＞Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＱ}の関係を満たすセル、若しくは、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）に亘ってＳｒｘｌｅｖ＞Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＰ}の関係を満たすセルを選択する。このようなケースにおいて、隣接セルが満たすべき基準を“Ｓ−ｃｒｉｔｅｒｉａ”と称することもある。

但し、Ｓｑｕａｌは、セル選択品質レベルを表す。Ｓｑｕａｌは、Ｓｑｕａｌ＝Ｑ_{ｑｕａｌｍｅａｓ}-（Ｑ_{ｑｕａｌｍｉｎ}＋Ｑ_{ｑｕａｌｍｉｎｏｆｆｓｅｔ}）−Ｑｏｆｆｓｅｔ_ｔｅｍｐによって算出される。Ｑ_{ｑｕａｌｍｅａｓ}は、隣接セルの品質レベル（ＲＳＲＱ）であり、Ｑ_{ｑｕａｌｍｉｎ}は、最小要求品質レベルであり、Ｑ_{ｑｕａｌｍｉｎｏｆｆｓｅｔ}は、隣接セルに定常的に適用される所定オフセットであり、Ｑｏｆｆｓｅｔ_ｔｅｍｐは、隣接セルに一時的に適用されるオフセットである。Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＱ}は、所定閾値である。

また、Ｓｒｘｌｅｖは、セル選択受信レベルを表す。Ｓｒｘｌｅｖは、Ｓｒｘｌｅｖ＝Ｑ_{ｒｘｌｅｖｍｅａｓ}-（Ｑ_{ｒｘｌｅｖｍｉｎ}＋Ｑ_{ｒｘｌｅｖｍｉｎｏｆｆｓｅｔ}）-Ｐｃｏｍｐｅｎｓａｔｉｏｎ−Ｑｏｆｆｓｅｔ_ｔｅｍｐによって算出される。Ｑ_{ｒｘｌｅｖｍｅａｓ}は、隣接セルの受信レベル（ＲＳＲＰ）であり、Ｑ_{ｒｘｌｅｖｍｉｎ}は、最小要求受信レベルであり、Ｑ_{ｒｘｌｅｖｍｉｎｏｆｆｓｅｔ}は、隣接セルに定常的に適用される所定オフセットであり、Ｐｃｏｍｐｅｎｓａｔｉｏｎは、アップリンクの能力に関するパラメータであり、Ｑｏｆｆｓｅｔ_ｔｅｍｐは、隣接セルに一時的に適用されるオフセットである。Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＰ}は、所定閾値である。

（Ｂ２）隣接セルの周波数の優先度が現在のサービングセルの優先度と同じである：
ＵＥ１００は、現在のサービングセルのランキングＲ_ｓ及び隣接セルのランキングＲ_ｎを算出するとともに、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）に亘ってＲ_ｓよりも高いランキングＲ_ｎを有するセルを対象セルとして選択する。このようなケースにおいて、隣接セルが満たすべき基準を“Ｒ−ｃｒｉｔｅｒｉａ”と称することもある。

但し、Ｒ_ｓは、Ｒ_ｓ＝Ｑ_ｍｅａｓ，_ｓ＋Ｑ_Ｈｙｓｔ−Ｑｏｆｆｓｅｔ_ｔｅｍｐによって算出される。Ｒ_ｎは、Ｒ_ｎ＝Ｑ_ｍｅａｓ，_ｎ−Ｑｏｆｆｓｅｔ−Ｑｏｆｆｓｅｔ_ｔｅｍｐによって算出される。Ｑ_ｍｅａｓ，_ｓは、現在のサービングセルの受信レベル（ＲＳＲＰ）であり、Ｑ_ｍｅａｓ，_ｎは、隣接セルの受信レベル（ＲＳＲＰ）である。Ｑ_Ｈｙｓｔは、現在のサービングセルが対象セルとして再選択されやすくするためのヒステリシス値である。Ｑｏｆｆｓｅｔ_ｔｅｍｐは、現在のサービングセル及び隣接セルに一時的に適用されるオフセットである。

（Ｂ３）隣接セルの周波数の優先度が現在のサービングセルの優先度よりも低い：
ＵＥ１００は、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）に亘ってＳｑｕａｌ＜Ｔｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＱ}が満たされる、若しくは、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）に亘ってＳｒｘｌｅｖ＜Ｔｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＰ}が満たされるという前提下において、上述した（Ｂ１）と同様の手法によって隣接セルの中から対象セルを選択する。

但し、Ｔｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＱ}及びＴｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＰ}は、Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＱ}及びＴｈｒｅｓｈ_{Ｘ，ＨｉｇｈＰ}と同様に、所定閾値である。

なお、対象セルの選択で用いる各種パラメータは、ｅＮＢ２００からブロードキャストされる情報（ＳＩＢ：Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）に含まれる。各種パラメータは、周波数の優先度（ｃｅｌｌＲｅｓｅｌｅｃｔｉｏｎＰｒｉｏｒｉｔｙ）、所定期間（Ｔｒｅｓｅｌｅｃｔｉｏｎ_ＲＡＴ）、各種オフセット（Ｑ_{ｑｕａｌｍｉｎｏｆｆｓｅｔ}、Ｑ_{ｒｘｌｅｖｍｉｎｏｆｆｓｅｔ}、Ｑｏｆｆｓｅｔ_ｔｅｍｐ、Ｑ_Ｈｙｓｔ、Ｑｏｆｆｓｅｔ）、各種閾値（Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＱ}、Ｔｈｒｅｓｈ_{Ｘ，ＨｉｇｈＰ}、Ｔｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＱ}、Ｔｈｒｅｓｈ_{Ｓｅｒｖｉｎｇ，ＬｏｗＰ}）を含む。

（ＳＣ−ＰＴＭの概要）
ＭＢＭＳ用の無線伝送方式としては、ＭＢＳＦＮ伝送及びＳＣ−ＰＴＭ伝送の２つの方式がある。ＭＢＳＦＮ伝送においては、複数のセルからなるＭＢＳＦＮエリア単位で、ＰＭＣＨを介してデータが送信される。これに対し、ＳＣ−ＰＴＭ伝送においては、セル単位で、ＰＤＳＣＨを介してデータが送信される。以下においては、ＵＥ１００がＳＣ−ＰＴＭ受信を行うシナリオを主として想定するが、ＭＢＳＦＮを想定してもよい。

ＵＥ１００は、ＲＲＣコネクティッド状態でＭＢＭＳサービスを受信してもよいし、ＲＲＣアイドル状態でＭＢＭＳサービスを受信してもよい。以下において、ＵＥ１００がＲＲＣアイドル状態でＭＢＭＳサービスを受信するケースを主として想定する。

図８は、ＳＣ−ＰＴＭの動作例を示す図である。

図８に示すように、ステップＳ１１において、ＵＥ１００は、ｅＮＢ２００を介してＥＰＣ２０からＵＳＤ（Ｕｓｅｒ Ｓｅｒｖｉｃｅ Ｄｅｓｃｒｉｐｔｉｏｎ）を取得する。ＵＳＤは、各ＭＢＭＳサービスの基本的な情報を提供する。ＵＳＤは、ＭＢＭＳサービスごとに、当該ＭＢＭＳサービスを識別するＴＭＧＩと、当該ＭＢＭＳサービスが提供される周波数と、当該ＭＢＭＳサービスの提供開始・終了時間と、を含む。

ステップＳ１２において、ＵＥ１００は、ＢＣＣＨを介してｅＮＢ２００からＳＩＢ２０を受信する。ＳＩＢ２０は、ＳＣ−ＭＣＣＨの取得に必要な情報（スケジューリング情報）を含む。図９は、ＳＩＢ２０を示す図である。図９に示すように、ＳＩＢ２０は、ＳＣ−ＭＣＣＨの内容が変更され得る周期を示すｓｃ−ｍｃｃｈ−ＭｏｄｉｆｉｃａｔｉｏｎＰｅｒｉｏｄ、ＳＣ−ＭＣＣＨの送信（再送）時間間隔を無線フレーム数で示すｓｃ−ｍｃｃｈ−ＲｅｐｅｔｉｔｉｏｎＰｅｒｉｏｄ、ＳＣ−ＭＣＣＨがスケジュールされる無線フレームのオフセットを示すｓｃ−ｍｃｃｈ−Ｏｆｆｓｅｔ、及びＳＣ−ＭＣＣＨがスケジュールされるサブフレームを示すｓｃ−ｍｃｃｈ−Ｓｕｂｆｒａｍｅ等を含む。

ステップＳ１３において、ＵＥ１００は、ＳＩＢ２０に基づいて、ＳＣ−ＭＣＣＨを介してｅＮＢ２００からＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信する。物理レイヤにおいてＳＣ−ＭＣＣＨの送信にはＳＣ−ＲＮＴＩ（Ｓｉｎｇｌｅ Ｃｅｌｌ ＲＮＴＩ）が用いられる。図１０は、ＳＣ−ＭＣＣＨ中のＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。図１０に示すように、ＳＣＰＴＭ設定情報は、ＳＣ−ＭＲＢ（Ｓｉｎｇｌｅ Ｃｅｌｌ ＭＢＭＳ Ｐｏｉｎｔ ｔｏ Ｍｕｌｔｉｐｏｉｎｔ Ｒａｄｉｏ Ｂｅａｒｅｒ）を介して送信されるＭＢＭＳサービスに適用可能な制御情報を含む。ＳＣＰＴＭ設定情報は、当該情報を送信するセルにおける各ＳＣ−ＭＴＣＨの設定を含むｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔ、及びＳＣ−ＭＲＢを介してＭＢＭＳサービスを提供する隣接セルのリストであるｓｃｐｔｍＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔを含む。ｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔは、１又は複数のＳＣ−ＭＴＣＨ−Ｉｎｆｏを含む。各ＳＣ−ＭＴＣＨ−Ｉｎｆｏは、ＳＣ−ＭＲＢを介して送信される進行中のＭＢＭＳセッションの情報（ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏ）、当該ＭＢＭＳセッションに対応するＧ−ＲＮＴＩ（Ｇｒｏｕｐ ＲＮＴＩ）、及びＳＣ−ＭＴＣＨのためのＤＲＸ情報であるｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏを含む。ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏは、ＭＢＭＳサービスを識別するＴＭＧＩ及びセッションＩＤ（ｓｅｓｓｉｏｎＩｄ）を含む。Ｇ−ＲＮＴＩは、マルチキャストグループ（具体的には、特定グループ宛てのＳＣ−ＭＴＣＨ）を識別するＲＮＴＩである。Ｇ−ＲＮＴＩは、ＴＭＧＩと１対１でマッピングされる。ｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏは、ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭ、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭ、ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭを含む。ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭは、ＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＣｙｃｌｅ及びＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＯｆｆｓｅｔを含む。

ステップＳ１４において、ＵＥ１００は、ＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）中のＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＩｎｆｏに基づいて、ＳＣ−ＭＴＣＨを介して、自身が興味のあるＴＭＧＩに対応するＭＢＭＳサービス（マルチキャストデータ）を受信する。物理レイヤにおいて、ｅＮＢ２００は、Ｇ−ＲＮＴＩを用いてＰＤＣＣＨを送信した後、ＰＤＳＣＨを介してマルチキャストデータを送信する。

なお、図１０に関連して説明した制御信号（シグナリング）は一例であり、省電力受信のための最適化等により、一部の制御信号が適宜省略されたり、制御信号の順序が入れ替わったりしてもよい。

（ｅＭＴＣ及びＮＢ−ＩｏＴの概要）
実施形態において、新たなカテゴリのＵＥ１００が存在するシナリオを想定する。新たなカテゴリのＵＥ１００は、システム送受信帯域の一部のみに送受信帯域幅が制限されるＵＥ１００である。新たなＵＥカテゴリは、例えば、カテゴリＭ１及びＮＢ（Ｎａｒｒｏｗ Ｂａｎｄ）−ＩｏＴカテゴリと称される。カテゴリＭ１は、ｅＭＴＣ（ｅｎｈａｎｃｅｄ Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）ＵＥである。ＮＢ−ＩｏＴ ＵＥは、カテゴリＮＢ１である。カテゴリＭ１は、ＵＥ１００の送受信帯域幅を１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）に制限するとともに、繰り返し送信等を用いたカバレッジ強化（ＣＥ：Ｅｎｈａｎｃｅｄ Ｃｏｖｅｒａｇｅ）技術をサポートする。ＮＢ−ＩｏＴカテゴリは、ＵＥ１００の送受信帯域幅を１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）にさらに制限するとともに、カバレッジ強化技術をサポートする。繰り返し送信は、複数のサブフレームを用いて同一の信号を繰り返し送信する技術である。一例として、ＬＴＥシステムのシステム帯域幅は１０ＭＨｚであり、そのうちの送受信帯域幅は９ＭＨｚ（すなわち、５０リソースブロックの帯域幅）である。一方、カテゴリＭ１のＵＥ１００は、６リソースブロックよりも広い帯域幅で送信される下りリンク無線信号を受信することができないため、通常のＰＤＣＣＨを受信することができない。このため、ＭＴＣ向けのＰＤＣＣＨであるＭＰＤＣＣＨ（ＭＴＣ−ＰＤＣＣＨ）が導入される。同様な理由で、ＮＢ−ＩｏＴ向けのＰＤＣＣＨであるＮＰＤＣＣＨ（ＮＢ−ＰＤＣＣＨ）が導入される。

図１１は、ｅＭＴＣ ＵＥ向けの下りリンク物理チャネルを示す図である。図１１に示すように、ｅＮＢ２００は、６リソースブロック以内でＭＰＤＣＣＨを送信する。ＭＰＤＣＣＨは、ＰＤＳＣＨを割り当てるためのスケジューリング情報を含む。一例として、ＭＰＤＣＣＨは、当該ＭＰＤＣＣＨが送信されるサブフレームとは異なるサブフレームのＰＤＳＣＨを割り当てる。ｅＮＢ２００は、６リソースブロック以内でＰＤＳＣＨを送信する。また、ｅＮＢ２００は、同一の信号の繰り返し送信を行うために、複数のサブフレームに亘ってＰＤＳＣＨを割り当てる。カテゴリＭ１のＵＥ１００は、ＭＰＤＣＣＨを受信することで割り当てＰＤＳＣＨを特定し、割り当てＰＤＳＣＨで送信されるデータを受信する。

図１２は、ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。図１２の初期状態において、ＵＥ１００は、ＲＲＣアイドル状態にある。ＵＥ１００は、ＲＲＣコネクティッド状態に遷移するためにランダムアクセスプロシージャを実行する。

ＵＥ１００は、ｅＮＢ２００のセルをサービングセルとして選択している。ＵＥ１００は、通常のカバレッジのための第１のセル選択基準（第１のＳ−ｃｒｉｔｅｒｉａ）が満たされず、強化カバレッジ（ｅｎｈａｎｃｅｄ ｃｏｖｅｒａｇｅ）のための第２のセル選択基準（第２のＳ−ｃｒｉｔｅｒｉａ）が満たされた場合、自身が強化カバレッジに居ると判断してもよい。「強化カバレッジに居るＵＥ」とは、セルにアクセスするためにカバレッジ強化技術（強化カバレッジモード）を用いることが必要とされるＵＥを意味する。なお、ｅＭＴＣ ＵＥは、強化カバレッジモードを用いることが必須である。

図１２に示すように、ステップＳ２１において、ｅＮＢ２００は、ＰＲＡＣＨ（Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｃｈａｎｎｅｌ）関連情報をブロードキャストシグナリング（例えば、ＳＩＢ）により送信する。ＰＲＡＣＨ関連情報は、カバレッジ強化レベル（ＣＥレベル）ごとに設けられた各種のパラメータを含む。ＣＥレベルは、「ｅｎｈａｎｃｅｄ ｃｏｖｅｒａｇｅ ｌｅｖｅｌ」と称されてもよい。一例として、ＣＥレベルは、ＣＥレベル０乃至３の合計４つのレベルが規定される。各種のパラメータは、ＲＳＲＰ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｐｏｗｅｒ）閾値、ＰＲＡＣＨリソース、及び最大プリアンブル送信回数を含む。ＰＲＡＣＨリソースは、無線リソース（時間・周波数リソース）及び信号系列（プリアンブル系列）を含む。ＵＥ１００は、受信したＰＲＡＣＨ関連情報を記憶する。

ステップＳ２２において、ＵＥ１００は、ｅＮＢ２００から送信される参照信号に基づいてＲＳＲＰを測定する。

ステップＳ２３において、ＵＥ１００は、測定したＲＳＲＰをＣＥレベルごとのＲＳＲＰ閾値と比較することにより、自身のＣＥレベルを決定する。ＣＥレベルは、ＵＥ１００に必要とされるカバレッジ強化の度合いを示す。ＣＥレベルは、少なくとも繰り返し送信における送信回数（すなわち、Ｒｅｐｅｔｉｔｉｏｎ回数）と関連する。

ステップＳ２４において、ＵＥ１００は、自身のＣＥレベルに対応するＰＲＡＣＨリソースを選択する。

ステップＳ２５において、ＵＥ１００は、選択したＰＲＡＣＨリソースを用いてＭｓｇ １（ランダムアクセスプリアンブル）をｅＮＢ２００に送信する。ｅＮＢ２００は、受信したＭｓｇ １に用いられたＰＲＡＣＨリソースに基づいて、ＵＥ１００のＣＥレベルを特定する。

ステップＳ２６において、ｅＮＢ２００は、ＵＥ１００に割り当てたＰＵＳＣＨリソースを示すスケジューリング情報を含むＭｓｇ ２（ランダムアクセス応答）をＵＥ１００に送信する。なお、ＵＥ１００は、Ｍｓｇ ２を正常に受信するまで、自身のＣＥレベルに対応する最大プリアンブル送信回数までＭｓｇ １を複数回送信し得る。

ステップＳ２７において、ＵＥ１００は、スケジューリング情報に基づいて、Ｍｓｇ ３をｅＮＢ２００に送信する。Ｍｓｇ ３は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージであってもよい。

ステップＳ２８において、ｅＮＢ２００は、Ｍｓｇ ４をＵＥ１００に送信する。

ステップＳ２９において、ＵＥ１００は、Ｍｓｇ ４の受信に応じてＲＲＣコネクティッド状態に遷移する。その後、ｅＮＢ２００は、特定したＣＥレベルに基づいて、ＵＥ１００への繰り返し送信を制御する。

（第１実施形態）
以下において、第１実施形態について説明する。第１実施形態は、上述した新たなカテゴリのＵＥ１００に対して、ＭＢＭＳを用いたマルチキャスト／ブロードキャストによりファームウェア等の一括配信を行うシナリオを想定する。また、ＲＲＣアイドル状態のＵＥ１００がＳＣ−ＰＴＭにより配信されるＭＢＭＳサービスを受信するケースを主として想定する。

第１実施形態に係るＵＥ１００は、繰り返し送信を含むカバレッジ強化技術を用いてｅＮＢ２００から配信されるＭＢＭＳサービスを受信する受信部１１０と、所定のイベントが発生したか否かを判断する制御部１３０と、所定のイベントが発生したことに応じて、ＵＥ１００が必要とするＣＥレベルを示す通知（以下、「ＣＥレベル通知」と称する）をｅＮＢ２００に送信する送信部１２０と、を備える。所定のイベントは、ＣＥレベル通知の送信をｅＮＢ２００から要求されたこと、又はＭＢＭＳサービスを正常に受信できないことである。

ＣＥレベル通知は、上述したＭｓｇ １（ランダムアクセスプリアンブル）であってもよいし、Ｍｓｇ １とは異なるメッセージであってもよい。但し、Ｍｓｇ １を用いる方法は、ＣＥレベル通知に伴うシグナリングが多く、かつ、ＵＥ１００が不必要にＲＲＣコネクティッド状態に遷移し得る。Ｍｓｇ １を用いる場合、ＵＥ１００をＲＲＣコネクティッド状態に遷移させないための情報をＭｓｇ １又はＭｓｇ ３に含めてもよい。もしくは、ＣＥレベル通知である事を示すシーケンス（信号系列）を用いてもよいし、ＣＥレベル通知用のリソース（時間・周波数リソース）を用いて送信してもよい。この場合、ＵＥ１００及びｅＮＢ２００は、ＲＲＣ接続を確立することなくランダムアクセスプロシージャを途中で終了させてもよい。

ＣＥレベル通知は、ＵＥ１００が決定したＣＥレベルの値を直接的に示す情報を含んでもよい。或いは、ＣＥレベル通知は、ＵＥ１００が決定したＣＥレベルの値を間接的に示す情報を含んでもよい。このような情報は、ＣＥレベルに対応する繰り返し送信回数であってもよいし、ＵＥ１００が測定したＲＳＲＰであってもよい。さらに、ＣＥレベル通知は、ＵＥ１００が受信している又は受信に興味を持つ１又は複数のＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）を含んでもよい。

第１実施形態の動作パターン１において、ＵＥ１００の受信部１１０は、ＭＢＭＳサービスの受信開始前において、ＣＥレベル通知の送信を要求する通知要求をｅＮＢ２００から受信する。ＵＥ１００の送信部１２０は、通知要求の受信に応じて、ＣＥレベル通知をｅＮＢ２００に送信する。すなわち、動作パターン１は、ＵＥ１００がｅＮＢ２００の要求に従ってＣＥレベルを通知するパターンである。これにより、ｅＮＢ２００は、ＵＥ１００のＣＥレベルに基づいて、適切な繰り返し送信回数及び／又はＭＣＳをＭＢＭＳ配信に適用することができる。

第１実施形態の動作パターン２において、ＵＥ１００の制御部１３０は、ＭＢＭＳサービスの受信開始後において、ＭＢＭＳサービスを正常に受信できるか否かを判断する。ＵＥ１００の送信部１２０は、ＭＢＭＳサービスを正常に受信できないと判断されたことに応じて、ＣＥレベル通知をｅＮＢ２００に送信する。すなわち、動作パターン２は、ＵＥ１００が自律的にＣＥレベルの通知タイミングを決定するパターンである。これにより、ｅＮＢ２００は、ＵＥ１００のＣＥレベルに基づいて、ＭＢＭＳ配信に適用する繰り返し送信回数及び／又はＭＣＳを適切に変更することができる。

ｅＮＢ２００は、動作パターン１を適用すべきか又は動作パターン２を適用すべきかを指定するためのトリガ指定情報をＵＥ１００に送信してもよい。ＵＥ１００は、指定された動作パターンに従ってＣＥレベル通知の送信を制御する。

第１実施形態において、ＵＥ１００の受信部１１０は、ＣＥレベル通知を送信するために複数のＵＥ１００が共用する共通リソースを示す設定情報をｅＮＢ２００から受信してもよい。ＵＥ１００の送信部１２０は、共通リソースを用いてＣＥレベル通知をｅＮＢ２００に送信してもよい。このような共通リソースを用いることにより、ｅＮＢ２００がＵＥ１００に個別にリソース割り当てを行う必要がなくなるため、ＲＲＣアイドル状態のＵＥ１００であってもＣＥレベル通知をｅＮＢ２００に送信することができる。

第１実施形態において、ＵＥ１００の制御部１３０は、ＣＥレベル通知を送信してから所定時間が経過するまで、次のＣＥレベル通知の送信を禁止してもよい。ＵＥ１００の制御部１３０は、ＣＥレベル通知を送信してから所定時間が経過した後、次のＣＥレベル通知の送信を可能にしてもよい。当該所定時間は、例えば設定情報中でｅＮＢ２００からＵＥ１００に設定されてもよい。これにより、同一のＵＥ１００が連続的にＣＥレベル通知を送信することを防止することができる。

第１実施形態において、ＵＥ１００の制御部１３０は、受信状態（例えば、ＲＳＲＰ）が閾値よりも良好であることに応じて、ＣＥレベル通知の送信を禁止してもよい。ＵＥ１００の制御部１３０は、受信状態が閾値よりも劣悪であることに応じて、ＣＥレベル通知の送信を可能にしてもよい。ｅＮＢ２００は、ブロードキャストシグナリング（例えば、ＳＩＢ）により閾値をＵＥ１００に設定してもよい。閾値は、強化カバレッジのための第２のセル選択基準に含まれる閾値であってもよいし、他の閾値であってもよい。言い換えると、強化カバレッジに居るＵＥ１００のみを対象としてＣＥレベル通知の送信を可能にしてもよいし、所定のＣＥレベル以下のＵＥ１００のみを対象としてＣＥレベル通知の送信を可能にしてもよい。

図１３は、第１実施形態の動作パターン１の一例を示す図である。ＵＥ１００は、ＲＲＣアイドル状態である。また、ＵＥ１００は、強化カバレッジに居るＵＥ、すなわち、カバレッジ強化技術（強化カバレッジモード）を用いることが必要とされるＵＥである。

図１３に示すように、ステップＳ１０１において、ｅＮＢ２００は、複数のＵＥ１００がＣＥレベル通知の送信に共通に用いるべき共通リソースを示す設定情報を送信する。設定情報は、ブロードキャスト又はマルチキャストで送信される。例えば、ｅＮＢ２００（送信部２１０）は、ＳＩＢ、ＳＣ−ＭＣＣＨ、又はＭＣＣＨを用いて設定情報を送信する。設定情報は、共通リソース（時間リソース、周波数リソース、及び／又は信号系列）を示すパラメータを含む。共通リソースは、ＣＥレベルごとに確保されてもよい。設定情報は、ＣＥレベル通知の送信電力を制御するための電力制御パラメータをさらに含んでもよい。時間リソースパラメータは、システムフレーム番号（ＳＦＮ）を示す情報、サブフレームを示す情報（ビットマップ）等を含んでもよい。周波数リソースパラメータは、リソースブロックの始点又は終点を示す情報、連続するリソースブロックの範囲（リソースブロック数）を示す情報等を含んでもよい。設定情報は、共通リソースが提供される期間（又は、開始時間／終了時間）を含んでもよい。当該期間は、秒として定義されてもよく、フレーム番号（ＳＦＮ、サブフレーム等）で定義されてもよい。当該期間は、予め決められた値（例えば、１０サブフレーム期間等）であってもよい。当該期間が存在する場合、ＵＥ１００は、当該期間内においてＣＥレベル通知を送信する。言い換えると、ＵＥ１００は、当該期間の経過後はＣＥレベル通知を送信しない。

ステップＳ１０２において、ｅＮＢ２００は、ＣＥレベル通知の送信を要求する通知要求を送信する。通知要求は、ブロードキャスト又はマルチキャストで送信される。例えば、ｅＮＢ２００（送信部２１０）は、システム情報ブロック（ＳＩＢ）、ＳＣ−ＭＣＣＨ、又はＭＣＣＨを用いて通知要求を送信する。通知要求は、ＣＥレベル通知の対象とする１又は複数のＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）を含んでもよい。通知要求は、ＲＲＣアイドル状態のＵＥ１００を対象とすることを示す情報を含んでもよい。

なお、ステップＳ１０２は、ステップＳ１０１の前に行われてもよい。或いは、ステップＳ１０２は、ステップＳ１０１と同時に行われてもよい。この場合、通知要求及び設定情報は、１つのメッセージに含まれてもよい。

ＵＥ１００は、通知要求及び設定情報を受信する。

ステップＳ１０３において、ＵＥ１００は、通知要求の受信に応じて、自身がＭＢＭＳサービスの受信に興味を持つか否かを判断してもよい。一例として、ＭＢＭＳサービスの受信を開始するよう上位レイヤから設定されている場合、自身がＭＢＭＳサービスの受信に興味を持つと判断する。ＭＢＭＳサービスの受信に興味を持たない場合、ＵＥ１００は、ＣＥレベル通知をｅＮＢ２００に送信しなくてもよい。ここでは、ＵＥ１００がＭＢＭＳサービスの受信に興味を持つと仮定して説明を進める。また、ＣＥレベル通知の対象とするＭＢＭＳサービスが指定されている場合、ＵＥ１００は、指定されたＭＢＭＳサービスと自身が興味を持つＭＢＭＳサービスとが一致するか否かを判断してもよい。指定されたＭＢＭＳサービスと自身が興味を持つＭＢＭＳサービスとが一致しない場合、ＵＥ１００は、ＣＥレベル通知をｅＮＢ２００に送信しなくてもよい。

ステップＳ１０４において、ＵＥ１００は、設定情報に基づいて、共通リソースに含まれるリソース（時間リソース、周波数リソース、及び／又は信号系列）を選択する。ＵＥ１００は、自身のＣＥレベルに対応するリソースを共通リソースの中から選択してもよい。

ステップＳ１０５において、ＵＥ１００は、選択されたリソースを用いて、ＣＥレベル通知をｅＮＢ２００に送信する。ＣＥレベル通知は、ＵＥ１００のＣＥレベルを示す情報及び／又はＵＥ１００が受信に興味を持つＭＢＭＳサービスを示す情報（ＴＭＧＩ）を含んでもよい。ここで、ＵＥ１００は、ＲＲＣアイドル状態であっても、共通リソースを用いてＣＥレベル通知をｅＮＢ２００に送信可能である。

ｅＮＢ２００は、ＣＥレベル通知を受信する。なお、複数のＵＥ１００間でリソースの衝突が発生した場合、ｅＮＢ２００は、当該リソースを用いて送信されたＣＥレベル通知の復号に失敗し得る。これに対し、リソース衝突が発生しない場合、ｅＮＢ２００は、ＣＥレベル通知の復号に成功する。ｅＮＢ２００は、ＣＥレベル通知に基づいて、ＭＢＭＳサービスの受信に興味を持つ各ＵＥ１００のＣＥレベルを把握する。ｅＮＢ２００は、ＵＥ１００から受信したＣＥレベル通知をＭＭＥ３００及び／又はＭＣＥ１１等に転送してもよい。

ステップＳ１０６において、ｅＮＢ２００は、把握したＣＥレベルに基づいて、ＳＣ−ＰＴＭにより配信するＭＢＭＳサービスに適用する繰り返し送信回数及び／又はＭＣＳを決定する。

ステップＳ１０７において、ｅＮＢ２００は、決定した繰り返し送信回数及び／又はＭＣＳを用いて、ＭＢＭＳサービスをＳＣ−ＰＴＭにより配信する。

図１４は、第１実施形態の動作パターン２の一例を示す図である。ここでは、動作パターン１との相違点を主として説明し、重複する説明を省略する。ＵＥ１００は、ＲＲＣアイドル状態であって、強化カバレッジに居るＵＥである。

図１４に示すように、ステップＳ２０１において、ｅＮＢ２００は、複数のＵＥ１００がＣＥレベル通知の送信に共通に用いるべき共通リソースを示す設定情報を送信する。

ステップＳ２０２において、ｅＮＢ２００は、所定の繰り返し送信回数及び／又は所定のＭＣＳを用いて、ＭＢＭＳサービスをＳＣ−ＰＴＭにより配信する。受信状態が非常に劣悪なＵＥでもＭＢＭＳサービスを受信できるように、所定の繰り返し送信回数及び／又は所定のＭＣＳは、例えば最大の繰り返し送信回数及び／又は最低のＭＣＳであってもよい。最低のＭＣＳとは、最もデータレートが低く、かつ最も誤り耐性が高いＭＣＳである。

ステップＳ２０３において、ＵＥ１００は、ＳＣ−ＰＴＭにより配信されるＭＢＭＳサービスの受信を開始する。ここで、「ＭＢＭＳサービスの受信を開始する」とは、ＭＢＭＳサービス（ＳＣ−ＰＴＭ）のための制御情報及び／又はデータの受信を開始することを意味する。よって、ＳＣ−ＭＴＣＨの受信を開始することに限らず、ＳＣ−ＭＣＣＨの受信を開始することであってもよいし、ＳＩＢ２０の受信を開始することであってもよい。

ステップＳ２０４において、ＵＥ１００は、自身が興味を持つＭＢＭＳサービスを正常に受信できるか否かを判断する。一例として、ＵＥ１００は、自身が興味を持つＭＢＭＳサービスに属するデータを運搬するＳＣ−ＭＴＣＨの復号に失敗したことに応じて、当該ＭＢＭＳサービスを正常に受信できないと判断する。或いは、ＵＥ１００は、受信状態の指標値（例えば、ＲＳＲＰ、誤り率等）が閾値よりも劣化したことに応じて、当該ＭＢＭＳサービスを正常に受信できないと判断してもよい。

他の例として、ＵＥ１００は、自身が興味を持つＭＢＭＳサービスに属するデータを運搬するＳＣ−ＭＴＣＨの復号に成功するか否かを予測してもよい。ｅＮＢ２００は、当該予測に用いる情報をＵＥ１００に提供してもよい。ｅＮＢ２００は、当該予測に用いる情報として、ＳＣ−ＭＴＣＨ（データ）の初送の繰り返し送信回数及び／又はＭＣＳを示す情報をＳＣ−ＭＣＣＨ（ＳＣ−ＰＴＭ設定情報）中で送信してもよい。もしくは、予測に用いる情報は、ＳＣ−ＭＴＣＨ及び／又はＳＣ−ＭＣＣＨの最小繰り返し送信回数でもよい。すなわち、ｅＮＢ２００は、ＳＣ−ＰＴＭ伝送（もしくはＭＢＭＳセッション）において各パケットを、少なくとも最小繰り返し送信回数だけ繰り返し送信する事を報知する。当該報知情報により、ＵＥ１００は、強化カバレッジのレベルに応じて、当該ＳＣ−ＰＴＭ伝送を受信できるか否かを判断する事ができる。もしくは、予測に用いる情報は、ＳＣ−ＭＴＣＨ及び／又はＳＣ−ＭＣＣＨの最大繰り返し送信回数であってもよい。ＵＥ１００は、当該情報により、当該ＳＣ−ＰＴＭ伝送を受信できる見込みがあるのか否かを判断する事ができる。

他の例として、ＵＥ１００は、自身が興味を持つＭＢＭＳサービスに属する制御情報を運搬するＳＣ−ＭＣＣＨの復号に成功するか否かを予測してもよい。繰り返し送信回数及び／又はＭＣＳが異なる複数のＳＣ−ＭＣＣＨが提供される場合、ｅＮＢ２００は、ＳＣ−ＭＣＣＨとＭＢＭＳサービス（ＴＭＧＩ）との対応関係に関する情報をＳＩＢ２０中でＵＥ１００に送信する。ＵＥ１００は、ＳＩＢ２０に基づいて、自身が興味を持つＭＢＭＳサービスに属する制御情報を運搬するＳＣ−ＭＣＣＨの繰り返し送信回数及び／又はＭＣＳを特定し、当該ＳＣ−ＭＣＣＨの復号に成功するか否かを予測する。

自身が興味を持つＭＢＭＳサービスを正常に受信できないと判断した場合（ステップＳ２０４：ＹＥＳ）、ＵＥ１００は、ＣＥレベル通知を送信するための動作を行う。

ステップＳ２０５において、ＵＥ１００は、前回のＣＥレベル通知を送信してから所定時間が経過した否かを判断してもよい。一例として、ＵＥ１００は、ＣＥレベル通知の送信時又はＣＥレベル通知の送信決定時に、ｅＮＢ２００から設定されたタイマを開始させる。ＵＥ１００は、タイマの動作中は、ＣＥレベル通知の送信を禁止（無効化）する。ＵＥ１００は、タイマの満了後に、ＣＥレベル通知の送信を有効化する。

ステップＳ２０６において、ＵＥ１００は、設定情報に基づいて、共通リソースに含まれるリソース（時間リソース、周波数リソース、及び／又は信号系列）を選択する。ＵＥ１００は、自身のＣＥレベルに対応するリソースを共通リソースの中から選択してもよい。

ステップＳ２０７において、ＵＥ１００は、選択されたリソースを用いて、ＣＥレベル通知をｅＮＢ２００に送信する。ＣＥレベル通知の内容は、動作パターン１と同様であってもよい。動作パターン２において、ＣＥレベル通知は、受信できない旨を示す情報を含んでもよいし、ＮＡＣＫを含んでもよい。

ｅＮＢ２００は、ＣＥレベル通知を受信する。ｅＮＢ２００は、ＣＥレベル通知に基づいて、ＭＢＭＳサービスの受信に興味を持つ各ＵＥ１００のＣＥレベルを把握する。ｅＮＢ２００は、ＵＥ１００から受信したＣＥレベル通知をＭＭＥ３００及び／又はＭＣＥ１１等に転送してもよい。

ステップＳ２０８において、ｅＮＢ２００は、把握したＣＥレベルに基づいて、ＳＣ−ＰＴＭにより配信するＭＢＭＳサービスに適用する繰り返し送信回数及び／又はＭＣＳを変更する。そして、ｅＮＢ２００は、変更後の繰り返し送信回数及び／又はＭＣＳを用いて、ＭＢＭＳサービスをＳＣ−ＰＴＭにより配信する。

なお、ステップＳ２０４において、ＭＢＭＳ受信不可と判断した場合、ＵＥ１００の所定レイヤ（例えばＲＲＣレイヤ）は、ＵＥ１００の上位レイヤ（例えばＮＡＳレイヤ）に対して、当該ＭＢＭＳ受信が不可である事を通知してもよい。その際、所定レイヤは、受信が不可であるＭＢＭＳサービスの情報（例えばＴＭＧＩ情報）を上位レイヤに通知してもよい。或いは、ステップＳ２０４において、ＭＢＭＳ受信不可と判断した場合、ＵＥ１００は、ユニキャストによるＭＢＭＳサービス受信を行うために、ＲＲＣコネクティッド状態への遷移を試みてもよい。具体的には、ＵＥ１００は、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００に対して送信してもよい。当該ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージの送信は上位レイヤからの指示によって実施されてもよい。なお、この場合、ステップＳ２０５以降のＣＥレベル通知は行わなくてもよい。もしくは、ＵＥ１００は、ステップＳ２０１の設定情報においてＣＥレベル通知に関する情報が無い場合に、本動作を行ってもよい。

図１５は、第１実施形態に係る共通リソースの第１の例を示す図である。図１５において、時間方向の１つの区画は、１つの無線フレーム（又は１つのサブフレーム）を示す。

図１５に示すように、共通リソース（Ａ ｓｅｔ ｏｆ ｒｅｓｏｕｒｃｅｓ）は、ｅＮＢ２００の上りリンク無線リソースの一部である。一例として、共通リソースは、複数のリソースブロック（ＰＲＢ：Ｐｈｙｓｉｃａｌ Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）からなる。ＵＥ＃１乃至＃６は、ｅＮＢ２００から受信する通知要求及び設定情報に基づいて、共通リソースに含まれるリソースブロックを用いてＣＥレベル通知をｅＮＢ２００に送信する。リソースブロックは、ランダムに選択されてもよい。

図１５の例において、ＵＥ＃１がリソースブロックＡを選択し、ＵＥ＃２がリソースブロックＢを選択し、ＵＥ＃３がリソースブロックＣを選択し、ＵＥ＃４乃至＃６がリソースブロックＤを選択している。すなわち、ＵＥ＃４乃至＃６間でリソースブロックの衝突が発生している。ｅＮＢ２００は、衝突が発生したリソースブロックＤを用いて送信されたＣＥレベル通知の復号に失敗し得る。これに対し、リソースブロックＡ、Ｂ、Ｃについては衝突が発生していないため、ｅＮＢ２００は、ＵＥ＃１乃至＃３のそれぞれのＣＥレベル通知の復号に成功する。なお、ＣＥレベル通知の送信に用いるリソースブロックの数は、１つである場合に限らず、２以上の数であってもよい。ＣＥレベル通知の送信に用いるリソースブロックの数は、設定情報のパラメータの１つとしてｅＮＢ２００が設定してもよい。

図１６及び図１７は、第１実施形態に係る共通リソースの第２の例を示す図である。第２の例は、複数のＵＥ１００間でリソースの衝突が生じる可能性を低下させる例である。ＵＥ１００は、自身が発生させた乱数又は自身の固有識別子を取得する。固有識別子は、ＩＭＳＩ（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）であってもよい。或いは、固有識別子は、Ｓ−ＴＭＳＩ（ＳＡＥ−Ｔｅｍｐｏｒａｒｙ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）であってもよいし、電話番号であってもよい。或いは、固有識別子は、ｅＮＢ２００がＵＥ１００に割り当てた識別子であってもよい。ＵＥ１００は、乱数又は固有識別子に基づいて、ＣＥレベル通知の送信が許可されるか否かを判断する。ＵＥ１００は、乱数又は固有識別子に基づいて、ＣＥレベル通知の送信タイミングを決定してもよい。送信タイミングは、無線フレームを識別するシステムフレーム番号（ＳＦＮ）により定義されてもよいし、サブフレームフレームを識別するサブフレーム番号により定義されてもよい。また、ＵＥ１００は、ｅＮＢ２００から送信された所定値を受信してもよい。所定値は、乱数又は固有識別子が所定の条件を満たしたか否かを判断するための閾値又は変数であってもよい。ＵＥ１００は、乱数又は固有識別子と、所定値とに基づいて、ＣＥレベル通知の送信が許可されるか否かを判断してもよい。さらに、ＵＥ１００は、乱数又は固有識別子と、所定値とに基づいて、ＣＥレベル通知の送信タイミングを判断してもよい。

図１６に示すように、ＵＥ＃１乃至＃６のそれぞれは、自身のＣＥレベル通知の送信が許可されているか否かを判断する。図１６の例において、ＵＥ＃１、＃３、及び＃４は条件を満たすが、ＵＥ＃２、＃５、及び＃６は条件を満たさない。この場合、ＵＥ＃１、＃３、及び＃４は、共通リソース内のリソースブロックを用いてＣＥレベル通知を送信する。一方、ＵＥ＃２、＃５、及び＃６は、ＣＥレベル通知の送信が禁止される。一例として、ＵＥ１００は、乱数（０〜１の範囲）を発生させ、ｅＮＢ２００から通知された閾値（０〜１の範囲）と乱数とを比較する。ＵＥ１００は、乱数が閾値条件を満たした場合に、ＣＥレベル通知の送信が許可されていると判断し、ＣＥレベル通知の送信機能を有効化する。「乱数が閾値条件を満たす」とは、乱数が閾値条件を超えたことであってもよいし、乱数が閾値条件を下回ったことであってもよい。一方、ＵＥ１００は、乱数が閾値条件を満たさない場合に、ＣＥレベル通知の送信が許可されていないと判断し、ＣＥレベル通知の送信機能を無効化する。他の例として、ＵＥ１００は、自身のＩＭＳＩを取得し、ｅＮＢ２００から通知された変数（”Ｎ”、”Ｔ”）により定義される条件をＩＭＳＩが満たすか否かを判断する。このような条件として、「（ＩＭＳＩ） ｍｏｄ （Ｎ） ＝ （Ｔ）」という条件式を用いてもよい。当該条件式において、ＩＭＳＩそのものを用いることに代えて、ＩＭＳＩに基づく値（例えば、ＩＭＳＩ ｍｏｄ １０２４）を用いてもよい。当該条件式において、等式を用いることに代えて、不等式（＞、＜、≦、又は≧）を用いてもよい。ＵＥ１００は、ＩＭＳＩが条件を満たした場合に、ＣＥレベル通知の送信が許可されていると判断し、ＣＥレベル通知の送信機能を有効化する。一方、ＵＥ１００は、ＩＭＳＩが条件を満たさない場合に、ＣＥレベル通知の送信が許可されていないと判断し、ＣＥレベル通知の送信機能を無効化する。

図１７に示すように、ＵＥ＃１乃至＃６のそれぞれは、自身のＣＥレベル通知の送信タイミングをＩＭＳＩ（又は乱数）に基づいて決定する。図１７の例において、ＵＥ＃１及び＃２はＳＦＮ＃１をＣＥレベル通知の送信タイミングとして決定し、ＵＥ＃３及び＃４はＳＦＮ＃２をＣＥレベル通知の送信タイミングとして決定し、ＵＥ＃５及び＃６はＳＦＮ＃３をＣＥレベル通知の送信タイミングとして決定している。このように、複数のＵＥのＣＥレベル通知の送信タイミングを時間方向に分散させることができる。一例として、ＵＥ１００（制御部１３０）は、自身のＩＭＳＩを取得し、ｅＮＢ２００から通知された変数（”Ｎ”）及びＩＭＳＩにより定義される条件を満たすＳＦＮを決定する。このような条件として、「（ＩＭＳＩ） ｍｏｄ （Ｎ） ＝ （ＳＦＮ） ｍｏｄ （Ｎ）」という条件式を用いてもよい。当該条件式において、ＩＭＳＩそのものを用いることに代えて、ＩＭＳＩに基づく値（例えば、ＩＭＳＩ ｍｏｄ １０２４）を用いてもよい。ＵＥ１００は、条件を満たしたＳＦＮにおいてＣＥレベル通知を送信することを決定する。一方、ＵＥ１００は、条件を満たさないＳＦＮにおいてＣＥレベル通知を送信しないことを決定する。他の例として、ＩＭＳＩに代えて乱数を用いてもよい。

図１８は、第１実施形態に係る共通リソースの第３の例を示す図である。第３の例において、設定情報は、複数のＣＥレベルに対応する共通リソースからなる複数の共通リソースを示す。ＵＥ１００は、自身のＣＥレベルに対応する共通リソースを複数の共通リソースの中から選択し、選択した共通リソースに含まれるリソースを用いてＣＥレベル通知をｅＮＢ２００に送信する。このように、ＣＥレベルと共通リソースとを対応付ける。このような対応関係を導入することにより、ＣＥレベル通知の情報量を削減することができる。一例として、ＣＥレベル通知は、スケジューリング要求（ＳＲ）のような１ビットのフラグにより構成してもよい。ｅＮＢ２００は、共通リソースごとにＣＥレベル通知をカウントすることにより、ＭＢＭＳサービスを受信している又は受信に興味を持つ各ＵＥ１００のＣＥレベルを把握する。

図１８（ａ）に示すように、ＣＥレベル０乃至３に対応する４つの共通リソースが設定されている。ＵＥ１００は、自身のＣＥレベルに対応する共通リソースを複数の共通リソースの中から選択し、選択した共通リソースに含まれるリソースを用いてＣＥレベル通知をｅＮＢ２００に送信する。

図１８（ｂ）に示すように、複数の共通リソースのそれぞれには、ＴＭＧＩとＣＥレベルとが対応付けられていてもよい。一例として、ＴＭＧＩ＃１且つＣＥレベル０に対応する共通リソースと、ＴＭＧＩ＃１且つＣＥレベル１に対応する共通リソースと、・・・が設定される。ｅＮＢ２００は、ＴＭＧＩとＣＥレベルと共通リソースとの対応関係を示す情報を設定情報中でＵＥ１００に送信してもよい。ＵＥ１００は、自身が受信している又は受信に興味を持つＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）に対応する複数の共通リソースを選択し、当該複数の共通リソースの中から自身のＣＥレベルに対応する共通リソースをさらに選択してもよい。

（第２実施形態）
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。

第１実施形態において、ｅＮＢ２００は、ＵＥ１００から受信するＣＥレベル通知に基づいて、ＳＣ−ＰＴＭにより配信するＭＢＭＳサービスに適用する繰り返し送信回数及び／又はＭＣＳを決定していた。これに対し、第２実施形態において、ｅＮＢ２００は、ＵＥ１００から受信するＣＥレベル通知に加えて又はＣＥレベル通知に代えて、他のネットワーク装置から受信する情報に基づいて繰り返し送信回数及び／又はＭＣＳを決定する。第２実施形態に係るｅＮＢ２００は、ＭＢＭＳサービスに適用すべきＣＥレベルを示す通知を他のネットワーク装置から受信する受信部（バックホール通信部２４０）と、当該通知に基づいて、繰り返し送信を含むカバレッジ強化技術を用いてＭＢＭＳサービスを配信する制御部２３０と、を備える。他のネットワーク装置とは、ＭＭＥ３００又はＭＣＥ１１であってもよい。

図１９は、第２実施形態の動作例を示す図である。

図１９に示すように、ステップＳ３０１において、ＵＥ１００は、自身のＣＥレベルをＧＣＳ−ＡＳ３１又はＢＭ−ＳＣ２２に通知してもよい。一例として、ＵＥ１００は、自身のＣＥレベルが変化する度に、変化後のＣＥレベルを通知する。ＧＣＳ−ＡＳ３１又はＢＭ−ＳＣ２２は、ＭＢＭＳサービスを受信している又は受信に興味を持つ各ＵＥ１００のＣＥレベルを把握し、ＭＢＭＳサービスに適用するＣＥレベル（繰り返し送信回数及び／又はＭＣＳ）を決定し、決定したＣＥレベルをＭＭＥ３００又はＭＣＥ１１に通知してもよい（ステップＳ３０２）。

或いは、ステップＳ３０３において、ＵＥ１００は、自身のＣＥレベルをＭＭＥ３００又はＭＣＥ１１に通知してもよい。或いは、ステップＳ３０４において、ｅＮＢ２００は、ランダムアクセスプロシージャ時に把握したＵＥ１００のＣＥレベルをＭＭＥ３００又はＭＣＥ１１に通知してもよい。一例として、ｅＮＢ２００は、ＵＥコンテキスト解放時に、ＭＰＤＣＣＨの繰り返し送信回数（ＣＥレベル）をＭＭＥ３００に通知する。

ＭＭＥ３００又はＭＣＥ１１は、通知されたＣＥレベルに基づいて、ＭＢＭＳサービスごとのＣＥレベルを決定及び／又は管理してもよい。

ステップＳ３０５において、ＭＭＥ３００又はＭＣＥ１１は、ＭＢＭＳサービス（ＴＭＧＩ）ごとのＣＥレベルをｅＮＢ２００に通知する。一例として、ＭＭＥ３００又はＭＣＥ１１は、ＭＢＭＳサービスの配信開始又は変更のためのメッセージ（ＭＢＭＳ Ｓｅｓｓｉｏｎ Ｓｔａｒｔ／Ｍｏｄｉｆｉｃａｔｉｏｎ）等で、ＴＭＧＩ毎にＣＥレベルをｅＮＢ２００に通知する。

ステップＳ３０６において、ｅＮＢ２００は、通知されたＣＥレベルに基づいて、ＳＣ−ＰＴＭにより配信するＭＢＭＳサービスに適用する繰り返し送信回数及び／又はＭＣＳを決定又は変更する。そして、ｅＮＢ２００は、決定又は変更した繰り返し送信回数及び／又はＭＣＳを用いて、ＭＢＭＳサービスをＳＣ−ＰＴＭにより配信する。

（第３実施形態）
以下において、第３実施形態について、第１及び第２実施形態との相違点を主として説明する。

第３実施形態は、強化カバレッジに居るＲＲＣアイドル状態のＵＥ１００がＭＢＭＳ受信を行うシナリオにおいて、ＭＢＭＳサービスをＵＥ１００が継続的に受信可能とする実施形態である。

第３実施形態に係るＵＥ１００は、ＲＲＣアイドル状態においてサービングセルとして用いるセルを選択するセル再選択動作を行う制御部１３０を備える。繰り返し送信を含むカバレッジ強化技術がＵＥ１００に必要とされる場合（すなわち、ＵＥ１００が強化カバレッジに居る場合）、制御部１３０は、無線品質に基づくランキングによりセルを選択する。

具体的には、ＵＥ１００は、現在のサービングセルがカバレッジ強化技術を用いなければアクセスできない場合に、同一周波数（ｉｎｔｒａ−ｆｒｅｑｕｅｎｃｙ）及び別の周波数（ｉｎｔｅｒ−ｆｒｅｑｕｅｎｃｙ）について、強化カバレッジのための“Ｓ−ｃｒｉｔｅｒｉａ”又は“Ｒ−ｃｒｉｔｅｒｉａ”を用いたランキングを適用する。言い換えると、強化カバレッジに居るＵＥ１００は、周波数優先度を考慮せずに、無線品質（受信レベル）が最も良好なセルを優先的に選択する。この場合の動作は、上述した「セル再選択動作の概要」の「（Ｂ２）隣接セルの周波数の優先度が現在のサービングセルの優先度と同じである」場合の動作と同様である。

しかしながら、このような方法では、ＭＢＭＳサービスが配信されない周波数又はセルをＵＥ１００が選択し得る。よって、ＭＢＭＳサービスを受信している又は受信に興味を持つＵＥ１００がＭＢＭＳサービスをＵＥ１００が継続的に受信できない虞がある。

よって、第３実施形態に係るＵＥ１００は、カバレッジ強化技術がＵＥ１００に必要とされる場合であっても、自身がＭＢＭＳサービスを受信している又は受信に興味を持つ場合には、ランキングを用いることなく、ＭＢＭＳサービスが配信される周波数に属するセルを優先的に選択する。一例として、強化カバレッジに居るＵＥ１００は、ＳＣ−ＰＴＭにより配信されるＭＢＭＳサービスの受信に興味がある場合、当該ＭＢＭＳサービスが配信される周波数（又はセル）を最高優先度と見なすとともに、ランキング動作を行わない。これにより、強化カバレッジに居るＵＥ１００であっても、ＭＢＭＳサービスを継続的に受信可能とすることができる。

第３実施形態に係る動作は、「ＭＢＭＳサービスを受信している又は受信に興味を持つＵＥは、当該ＭＢＭＳサービスが提供される周波数でキャンプする間のみ当該ＭＢＭＳサービスを受信できる場合、ＵＥが強化カバレッジに居るか否かと無関係に、当該周波数を最高優先度とみなすことができる」と規定されてもよい。或いは、第３実施形態に係る動作は、「現在のサービングセルがカバレッジ強化技術を用いなければアクセスできない場合で、かつ、ＭＢＭＳサービスを提供する最高優先度の周波数が設定されていない場合に、同一周波数（ｉｎｔｒａ−ｆｒｅｑｕｅｎｃｙ）及び別の周波数（ｉｎｔｅｒ−ｆｒｅｑｕｅｎｃｙ）について、強化カバレッジのための“Ｓ−ｃｒｉｔｅｒｉａ”又は“Ｒ−ｃｒｉｔｅｒｉａ”を用いたランキングを適用する。」と規定されてもよい。

図２０は、第３実施形態の動作例を示す図である。

図２０に示すように、ステップＳ４０１において、ＲＲＣアイドル状態のＵＥ１００は、カバレッジ強化技術が自身に必要とされるか否か（すなわち、自身が強化カバレッジに居るか否か）を判断する。

カバレッジ強化技術が自身に必要とされない場合（ステップＳ４０１：ＮＯ）、ステップＳ４０２において、ＵＥ１００は、上述した「セル再選択動作の概要」のような通常のセル再選択動作を行う。

一方、カバレッジ強化技術が自身に必要とされる場合（ステップＳ４０１：ＹＥＳ）、ステップＳ４０３において、ＵＥ１００は、ＭＢＭＳサービスを受信している又は受信に興味を持つか否かを判断する。

ＭＢＭＳサービスを受信しておらず、かつＭＢＭＳサービスの受信に興味を持たない場合（ステップＳ４０３：ＮＯ）、ステップＳ４０４において、ＵＥ１００は、周波数優先度を考慮せずに、ランキングを用いて、無線品質が最も良好なセルを優先的に選択する。

一方、ＭＢＭＳサービスを受信している又は受信に興味を持つ場合（ステップＳ４０３：ＹＥＳ）、ステップＳ４０５において、ＵＥ１００は、ランキングを行わずに、ＭＢＭＳサービスが配信される周波数に属するセルを優先的に選択する。

（その他の実施形態）
上述した実施形態において、「ＣＥレベル」を送受信するケースを主として説明したが、「ＣＥレベル」を「繰り返し送信回数」と読み替えてもよい。

上述した実施形態において、ＵＥ１００における受信状態の指標値としてＲＳＲＰを用いる一例を説明したが、ＲＳＲＰ以外の指標値を用いてもよい。一例として、ＲＳＲＱ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ Ｒｅｃｅｉｖｅｄ Ｑｕａｌｉｔｙ）又はＲＳ−ＳＩＮＲ（Ｒｅｆｅｒｅｎｃｅ Ｓｉｇｎａｌ ｓｉｇｎａｌ−ｔｏ−ｉｎｔｅｒｆｅｒｅｎｃｅ−ｐｌｕｓ−ｎｏｉｓｅ ｒａｔｉｏ）を受信状態の指標値として用いてもよい。

上述した各実施形態を別個独立に実施する場合に限らず、２以上の実施形態を組み合わせて実施してもよい。例えば、一の実施形態に係る一部の処理を他の実施形態に追加してもよい。或いは、一の実施形態に係る一部の処理を他の実施形態の一部の構成と置換してもよい。

上述した実施形態において、ＭＢＭＳサービスとしてファームウェア配信を想定していた。しかしながら、グループメッセージ配信、グループチャットメッセージ配信、ウィルス定義ファイルの配信、天気予報のような定期更新ファイルの配信、ニュース速報のような不定期ファイル配信、映像コンテンツ等の夜間ファイル配信（オフピーク配信）、音声／映像ストリーミング配信、電話／ビデオ電話（グループ通信）、ライブ映像配信、ラジオ音声配信等のＭＢＭＳサービスを想定してもよい。

上述した実施形態において、移動通信システムとしてＬＴＥシステムを例示した。しかしながら、本発明はＬＴＥシステムに限定されない。ＬＴＥシステム以外の移動通信システムに本発明を適用してもよい。

（付記）
（１．はじめに）
ＦｅＭＴＣとｅＮＢ−ＩｏＴのマルチキャスト拡張に関する議論が開始され、以下のように合意に達した。

Ｒｅｌ−１３ ＳＣ−ＰＴＭアーキテクチャは、ＮＢ−ＩｏＴおよびＭＴＣのマルチキャスト設計に想定されている。

ＲＡＮ２は、ＰＤＣＣＨによってＳＣ−ＭＴＣＨがスケジューリングされるレガシーＳＣ−ＭＴＣＨメカニズムが、ＮＢ−ＩｏＴおよびＭＴＣのマルチキャストに再利用され、柔軟なスケジューリングを達成すると想定する。

ＲＡＮ２は、ＮＢ−ＩｏＴおよびＭＴＣにおけるマルチキャストのためにＳＣ−ＭＴＣＨ送信の繰り返しが導入されると想定する。

ＣＥレベル情報（例えば、繰り返し）は、ＳＣ−ＭＴＣＨのためのＡＳ構成の１つである。

この付記では、強化カバレッジ（ＣＥ）をサポートするマルチキャスト強化の内部について説明する。

（２．検討）
（２．１．ＣＥレベルの情報ハンドリング）
「Ｒｅｌ−１３ ＳＣ−ＰＴＭアーキテクチャは、ＮＢ−ＩｏＴおよびＭＴＣのマルチキャスト設計に想定されている」と合意したが、マルチキャスティングのＣＥレベル、すなわち、繰り返し回数などを決定する責任がどのエンティティによってハンドルされるか結論されていない。いくつかのオプションがある。

ＧＣＳ ＡＳ：ＧＣＳ ＡＳは、ＵＥ位置の知識、すなわちセルＩＤのリストを含むＧＣＳセッションおよびグループ管理をハンドルする。従って、各セル内の各ＵＥのＣＥレベルの管理を追加することが可能であり、ＣＮの影響が予見され得る（例えば、ＧＣＳ ＡＳとＢＭ−ＳＣとの間のＭＢ２）。

ＭＭＥ：ＭＭＥは、開始／停止などのＭＢＭＳセッション管理の責任を負っている。Ｒｅｌ−１３ページングの最適化のために、ＵＥ Ｃｏｎｔｅｘｔ Ｒｅｌｅａｓｅが処理されるときに、ＭＭＥは、特定のＵＥのＣＥレベル、すなわち、ｍｐｄｃｃｈ−ＮｕｍＲｅｐｅｔｉｔｉｏｎを含むＵＥＰａｇｉｎｇＣｏｖｅｒａｇｅＩｎｆｏｒｍａｔｉｏｎについてｅＮＢによって通知される。情報は、ＲＲＣ ＩＤＬＥにおけるＵＥモビリティの場合には有効性が保証されていないが、再利用されてもよい。

ＭＣＥ：ＭＣＥは、ＭＢＭＳセッション制御を決定する。ＳＣ−ＰＴＭの場合、ＭＢＭＳベアラのセルＩＤおよびＱｏＳのリストは、例えば、ＭＢＭＳセッション開始要求を介してｅＮＢに通知される。したがって、セル単位でＣＥレベルの管理を追加することは可能ですが、ＲＡＮの仕様には影響がある。

ｅＮＢ：ｅＮＢは、無線リソースを詳細に管理する。ｅＮＢは、各ＲＲＣ ＣｏｎｎｅｃｔｅｄのＵＥに対するＣＥレベルを有するが、ＲＲＣ ＩＤＬＥのＵＥに対するＣＥレベルを有しないかもしれない。また、ＣＥレベルは、（ＭＯ呼のために）ＰＲＡＣＨが送信される時、又は（ＭＴ呼のために）ページングが開始される時にのみ通知される。したがって、ｅＮＢは、ＲＲＣ ＩＤＬＥまたは移動性のＵＥなど、ＳＣ−ＰＴＭに興味を持つＵＥのＣＥレベルの完全な知識を持っていない。ＲＡＮ２がＲｅｌ−１３ ＳＣ−ＰＴＭの原則、すなわち、「スケジューリングはｅＮＢによって行われる」に従うならばｅＮＢが責任を持つべきである。

各オプションには長所と短所があるが、この時点ではＳＣ−ＰＴＭのＣＥレベルの決定に関する完全な知識を有するオプションはない。ＣＥレベルがＲＡＮ由来の情報であることを考慮すると、不要なクロスレイヤ相互作用を避けるために、ＲＡＮノード内で処理することが望ましい。例えば、ＧＣＳ ＡＳまたはＭＭＥのいずれかがＵＥのＣＥレベル情報を受信したとしても、ＳＣ−ＰＴＭ送信の設定はｅＮＢによって決定されるため、ｅＮＢと調整する必要がある。一方、ｅＮＢがＣＥレベルの情報を受信した場合、この情報は、コアネットワークまたはアプリケーションレイヤに対して透過的になる。また、ＣＥレベルがＵＥのモビリティによって動的に変更されると仮定すべき場合、ｅＮＢは、スケジューリングのためにＣＥレベルを処理するためにわずかに優先されるノードである。

提案１：ＳＣ−ＰＴＭのＣＥレベルは、ＲＡＮノード、好ましくはｅＮＢによって決定されるべきである。

上述したように、エンティティは、Ｒｅｌ−１４マルチキャスト拡張のためのＣＥレベルについての十分な知識を有することができない。したがって、特定のＭＢＭＳサービスのＣＥレベルを決定する方法が問題になる。いくつかの潜在的なアプローチが考えられる。

ＵＥからの報告に基づく：どのエンティティが決定するかにかかわらず、ＵＥが位置するＣＥレベルの報告、例えばＧＣ１を介した報告は、正確／動的決定、すなわち適切な繰り返し回数及びアダプティブＭＣＳに対して有用である。しかしながら、ＲＡＮ２に指摘されているように、ＵＥがＣＥレベルが変化するたびに報告する必要がある場合、それは過剰なオーバヘッドを引き起こす可能性がある。また、報告によるＵＥの電力消費が問題となる可能性がある。

ブラインド決定：エンティティは、例えば、最悪の場合を想定するために、ブラインド的にＳＣ−ＰＴＭのＣＥレベルを決定することができる。これは、最大繰り返し回数と最低ＭＣＳでＳＣ−ＰＴＭを送信する簡単な方法であり、この時点ではベースラインになる可能性がある。加えて、ＣＥの繰り返しは、通常のカバレッジにおけるＵＥのより強固な受信を保証する。しかしながら、それはＳＣ−ＰＴＭからの十分な利益を取らない、すなわち、静的／控えめのスケジューリングによってスペクトル効率が低い。さらに、ＵＥは、ＳＣ−ＰＴＭ受信の長い持続時間のために、実際に必要とする以上にバッテリを消費し得る。すなわち、セル中心のＵＥが短い期間で高いＭＣＳで実際ファイルを受信することができても、低いＭＣＳは、すべてのＵＥにファイルを配信するためにより多くのサブフレームを必要とする。

新たな報告が指定された場合、過剰なオーバヘッド及び追加のＵＥ消費を避けるために、ＵＬシグナリングの数を最小限に抑える必要がある。

最初のＣＥレベル決定の可能性の１つは、ｅＮＢは、ＭＢＭＳサービスが既存のＭＢＭＳカウント手順のように、強化カバレッジで受信されるかどうか一度だけＵＥに問い合わせることである。ＩＤＬＥのＵＥも報告を送信する必要がある場合は、ＲＲＣ Ｃｏｎｎｅｃｔｅｄへの移行なしで処理する方がよい。この意味で、どのＵＥが報告を送信するかをｅＮＢが決定する必要がないと仮定すると、ＲＡＣＨ手順中の既存のＣＥレベル報告は、アプローチの１つと考えることができる。

ＳＣ−ＰＴＭ中のＣＥレベル変更の別の可能性は、ＵＥがもはやＳＣ−ＰＴＭを成功に受信できなくなったときにのみ報告が開始されることである。提案されているように、これを再送のためのフィードバック方式内に統合してもよい。

しかし、技術的な観点から、優れたアプローチではないにもかかわらず、このＷＩに割り当てられた時間単位の制限のために、このリリースおけるブラインド決定に依存することも考えられる。

提案２：ＲＡＮ２は、最小ＵＬシグナリングとＷＩに割り当てられた時間単位を考慮して、ＣＥレベルの報告を考慮する必要がある。

（２．２．セル再選択）
現在のアイドルモード手順によれば、ＭＢＭＳサービスに興味を持つ又は受信しているＵＥは、他の周波数よりもＳＣ−ＰＴＭを提供する周波数を優先させ得る、すなわち、最高優先度として考慮する。一方、「強化カバレッジ用のセル選択基準Ｓでのランキングは、現在のサービングセルが強化カバレッジを用いてのみアクセス可能である場合に周波数内および周波数間セル再選択に適用される」と指定されており、ＵＥが強化カバレッジ内にある場合は、すべての周波数を等しい優先度とみなす。強化カバレッジにおけるＳＣ−ＰＴＭ受信がＲｅｌ−１３で明確に定義されていないので、現在の仕様により、強化カバレッジ内のＵＥは、通常のカバレッジで行われるようにＳＣ−ＰＴＭ周波数を優先させることができることを明確にすべきである。また、ＲＡＮ２は、優先度の高いコンセプトを持つ仕様に注釈を追加するか、ランキングメカニズムを強化するなど、いくつかの小さな強化が必要かどうかについて議論すべきである。

提案３：ＲＡＮ２は、強化カバレッジ内のＵＥが、興味のあるマルチキャストサービスを提供する周波数を優先させることができるか否かについて議論し、明確にするべきである。

米国仮出願第６２／４０２１６１号（２０１６年９月３０日出願）の全内容が、参照により、本願明細書に組み込まれている。

本発明は移動通信分野において有用である。

Claims (5)

1. 移動通信システムのための無線端末であって、
   繰り返し送信を含むカバレッジ強化技術を用いて基地局から配信されるＭＢＭＳサービスを受信する受信部と、
   所定のイベントが発生したか否かを判断する制御部と、
   前記所定のイベントが発生したことに応じて、前記無線端末が必要とするカバレッジ強化レベルに関する通知を前記基地局に送信する送信部と、を備え、
   前記所定のイベントは、前記通知の送信を前記基地局から要求されたこと、又は前記ＭＢＭＳサービスを正常に受信できないことであり、
   前記受信部は、前記通知を送信するために複数の無線端末が共用する共通リソースを示す設定情報を前記基地局からさらに受信し、
   前記送信部は、前記共通リソースを用いて前記通知を前記基地局に送信する
   無線端末。
2. 移動通信システムのための無線端末であって、
   繰り返し送信を含むカバレッジ強化技術を用いて基地局から配信されるＭＢＭＳサービスを受信する受信部と、
   所定のイベントが発生したか否かを判断する制御部と、
   前記所定のイベントが発生したことに応じて、前記無線端末が必要とするカバレッジ強化レベルに関する通知を前記基地局に送信する送信部と、を備え、
   前記所定のイベントは、前記通知の送信を前記基地局から要求されたこと、又は前記ＭＢＭＳサービスを正常に受信できないことであり、
   前記制御部は、前記通知を送信してから所定時間が経過するまで、次の通知の送信を禁止し、
   前記制御部は、前記通知を送信してから前記所定時間が経過した後、前記次の通知の送信を可能にする
   無線端末。
3. 前記受信部は、前記ＭＢＭＳサービスの受信開始前において、前記通知の送信を要求する通知要求を前記基地局から受信し、
   前記送信部は、前記通知要求の受信に応じて、前記通知を前記基地局に送信する
   請求項１又は２に記載の無線端末。
4. 前記制御部は、前記ＭＢＭＳサービスの受信開始後において、前記ＭＢＭＳサービスを正常に受信できるか否かを判断し、
   前記送信部は、前記ＭＢＭＳサービスを正常に受信できないと判断されたことに応じて、前記通知を前記基地局に送信する
   請求項１又は２に記載の無線端末。
5. 前記制御部は、前記受信状態が閾値よりも良好であることに応じて、前記通知の送信を禁止し、
   前記制御部は、前記受信状態が前記閾値よりも劣悪であることに応じて、前記通知の送信を可能にする
   請求項１又は２に記載の無線端末。

Images