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

Description

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

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

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

一実施形態に係る無線端末は、ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートする移動通信システムのための無線端末である。無線端末は、基地局からＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報を間欠的に監視する制御部と、前記ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更され得るＳＣ−ＭＣＣＨ変更周期を示す情報を前記基地局から受信する受信部と、を備える。前記ＳＣ−ＭＣＣＨ変更周期は、複数の無線フレームからなるハイパーフレーム以上の時間長を有する。前記制御部は、前記ＳＣ−ＭＣＣＨ変更周期に基づいて、ＳＣ−ＭＣＣＨ変更境界に対応するハイパーフレーム番号及びフレーム番号を、（１０２４×Ｈ−ＳＦＮ＋ＳＦＮ） ｍｏｄ Ｍ ＝ ０により決定する。前記「Ｈ−ＳＦＮ」は前記ＳＣ−ＭＣＣＨ変更境界に対応するハイパーフレーム番号を示し、前記「ＳＦＮ」は前記ＳＣ−ＭＣＣＨ変更境界に対応するフレーム番号を示し、前記「Ｍ」は前記ＳＣ−ＭＣＣＨ変更周期を示す。

一実施形態に係る基地局は、ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートする移動通信システムのための基地局である。基地局は、ＳＣ−ＭＣＣＨを介してＭＢＭＳ制御情報を無線端末に送信する送信部と、前記ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更され得るＳＣ−ＭＣＣＨ変更周期を示す情報を前記無線端末に通知する制御部と、を備える。前記ＳＣ−ＭＣＣＨ変更周期は、複数の無線フレームからなるハイパーフレーム以上の時間長を有する。ＳＣ−ＭＣＣＨ変更境界は、（１０２４×Ｈ−ＳＦＮ＋ＳＦＮ） ｍｏｄ Ｍ ＝ ０により決定される。前記「Ｈ−ＳＦＮ」は前記ＳＣ−ＭＣＣＨ変更境界に対応するハイパーフレーム番号を示し、前記「ＳＦＮ」は前記ＳＣ−ＭＣＣＨ変更境界に対応するフレーム番号を示し、前記「Ｍ」は前記ＳＣ−ＭＣＣＨ変更周期を示す。

一実施形態に係る無線端末は、ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートする移動通信システムのための無線端末である。無線端末は、基地局からＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを受信する受信部と、制御部と、を備える。前記受信部は、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信する。前記制御部は、前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断する。

一実施形態に係る基地局は、ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートする移動通信システムのための基地局である。基地局は、ＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを送信する送信部を備える。前記送信部は、さらに、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記無線端末に送信する。

実施形態に係るＬＴＥシステムの構成を示す図である。 実施形態に係るＭＢＭＳに係るネットワーク構成を示す図である。 実施形態に係るＵＥ（無線端末）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 実施形態に係るＳＣ−ＰＴＭの動作例を示す図である。 実施形態に係るＳＩＢ２０を示す図である。 実施形態に係るＳＣ−ＭＣＣＨ中のＭＢＭＳ制御情報を示す図である。 実施形態に係るｅＭＴＣ ＵＥ向けの下りリンク物理チャネルを示す図である。 ｅＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥ向けのランダムアクセスプロシージャを示す図である。 第１実施形態に係るＵＥの動作フロー例を示す図である。 第１実施形態の動作パターン１を示す図である。 第１実施形態の動作パターン２を示す図である。 ハイパーフレーム、無線フレーム、及びサブフレームの関係を示す図である。 第２実施形態に係るＵＥの動作フロー例を示す図である。 第２実施形態の動作パターン１を示す図である。 第２実施形態の動作パターン２を示す図である。 第２実施形態の動作パターン３を示す図である。 第３実施形態に係るＵＥの動作フロー例を示す図である。 第３実施形態の動作パターン１を示す図である。 第３実施形態の動作パターン２を示す図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。 付記に係る図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（第１実施形態）
上述したような移動通信システムを前提として、以下において、第１実施形態について説明する。第１実施形態は、ＲＲＣアイドル状態のＵＥ１００に対して、ＳＣ−ＰＴＭを用いたＭＢＭＳによりファームウェア等の一括配信を行うシナリオを想定する。ＵＥ１００は、上述した新たなカテゴリのＵＥであってもよい。

第１実施形態において、ｅＮＢ２００（送信部２１０）は、ＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介してＭＢＭＳ信号を周期的にＵＥ１００に送信する。ＭＢＭＳ信号は、ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報（ＳＣ−ＰＴＭ設定情報）及びＳＣ−ＭＴＣＨを介して送信されるＭＢＭＳデータの少なくとも１つを含む。ＳＣ−ＭＣＣＨ及びＳＣ−ＭＴＣＨは、ＳＣ−ＰＴＭ用の論理チャネルである。ｅＮＢ２００（制御部２３０）は、ＵＥ１００がＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報をＵＥ１００に通知する。監視不要期間は、ＭＢＭＳ信号の送信周期よりも長い時間長を有してもよい。ＵＥ１００（制御部１３０）は、ｅＮＢ２００からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視する。ＵＥ１００（受信部１１０）は、通知情報をｅＮＢ２００から受信する。ＵＥ１００（制御部１３０）は、通知情報に基づいて、ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定する。ＵＥ１００（制御部１３０）は、監視不要期間においてＭＢＭＳ信号の監視を省略することができるため、ＳＣ−ＰＴＭ受信に伴うＵＥ１００の消費電力を削減することができる。

なお、第１実施形態において、ｅＮＢ２００（送信部２１０）は、自身のカバレッジを強化するための強化カバレッジ機能を用いてＭＢＭＳ信号を送信してもよい。また、ＭＢＭＳサービス（ＴＭＧＩ）ごとに強化カバレッジのレベルが異なってもよい。強化カバレッジ機能は、同一信号を繰り返し送信する繰り返し送信（Ｒｅｐｅｔｉｔｉｏｎ）を含んでもよい。繰り返し送信の回数が多いほど、カバレッジを強化することができる。強化カバレッジ機能は、送信信号の電力密度を上げる電力ブースト（Ｐｏｗｅｒ ｂｏｏｓｔｉｎｇ）を含んでもよい。一例として、送信信号の周波数帯域幅を狭くする狭帯域送信により電力密度を上げる。送信信号の電力密度を上げるほど、カバレッジを強化することができる。強化カバレッジ機能は、送信信号に用いるＭＣＳを下げる低ＭＣＳ（Ｌｏｗｅｒ ＭＣＳ）送信を含んでもよい。データレートが低く、誤り耐性の高いＭＣＳを用いて送信を行うことにより、カバレッジを強化することができる。

図１３は、第１実施形態に係るＵＥ１００の動作フロー例を示す図である。図１３に示すように、ステップＳ１１において、ＵＥ１００（受信部１１０）は、ＵＥ１００がＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報をｅＮＢ２００から受信する。通知情報は、ＭＢＭＳサービスの識別子（ＴＭＧＩ）と対応付けられていてもよい。ステップＳ１２において、ＵＥ１００（制御部１３０）は、通知情報に基づいて監視不要期間を特定する。ＵＥ１００（制御部１３０）は、自身が受信している又は受信に興味を持つＭＢＭＳサービスに対応する監視不要期間を特定してもよい。ステップＳ１３において、ＵＥ１００（制御部１３０）は、監視不要期間においてＭＢＭＳ信号の監視を省略する。ステップＳ１４において、ＵＥ１００は、監視不要期間の経過後に、ＭＢＭＳ信号を監視し、ＭＢＭＳ信号をｅＮＢ２００から受信する。

図１４は、第１実施形態の動作パターン１を示す図である。第１実施形態の動作パターン１において、通知情報は、ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報（以下、「ＳＣ−ＭＣＣＨ情報」と称する）の内容が変更される将来のタイミングを示す情報を含む。監視不要期間は、ＳＣ−ＭＣＣＨ情報の内容が変更される将来のタイミングまでの期間である。第１実施形態の動作パターン１に係る監視不要期間を「ＳＣ−ＭＣＣＨ監視不要期間」と称する。

図１４（ａ）に示すように、ｅＮＢ２００は、ＳＣ−ＭＣＣＨを介してＳＣ−ＭＣＣＨ情報を周期的に送信する。ＳＣ−ＭＣＣＨ情報の送信周期（Ｒｅｐｅｔｉｔｉｏｎ Ｐｅｒｉｏｄ）は、ＳＩＢ２０中のパラメータであるｓｃ−ｍｃｃｈ−ＲｅｐｅｔｉｔｉｏｎＰｅｒｉｏｄにより設定され、無線フレームの整数倍である。また、ｅＮＢ２００は、ＳＣ−ＭＣＣＨ変更周期（ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ）の境界において、ＳＣ−ＭＣＣＨ情報を変更し得る。ＳＣ−ＭＣＣＨ変更周期は、ＳＩＢ２０中のパラメータであるｓｃ−ｍｃｃｈ−ＭｏｄｉｆｉｃａｔｉｏｎＰｅｒｉｏｄにより設定され、無線フレームの整数倍である。図１４に示す例において、時刻ｔ０〜ｔ６の区間が１つのＳＣ−ＭＣＣＨ変更周期に相当し、時刻ｔ６〜ｔ１２の区間が次のＳＣ−ＭＣＣＨ変更周期に相当する。

ｅＮＢ２００は、ＳＣ−ＭＣＣＨ変更周期内で、送信周期（Ｒｅｐｅｔｉｔｉｏｎ Ｐｅｒｉｏｄ）ごとに同一のＳＣ−ＭＣＣＨ情報を送信し得る。ｅＮＢ２００は、あるＳＣ−ＭＣＣＨ変更周期のＳＣ−ＭＣＣＨ情報を変更する場合、当該ＳＣ−ＭＣＣＨ変更周期内でＳＣ−ＭＣＣＨに用いられる所定のサブフレームにおいて変更通知（ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ）をＵＥ１００に送信する。ＳＣ−ＰＴＭ受信に興味を持つＵＥ１００は、ｅＮＢ２００から変更通知を受信すると、当該ＳＣ−ＭＣＣＨ変更周期内で新たなＳＣ−ＭＣＣＨ情報を取得する。ＵＥ１００は、新たなＳＣ−ＭＣＣＨ情報を取得するまでは、既に取得した以前のＳＣ−ＭＣＣＨ情報を適用する。ＳＣ−ＭＣＣＨ情報が変更されない場合には、ＵＥ１００は、ＳＣ−ＭＣＣＨの監視を省略する（例えば、受信機をオフにする）ことにより、消費電力を削減することができる。

しかしながら、このような変更通知（ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ）を用いる方法では、ＵＥ１００は、各ＳＣ−ＭＣＣＨ変更周期内で少なくとも１回は受信を行う必要がある。

第１実施形態の動作パターン１において、ｅＮＢ２００（制御部２３０）は、ＳＣ−ＭＣＣＨ情報が次に変更されるタイミングを示すタイミング情報を含む通知情報をＵＥ１００に通知する。ｅＮＢ２００（制御部２３０）は、ＢＣＣＨ（ＳＩＢ２０）に通知情報を含めてもよいし、ＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）に通知情報を含めてもよい。タイミング情報は、ＳＣ−ＭＣＣＨ情報の変更タイミングを直接的に示す情報であってもよいし、現在のタイミングを基準として当該変更タイミングを相対的に示す情報であってもよい。タイミング情報は、無線フレーム（ＳＦＮ：Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）単位、ハイパーフレーム（Ｈ−ＳＦＮ：Ｈｙｐｅｒ Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）単位、又はＳＣ−ＭＣＣＨ変更周期単位で指定されてもよい。ＵＥ１００は、通知情報を受信したタイミングから当該変更タイミングまでの期間をＳＣ−ＭＣＣＨ監視不要期間として特定する。

図１４に示す例において、ｅＮＢ２００は、時刻ｔ０〜ｔ６のＳＣ−ＭＣＣＨ変更周期内の最初のタイミング（時刻ｔ０〜ｔ１）で通知情報をＵＥ１００に通知する。通知情報は、次のＳＣ−ＭＣＣＨ変更周期の経過後にＳＣ−ＭＣＣＨ情報を変更する旨のタイミング情報を含む。図１４（ｂ）に示すように、ＵＥ１００は、時刻ｔ０〜ｔ１のタイミングにおいて通知情報を受信すると、当該タイミング（時刻ｔ１）から次のＳＣ−ＭＣＣＨ変更周期の終了タイミング（時刻ｔ１２）までの期間をＳＣ−ＭＣＣＨ監視不要期間として特定し、当該ＳＣ−ＭＣＣＨ監視不要期間においてＳＣ−ＭＣＣＨの監視を省略する。よって、ＵＥ１００は、時刻ｔ６〜ｔ１２のＳＣ−ＭＣＣＨ変更周期内でＳＣ−ＭＣＣＨの監視を１回も行わなくて済む。ＵＥ１００は、ＳＣ−ＭＣＣＨ監視不要期間が経過したタイミング（時刻ｔ１２〜ｔ１３）でＳＣ−ＭＣＣＨを監視する。

ｅＮＢ２００は、ＭＢＭＳサービス（ＴＭＧＩ）ごとに通知情報をＵＥ１００に通知してもよい。この場合、ｅＮＢ２００は、通知情報中でＴＭＧＩごとにタイミング情報を通知してもよい。通知情報は、所定のＭＢＭＳサービスに対応するＴＭＧＩと、当該所定のＭＢＭＳサービスに対応するＳＣ−ＭＣＣＨ情報が次に変更されるタイミングを示すタイミング情報とを含む。通知情報は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたタイミング情報とを含んでもよい。ＵＥ１００は、通知情報を受信すると、自身が受信している又は受信に興味を持つＭＢＭＳサービス（ＴＭＧＩ）に対応するタイミング情報を通知情報から取得し、取得したタイミング情報に基づいてＳＣ−ＭＣＣＨ監視不要期間を特定する。

第１実施形態の動作パターン１において、ＳＣ−ＭＣＣＨが同一セルに複数設けられるシナリオを想定してもよい。この場合、各ＳＣ−ＭＣＣＨが１又は複数のＭＢＭＳサービス（ＴＭＧＩ）と対応付けられてもよい。各ＳＣ−ＭＣＣＨに適用される強化カバレッジのレベルが異なってもよい。複数のＴＭＧＩに対応するＳＣ−ＭＣＣＨが存在する場合、ＴＭＧＩごとにＳＣ−ＭＣＣＨ変更周期を異ならせてもよい。一例として、ｅＮＢ２００は、ＴＭＧＩと対応付けたＳＣ−ＭＣＣＨ変更周期をＳＩＢ２０中でＵＥ１００に通知する。ＳＩＢ２０は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたＳＣ−ＭＣＣＨ変更周期とを含んでもよい。ＵＥ１００は、ＳＩＢ２０を受信すると、自身が受信している又は受信に興味を持つＭＢＭＳサービス（ＴＭＧＩ）に対応するＳＣ−ＭＣＣＨ変更周期をＳＩＢ２０から取得し、取得したＳＣ−ＭＣＣＨ変更周期に基づいてＳＣ−ＭＣＣＨ監視不要期間を特定する。

図１５は、第１実施形態の動作パターン２を示す図である。

図１５（ｂ）に示すように、ｅＮＢ２００は、ＳＣ−ＭＴＣＨを周期的にスケジューリングする。ＳＣ−ＭＴＣＨのスケジューリング周期（Ｃｙｃｌｅ）及びスケジューリング開始オフセット（Ｓｔａｒｔ ｏｆｆｓｅｔ）は、ＳＣ−ＭＣＣＨ中のパラメータであるｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭにより設定され、サブフレームの整数倍である。通常、ＵＥ１００は、スケジューリング周期（Ｃｙｃｌｅ）ごとに、オン持続時間（Ｏｎ ｄｕｒａｔｉｏｎ）の間はＳＣ−ＭＴＣＨを監視する。オン持続時間は、ＳＣ−ＭＣＣＨ中のパラメータであるｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭにより設定され、サブフレームの整数倍である。ＵＥ１００は、オン持続時間内で、自身宛のＰＤＣＣＨが下りリンク送信をスケジューリングすることを検知した場合、所定時間の間はオン状態を維持し、ＳＣ−ＭＴＣＨの監視を継続する。当該所定時間は、ＳＣ−ＭＣＣＨ中のパラメータであるｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭにより設定され、サブフレームの整数倍である。このように、ＵＥ１００は、ＳＣ−ＭＣＣＨ中のパラメータに従ってＳＣ−ＭＴＣＨを間欠的に監視する。このような動作は、ＳＣ−ＰＴＭのための間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）と称される。

しかしながら、このようなＤＲＸを用いる方法では、ＵＥ１００は、スケジューリング周期（Ｃｙｃｌｅ）ごとにＳＣ−ＭＴＣＨの監視を行う必要がある。

図１５（ａ）に示す例において、ｅＮＢ２００は、ＳＣ−ＭＣＣＨを介して、ＳＣ−ＭＣＣＨ送信タイミング（時刻ｔ０〜ｔ１）で通知情報をＵＥ１００に通知する。通知情報は、所定の無線フレーム（ＳＦＮ）の経過後にＳＣ−ＭＴＣＨをスケジューリングする旨のタイミング情報を含む。通知情報は、監視を省略すべきスケジューリング周期の数（Ｎ ｃｙｃｌｅｓ）を示してもよい。監視不要期間は、ＭＢＭＳデータがスケジューリングされる将来のタイミングまでの期間である。第１実施形態の動作パターン２に係る監視不要期間を「ＳＣ−ＭＴＣＨ監視不要期間」と称する。

ｅＮＢ２００（制御部２３０）は、ＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）に通知情報を含める。或いは、ｅＮＢ２００（制御部２３０）は、ＢＣＣＨ（ＳＩＢ２０）に通知情報を含めてもよい。タイミング情報は、ＳＣ−ＭＴＣＨ情報のスケジューリングタイミングを直接的に示す情報であってもよいし、現在のタイミングを基準として当該スケジューリングタイミングを相対的に示す情報であってもよい。タイミング情報は、無線フレーム（ＳＦＮ）単位、ハイパーフレーム（Ｈ−ＳＦＮ）単位、サブフレーム単位、スケジューリング周期単位で指定されてもよい。

図１５（ｃ）に示すように、ＵＥ１００は、時刻ｔ０〜ｔ１のタイミングにおいて通知情報を受信すると、当該タイミング（時刻ｔ１）からＳＣ−ＭＴＣＨスケジューリングタイミング（時刻ｔ８）までの期間をＳＣ−ＭＴＣＨ監視不要期間として特定し、当該ＳＣ−ＭＴＣＨ監視不要期間においてＳＣ−ＭＴＣＨの監視を省略する。よって、ＵＥ１００は、時刻ｔ１〜ｔ８の間はＳＣ−ＭＴＣＨの監視を１回も行わなくて済む。ＵＥ１００は、ＳＣ−ＭＴＣＨ監視不要期間が経過したタイミングのオン持続時間（時刻ｔ８〜ｔ９）でＳＣ−ＭＴＣＨを監視する。また、ＵＥ１００は、オン持続時間（時刻ｔ８〜ｔ９）中に、自身宛の下りリンク送信のスケジューリングを示すＰＤＣＣＨを検知し、時刻ｔ１０までＳＣ−ＭＴＣＨの監視を継続する。

ｅＮＢ２００は、ＭＢＭＳサービス（ＴＭＧＩ）ごとに通知情報をＵＥ１００に通知してもよい。この場合、ｅＮＢ２００は、通知情報中でＴＭＧＩごとにタイミング情報を通知してもよい。通知情報は、所定のＭＢＭＳサービスに対応するＴＭＧＩと、当該所定のＭＢＭＳサービスに対応するＳＣ−ＭＴＣＨが次にスケジューリングされるタイミングを示すタイミング情報とを含む。通知情報は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたタイミング情報とを含んでもよい。ＵＥ１００は、通知情報を受信すると、自身が受信している又は受信に興味を持つＭＢＭＳサービス（ＴＭＧＩ）に対応するタイミング情報を通知情報から取得し、取得したタイミング情報に基づいてＳＣ−ＭＴＣＨ監視不要期間を特定する。

第１実施形態の動作パターン２において、ｅＮＢ２００（制御部２３０）は、ＳＣ−ＭＴＣＨ（ＭＢＭＳデータ）がスケジューリングされる将来のタイミングを示す通知情報をＵＥ１００に通知する。当該将来のタイミングは、ＳＣ−ＭＴＣＨのスケジューリング開始タイミング（すなわち、ＵＥ１００がＳＣ−ＭＴＣＨの監視を開始すべきタイミング）とみなすことができる。さらに、ｅＮＢ２００（制御部２３０）は、通知情報中で、ＳＣ−ＭＴＣＨ（ＭＢＭＳデータ）のスケジューリングが終了される将来のタイミングを示してもよい。このような終了タイミングは、ＳＣ−ＭＴＣＨのスケジューリング終了タイミングを直接的に示す情報であってもよいし、スケジューリング開始タイミングを基準として当該スケジューリング終了タイミングを相対的に示す情報（期間情報）であってもよい。スケジューリング終了タイミングの情報は、無線フレーム（ＳＦＮ）単位、ハイパーフレーム（Ｈ−ＳＦＮ）単位、サブフレーム単位、スケジューリング周期単位で指定されてもよい。ＵＥ１００は、スケジューリング開始タイミングからスケジューリング終了タイミングまでの期間をＳＣ−ＭＴＣＨ監視必要期間として特定する。

（第２実施形態）
第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態は、第１実施形態と同様に、ＲＲＣアイドル状態のＵＥ１００がＳＣ−ＰＴＭにより配信されるＭＢＭＳサービスを受信するケースを主として想定する。ＵＥ１００は、上述した新たなカテゴリのＵＥであってもよい。

第１実施形態において、ＳＣ−ＭＣＣＨが無線フレーム単位でスケジューリングされ、ＳＣ−ＭＴＣＨがサブフレーム単位でスケジューリングされる一例を説明した。第２実施形態においては、ＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨがハイパーフレーム単位でスケジューリングされる。ＵＥ１００は、ＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨがスケジューリングされないハイパーフレームにおいてＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨの監視を省略することができる。

図１６は、ハイパーフレーム、無線フレーム、及びサブフレームの関係を示す図である。図１６に示すように、１つの無線フレーム（Ｒａｄｉｏ ｆｒａｍｅ）は、１０個のサブフレーム（Ｓｕｂｆｒａｍｅ）により構成される。サブフレームは、０番から９番までのサブフレーム番号により識別される。１つのハイパーフレーム（Ｈｙｐｅｒ ｆｒａｍｅ）は、１０２４個の無線フレームにより構成される。無線フレームは、０番から１０２３番までのシステムフレーム番号（ＳＦＮ：Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）により識別される。ハイパーフレームは、ハイパーフレーム番号（Ｈ−ＳＦＮ：Ｈｙｐｅｒ Ｓｙｓｔｅｍ Ｆｒａｍｅ Ｎｕｍｂｅｒ）により識別される。各セルは、現在のＨ−ＳＦＮを報知する。

第２実施形態に係るｅＮＢ２００（送信部２１０）は、ＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介してＭＢＭＳ信号をＵＥ１００に送信する。ＭＢＭＳ信号は、ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報（ＳＣ−ＰＴＭ設定情報）及びＳＣ−ＭＴＣＨを介して送信されるＭＢＭＳデータの少なくとも１つを含む。ｅＮＢ２００（制御部２３０）は、ＵＥ１００がＭＢＭＳ信号を監視すべき周期を示す周期情報をＵＥ１００に通知する。当該周期は、ＳＣ−ＭＴＣＨがスケジューリングされるＳＣ−ＭＴＣＨスケジューリング周期（ＳＣ−ＭＴＣＨ ｓｃｈｅｄｕｌｉｎｇ ｐｅｒｉｏｄ）である。或いは、当該周期は、ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更され得るＳＣ−ＭＣＣＨ変更周期（ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ）である。当該周期は、複数の無線フレームからなるハイパーフレーム以上の時間長を有する。当該周期は、ハイパーフレームの整数倍の時間長を有してもよい。周期情報は、ＭＢＭＳ信号を監視すべきハイパーフレーム番号（Ｈ−ＳＦＮ）をＵＥ１００が決定するために用いられる。

第２実施形態に係るＵＥ１００（制御部１３０）は、ｅＮＢ２００からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して送信されるＭＢＭＳ信号を間欠的に監視する。ＵＥ１００（受信部１１０）は、ＭＢＭＳ信号を監視すべき周期を示す周期情報をｅＮＢ２００から受信する。ＵＥ１００（制御部１３０）は、周期情報に基づいて、ＭＢＭＳ信号を監視すべきハイパーフレーム番号（Ｈ−ＳＦＮ）を決定する。

図１７は、第２実施形態に係るＵＥ１００の動作フロー例を示す図である。図１７に示すように、ステップＳ２１において、ＵＥ１００（受信部１１０）は、ＭＢＭＳ信号を監視すべき周期を示す周期情報をｅＮＢ２００から受信する。当該周期は、ハイパーフレームの整数倍の時間長を有する。ステップＳ２２において、ＵＥ１００（制御部１３０）は、周期情報に基づいて、ＭＢＭＳ信号を監視すべきハイパーフレーム番号（Ｈ−ＳＦＮ）を決定する。ＵＥ１００（制御部１３０）は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスの識別子（ＴＭＧＩ）と周期情報とに基づいて、ＭＢＭＳ信号を監視すべきハイパーフレーム番号（Ｈ−ＳＦＮ）を決定してもよい。ステップＳ２３において、ＵＥ１００（制御部１３０）は、決定したハイパーフレーム番号（Ｈ−ＳＦＮ）内でＭＢＭＳ信号を監視すべきフレーム番号（ＳＦＮ）及び／又はサブフレーム番号を決定する。ＵＥ１００（制御部１３０）は、周期情報に基づいて、ＭＢＭＳ信号を監視すべきハイパーフレーム番号及びフレーム番号を決定してもよい。ＵＥ１００（制御部１３０）は、ＳＩＢ２０中のパラメータに従ってＳＣ−ＭＣＣＨを監視すべきフレーム番号（ＳＦＮ）を決定してもよい。ＵＥ１００（制御部１３０）は、ＳＣ−ＭＣＣＨ中のパラメータに従ってＳＣ−ＭＴＣＨを監視すべきサブフレーム番号を決定してもよい。ステップＳ２４において、ＵＥ１００（制御部１３０）は、決定したハイパーフレーム中の無線フレーム番号及び／又はサブフレームにおいてＭＢＭＳ信号を監視（及び受信）する。

図１８は、第２実施形態の動作パターン１を示す図である。第２実施形態の動作パターン１は、ハイパーフレーム単位でＳＣ−ＭＴＣＨスケジューリング周期（ＳＣ−ＭＴＣＨ ｓｃｈｅｄｕｌｉｎｇ ｐｅｒｉｏｄ）を設定するパターンである。

図１８に示すように、ステップＳ２０１において、ＵＥ１００は、ＳＣ−ＭＴＣＨスケジューリング周期（Ｍ）をｅＮＢ２００から受信する。ＳＣ−ＭＴＣＨスケジューリング周期（Ｍ）は、ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）に含まれてもよい。ＳＣ−ＭＴＣＨスケジューリング周期（Ｍ）は、ＴＭＧＩと対応付けられていてもよい。ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたＳＣ−ＭＴＣＨスケジューリング周期（Ｍ）とを含んでもよい。

ステップＳ２０２において、ＵＥ１００は、「現Ｈ−ＳＦＮ ｍｏｄ Ｍ ＝ ＴＭＧＩ ｍｏｄ Ｍ」が満たされるか否か判定する。ここで、「現Ｈ−ＳＦＮ」は、ｅＮＢ２００から報知される現在のＨ−ＳＦＮである。「ＴＭＧＩ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスの識別子である。「Ｍ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスに属するＳＣ−ＭＴＣＨのスケジューリング周期であり、ハイパーフレームの整数倍である。

ステップＳ２０２で「ＮＯ」の場合、ステップＳ２０３において、ＵＥ１００は、現在のＨ−ＳＦＮにおいて、ＳＣ−ＭＴＣＨがスケジューリングされないと判断し、ＳＣ−ＭＴＣＨを監視しない（すなわち、スリープする）。

一方、ステップＳ２０２で「ＹＥＳ」の場合、ステップＳ２０４において、ＵＥ１００は、現在のＨ−ＳＦＮにおいてＳＣ−ＭＴＣＨを監視する。ＵＥ１００（制御部１３０）は、ＳＣ−ＭＣＣＨ中のパラメータに従ってＳＣ−ＭＴＣＨを監視すべきフレーム番号（ＳＦＮ）及び／又はサブフレーム番号を決定してもよい。

図１９は、第２実施形態の動作パターン２を示す図である。第２実施形態の動作パターン２は、ハイパーフレーム単位でＳＣ−ＭＣＣＨ変更周期（ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ）を設定するパターンである。

図１９に示すように、ステップＳ２１１において、ＵＥ１００は、ＳＣ−ＭＣＣＨ変更周期（Ｍ）をｅＮＢ２００から受信する。ＳＣ−ＭＣＣＨ変更周期（Ｍ）は、ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）に含まれてもよい。ＳＣ−ＭＣＣＨ変更周期（Ｍ）は、ＴＭＧＩと対応付けられていてもよい。ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたＳＣ−ＭＣＣＨ変更周期（Ｍ）とを含んでもよい。ＵＥ１００は、ＳＣ−ＭＣＣＨ変更周期（Ｍ）が通知される場合、ＢＣＣＨ（ＳＩＢ２０）中の従来のｓｃ−ｍｃｃｈ−ＭｏｄｉｆｉｃａｔｉｏｎＰｅｒｉｏｄ（すなわち、無線フレーム単位のＳＣ−ＭＣＣＨ変更周期）を無視してもよい。

ステップＳ２１２において、ＵＥ１００は、「現Ｈ−ＳＦＮ ｍｏｄ Ｍ ＝ ０」が満たされるか否か判定する。ここで、「現Ｈ−ＳＦＮ」は、ｅＮＢ２００から報知される現在のＨ−ＳＦＮである。「Ｍ」は、ＳＣ−ＭＣＣＨのスケジューリング周期であり、ハイパーフレームの整数倍である。「Ｍ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスに属するＳＣ−ＭＣＣＨのスケジューリング周期であってもよい。

ステップＳ２１２で「ＮＯ」の場合、ステップＳ２１３において、ＵＥ１００は、現在のＨ−ＳＦＮがＳＣ−ＭＣＣＨ変更周期の境界ではないと判断し、ＳＣ−ＭＣＣＨを監視しなくてもよい（すなわち、スリープする）。

一方、ステップＳ２１２で「ＹＥＳ」の場合、ステップＳ２１４において、ＵＥ１００は、現在のＨ−ＳＦＮがＳＣ−ＭＣＣＨ変更周期の境界であると判断し、ＳＣ−ＭＣＣＨを監視する。ＵＥ１００（制御部１３０）は、現在のＨ−ＳＦＮにおける「ＳＦＮ ｍｏｄ （ＴＭＧＩ ｍｏｄ １０２４）」により定まるＳＦＮをＳＣ−ＭＣＣＨ変更周期の境界として決定してもよい。ここで、「ＴＭＧＩ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスの識別子である。ＵＥ１００（制御部１３０）は、ＢＣＣＨ（ＳＩＢ２０）中のパラメータに従ってＳＣ−ＭＣＣＨを監視すべきフレーム番号（ＳＦＮ）及び／又はサブフレーム番号を決定してもよい。

図２０は、第２実施形態の動作パターン３を示す図である。第２実施形態の動作パターン３は、第２実施形態の動作パターン２を一部変更したパターンである。

図２０に示すように、ステップＳ２２１において、ＵＥ１００は、ＳＣ−ＭＣＣＨ変更周期（Ｍ）をｅＮＢ２００から受信する。ＳＣ−ＭＣＣＨ変更周期（Ｍ）は、ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）に含まれてもよい。ＳＣ−ＭＣＣＨ変更周期（Ｍ）は、ＴＭＧＩと対応付けられていてもよい。ＢＣＣＨ（ＳＩＢ２０）又はＳＣ−ＭＣＣＨ（ＳＣ−ＭＣＣＨ情報）は、ＴＭＧＩのリストと、各ＴＭＧＩに対応付けられたＳＣ−ＭＣＣＨ変更周期（Ｍ）とを含んでもよい。

ステップＳ２２２において、ＵＥ１００は、「（１０２４×現Ｈ−ＳＦＮ＋現ＳＦＮ） ｍｏｄ Ｍ ＝ ０」が満たされるか否か判定する。ここで、「Ｍ」は、ＳＣ−ＭＣＣＨのスケジューリング周期であり、無線フレームの整数倍であるが、１０２４以上の値（すなわち、１ハイパーフレーム以上の時間）が設定されてもよい。「Ｍ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスに属するＳＣ−ＭＣＣＨのスケジューリング周期であってもよい。

或いは、ステップＳ２２２において、「（１０２４×現Ｈ−ＳＦＮ＋現ＳＦＮ） ｍｏｄ Ｍ ＝ ０」に代えて、「（１０２４×現Ｈ−ＳＦＮ＋現ＳＦＮ） ｍｏｄ Ｍ ＝ ＴＭＧＩ ｍｏｄ Ｍ」が満たされるか否か判定してもよい。「ＴＭＧＩ」は、ＵＥ１００が受信している又は受信に興味を持つＭＢＭＳサービスの識別子である。

ステップＳ２２２で「ＮＯ」の場合、ステップＳ２２３において、ＵＥ１００は、現在のＨ−ＳＦＮ及び現在のＳＦＮがＳＣ−ＭＣＣＨ変更周期の境界ではないと判断し、ＳＣ−ＭＣＣＨを監視しなくてもよい（すなわち、スリープする）。

一方、ステップＳ２２２で「ＹＥＳ」の場合、ステップＳ２２４において、ＵＥ１００は、現在のＨ−ＳＦＮ及び現在のＳＦＮがＳＣ−ＭＣＣＨ変更周期の境界であると判断し、ＳＣ−ＭＣＣＨを監視する。

（第３実施形態）
第３実施形態について、第１及び第２実施形態との相違点を主として説明する。第３実施形態は、第１及び第２実施形態と同様に、ＲＲＣアイドル状態のＵＥ１００がＳＣ−ＰＴＭにより配信されるＭＢＭＳサービスを受信するケースを主として想定する。ＵＥ１００は、上述した新たなカテゴリのＵＥであってもよい。

第３実施形態に係るＵＥ１００（受信部１１０）は、ＲＲＣアイドル状態において、ＳＣ−ＭＴＣＨを介してｅＮＢ２００からＭＢＭＳデータを受信する。ＵＥ１００（制御部１３０）は、ＭＢＭＳデータの受信中に、ＲＲＣコネクティッド状態に遷移すべきイベントが生じたことに応じて、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する。ＵＥ１００（送信部１２０）は、ＲＲＣコネクティッド状態に遷移した後、ＲＲＣアイドル状態においてＵＥ１００が受信していたＭＢＭＳデータに対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）をｅＮＢ２００に送信する。

図２１は、第３実施形態に係るＵＥ１００の動作フロー例を示す図である。図２１に示すように、ステップＳ３１において、ＵＥ１００（受信部１１０）は、ＲＲＣアイドル状態において、ＳＣ−ＭＴＣＨを介してｅＮＢ２００からＭＢＭＳデータを受信する。ステップＳ３２において、ＵＥ１００（制御部１３０）は、ＭＢＭＳデータの受信中に、ＲＲＣコネクティッド状態に遷移すべきイベントを検知する。このようなイベントは、ページングを受信したというイベント、又はシグナリングを送信する必要が生じたというイベントであってもよい。ステップＳ３３において、ＵＥ１００（制御部１３０）は、ＲＲＣアイドル状態からＲＲＣコネクティッド状態に遷移する。ステップＳ３４において、ＵＥ１００（送信部１２０）は、ＲＲＣアイドル状態においてＵＥ１００が受信していたＭＢＭＳデータに対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）をｅＮＢ２００に送信する。

第３実施形態において、ＵＥ１００は、ＳＣ−ＰＴＭ受信中にユニキャストに関するイベントが発生した場合には、必ずユニキャストに係る動作を優先して実施する事としてもよい。例えば、ユニキャストで伝送するデータが発生した場合には、ＵＥ１００は当該データ送信を優先するとともに、必要であれば（例えば同時処理が不可能であれば）ＳＣ−ＰＴＭ受信動作を中断してもよい。

図２２は、第３実施形態の動作パターン１を示す図である。第３実施形態の動作パターン１において、ＵＥ１００（送信部１２０）は、ＭＢＭＳデータのユニキャスト再送を要求する要求信号をｅＮＢ２００に送信する。要求信号は、ＲＲＣアイドル状態においてＵＥ１００が受信していたＭＢＭＳデータに対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）を含む。ＵＥ１００（受信部１１０）は、ＲＲＣコネクティッド状態において、ｅＮＢ２００からユニキャストで送信されるＭＢＭＳデータを受信する。

図２２に示すように、ステップＳ３０１において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨを介してＭＢＭＳデータを送信する。当該ＭＢＭＳデータは、所定のＭＢＭＳサービスに属するデータである。ＵＥ１００は、ＲＲＣアイドル状態でＳＣ−ＭＴＣＨを介してＭＢＭＳデータを受信する。ｅＮＢ２００は、ＳＣ−ＭＴＣＨを介して送信したＭＢＭＳデータをＴＭＧＩと対応付けて自身のバッファに蓄積する。さらに、ｅＮＢ２００は、蓄積するＭＢＭＳデータにＨＡＲＱプロセスＩＤ、ＲＬＣシーケンス番号等のデータ識別子を対応付けてもよい。

ステップＳ３０２において、ＵＥ１００は、ＲＲＣコネクティッド状態に遷移すべきイベントを検知する。ステップＳ３０３において、ＵＥ１００は、イベントの検知に応じて、ＳＣ−ＰＴＭ受信を中断する。ステップＳ３０４において、ＵＥ１００は、ＲＲＣ接続要求メッセージをｅＮＢ２００に送信することによりｅＮＢ２００とのＲＲＣ接続を確立し、ＲＲＣコネクティッド状態に遷移する。

ステップＳ３０５において、ＲＲＣコネクティッド状態のＵＥ１００は、ＳＣ−ＰＴＭ受信の中断により未受信となったＭＢＭＳデータの再送を要求するためのＮＡＣＫ（再送要求）をｅＮＢ２００に送信する。当該ＮＡＣＫは、ＲＲＣメッセージ、ＲＬＣ Ｃｏｎｔｒｏｌ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）、又はＭＡＣ ＣＥ（Ｃｏｎｔｒｏｌ Ｅｌｅｍｅｎｔ）で送信されてもよい。ＮＡＣＫは、ＲＲＣアイドル状態においてＵＥ１００が受信していたＭＢＭＳデータに対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）を含む。ＮＡＣＫは、最後に受信した又は未受信のデータの識別子（ＨＡＲＱプロセスＩＤ、ＲＬＣシーケンス番号等）を含んでもよい。

ｅＮＢ２００は、ＮＡＣＫに基づいて、ＵＥ１００が再送を要求するＭＢＭＳデータを特定する。ｅＮＢ２００は、自身のバッファから当該ＭＢＭＳデータを読み出す。ステップＳ３０６において、ｅＮＢ２００は、ＤＴＣＨを介して、バッファから読み出したＭＢＭＳデータをＵＥ１００に送信する。ＤＴＣＨは、ユニキャスト送信用の論理チャネルである。以降、ＵＥ１００は、ＲＲＣコネクティッド状態においてＭＢＭＳデータをユニキャストで受信する。

図２３は、第３実施形態の動作パターン２を示す図である。第３実施形態の動作パターン２において、ＵＥ１００（受信部１１０）は、ＲＲＣコネクティッド状態に遷移しても、ＳＣ−ＭＴＣＨを介してｅＮＢ２００からＭＢＭＳデータの受信を継続する。

図２３に示すように、ステップＳ３１１において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨを介してＭＢＭＳデータを送信する。当該ＭＢＭＳデータは、所定のＭＢＭＳサービスに属するデータである。ＵＥ１００は、ＲＲＣアイドル状態でＳＣ−ＭＴＣＨを介してＭＢＭＳデータを受信する。

ステップＳ３１２において、ＵＥ１００は、ＲＲＣコネクティッド状態に遷移すべきイベントを検知する。動作パターン２において、ＵＥ１００は、イベントを検知しても、ＳＣ−ＰＴＭ受信を中断せずに継続してもよい。ステップＳ３１３において、ＵＥ１００は、ＲＲＣ接続要求メッセージをｅＮＢ２００に送信することによりｅＮＢ２００とのＲＲＣ接続を確立し、ＲＲＣコネクティッド状態に遷移する。

ステップＳ３１４において、ＲＲＣコネクティッド状態のＵＥ１００は、受信中ＳＣ−ＰＴＭのＴＭＧＩをｅＮＢ２００に通知する。ＵＥ１００は、ＲＲＣメッセージの一つであるＭＢＭＳ興味通知（ＭＢＭＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎ）にＴＭＧＩを含めてもよい。ＭＢＭＳ興味通知は、ＭＢＭＳを受信している又は受信に興味があることを示すメッセージである。実際にＭＢＭＳを受信していることを示すフラグをＭＢＭＳ興味通知に含めることにより、単に受信に興味がある状態（未受信の状態）ではないことを示してもよい。或いは、ＵＥ１００は、ＲＬＣ Ｃｏｎｔｒｏｌ ＰＤＵ又はＭＡＣ ＣＥ等にＴＭＧＩを含めてもよい。

また、ＵＥ１００は、受信中のＭＢＭＳサービスの属性（配信方法）をｅＮＢ２００に通知してもよい。一例として、ＭＢＭＳサービスの属性（配信方法）は、ダウンロード（Ｄｏｗｎｌｏａｄ ｄｅｌｉｖｅｒｙ ｍｅｔｈｏｄ）、ストリーミング（Ｓｔｒｅａｍｉｎｇ ｄｅｌｉｖｅｒｙ ｍｅｔｈｏｄ）、グループ通信（Ｇｒｏｕｐ ｃｏｍｍｕｎｉｃａｔｉｏｎ ｄｅｌｉｖｅｒｙ ｍｅｔｈｏｄ）等である。

ステップＳ３１５において、ｅＮＢ２００は、ＵＥ１００からの通知（及びＵＥ１００の能力等）に基づいて、ＳＣ−ＰＴＭ送信（マルチキャスト）及び当該ＵＥ１００へのユニキャスト送信をＵＥ１００が適切に受信できるようにスケジューリングを行う。一例として、ｅＮＢ２００は、ＳＣ−ＰＴＭ送信及びＵＥ１００へのユニキャスト送信を同一サブフレームにスケジューリングしない。或いは、ｅＮＢ２００は、ＳＣ−ＰＴＭ送信及びＵＥ１００へのユニキャスト送信を隣接ＲＢ（Ｒｅｓｏｕｒｃｅ Ｂｌｏｃｋ）又は同一ＮＢ（Ｎａｒｒｏｗ Ｂａｎｄ）にスケジューリングする。また、ｅＮＢ２００は、１つのサブフレームにおいてＵＥ１００へのユニキャスト送信よりもＳＣ−ＰＴＭ送信を優先してスケジューリングしてもよい。ＳＣ−ＰＴＭ送信は複数ＵＥ宛てであるため、他ＵＥへの影響を考えるとＳＣ−ＰＴＭを優先することが好ましい。ＳＣ−ＰＴＭ送信を優先する場合、ｅＮＢ２００は、ユニキャスト用のデータを一時的にバッファしてもよい。

（その他の実施形態）
ネットワーク（基地局等）は、ＭＢＭＳセッション中（もしくはファイル配信セッション中）において、既にマルチキャスト送信済みのデータと同一のデータを、再度送信する事が可能である。このような再送データは、データ送達の確実性を高める事に寄与する一方、当該データを既に受信済みのＵＥにとっては、重複した不要なデータやこれに係る制御情報を受信してしまう虞がある。よって、基地局は、次回ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄにおいて、当該データ再送が実施される場合に、ＵＥに対して通知を行う。当該通知を受信し、既に当該データを受信済みのＵＥは、当該データ（及び係る制御情報）の取得を行わなくてもよい。

上述した実施形態において、ＵＥが、ページング（又はＰ−ＲＮＴＩでマスクされたＤＣＩ）によって、ＳＣ−ＭＣＣＨの変更通知（ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎ）を受信する場合について述べていなかった。この場合、当該ＵＥには更にＤＲＸ（ページングの間欠モニタ）が設定されている事が想定される。もし、ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄが当該ＤＲＸサイクル内に複数存在する場合、当該ＵＥはＳＣ−ＭＣＣＨ ｃｈａｎｇｅ ｎｏｔｉｆｉｃａｔｉｏｎのモニタを、実際のページングモニタ回数よりも多く実施しなければならず、消費電力が上がってしまう虞がある。このような場合、ＵＥは、ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ毎の受信動作が免除される。例えば、上述した監視不要期間を特定する為の情報を用いて、受信が免除されるＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ （ｂｏｕｎｄａｒｙ）を特定してもよい。もしくは、ネットワーク（基地局）は、ある所定の期間において当該ｎｏｔｉｆｉｃａｔｉｏｎを送信し続けてもよい。

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

上述した実施形態において、ＳＣ−ＰＴＭを用いたＭＢＭＳのシナリオを主として想定したが、ＭＢＳＦＮを用いたＭＢＭＳのシナリオを想定してもよい。一例として、上述した実施形態において、ＳＣ−ＰＴＭをＭＢＳＦＮと読み替え、ＳＣ−ＭＣＣＨをＭＣＣＨと読み替え、ＳＣ−ＭＴＣＨをＭＴＣＨと読み替えてもよい。

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

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

［付記１］
（１．はじめに）
本付記では、ＳＣ−ＭＣＣＨ変更／繰り返し期間、ＲＡＮレベル開始／停止時間情報、及び他のいくつかの側面の詳細が議論される。

（２．検討）
（２．１．ＳＣ−ＭＣＣＨ変更周期）
現在の仕様によれば、ＳＣ−ＭＣＣＨ変更境界は、「ＳＦＮ ｍｏｄ ｍ ＝ ０のＳＦＮ値（ｍは変更周期を含む無線フレームの数である）」によって定義され、変更周期はＳＩＢ２０によって提供される（図２４参照）。

一方、ＳＦＮは１０ビットで表され、すなわち、上限は１０２４である。したがって、ｓｃ−ｍｃｃｈ−ＭｏｄｉｆｉｃａｔｉｏｎＰｅｒｉｏｄで定義された既存の値の一部は実際には機能しない、つまり、ｒｆ２０４８（２０．４８［ｓ］）〜ｒｆ６５５３６（１０．９２［ｍｉｎ］）である。

考察１：現在のＳＣ−ＭＣＣＨ変更境界の定義は、ＳＦＮ上限によって１０．２４秒以内に制限され、ＳＣ−ＭＣＣＨ変更周期は１０．９２分（「予備」として）に規定される。

現在の制限は、Ｈ−ＳＦＮとのＳＩ変更境界の拡張について、リリース１３と同じ方法で削除することができる。つまり、変更期間の境界は「（Ｈ−ＳＦＮ ＊ １０２４ ＋ ＳＦＮ） ｍｏｄ ｍ ＝ ０」である。したがって、少なくとも既存の値を完全に使用するためには、ＳＣ−ＭＣＣＨ変更境界を強化すべきである。

提案１：ＳＣ−ＭＣＣＨ変更境界は、Ｈ−ＳＦＮがＳＩＢ１−ＢＲ又はＭＩＢ−ＮＢ／ＳＩＢ−ＮＢに提供されている場合、リリース１３のｅＭＴＣ／ＮＢ−ＩｏＴのＢＣＣＨ変更境界と同様に「（Ｈ−ＳＦＮ ＊ １０２４ ＋ ＳＦＮ）ｍｏｄ ｍ ＝ ０」で定義すべきである。

提案１が妥当である場合、特に同一のＳＣ−ＭＣＣＨがＦｅＭＴＣ ＵＥ及びリリース１３のＳＣ−ＰＴＭ ＵＥに使用される場合、下位互換性を確保する方法を考慮する必要がある。考察１で説明したように、リリース１３のＵＥがｒｆ１０２４より大きい値で設定されている場合、変更境界はない。しかし、リリース１３のＳＣ−ＰＴＭでは、重要な通信のユースケースが想定されていたが（ただしこれに限定されません）、これはリリース１４のＦｅＭＴＣの全く異なるユースケースである。したがって、ＲＡＮ２は、ＳＣ−ＭＣＣＨ変更周期の設定に関して後方互換性が必要かどうかについて議論すべきである。必要であれば、リリース１３／１４分離などのために複数のＳＣ−ＭＣＣＨを可能にするために、新しいＩＥ−リリース１４のＳＣ−ＭＣＣＨ変更周期を定義するなどのいくつかの単純な解決策が存在する。

提案２：提案１が納得のいくものである場合、ＲＡＮ２は、ＳＣ−ＭＣＣＨ変更周期の設定の下位互換性を確保するかどうか、及びその方法をさらに検討する必要がある。

また、ＳＣ−ＭＣＣＨ変更周期の既存の上限、すなわち、ｒｆ６５５３６（１０．９２ ［分］）が十分であるかどうかを検討することも価値がある。議論されるように、それは現在の期間のＵＥでより多くの電力消費を引き起こすかもしれない。例えば、ＳＣ−ＰＴＣＨ受信に関心のあるＵＥは、ＳＣ−ＭＣＣＨ変更通知が利用可能であるかどうかをチェックするために、すなわちリリース１３におけるＳＣ−ＭＣＣＨ機会でＳＣ−Ｎ−ＲＮＴＩでスクランブルされたＰＤＣＣＨを監視する。ＭＴＣ ＵＥ及びＮＢ−ＩｏＴ ＵＥがｅＤＲＸ（それぞれ最大で４３．６９［分］及び２．９１［Ｈ］）で設定されている可能性が高いと仮定すると、通常のページング監視に加えて、ＳＣ−ＭＣＣＨ変更周期の現在の上限はＵＥの電力消費を著しく増加させる（図２５：ｅＤＲＸ中のＳＣ−ＭＣＣＨ変更通知チェック参照）。したがって、ＳＣ−ＭＣＣＨ変更境界は、４３．６９［分］及び２．９１［Ｈ］で拡張されるべきである。

提案３：ＳＣ−ＭＣＣＨの変更周期は、ｅＤＲＸの上限に合わせて４３．６９分と２．９１時間に延長すべきである。

（２．２．ＳＣ−ＭＣＣＨ繰り返し周期）
ＳＣ−ＭＣＣＨの繰返し周期の延長は、実際の仮定として結論付けられた。値と範囲は現在図２６のように定義されている。

リリース１３で定義された繰り返し期間は、アクセスレイテンシ要件を満たすためのものである。しかしながら、リリース１４マルチキャストにおける主な使用事例の１つは、ファームウェア更新、すなわち遅延許容性と考えられる。リリース１３では、反復を行う主な動機の１つは、ＵＥが遅れて参加する場合に、進行中のセッションにＵＥが参加できるようにすることであった。しかし、これは主にストリーミング配信、例えばＭＣＰＴＴのためのものであった。このＷＩの主な用途は、ファームウェアのダウンロード送信のためである。そのため、意図されたユースケースにほとんど影響を与えずに繰り返し時間を延長することができる。また、欠落したパケットを防止する必要がある場合、ネットワークは、対応するＳＣ−ＭＣＣＨ送信が完了した後、例えば次の変更境界の後に、ＳＣ−ＭＴＣＨが送信を開始することを保証できると仮定する。したがって、少なくともＳＣ−ＭＣＣＨ変更境界のリリース１３上限、すなわち１０．２４［ｓｅｃ］又はｒｆ１０２４で拡張することができ、ＮＷの観点からリソース効率及び電力節約を改善する。反復が設定されていない場合、すなわちＳＣ−ＭＣＣＨ変更境界に等しい期間で利益が最大化される。

さらに、提案３が納得のいくものであれば、繰返し期間をｒｆ６５５３６（１０．９２分）、ｒｆ２６２１４４（４３．６９［分］）又はｒｆ１０４８５７６（２．９１ ［Ｈ］）までさらに延長することが有益である。

提案４：ＳＣ−ＭＣＣＨの繰り返し周期は、遅延許容用途の最適化として、ＳＣ−ＭＣＣＨ変更周期の上限に合わせるために延長すべきである。

図２７に、ＳＣ−ＭＣＣＨの繰り返し周期（ＣＥのＰＤＳＣＨ繰り返し以外）を示す。

（２．３．ＲＡＮレベルの開始／停止時間情報）
現在の情報に加えて、ＲＡＮレベルの開始／停止時間情報、すなわちＵＳＤによって、ファームウェア配信のスケジューリングを考慮するいくつかのユースケースがＡＳ層におけるｅＮＢの責任であると仮定する。例えば、いくつかのＵＥが両方のＴＭＧＩに関心がある場合、ｅＮＢは、異なるＴＭＧＩを有する異なるファームウェアファイルをＴＤＤ方式で送信したいことがある。この場合、正確な開始／停止時間は２つのファイル間で異なり、バッテリーの消費を節約するために、ＵＥが配信開始／停止のタイミングを知ることはＵＥにとって有益である。

既存のＭＢＳＦＮは、ＵＥ省電力のための動的スケジューリング情報を提供するために、ＭＡＣ ＣＥ、すなわち、ＭＣＨスケジューリング情報ＭＡＣ制御要素にＲＡＮレベル停止時間情報を提供する手段を有する。そのとき、「停止」情報のみを導入する理由は、「停止」情報から導かれる「開始」であった。ただし、ＭＣＨ（つまりＭＢＳＦＮ）にのみ適用される。

リリース１４のＳＣ−ＰＴＭの場合、ＳＣ−ＭＴＣＨは動的スケジューリング（すなわち、Ｍ／ＮＰＤＣＣＨ）を使用することが前提となっており、これは、ＲＡＮ２はＰＤＣＣＨによりスケジューリングされるＳＣ−ＭＴＣＨメカニズムが柔軟なスケジューリングを実現するためにＮＢ−ＩｏＴ及びＭＴＣにおけるマルチキャストに再利用され、ｆｅＭＴＣ及びＮＢ−ＩｏＴのためのＳＣ−ＭＣＣＨが動的にスケジューリングされるという合意事項による。さらに、ＳＣ−ＭＣＣＨとＳＣ−ＭＴＣＨの両方が、ＮＢ−ＩｏＴのためのアンカーキャリア及び／又は非アンカーキャリアでスケジューリングされる可能性があり、ＳＣ−ＭＣＣＨ及びＳＣ−ＭＴＣＨがＮＢ−ＩｏＴ及びＭＴＣ（狭帯域のＭＴＣ）で異なるキャリアでスケジューリングされる可能性がある。ＳＣ−ＰＴＭのこれらの特性は、システム帯域幅でのみ送信されるＭＢＳＦＮとはかなり異なる。したがって、図２８：不要なウェイクアップ（例えば、ＴＭＧＩ＃５に関心のあるＵＥ）に示すように、関心のあるＴＭＧＩにサービスを提供するＳＣ−ＭＴＣＨがいつ配信されるかをＵＥの観点からは予測できず、各ＳＣ−ＭＴＣＨスケジューリング期間でウェイクアップによりＵＥバッテリーを消費する。したがって、効率的なマルチキャストのための開始／停止時間情報を導入するのに有用である。

注：開始／停止時間情報の別の使用法として、（ＳＣ−ＭＴＣＨ監視に加えて／に代えて）ＳＣ−ＭＣＣＨ監視のための不必要なウェイクアップを防ぐために適用することができる。

提案５：ＲＡＮレベルの開始／停止情報は、ＵＥの電力を節約するために提供されるべきである。

提案５が納得できる場合、どのシグナリングが情報を運ぶか（すなわち、ＭＡＣ ＣＥ又はＲＲＣメッセージ）が問題である。「停止」に関しては、「停止」に関心のあるＵＥが対応するＳＣ−ＭＴＣＨを受信しているので、ＭＡＣ ＣＥを使用することが有益である。しかしながら、「開始」は、対応するＳＣ−ＭＴＣＨの実際の開始に先立って提供されるべきであるので、そうではない。したがって、「開始」は、例えばＳＣ−ＭＣＣＨのようなＲＲＣメッセージで提供されるべきである。

提案６：提案５が納得できる場合、ＲＡＮ２は、ＲＲＣメッセージによって「開始」情報が提供され、ＭＡＣ ＣＥによって「停止」情報が提供されるかどうかを検討すべきである。

（２．４．その他）
（２．４．１．ＳＣ−ＭＣＣＨ変更通知）
ＲＡＮ２は、ＤＣＩの情報を提供する直接的な表示又は同様のメカニズムをＳＣ−ＭＣＣＨの変更通知に使用できると想定している。ＲＡＮ２は、ＭＴ（ページング）とＳＣ−ＰＴＭ：ＭＴ（ページング）がＳＣ−ＰＴＭよりも優先度が高いという実用的な仮定も持っている。したがって、ページングの機会は、リリース１３直接指示と調和するすべての通知のよい機会である。さらに、ページングモニタと通知チェックの両方の状況を調整することができる。したがって、ＳＣ−ＭＣＣＨ変更通知のＲＮＴＩはＰ−ＲＮＴＩでなければならない。

提案７：Ｐ−ＲＮＴＩは、ＳＣ−ＭＣＣＨ変更通知に使用されるべきである
これは、ＴＳ ３６．３３１の表６．６−１と表６．７．５−１の８ビットの予約ビット内に“ＳＣ−ＭＣＣＨ変更通知”を割り当てて既存のダイレクトインジケーションを完全に再利用する最も簡単な方法である。ＳＣ−ＭＣＣＨの変更に対してただ１つの通知で十分である。一方、ＳＣ−ＭＴＣＨスケジューリングにＤＣＩを用いたＴＭＧＩ固有の変更通知は提案されている。ＳＣ−ＭＣＣＨのコンテンツが頻繁に変更されると想定される場合、実際には（ＳＣ−ＭＣＣＨとＳＣ−ＭＴＣＨとの間の）よりスケジューリングの柔軟性を可能にし、ＵＥが不要なＳＣ−ＭＣＣＨの取得を回避する。

ＳＣ−ＭＣＣＨが頻繁に変更されると想定される場合、ＴＭＧＩ固有のＳＣ−ＭＣＣＨ変更通知が有益であろう。

（２．４．２．複数のＳＣ−ＭＣＣＨ）
ＲＡＮ２＃９５ｂｉｓでは、複数のＳＣ−ＭＣＣＨが存在する場合は「ＦＦＳ」となった。同時に、異なるマルチキャストサービスには異なるカバレッジ強化レベルがあり、そのサービスの特定のカバレッジ強化の必要性に応じて設定可能でなければならないと合意された。現在のＳＣ−ＭＣＣＨの観点からは、異なるサービスの設定を１つのＳＣ−ＭＣＣＨに含める必要がある。したがって、ＳＣ−ＭＣＣＨは、最も深い拡張カバレッジ、すなわち、サービスの中で最大の反復回数で送信されることをカバーしなければならない。

セクション２．１及び２．２で説明したように、異なるサービスは、異なる待ち時間、すなわち異なるＳＣ−ＭＣＣＨ変更周期及び異なるＳＣ−ＭＣＣＨ繰返し期間を必要とすることがある。さらに、逆方向互換性のないＳＣ−ＭＣＣＨ変更周期を有する設定に問題がない場合（例えば、ｒｆ６５５３６）には、リリース１３／１４のＵＥのＳＣ−ＭＣＣＨ（すなわち異なるＳＣ−ＭＣＣＨに）を分離することが有用であり得る。ＲＡＮ１＃８６は、以下の合意を締結した。

契約：
・ＳＣ−ＭＣＣＨでサポートされている進行中のＳＣ−ＭＴＣＨの最大数は、ＬＴＥに比べて少なくなる。

・ＬＳをＲＡＮ２に送信して
−ＲＡＮ１は、ＳＣ−ＭＣＣＨによってサポートされている進行中のＳＣ−ＭＴＣＨの最大数がＬＴＥに比べて減少しているとＲＡＮ２に通知し、
−ＦｅＭＴＣ内のＳＣ−ＭＣＣＨによってサポートされている進行中のＳＣ−ＭＴＣＨの最大数をＲＡＮ１に通知するようにＲＡＮ２に要求し、
−リリース１４でＳＣ−ＭＣＣＨのセグメンテーションがどのようにサポートされるか、及びＲＡＮ１に通知するようにＲＡＮ２に要求する。

合意事項：
・ＳＣ−ＭＣＣＨでサポートされている進行中のＳＣ−ＭＴＣＨの最大数は、ＬＴＥに比べて少なくなる。

ＬＳをＲＡＮ２に送信して
・ＲＡＮ１は、ＳＣ−ＭＣＣＨによってサポートされている進行中のＳＣ−ＭＴＣＨの最大数がＬＴＥに比べて減少しているとＲＡＮ２に通知し、
・ＮＢ−ＩｏＴにおいてＳＣ−ＭＣＣＨによってサポートされている進行中のＳＣ−ＭＴＣＨの最大数をＲＡＮ１に通知するようにＲＡＮ２に要求し、
・最大のＴＢＳ値をさらに大きくし、
・リリース１４でＳＣ−ＭＣＣＨのセグメンテーションがサポートされるかどうか、及びどのようにセグメント化されるかをＲＡＮ１に通知するようにＲＡＮ２に要求する。

上記のＬＳに基づいて、現在ＲＡＮ１はサービスの数、すなわちＳＣ−ＭＣＣＨで設定可能なＳＣ−ＭＴＣＨをＬＴＥと比較して削減すべきであると仮定するが、セルごとに複数のＳＣ−ＭＣＣＨが存在する可能性を排除しなかった。同時に多くのサービスをサポートする必要がある場合、１つのセルにつき１つのＳＣ−ＭＣＣＨの原理では不十分な場合がある。

上記の考察を考慮すると、将来のプルーフィングのために複数のＳＣ−ＭＣＣＨを持つことは妥当である。

考察３：ＲＡＮ２は、ＳＣ−ＭＣＣＨが異なる「ＣＥレベル」だけでなく、異なる待ち時間要件及びサービス数をカバーする必要があることを考慮すべきである。

（２．４．３．キャリア情報（確認））
最後の会議では、ＲＡＮ２は、ＳＩＢ２０はＳＣ−ＭＣＣＨのキャリアを示し、ＳＣ−ＭＣＣＨはＭＴＣＨのキャリアを示すと合意した。この声明はｅＮＢ−ＩｏＴにのみ適用されると思われるが、ＦｅＭＴＣにもその意図があると思われる。したがって、確認のためだけに、ＲＡＮ２は、「ＳＩＢ２０がＳＣ−ＭＣＣＨのＮＢを示し、ＳＣ−ＭＣＣＨがＳＣ−ＭＴＣＨのＮＢを示している」と合意されているかどうかを議論するよう求められる。

提案８：ＳＩＢ２０がＳＣ−ＭＣＣＨのナローバンドを示し、ＳＣ−ＭＣＣＨがＳＣ−ＭＴＣＨのナローバンドを示すことが確認された。

［付記２］
（１．はじめに）
本付記では、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴのＳＣ−ＰＴＭサービス継続性の詳細について説明する。

（２．検討）
（２．１．リリース１３のメカニズム）
リリース１３において、ＳＣ−ＭＣＣＨは、ＵＥが他の周波数／セルでサービスされている関心のあるＭＢＭＳサービスを容易に見つけるために、サービス継続性に関する情報を提供する。詳細には、ＳＣＰＴＭ−ＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔはセルＩＤと周波数とを含み、ＴＭＧＩごとのｓｃ−ｍｔｃｈ−ｎｅｉｇｈｂｏｕｒＣｅｌｌは、リストの各エントリがＭＢＭＳサービスを提供するか否かをそのビット列内で示す（図２９参照）。

一方、ＳＩＢ１５は同様の情報を提供するが、主にＭＢＳＦＮを対象としていた。詳細には、ＭＢＭＳサービスエリアＩＤを含むＭＢＭＳ−ＳＡＩ−Ｌｉｓｔが、イントラ周波数に対して提供され、また、インター周波数について、ｄｌ−ＣａｒｒｉｅｒＦｒｅｑと共に提供される。

ＳＩＢ１５と比較して、ＳＣ−ＭＣＣＨは、マルチセルブロードキャスト（又は単一周波数ネットワーク）からシングルセルＰＴＭへの粒度の変更のために、セルＩＤをサービス継続性情報に追加した。したがって、どのリソースが関心のあるＭＢＭＳサービスを提供するかの正確な情報は、リリース１３において、サービス継続性（及びセル再選択時のＵＥバッテリ消費量）にとって有用である。

考察１：ＳＣ−ＰＴＭのサービス継続性のために、単一周波数から単一セルマルチキャストへの変更のために、リリース１３はＭＢＭＳサービスが提供されるセルＩＤをＳＣ−ＭＣＣＨに含めた。

（２．２．リリース１４サービス継続性強化）
サービス継続情報を拡張するかどうかはまだ決まっていない。考察１のように、リリース１４ではリソースの粒度が変更されているかどうかを調べる必要がある。ＲＡＮ２は「ナローバンド動作をサポートするために必要な拡張機能を導入すること」を目的としているため、以前のリリースとは異なる無線リソースの仮定でマルチキャストをサポートすることは明らかである（例えば、ＭＰＤＣＣＨのサポート、及びカバレッジ強化、例えば、繰り返し）。また、異なるユースケースがＷＩＤに記載されている（例えば、ファームウェア又はソフトウェアの更新、グループメッセージの配信）。変更は次のように識別される。

動作：リリース１３の広帯域、リリース１４のナローバンド
カバレッジ：リリース１３の通常カバレッジとリリース１４のカバレッジの強化
ユースケース（ただしこれに限定されない）：リリース１３のＭＣＰＴＴとファームウェア／ソフトウェアのアップデート、そしてリリース１４のグループメッセージ配信

考察２：マルチキャストの仮定／目的はリリース１４で変更されている。

したがって、ＲＡＮ２は、各変更に対してサービス継続性を強化する必要があるかどうかについて議論すべきである。

（２．２．１．ナローバンド動作）
考察１で述べたように、リソースの細かさが変更されたときにサービス継続性情報を拡張すると便利である。これは、リリース１４のナローバンドマルチキャストにも適用される。以下の２つの選択肢が考えられる。

オプション１：ＭＢＭＳサービスがナローバンド／キャリアに提供されるかどうかを示す。

これは、ＳＣ−ＭＴＣＨがＢＬ ＵＥ／ＮＢ−ＩｏＴ ＵＥによって受信可能であるかどうかを示す簡単な拡張である。例えば、図３０のようにＳＣ−ＭＴＣＨ−ＩｎｆｏＬｉｓｔに実装することができる。但し、ｓｃ−ｍｔｃｈ−ｎｅｉｇｈｂｏｕｒＣｅｌｌ−ＢＬは、ＳＣ−ＭＴＣＨがナローバンド（すなわち、６個のＰＲＢ）内に提供されるかどうかを示し、ｓｃ−ｍｔｃｈ−ｎｅｉｇｈｂｏｕｒＣｅｌｌ−ＮＢは、ＳＣ−ＭＴＣＨがキャリア（すなわち、１個のＰＲＢ）内に提供されるかどうかを示す。

オプション２：ＭＢＭＳサービスが提供されているナローバンド／キャリアを指定する。

また、ＳＣ−ＭＣＣＨは、「ＳＩＢ２０がＳＣ−ＭＣＣＨの搬送波を示し、ＳＣ−ＭＣＣＨが搬送波を示している」というＲＡＮ２の同意と同様に、隣接セルでＭＢＭＳサービスが提供される場所などの情報を提供することも有用である。しかし、システム帯域幅内で多少動的に構成可能であると仮定できるので、ｅＮＢがＦｅＭＴＣの下で同様の情報、すなわちＭＢＭＳサービスが提供されるナローバンドを提供することは困難であり得る。例えば、図３１のようにＳＣＰＴＭ−ＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔに実装することができる。但し、ＮａｒｒｏｗｂａｎｄＯｐｅｒａｔｉｏｎはＳＣ−ＰＴＭがナローバンド（すなわち６ ＰＲＢｓ）内に提供されるかどうかを示し、ｃａｒｒｉｅｒＦｒｅｑＯｆｆｓｅｔはアンカーキャリア（すなわち１個のＰＲＢ）がＳＣ−ＰＴＭを提供するかどうかを示す。

ＦｅＭＴＣ ＵＥの場合、これらのオプションは非常に似ているが、ｅＮＢ−ＩｏＴ ＵＥに関してはいくつかの違いがある。オプション１では、ＵＥは、どのキャリアが隣接セルでＳＣ−ＰＴＭを提供するかを探索する必要があり、オプション２は、よりスムーズな移動を容易にする。しかしながら、複数のアンカーキャリアが複数の（異なる）ＳＩＢ２０をブロードキャストする場合、オプション２は、追加のオーバーヘッドを引き起こす（複数のＩＥ、例えばリストを必要とすることがある）。

両方のオプションに長所と短所がある。しかしながら、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴのためのリリース１４マルチキャストの拡張として、ナローバンド／キャリア動作に関する何らかの情報が必要であることは明らかである。

提案１：ＲＡＮ２は、隣接セルにおけるＳＣ−ＰＴＭのナローバンド動作が提供されるべきかどうかについて議論すべきである。

（２．２．２．）拡張カバレッジ
リリース１４における他の拡張は、例えば、繰返し、パワーブースティング及びＭＣＳ選択によって促進される、拡張カバレッジにおけるマルチキャストをサポートすることである。ＳＣ−ＰＴＭのＣＥレベルの定義がある場合でも、「ＦＦＳ」であるが、「ＵＥは、ＵＥの無線状態と予想されるカバレッジに基づいてＳＣ−ＰＴＭ送信を受信するかどうかを知る必要がある。カバレッジブーストレベル（すなわち、ＳＣ−ＰＴＭ受信信頼性チェックのための通常のカバレッジへのある閾値又は「オフセット」）がサービングセルによって提供されると仮定されている場合、カバレッジブーストレベルがサービス継続性を容易にするために、すなわちパケット損失を最小限に抑えるために、サービングセルにも隣接セルからのカバレッジブーストレベルを含めるべきである。

提案２：ＲＡＮ２は、隣接セルのＳＣ−ＰＴＭカバレッジ情報（例えば、繰り返し回数、パワーブーストレベル及びＭＣＳ、又は信頼性チェックのためのいくつかの統合された閾値／オフセット）がサービングセルによって提供されるべきかどうかについて議論すべきである。

（２．２．３．ファームウェア／ソフトウェアのアップデートとグループメッセージの配信）
サービス継続性の観点から、リリース１３（例えば、ストリーミング）はむしろより低いアクセス待ち時間を要求したが、リリース１４（例えば、ファイル配信）の違いは、ロスレスモビリティが好ましいかどうかである。しかし、ＡＳ層のロスレスな移動性を保証するのはマルチキャストでは困難である。「リリース１４では、フィードバックの解決策はない」と合意されており、ｅＮＢのスケジューラに依存している。パケット配信は、ネットワーク内のｅＮＢ間で同期されない。しかし、上位層機構、すなわちＦＬＵＴＥは、例えばユニキャストファイル回復によって、ＡＳ層におけるパケット損失を補償する。したがって、ロスレスモビリティは、リリース１４マルチキャストのいくつかの上位層メカニズムに依存することもある。

考察３：リリース１４マルチキャストのロスレスモビリティには、追加のＡＳメカニズムは必要ない。

しかし、欠落したＦＬＵＴＥブロックなどのパケット損失の量は、いくつかのＡＳ層構成、例えば同期配信、ＳＩＢ２０スケジューリング周期性、ＳＣ−ＭＣＣＨ繰り返し周期などに依存する。これは、例えば、ユニキャストファイル回復のＲＲＣ接続要求におけるＲＲＣ接続要求の数及び滞留時間に影響を与え、追加のＵＥ電力消費を引き起こす。しかし、セクション２．２．１と２．２．２で説明した支援情報を除いて、パケット損失を最小限に抑える方法は、ＮＷの実装に依存する。

考察４：ＵＥのモビリティによるパケット損失を最小限にする方法は、リリース１４のＮＷ実装次第である。

［相互参照］
本願は米国仮出願第６２／４１７５１９号（２０１６年１１月４日出願）の優先権を主張し、その内容の全てが本願明細書に組み込まれている。

Claims (6)

1. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置であって、
   基地局からＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを受信する受信部と、
   制御部と、を備え、
   前記受信部は、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信し、
   前記制御部は、前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断し、
   前記制御部は、前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視し、
   前記受信部は、前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信し、
   前記制御部は、前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定し、
   前記通知情報は、ＭＢＭＳサービスの識別子と対応付けられている
   ユーザ装置。
2. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置であって、
   基地局からＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを受信する受信部と、
   制御部と、を備え、
   前記受信部は、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信し、
   前記制御部は、前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断し、
   前記制御部は、前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視し、
   前記受信部は、前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信し、
   前記制御部は、前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定し、
   前記通知情報は、前記ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更される将来のタイミングを示す情報を含み、
   前記監視不要期間は、前記ＭＢＭＳ制御情報の内容が変更される前記将来のタイミングまでの期間である
   ユーザ装置。
3. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置が、ＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを基地局から受信するステップと、
   前記ユーザ装置が、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信するステップと、
   前記ユーザ装置が、前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断するステップと、
   前記ユーザ装置が、前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視するステップと、
   前記ユーザ装置が、前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信するステップと、
   前記ユーザ装置が、前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定するステップと、を備え、
   前記通知情報は、ＭＢＭＳサービスの識別子と対応付けられている
   方法。
4. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置が、ＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを基地局から受信するステップと、
   前記ユーザ装置が、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信するステップと、
   前記ユーザ装置が、前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断するステップと、
   前記ユーザ装置が、前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視するステップと、
   前記ユーザ装置が、前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信するステップと、
   前記ユーザ装置が、前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定するステップと、を備え、
   前記通知情報は、前記ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更される将来のタイミングを示す情報を含み、
   前記監視不要期間は、前記ＭＢＭＳ制御情報の内容が変更される前記将来のタイミングまでの期間である
   方法。
5. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置を制御するプロセッサであって、
   ＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを基地局から受信する処理と、
   前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信する処理と、
   前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断する処理と、
   前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視する処理と、
   前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信する処理と、
   前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定する処理と、を実行し、
   前記通知情報は、ＭＢＭＳサービスの識別子と対応付けられている
   プロセッサ。
6. ＳＣ−ＰＴＭを用いたＭＢＭＳ伝送をサポートするユーザ装置を制御するプロセッサであって、
   ＳＣ−ＭＴＣＨを介してＭＢＭＳサービスを基地局から受信する処理と、
   前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信の停止を示すＭＡＣ ＣＥを前記基地局から受信する処理と、
   前記ＭＡＣ ＣＥの受信に応じて、前記ＳＣ−ＭＴＣＨを介した前記ＭＢＭＳサービスの送信が停止されると判断する処理と、
   前記基地局からＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨを介して周期的に送信されるＭＢＭＳ信号を監視する処理と、
   前記ＭＢＭＳ信号を受信すべき将来のタイミングを示す通知情報を前記基地局から受信する処理と、
   前記通知情報に基づいて、前記ＭＢＭＳ信号の監視を省略可能な監視不要期間を特定する処理と、を実行し、
   前記通知情報は、前記ＳＣ−ＭＣＣＨを介して送信されるＭＢＭＳ制御情報の内容が変更される将来のタイミングを示す情報を含み、
   前記監視不要期間は、前記ＭＢＭＳ制御情報の内容が変更される前記将来のタイミングまでの期間である
   プロセッサ。

Images