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

Description

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

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

一方、人が介在することなく通信を行うＭＴＣ（Ｍａｃｈｉｎｅ Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）やＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）サービスを対象とした無線端末が検討されている。このような無線端末は、低コスト化、カバレッジ広域化、及び低消費電力化を実現することが求められる。このため、３ＧＰＰにおいて、システム送受信帯域の一部のみに送受信帯域幅を制限した新たな無線端末のカテゴリが仕様化されている。しかしながら、現状、新たなカテゴリの無線端末がＭＢＭＳを用いたマルチキャスト／ブロードキャストサービスを効率的に受信するための仕組みが存在しないという問題がある。

第１の特徴に係る無線端末は、移動通信システムのための無線端末である。前記無線端末は、システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成された送受信機と、前記送受信機を用いて基地局との無線通信を行う制御部と、を備える。前記制御部は、前記基地局を介して提供されるＭＢＭＳサービスを受信するために必要な情報を、前記制限帯域幅内で前記基地局から受信する処理を行う。

第２の特徴に係る基地局は、移動通信システムのための基地局である。前記基地局は、システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成された無線端末に対して、前記基地局を介して提供されるＭＢＭＳサービスを受信するために必要な情報を前記制限帯域幅内で送信する処理を行う制御部を備える。

実施形態に係るＬＴＥシステムの構成を示す図である。 実施形態に係るＭＢＭＳに係るネットワーク構成を示す図である。 実施形態に係るＵＥ（無線端末）の構成を示す図である。 実施形態に係るｅＮＢ（基地局）の構成を示す図である。 実施形態に係るＬＴＥシステムにおける無線インターフェイスのプロトコルスタックを示す図である。 実施形態に係るＬＴＥシステムの下りリンクのチャネルの構成を示す図である。 実施形態に係るＬＴＥシステムの無線フレームの構成を示す図である。 実施形態に係るハイパーフレーム、無線フレーム、及びサブフレームの関係を示す図である。 実施形態に係るカテゴリＭ１向けの下りリンク物理チャネルを示す図である。 実施形態に係るＵＥがＳＣ−ＰＴＭ受信を行う動作の一例を示す図である。 実施形態に係るＤｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎを示す図である。 実施形態に係るＳＩＢ２０を示す図である。 実施形態に係るＳＣ−ＭＣＣＨ中のＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。 実施形態に係るＨ−ＳＦＮにより表現される提供開始時間を示す図である。 実施形態に係る繰り返し回数情報を示す図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ＬＴＥシステムにおいて、消費電力を削減するために間欠受信（ＤＲＸ：Ｄｉｓｃｏｎｔｉｎｕｏｕｓ Ｒｅｃｅｐｔｉｏｎ）がＵＥ１００に設定され得る。ＤＲＸ動作において、ＲＲＣアイドルモードのＵＥ１００は、所定の時間間隔（ＤＲＸサイクル）で発生するページング受信機会（Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ）においてページングメッセージを監視する。

ＤＲＸ動作において、ＵＥ１００は、ページングを受信するためにＰＤＣＣＨを間欠的に監視する。ＵＥ１００は、ページング用の識別子（Ｐ−ＲＮＴＩ：Ｐａｇｉｎｇ Ｒａｄｉｏ Ｎｅｔｗｏｒｋ Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ）を用いてＰＤＣＣＨをデコードし、ページングチャネルの割り当て情報を取得する。ＵＥ１００は、割当情報に基づいて、ページングメッセージを取得する。ＵＥ１００におけるＰＤＣＣＨ監視タイミングは、ＵＥ１００の識別子（ＩＭＳＩ：Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ）に基づいて定められる。

ＤＲＸ動作におけるＰＤＣＣＨ監視タイミング（ＰＤＣＣＨ監視サブフレーム）は、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ（ＰＯ）と称される。ＰＯは、ページングの受信機会に相当する。

ＵＥ１００及びｅＮＢ２００は、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎ（ＰＯ）、及び、Ｐａｇｉｎｇ Ｏｃｃａｓｉｏｎを含みうる無線フレームであるＰａｇｉｎｇ Ｆｒａｍｅ（ＰＦ）を下記のように計算する。

ＰＦのシステムフレーム番号（ＳＦＮ）は、下記の式（１）から求められる。

ＳＦＮ ｍｏｄ Ｔ ＝ （Ｔ ｄｉｖ Ｎ） ＊ （ＵＥ＿ＩＤ ｍｏｄ Ｎ） …（１）

但し、Ｔは、ページングを監視するためのＵＥ１００のＤＲＸサイクルであり、無線フレームの数で表される。また、Ｔは、ｅＮＢ２００がＳＩＢ（Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）によりブロードキャストするデフォルトＤＲＸ値、及びＮＡＳメッセージによりＵＥ１００に設定されるＵＥ固有ＤＲＸ値のうち、何れか小さい方である。なお、ＵＥ固有ＤＲＸ値が設定されていない場合、ＵＥ１００は、デフォルトＤＲＸ値を適用する。また、Ｎは、ＴとｎＢのうち最小値である。ｎＢは、４Ｔ， ２Ｔ， Ｔ， Ｔ／２， Ｔ／４， Ｔ／８， Ｔ／１６， Ｔ／３２から選択される値である。ＵＥ＿ＩＤは、「ＩＭＳＩ ｍｏｄ１０２４」により求められる値である。

このようにして求められたＰＦのうち、下記の式（２）により、インデックスｉ＿ｓを求め、インデックスｉ＿ｓに対応するＰＯのサブフレーム番号を求める。

ｉ＿ｓ ＝ ｆｌｏｏｒ（ＵＥ＿ＩＤ／Ｎ） ｍｏｄ Ｎｓ …（２）

但し、Ｎｓは、１とｎＢ／Ｔのうち最大値である。

次に、拡張ＤＲＸ（ｅｘｔｅｎｄｅｄ ＤＲＸ）について説明する。拡張ＤＲＸにおいては、非常に長いＤＲＸサイクルをサポートするためにハイパーフレームが用いられる。

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

拡張ＤＲＸサイクルが設定されたＵＥ１００は、拡張ＤＲＸのサポートをセルがシステム情報により示す場合に、拡張ＤＲＸ動作を行う。ＵＥ１００は、自ＵＥに設定された周期的なページングウィンドウ内で、上述したＰＯの監視を行う。ページングウィンドウは、ＵＥ固有である。ページングウィンドウは、ページングハイパーフレーム（ＰＨ）、ＰＨ内の開始点（ＰＷ＿ｓｔａｒｔ）、及びＰＨ内の終了点（ＰＷ＿ｅｎｄ）により定められる。

ここで、ＰＨは、下記の式（３）を満たすＨ−ＳＦＮである。

Ｈ−ＳＦＮ ｍｏｄ Ｔ_{ｅＤＲＸ，Ｈ}＝ （ＵＥ＿ＩＤ ｍｏｄ Ｔ_{ｅＤＲＸ，Ｈ}） …（３）

ＵＥ＿ＩＤは「ＩＭＳＩ ｍｏｄ １０２４」である。Ｔ_{ｅＤＲＸ，Ｈ}は、ＵＥ１００に設定された拡張ＤＲＸサイクル（ｅＤＲＸ ｃｙｃｌｅ）である。

ＰＷ＿ｓｔａｒｔは、ページングウィンドウの最初の無線フレームを示し、下記の式（４）を満たすＳＦＮである。

ＳＦＮ ＝ ２５６＊ ｉ_ｅＤＲＸ …（４）

ｉ_ｅＤＲＸは、「ｆｌｏｏｒ（ＵＥ＿ＩＤ／Ｔ_{ｅＤＲＸ，Ｈ}） ｍｏｄ ４」である。

ＰＷ＿ｅｎｄは、ページングウィンドウの最後の無線フレームを示し、下記の式（５）を満たすＳＦＮである。

ＳＦＮ ＝ （ＰＷ＿ｓｔａｒｔ ＋ Ｌ＊１００ − １） ｍｏｄ １０２４ …（５）

Ｌは、ＵＥ１００に設定されたページングウィンドウ長である。

（想定シナリオ）
実施形態に係る想定シナリオについて説明する。実施形態において、システム送受信帯域の一部のみに送受信帯域幅を制限した新たなカテゴリのＵＥ１００がＭＢＭＳを用いたマルチキャスト／ブロードキャストサービスを受信するシナリオを想定する。このようなシナリオ（ユースケース）としては、ＭＢＭＳサービスとして多数のＵＥ１００に対するファームウェアの一括配信を行うケースが挙げられる。

新たなＵＥカテゴリは、カテゴリＭ１及びＮＢ（Ｎａｒｒｏｗ Ｂａｎｄ）−ＩｏＴカテゴリと称される。カテゴリＭ１は、ＵＥ１００の送受信帯域幅を１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）に制限するとともに、繰り返し送信等を用いたカバレッジ強化（ＣＥ：Ｅｎｈａｎｃｅｄ Ｃｏｖｅｒａｇｅ）技術をサポートする。ＮＢ−ＩｏＴカテゴリは、ＵＥ１００の送受信帯域幅を１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）にさらに制限するとともに、カバレッジ強化技術をサポートする。繰り返し送信は、複数のサブフレームを用いて同一の信号を繰り返し送信する技術である。以下において、カテゴリＭ１のＵＥ１００を主として想定するが、ＮＢ−ＩｏＴカテゴリのＵＥ１００を想定してもよい。なお、このようなＵＥ１００には、省電力化のためにｅＤＲＸが設定されることが想定される。

一例として、ＬＴＥシステムのシステム帯域幅は１０ＭＨｚであり、そのうちの送受信帯域幅は９ＭＨｚ（すなわち、５０リソースブロックの帯域幅）である。一方、カテゴリＭ１のＵＥ１００は、６リソースブロックよりも広い帯域幅で送信される下りリンク無線信号を受信することができないため、通常のＰＤＣＣＨを受信することができない。このため、ＭＴＣ向けのＰＤＣＣＨであるＭＰＤＣＣＨ（ＭＴＣ−ＰＤＣＣＨ）が導入される。同様な理由で、ＮＢ−ＩｏＴ向けのＰＤＣＣＨであるＮＰＤＣＣＨ（ＮＢ−ＰＤＣＣＨ）が導入される。

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

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

ＵＥ１００は、ＲＲＣコネクティッドモードでＭＢＭＳサービスを受信してもよい。ＵＥ１００は、ＲＲＣアイドルモードでＭＢＭＳサービスを受信してもよい。以下において、ＵＥ１００がＲＲＣアイドルモードでＭＢＭＳサービスを受信するケースを主として想定する。なお、ＲＲＣアイドルモードは、サスペンド状態を含む。サスペンド状態の場合、ＵＥ１００のコンテキスト情報がｅＮＢ２００に維持されるため、ＲＲＣ接続を速やかに復旧することができる。

図１０は、実施形態に係るＵＥ１００がＳＣ−ＰＴＭ受信を行う動作の一例を示す図である。ＵＥ１００は、カテゴリＭ１又はＮＢ−ＩｏＴカテゴリのＵＥ１００である。

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

ステップＳ２において、ＵＥ１００は、ＭＰＤＣＣＨ又はＮＰＤＣＣＨをｅＮＢ２００から受信する。ＭＰＤＣＣＨ及びＮＰＤＣＣＨのそれぞれは、システム情報（ＳＩＢ：Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ Ｂｌｏｃｋ）の更新を示す更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）を含む。図１１は、Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎを示す図である。図１１（ａ）はＭＰＤＣＣＨ中のＤｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎを示し、図１１（ｂ）はＮＰＤＣＣＨ中のＤｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎを示す。ＵＥ１００は、Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎに基づいて、いずれかのシステム情報が更新されたことを認識し、ＳＩＢタイプ１（ＳＩＢ１）をさらに受信する。ＳＩＢ１は、各ＳＩＢの更新有無を示すタグ番号（ｖａｌｕｅＴａｇ）を含む。ＵＥ１００は、タグ番号に基づいて、ＳＣ−ＰＴＭ用のＳＩＢであるＳＩＢタイプ２０（ＳＩＢ２０）の更新有無を判断する。ここでは、ＳＩＢ２０が更新されていると仮定して説明を進める。なお、ＳＩＢ２０はＳＣ−ＭＣＣＨのスケジューリング情報のみを含むので、更新は稀であると考えられる。

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

ステップＳ４において、ＵＥ１００は、ＳＩＢ２０に基づいて、ＳＣ−ＭＣＣＨを介してｅＮＢ２００からＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を受信する。物理レイヤにおいてＳＣ−ＭＣＣＨの送信にはＳＣ−ＲＮＴＩ（Ｓｉｎｇｌｅ Ｃｅｌｌ ＲＮＴＩ）が用いられる。図１３は、ＳＣ−ＭＣＣＨ中のＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）を示す図である。図１３に示すように、ＳＣＰＴＭ設定情報は、ＳＣ−ＭＲＢ（Ｓｉｎｇｌｅ Ｃｅｌｌ ＭＢＭＳ Ｐｏｉｎｔ ｔｏ Ｍｕｌｔｉｐｏｉｎｔ Ｒａｄｉｏ Ｂｅａｒｅｒ）を介して送信されるＭＢＭＳサービスに適用可能な制御情報を含む。ＳＣＰＴＭ設定情報は、当該情報を送信するセルにおける各ＳＣ−ＭＴＣＨの設定を含むｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔ、及びＳＣ−ＭＲＢを介してＭＢＭＳサービスを提供する隣接セルのリストであるｓｃｐｔｍＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔを含む。ｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔは、１又は複数のＳＣ−ＭＴＣＨ−Ｉｎｆｏを含む。各ＳＣ−ＭＴＣＨ−Ｉｎｆｏは、ＳＣ−ＭＲＢを介して送信される進行中のＭＢＭＳセッションの情報（ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏ）、当該ＭＢＭＳセッションに対応するＧ−ＲＮＴＩ（Ｇｒｏｕｐ ＲＮＴＩ）、及びＳＣ−ＭＴＣＨのためのＤＲＸ情報であるｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏを含む。ｍｂｍｓＳｅｓｓｉｏｎＩｎｆｏは、ＭＢＭＳサービスを識別するＴＭＧＩ及びセッションＩＤ（ｓｅｓｓｉｏｎＩｄ）を含む。Ｇ−ＲＮＴＩは、マルチキャストグループ（具体的には、特定グループ宛てのＳＣ−ＭＴＣＨ）を識別するＲＮＴＩである。Ｇ−ＲＮＴＩは、ＴＭＧＩと１対１でマッピングされる。ｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏは、ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭ、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭ、ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭを含む。ｓｃｈｅｄｕｌｉｎｇＰｅｒｉｏｄＳｔａｒｔＯｆｆｓｅｔＳＣＰＴＭは、ＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＣｙｃｌｅ及びＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＯｆｆｓｅｔを含む。ここで、ＳＣ−ＰＴＭ伝送向けのＤＲＸについて説明する。ＳＣ−ＰＴＭ伝送向けのＤＲＸは、上述したＤＲＸとは独立した動作である。ＳＣ−ＰＴＭ伝送向けのＤＲＸが設定されたＵＥ１００は、ＲＲＣコネクティッドモード又はＲＲＣアイドルモードにおいて、対応するＧ−ＲＮＴＩを用いてＰＤＣＣＨを間欠的に監視する。ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭ又はｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭが動作中（ｒｕｎｎｎｉｎｇ）である場合、アクティブ時間となる。ＵＥ１００は、アクティブ時間においてＰＤＣＣＨを監視する。また、ＵＥ１００は、「［（ＳＦＮ ＊ １０） ＋ ｓｕｂｆｒａｍｅ ｎｕｍｂｅｒ］ ｍｏｄｕｌｏ （ＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＣｙｃｌｅ） ＝ ＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＯｆｆｓｅｔ」が満たされる場合、ｏｎＤｕｒａｔｉｏｎＴｉｍｅｒＳＣＰＴＭを開始させる。ＵＥ１００は、ＰＤＣＣＨがＤＬ送信を示す場合、ｄｒｘ−ＩｎａｃｔｉｖｉｔｙＴｉｍｅｒＳＣＰＴＭを開始させる。

ステップＳ５において、ＵＥ１００は、ＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）中のＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＩｎｆｏに基づいて、ＳＣ−ＭＴＣＨを介して、自身が興味のあるＴＭＧＩに対応するＭＢＭＳサービス（データ）を受信する。物理レイヤにおいて、ｅＮＢ２００は、Ｇ−ＲＮＴＩを用いてＰＤＣＣＨを送信した後、ＰＤＳＣＨを介してデータを送信する。ＵＥ１００は、最大でも８１９２ｍｓ毎にデータ受信を試みる。このデータ受信は、ＵＥ１００の消費電力を増加させ得る。

（動作パターン）
実施形態に係る動作パターンについて説明する。前提として、ＵＥ１００は、システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成された送受信機（受信部１１０及び制御部１３０）と、送受信機を用いてｅＮＢ２００との無線通信を行う制御部１３０と、を備える。制限帯域幅とは、例えば、ＵＥ１００がＭ１カテゴリに属する場合には１．０８ＭＨｚ（すなわち、６リソースブロックの帯域幅）であり、ＵＥ１００がＮＢ−ＩｏＴカテゴリに属する場合には１８０ｋＨｚ（すなわち、１リソースブロックの帯域幅）である。制御部１３０は、ｅＮＢ２００を介して提供されるマルチキャスト／ブロードキャストサービス（ＭＢＭＳサービス）を受信するために必要な情報を、制限帯域幅内でｅＮＢ２００から受信する処理を行う。

（１）動作パターン１
上述したように、カテゴリＭ１又はＮＢ−ＩｏＴカテゴリのＵＥ１００がＳＣ−ＰＴＭ受信を行う場合、ＵＥ１００の消費電力を増加させる。特に、ｅＤＲＸがＵＥ１００に設定されるケースを想定すると、ＳＣ−ＰＴＭ受信に関連したウェイクアップにより、十分な消費電力削減効果が得られなくなる懸念がある。よって、ＵＥ１００の消費電力の増加を抑制しつつＳＣ−ＰＴＭ受信を可能とすることが望まれる。

動作パターン１において、ＵＥ１００には、事前設定されたサービス識別子（ＴＭＧＩ）を記憶する所定の記憶媒体が設けられる。一例として、所定の記憶媒体は、ＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）である。事前設定されたサービス識別子は、特定のＭＢＭＳサービスに専用のサービス識別子である。特定のＭＢＭＳサービスは、ファームウェア配信サービスであってもよい。

これにより、ＵＥ１００は、ＵＳＤをユニキャストで取得することなく、ｅＮＢ２００（サービングセル）から提供されるＳＣ−ＭＣＣＨを見るだけで、ｅＮＢ２００から特定のＭＢＭＳサービスが提供されることを確認することができる。よって、ＲＲＣアイドルモードのＵＥ１００は、ＵＳＤを取得するためだけにＲＲＣコネクティッドモードに遷移する必要がない。また、ＵＥ１００はｅＤＲＸのウェイクアップ時（ページング確認時）に、ＳＣ−ＭＣＣＨを受信してもよい。

（２）動作パターン２
上述したように、ＵＥ１００は、ＭＰＤＣＣＨ又はＮＰＤＣＣＨ中の更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）を受信した後、ＳＩＢ１中のタグ番号（ｖａｌｕｅＴａｇ）を受信して確認しなければ、ＳＩＢ２０の更新を認識することができない。このようなタグ番号の受信及び確認の処理は、ＵＥ１００の消費電力を増加させる。

動作パターン２において、ＵＥ１００は、制限帯域幅以下の帯域幅を有する所定物理下りリンク制御チャネル（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）上でｅＮＢ２００から更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）を受信する。更新通知情報は、ＳＣ−ＰＴＭ用のシステム情報ブロック（ＳＩＢ２０）の更新を示す第１の更新通知、ＳＣ−ＰＴＭ用のマルチキャスト制御チャネル（ＳＣ−ＭＣＣＨ）の更新を示す第２の更新通知、ＳＣ−ＰＴＭ用のマルチキャスト制御チャネル（ＳＣ−ＭＣＣＨ）中で示される特定のＭＢＭＳサービスに関する更新を示す第３の更新通知、のうち少なくとも１つを含む。第１乃至第３の更新通知のそれぞれは、１ビットのフラグとして定義されてもよい。更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）は、既存フォーマットを用いてもよいし、新たなフォーマット（新たなＰＤＣＣＨフォーマット）を定義してもよい。

第１の更新通知は、ＳＩＢ２０単独での更新通知である。ＵＥ１００は、ＭＰＤＣＣＨ又はＮＰＤＣＣＨ中の更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）が第１の更新通知を含むことに応じて、ＳＩＢ１を受信しなくても、ＳＩＢ２０の更新を認識することができる。

第２の更新通知は、ＳＣ−ＭＣＣＨ（すなわち、ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）の更新通知である。ｅＮＢ２００は、ＳＣ−Ｎ−ＲＮＴＩでスクランブルされたＭＰＤＣＣＨ又はＮＰＤＣＣＨにより第２の更新通知をＵＥ１００に送信してもよい。ＵＥ１００は、ＭＰＤＣＣＨ又はＮＰＤＣＣＨ中の更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）が第２の更新通知を含むことに応じて、ＳＣ−ＭＣＣＨの更新を認識することができる。

第３の更新通知は、ＳＣ−ＭＣＣＨ中のｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔのうち特定のＳＣ−ＭＴＣＨ−Ｉｎｆｏに関する更新通知である。特定のＳＣ−ＭＴＣＨ−Ｉｎｆｏは、特定のＭＢＭＳサービス（例えば、ファームウェア配信サービス）と対応付けられている。具体的には、特定のＳＣ−ＭＴＣＨ−Ｉｎｆｏは、特定のＭＢＭＳサービスを識別するＴＭＧＩ（サービス識別子）を含む。ＵＥ１００は、ＭＰＤＣＣＨ又はＮＰＤＣＣＨ中の更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）が第３の更新通知を含むことに応じて、ＳＣ−ＭＣＣＨを受信しなくても、特定のＳＣ−ＭＴＣＨ−Ｉｎｆｏの更新を認識することができる。複数のＭＢＭＳサービスのそれぞれの更新を通知可能とする場合、更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）中の２ビット以上を第３の更新通知に割り当ててもよい。各ビットの位置はＭＢＭＳサービス（具体的には、ＳＣ−ＭＴＣＨ−Ｉｎｆｏ）と対応付けられる。ビット位置とＭＢＭＳサービスとの対応関係は、ｅＮＢ２００からＵＥ１００にＳＩＢ等により設定されてもよい。この場合、ＵＥ１００は、更新通知情報（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）中の第３の更新通知のビット位置に基づいて、ＳＣ−ＭＣＣＨ中のｓｃ−ｍｔｃｈ−ＩｎｆｏＬｉｓｔのうち、どのＳＣ−ＭＴＣＨ−Ｉｎｆｏが更新されたかを確認する。

ＵＥ１００は、第２及び第３の更新通知が提供されていない場合、ＳＣ−ＭＣＣＨ ｍｏｄｉｆｉｃａｔｉｏｎ ｂｏｕｎｄａｒｙ毎もしくはＳＣ−Ｎ−ＲＮＴＩでスクランブルされたＰＤＣＣＨを受信する毎に、ＳＣ−ＭＣＣＨを受信し、興味のあるＴＭＧＩに関する設定（ＳＣ−ＭＴＣＨ−Ｉｎｆｏ）の更新有無を確認してもよい。

（３）動作パターン３
動作パターン３は、特定のＭＢＭＳサービスの配信開始を直接的にＵＥ１００に通知可能とする動作パターンである。

動作パターン３において、ＵＥ１００は、制限帯域幅以下の帯域幅を有するＰＤＳＣＨ上でｅＮＢ２００からページングメッセージを受信する。ページングメッセージは、特定のＭＢＭＳサービスのサービス識別子（ＴＭＧＩ）を含む。ページングメッセージは、複数のサービス識別子（ＴＭＧＩ）からなるリストを含んでもよい。これにより、ＵＥ１００は、特定のＭＢＭＳサービスの配信が開始されることを認識し、特定のＭＢＭＳサービスを受信するための処理を開始することができる。よって、ＵＥ１００のウェイクアップを必要最小限に留めることができる。なお、一般的なページングメッセージは、サービス識別子（ＴＭＧＩ）を含むのではなく、呼び出し対象のＵＥ１００の識別子（ＩＭＳＩ等）を含むことに留意すべきである。

ｅＮＢ２００は、Ｐ−ＲＮＴＩでスクランブルされたＭＰＤＣＣＨ又はＮＰＤＣＣＨにより、ページングメッセージを運ぶＰＤＳＣＨ（狭帯域ＰＤＳＣＨ）を指定する。そして、ｅＮＢ２００は、指定したＰＤＳＣＨでページングメッセージを送信する。ＵＥ１００は、Ｐ−ＲＮＴＩでスクランブルされたＭＰＤＣＣＨ又はＮＰＤＣＣＨを受信することにより、ページングメッセージを運ぶＰＤＳＣＨ（狭帯域ＰＤＳＣＨ）を認識する。そして、ＵＥ１００は、認識したＰＤＳＣＨでページングメッセージを受信する。ＵＥ１００は、動作パターン１で説明した事前設定されたサービス識別子（ＴＭＧＩ）がページングメッセージ中で示されているか否かを確認してもよい。

ＵＥ１００は、ページングメッセージに含まれるサービス識別子（ＴＭＧＩ）が示すＭＢＭＳサービスの受信を望む場合、ｅＮＢ２００とのＲＲＣ接続を確立してもよい。この場合、ＵＥ１００は、ｅＮＢ２００にＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信してもよいし、サスペンド状態の場合はＲＲＣ Ｒｅｓｕｍｅ ＲｅｑｕｅｓｔメッセージをｅＮＢ２００に送信してもよい。或いは、ＵＥ１００は、ＲＲＣ接続を確立することに代えて、ＳＩＢ２０及び／又はＳＣ−ＭＣＣＨを取得し、その後、ＳＣ−ＰＴＭが送信されていれば、受信を試みてもよい。

（４）動作パターン４
動作パターン４において、ＵＥ１００は、特定のＭＢＭＳサービスの提供が開始される時間及び提供が終了される時間のうち少なくとも一方を示す時間情報をｅＮＢ２００から受信する。時間情報は、ＳＣ−ＰＴＭ用のシステム情報ブロック（ＳＩＢ２０）又はＳＣ−ＰＴＭ用のマルチキャスト制御チャネル（ＳＣ−ＭＣＣＨ）によりｅＮＢ２００から送信される。ＳＩＢ２０又はＳＣ−ＭＣＣＨ（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）は、複数のサービス識別子（ＴＭＧＩ）と、当該複数のサービス識別子（ＴＭＧＩ）のそれぞれの時間情報と、からなるリストを含んでもよい。これにより、ＴＭＧＩ毎に開始時間等をＵＥ１００に通知することができる。よって、ＵＥ１００は、自身が興味のあるＭＢＭＳサービス（例えば、事前設定されたサービス識別子が示すＭＢＭＳサービス）の提供が開始されるまで、スリープ状態を維持することができる。

時間情報は、提供開始時間及び提供終了時間の組み合わせであってもよい。或いは、時間情報は、提供開始時間及び提供持続時間（例えば、１分間）の組み合わせであってもよい。提供開始時間（及び提供終了時間）は、Ｈ−ＳＦＮにより表現されてもよいし、ＵＴＣ（Ｃｏｏｒｄｉｎａｔｅｄ Ｕｎｉｖｅｒｓａｌ Ｔｉｍｅ）により表現されてもよい。

Ｈ−ＳＦＮにより表現される場合、ＵＥ１００は、提供開始時間を示すＨ−ＳＦＮがラップアラウンド（＃１０２３→＃０）後のＨ−ＳＦＮであると認識する。図１４は、Ｈ−ＳＦＮにより表現される提供開始時間を示す図である。図１４（ａ）は、ＵＥ１００が、Ｈ−ＳＦＮ＝１５０の時点において、ＳＣ−ＭＣＣＨ中で提供開始時間がＨ−ＳＦＮ＝２００と示されるケースを示す。この場合、ＵＥ１００は、ラップアラウンド（＃１０２３→＃０）後のＨ−ＳＦＮ＝２００においてＭＢＭＳサービスの提供が開始されると認識する。図１４（ｂ）は、ＵＥ１００が、Ｈ−ＳＦＮ＝３００の時点において、ＳＣ−ＭＣＣＨ中で提供開始時間がＨ−ＳＦＮ＝２００と示されるケースを示す。この場合、ＵＥ１００は、ラップアラウンド（＃１０２３→＃０）後のＨ−ＳＦＮ＝２００においてＭＢＭＳサービスの提供が開始されると認識する。このような規則を定めることにより、ＵＥ１００とネットワークとで提供開始時間の解釈にずれが生じることを防止することができる。このような規則としては、例えば「ＵＥ１００は、Ｈ−ＳＦＮがラップアラウンド（上限値に達した）後の、指定Ｈ−ＳＦＮを提供開始タイミングとして理解しなければならない」というような規則とすることができる。同様な考え方で、Ｈ−ＳＦＮの上限に代えてＳＣ−ＭＣＣＨ又はＳＩＢのｍｏｄｉｆｉｃａｔｉｏｎ ｂｏｕｎｄａｒｙを用いて、ＳＣ−ＭＣＣＨ又はＳＩＢのｍｏｄｉｆｉｃａｔｉｏｎ ｂｏｕｎｄａｒｙの次のｂｏｕｎｄａｒｙ以降のタイミングに該当するＨ−ＳＦＮで提供が開始されるとしてもよい。

一方、ＵＴＣにより表現される場合、ＵＥ１００がＧＰＳ等を有しておらず、現在のＵＴＣを確認することができないケースも想定される。但し、現在のＵＴＣがＳＩＢタイプ１６（ＳＩＢ１６）で提供されている場合、ＧＰＳ等を利用不能なＵＥ１００であってもＵＴＣを確認することができる。よって、ｅＮＢ２００は、自身がＳＩＢ１６を送信している場合に限って、ＵＴＣにより表現される提供開始時間をＵＥ１００に提供してもよい。

（５）動作パターン５
上述したように、カバレッジ強化（ＣＥ）を目的として、ＭＰＤＣＣＨ（又はＮＰＤＣＣＨ）とＰＤＳＣＨ（狭帯域ＰＤＳＣＨ）とに繰り返し送信が適用され得る。繰り返し送信が適用される場合、ＵＥ１００は、最大繰り返し送信回数及び実際の繰り返し送信回数を把握していることが望ましい。

動作パターン５において、ＵＥ１００は、制限帯域幅以下の帯域幅を有する所定物理下りリンク制御チャネル（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）の繰り返し送信回数及び制限帯域幅以下の帯域幅を有する物理下りリンク共有チャネル（狭帯域ＰＤＳＣＨ）の繰り返し送信回数のうち少なくとも一方を示す繰り返し回数情報をｅＮＢ２００から受信する。繰り返し回数情報は、最大繰り返し送信回数及び実際の繰り返し送信回数の少なくとも一方を示す。繰り返し回数情報は、ＳＣ−ＰＴＭ用のシステム情報ブロック（ＳＩＢ２０）又はＳＣ−ＰＴＭ用のマルチキャスト制御チャネル（ＳＣ−ＭＣＣＨ）によりｅＮＢ２００から送信される。

図１５は、繰り返し回数情報を示す図である。図１５（ａ）は、ＳＩＢ２０中で繰り返し回数情報（＃ ｏｆ ｒｅｐｅｔｉｔｉｏｎ）が提供されるケースを示す。図１５（ａ）に示すように、ｅＮＢ２００は、ＳＩＢ２０中で、ＳＣ−ＭＣＣＨに対応するＭＰＤＣＣＨ（又はＮＰＤＣＣＨ）の繰り返し回数情報と、ＳＣ−ＭＣＣＨに対応する狭帯域ＰＤＳＣＨの繰り返し回数情報と、を提供する。ＵＥ１００は、ＳＣ−ＭＣＣＨに繰り返し送信が適用される場合でも、ＳＩＢ２０中の繰り返し回数情報に基づいてＳＣ−ＭＣＣＨを適切に受信することができる。図１５（ｂ）は、ＳＣ−ＭＣＣＨ中で繰り返し回数情報（＃ ｏｆ ｒｅｐｅｔｉｔｉｏｎ）が提供されるケースを示す。図１５（ｂ）に示すように、ｅＮＢ２００は、ＳＣ−ＭＣＣＨ中で、ＳＣ−ＭＴＣＨに対応するＭＰＤＣＣＨ（又はＮＰＤＣＣＨ）の繰り返し回数情報と、ＳＣ−ＭＴＣＨに対応する狭帯域ＰＤＳＣＨの繰り返し回数情報と、を提供する。ここでは、繰り返し送信回数情報がＭＢＭＳサービス毎（ＴＭＧＩ毎）に提供される一例を示している。ＵＥ１００は、ＳＩＢ２０中の繰り返し回数情報に基づいてＳＣ−ＭＴＣＨを適切に受信することができる。

（６）動作パターン６
ＵＥ１００は、ＳＣ−ＰＴＭ受信中に一のセルから他のセルに移動し得る。このような場合において、ＳＣ−ＰＴＭ受信を継続可能とすることが望ましい。

動作パターン６において、ＵＥ１００は、ｅＮＢ２００が管理するサービングセルに隣接する隣接セルが提供するＭＢＭＳサービスに対応付けられたグループＲＮＴＩ（Ｇ−ＲＮＴＩ）をｅＮＢ２００からサービングセルを介して受信する。すなわち、ＵＥ１００は、隣接セルが用いるＧ−ＲＮＴＩをサービングセルから受信する。当該Ｇ−ＲＮＴＩは、ＳＣ−ＰＴＭ用のシステム情報ブロック（ＳＩＢ２０）又はＳＣ−ＰＴＭ用のマルチキャスト制御チャネル（ＳＣ−ＭＣＣＨ）によりｅＮＢ２００（サービングセル）から送信される。

ｅＮＢ２００（サービングセル）は、Ｇ−ＲＮＴＩに加えて、隣接セルのＳＣ−ＭＴＣＨスケジューリング情報（ｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏ）をＵＥ１００に提供してもよい。或いは、ｅＮＢ２００（サービングセル）は、隣接セルのＳＣ−ＭＣＣＨ情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）の全てをＵＥ１００に提供してもよい。これにより、ＵＥ１００は、サービングセルから隣接セルに移動した場合でも、当該隣接セルのＳＣ−ＭＴＣＨを速やかに受信することができる。なお、ｅＮＢ２００（サービングセル）は、隣接セルのＳＩＢ２０の少なくとも一部をＵＥ１００に提供してもよい。

（７）動作パターン７
ＵＥ１００は、ＳＣ−ＭＴＣＨ上で送信されるＭＢＭＳサービス（データ）の受信に必ずしも成功するとは限らない。ファームウェア配信サービスを想定すると、データ（ファームウェア）が一部でも欠落することは問題である。

動作パターン７において、ＵＥ１００は、ｅＮＢ２００とのＲＲＣ接続を有しない状態（すなわち、ＲＲＣアイドルモード）において、ＭＢＭＳサービスの受信に失敗したことに応じてＲＲＣ接続を確立し、受信に失敗したＭＢＭＳサービスに関する情報をｅＮＢ２００に送信する。これにより、当該ＭＢＭＳサービスのユニキャスト再送をｅＮＢ２００に促すことができる。

動作パターン７において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨ上で送信済みのＭＢＭＳサービス（データ）を一定時間はバッファする。ｅＮＢ２００は、データをバッファしておく時間に関連するタイマ値をＳＩＢ等によりＵＥ１００に設定してもよい。当該タイマ値は、ＵＥ１００がＳＣ−ＭＴＣＨの受信に失敗してから、ＲＲＣ接続を確立する（例えば、ＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する）までの許容時間を規定する。ＵＥ１００は、受信失敗した場合に、当該タイマ値をセットしたタイマを起動し、当該タイマが満了するまでの間にＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージ（又はＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｓｕｍｅメッセージ）を送信しなければならない。ｅＮＢ２００は、ＳＣ−ＭＴＣＨ送信又はバッファリング毎に当該タイマを起動し、当該タイマが満了した場合に、当該バッファリングしたデータを破棄する。

ＭＢＭＳサービスの受信に失敗したＵＥ１００は、ＲＲＣコネクティッドモードに遷移した後、以下の情報のうち少なくとも１つをｅＮＢ２００に通知してもよい。

・ＳＣ−ＰＴＭ受信に失敗した旨
・受信に失敗したＴＭＧＩ
・受信に失敗した先頭のパケット番号（ＰＤＣＰシーケンス番号等）
・受信に失敗したＨＡＲＱプロセスＩＤ

ここで、パケット番号及び／又はＨＡＲＱプロセスＩＤを通知することにより、ｅＮＢ２００は、ＭＢＭＳサービス（データ）の全部をユニキャストで再送するのではなく、ＵＥ１００が受信に失敗した時点以降のデータのみをユニキャストで再送することができる。これにより、ＵＥ１００は、マルチキャストで正常受信できたデータを活用することができる。

ｅＮＢ２００は、ユニキャスト再送を行う際に、以下の情報のうち少なくとも１つをＵＥ１００に通知してもよい。

・再送用ベアラのＩＤ
・再送開始パケットのＰＤＣＰシーケンス番号
・ＨＡＲＱプロセスＩＤ

なお、ＵＥ１００がＭＢＭＳサービスの受信に失敗したことに応じてＲＲＣ Ｃｏｎｎｅｃｔｉｏｎ Ｒｅｑｕｅｓｔメッセージを送信する一例を説明したが、これに限らず、ＳＣ−ＭＴＣＨ受信失敗を示すフィードバック情報を送信してもよい。当該フィードバック情報は、再送制御信号（ＡＣＫもしくはＮＡＣＫ）などであってもよい。

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

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

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

［付記］
（１．はじめに）
本付記において、ＦｅＭＴＣ ＵＥのための既存のマルチキャストメカニズムを強化するための一般的な問題について検討する。

（２．検討）
（２．１．リリース１３のＳＣ−ＰＴＭ）
ＳＣＣＨは、ＰＭＣＨを使用したＭＢＳＦＮとは異なり、ＰＤＳＣＨを使用して単一セル内のＤＬマルチキャスト伝送をサポートするように、ｅＭＢＭＳアーキテクチャの上に規定された。ＰＤＳＣＨベースのマルチキャストメカニズムは、ＳＣ−ＲＮＴＩ又はＧ−ＲＮＴＩでスクランブルされたＰＤＣＣＨによる動的スケジューリングを可能にし、これは、ＷＩの目的、つまり「ＢＬ／ＣＥ（ｅＭＴＣ）ＵＥのマシンタイプ通信」に適合するが、ＭＰＤＣＣＨはリリース１３においてＳＣ−ＲＮＴＩ、ＳＣ−Ｎ−ＲＮＴＩ及びＧ−ＲＮＴＩをサポートしていない。

考察１：リリース１３のＳＣ−ＰＴＭは、潜在的に６つのＰＲＢ動作をサポートするが、ＭＰＤＣＣＨはＳＣ−ＰＴＭ送信のためのＲＮＴＩを必要とする。

ＵＥがＤＬマルチキャストデータを受信する前に、ＵＥは、ＳＣ−ＭＣＣＨ送信の機会を知るためにＳＩＢ２０を取得する必要があり、ＳＣ−ＭＣＣＨは、ＳＣ−ＰＴＭ受信のための詳細情報、すなわち、Ｇ−ＲＮＴＩに対するＴＭＧＩなどのＳＣ−ＭＴＣＨ−ＩｎｆｏＬｉｓｔ、ＳＣ−ＰＴＭスケジューリング情報を運ぶ。

ＳＣ−ＭＣＣＨ修正期間の現在の上限は、約１０．９２分、すなわち、ｒｆ６５５３６である。したがって、ＳＣ−ＰＴＭに興味のあるＵＥは、既にＳＣ−ＭＣＣＨを受信していても、すなわちＳＣ−ＭＣＣＨ変更通知を受信しようとしても、ＳＣ−ＭＣＣＨの内容が少なくとも１０．９２分に１回変更されたかどうかを確認する必要がある（ＳＣ−Ｎ−ＲＮＴＩでスクランブルされたＰＤＣＣＨ）。一方、リリース１３のｅＤＲＸはアイドルモードのＤＲＸサイクルを４３．６９ ｍｕｎｉｔｉｅｓまで拡張する。ＦｅＭＴＣ ＵＥがｅＤＲＸサイクルで設定されていると仮定することができるが、ＵＥがＳＣ−ＰＴＭ受信に関心がある場合、ｅＤＲＸが電力節約の観点から完全に利益を得ることはできない。

ＵＥは、ＰＤＣＣＨ内のＳＣ−ＲＮＴＩを監視し、ＤＬ−ＳＣＨ内のＳＣ−ＭＣＣＨ送信を取得する。ＳＣ−ＭＣＣＨは、各ＭＢＭＳサービスＴＭＧＩ及びオプションのセッションＩＤ、関連するＧ−ＲＮＴＩ及びスケジューリング情報を含む、ＳＣ−ＭＴＣＨ上で送信された進行中のセッションを有するすべてのＭＢＭＳサービスのリストを提供する。対象のＴＭＧＩがＳＣ−ＭＣＣＨで利用可能である場合、ＵＥは、サブフレームオケージョンにおいてＧ−ＲＮＴＩでスクランブルされたＰＤＣＣＨ、すなわちＳＣ−ＰＴＭを監視する。ＳＣ−ＰＴＭの現在のスケジューリング期間は８，１９２ｍｓまで、すなわちｓｆ８１９２までに規定されているので、ＵＥはｅＤＲＸサイクルに比べてはるかに短い期間である８秒ごとにＰＤＣＣＨを復号する必要がある。

考察２：ＳＣ−ＰＴＭ受信に関心のあるＩＤＬＥ ＵＥは、ＳＣ−Ｎ−ＲＮＴＩ及び／又はＧ−ＲＮＴＩでスクランブルされたＰＤＣＣＨを、その設定されたｅＤＲＸサイクルよりも短い時間で復号する必要があるかもしれない。

ＦｅＭＴＣ ＵＥの追加の電力消費を回避するために、例えば、Ｈ−ＳＦＮを使用するｅＤＲＸメカニズムと整合するように、ＳＣ−ＭＣＣＨ変更通知メカニズム及び／又はＳＣ−ＰＴＭスケジューリング期間を延長する必要があることが議論されるべきである。

提案１：ＲＡＮ２は、ＵＥの電力消費を最小限に抑えるために、ＳＣ−ＭＣＣＨ変更通知及びＳＣ−ＰＴＭスケジューリング期間が延長されるかどうかを議論するべきである。

（２．２．リリース１４マルチキャスト要件）
（２．２．１．ファームウェア更新ユースケースのサポート）
ＷＩＤは、ＦｅＭＴＣ ＵＥのためのＤＬマルチキャストのモチベーション、例えば、ファームウェア又はソフトウェアアップデート、グループメッセージ配信を特定する。レガシーｅＭＢＭＳの主なアプリケーションとして想定されたグループ通信及びビデオストリーミングと比較して、より信頼性の高い通信を必要とする。すなわち、１つのパケットだけが失われてもファームウェアは意味をなさない。

ユニキャスト伝送に関して、ＨＡＲＱ及びＡＲＱ機能は、ファームウェア更新の場合の要求されるＱｏＳに合致する可能性がある信頼できるパケット転送を保証する。しかし、近い将来、ＩｏＴデバイスに期待される大量の接続数を考慮すると、信頼性の高い通信はユニキャスト（及び場合によっては堅牢なネットワーク展開のみ）に依存していることはもはや意味をなさない。

一方、マルチキャスト送信は、複数のＵＥへのデータ転送を同時に提供することができ、これは、セル内の膨大な数のデバイスに役立つために有益である。しかし、既存のマルチキャスト方式は、パケットのデコードに失敗したプロトコルのサポートがないため、場合によっては十分に堅牢ではない。

考察３：ユニキャスト伝送は、例えばファームウェアなどの信頼できるデータ転送を保証することができ、マルチキャスト伝送は、より多くの数のＵＥ、大規模なＭＴＣデバイスに役立つことができる。

改善のアプローチは、ａ）ユニキャストとマルチキャストの組み合わせ、ｂ）ユニキャストへの拡張、ｃ）マルチキャストへの拡張の３つであり、ａ）とｃ）のみがＷＩの範囲に沿っている。

ａ）に関して、マルチキャストを介してダウンロードされたファイルの完全性チェックに失敗したＵＥは、例えば、上位レイヤ開始の再送信要求によってユニキャストを介してファイルを再取得することが予想される。ＡＳ仕様の観点からは単純なメカニズムであるが、ＵＥの電力消費の観点からはいくつかの欠点がある。例えば、パケットの一部が首尾よく復号されなくても、ＵＥはファイル全体を再取得する必要があり、特にファイルがファームウェア／ソフトウェアなどの小さいサイズでない場合は効率的ではない。さらに、ＵＥがＩＤＬＥ、すなわちマルチキャストのアイドルモード受信中であった場合、ＵＥはユニキャスト転送のためのＲＲＣ接続を確立する必要があり、接続確立／再開のために追加のシグナリングが必要となる。

ｃ）に関しては、マルチキャストのＡＳ仕様に再送方式を導入するアプローチの１つであるかもしれない。それは、ファームウェアを完全にダウンロードするためにＦｅＭＴＣ ＵＥの効率を改善する一方で、例えば、ＵＬフィードバック及び／又は再送信メカニズムのための標準化努力を必要とする。低電力消費がＭＴＣデバイスの重要な性能であることを考慮すると、再送信スキームはＤＬマルチキャストのために考慮されるべきである。

提案２：ＲＡＮ２は、ＵＬフィードバックを含む再送方式がＦｅＭＴＣ ＵＥ用のＳＣ−ＰＴＭに導入されるべきかどうかについて議論すべきである。

（２．２．２．強化カバレッジのサポート）
現在、Ｃｏｎｎｅｃｔｅｄ及びＩＤＬＥのリリース１４前のＵＥは、ＭＢＭＳサービスを受信することができる。リリース１４のＵＥは強化カバレッジにあると仮定されるので、現在のマルチキャストメカニズムの原則が適用されるべきである。

提案３：ＣｏｎｎｅｃｔｅｄとＩＤＬＥのリリース１４のＵＥは、強化カバレッジでＳＣ−ＰＴＭも受信できる必要がある。

信号の繰り返しは、帯域幅を削減したアクセス技術に加えて、リリース１３のカバレッジ強化をサポートするための重要なコンポーネントである。この繰り返し送信技術は、強化カバレッジにおいてＵＥへのリリース１４マルチキャストに再使用されると考えられる。ＲＡＮ２の観点からは、少なくともＢＣＣＨ（ＳＩＢ２０）及びＤＬ−ＳＣＨ（ＳＣ−ＭＣＣＨ及びＳＣ−ＰＴＭ）を考慮する必要があり、これらのチャネルの（最大）繰り返し回数はＲＲＣによって既に提供されている、すなわちｐｄｓｃｈ−ｍａｘＮｕｍＲｅｐｅｔｉｔｉｏｎＣＥｍｏｄｅＡ、ｐｄｓｃｈ−ｍａｘＮｕｍＲｅｐｅｔｉｔｉｏｎＣＥｍｏｄｅＢ及びｍｐｄｃｃｈ−ＮｕｍＲｅｐｅｔｉｔｉｏｎ。ＭＰＤＣＣＨは、ＰＤＳＣＨの繰り返しの実際の回数を提供する。対応するＰＤＳＣＨを割り当てるＭＰＤＣＣＨが使用される場合、ＳＣ−ＭＣＣＨ／ＳＣ−ＰＴＭ送信のためのｍｐｄｃｃｈ−ＮｕｍＲｅｐｅｔｉｔｉｏｎは、ＩＤＬＥ ＵＥに対してＳＩＢ中で提供する必要がある。さらに、ＳＣ−ＭＣＣＨの繰り返しは、アクセスレイテンシを制限するために、ＳＩＢ２０、すなわちｓｃ−ｍｃｃｈ−ＲｅｐｅｔｉｏｎＰｅｒｉｏｄ−ｒ１３で既に提供されている。それは強化カバレッジをサポートするために再利用することもできる。ＲＡＮ２がこれらの変更が必要であることに同意する場合、ＲＡＮ１にはＲＡＮ２の意見も通知する必要がある。

考察４：強化カバレッジでのマルチキャスティングでは、繰り返し技法を再利用する必要がある。

提案４：ＲＡＮ２が考察４に同意する場合、希望の変更を通知するためにＬＳがＲＡＮ１に送られるべきである。

現在のアイドルモード手順によれば、ＭＢＭＳサービスを受信又は関心を持つＵＥは、他の周波数にわたってＳＣ−ＰＴＭを提供する周波数に優先順位を付けること、すなわち最も高い優先順位を考慮することができる。一方、「カバレッジを向上させるためのセル選択基準Ｓによるランク付けは、現在のサービングセルが強化されたカバレッジを使用してしかアクセスできない場合に周波数内（intra-frequency）及び周波数間（inter-frequency）セル再選択に適用される」と規定されており、ＵＥが強化カバレッジ内にある場合、すべての周波数を等しい優先度とする。強化カバレッジにおけるＳＣ−ＰＴＭ受信は、リリース１３において明確に想定されていないので、現在の仕様により、強化カバレッジのＵＥは、通常のカバレッジで行われるようにＳＣ−ＰＴＭ周波数を優先させることができることが確認される。また、ＲＡＮ２は、仕様にメモを追加するなど、いくつかの小さな強化が必要かどうかを議論する必要がある。

提案５：ＲＡＮ２は、強化カバレッジ内のＵＥが関心のあるマルチキャストサービスを提供する周波数に優先順位を付けることを許可されているかどうかを議論し、明確にすべきである。

（２．２．３．その他の最適化）
（２．２．３．１．サービス継続性）
現在の仕様では、ＳＣ−ＭＣＣＨは、ＳＣＰＴＭ−ＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔ内の隣接セル情報、すなわち物理セルＩＤ及び周波数を提供する。サービングセルがＳＣ−ＰＴＭを提供しないＴＭＧＩにＵＥの関心がある場合、ＵＥは、関心のあるＴＭＧＩを探索するために、隣接セルのＳＣ−ＭＣＣＨを復号する必要がある。これは、周波数間測定よりもさらに復号化するためにＵＥのバッテリを消費し、これは、このＷＩで幾分強化されたＵＥの移動性に大きな影響を及ぼす。したがって、低消費電力でＦｅＭＴＣ ＵＥのモビリティを促進するために、いくつかの追加情報をブロードキャストする必要があるかどうかについて議論すべきである。

提案６：ＲＡＮ２は、より低い電力消費でＵＥの移動性を支援するために、例えばＳＣ−ＭＣＣＨにおいて追加の情報がブロードキャストされるか否かを議論すべきである。

（２．２．３．２．ワンショットマルチキャスト）
２．２．１節で説明したように、ファームウェア／ソフトウェアアップデートのユースケースは、ブロードキャストサービスではなくマルチキャストタイプのサービスである。ファームウェアはファイルのセットであると仮定することもできるので、同じファームウェアが何度もマルチキャストされることは効率的ではない。現在のＭＢＭＳサービスでは、「アプリケーション／サービス層が、各サービスに対して、ＴＭＧＩ、セッションの開始及び終了時間、周波数及びＭＢＭＳサービスエリア識別子をＵＳＤで提供すると仮定している。これは、ワンショットマルチキャスティングを実行することを可能にすることができる。すなわち、１つのファームウェアは、適切な開始／終了時間をＵＳＤで設定することによって、一度だけマルチキャストされる。ただし、ユニキャストでＵＳＤを取得する必要がある。したがって、関連するＵＥは、ファームウェアが配信されるときに少なくとも１回はＲＲＣ接続を確立する必要があり、ＮＷ容量及びＵＥ電力消費の観点からは効率的ではない。したがって、ＲＡＮレベルの最適化、例えばＵＳＤと相互作用する／補完する開始／停止時間、ＴＭＧＩベースのページングなどのＲＡＮレベル情報など、ある種の最適化が必要な場合がある。

提案７：ＲＡＮ２は、ワンショットマルチキャスト配信を容易にするためにＲＡＮレベルの最適化が必要かどうかを議論すべきである。

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

Claims (6)

1. 移動通信システムのためのユーザ装置であって、
   システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成された送受信機と、
   前記送受信機を用いて、ＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）を用いてＭＢＭＳ（Ｍｕｌｔｉｍｅｄｉａ Ｂｒｏａｄｃａｓｔ Ｍｕｌｔｉｃａｓｔ Ｓｅｒｖｉｃｅ）サービスを提供する基地局との無線通信を行う制御部と、を備え、
   前記制御部は、前記制限帯域幅以下の帯域幅を有する物理下りリンク制御チャネルの最大繰り返し回数及び前記制限帯域幅以下の帯域幅を有する物理下りリンク共有チャネルの最大繰り返し回数のうち少なくとも一方を示す第１情報を前記基地局から受信する処理を行い、
   前記第１情報は、前記ＳＣ−ＰＴＭ用のシステム情報ブロック又は前記ＳＣ−ＰＴＭ用のマルチキャスト制御チャネルにより前記基地局から送信される ユーザ装置。
2. 前記制御部は、前記所定物理下りリンク制御チャネル上で前記基地局から更新通知情報を受信する処理を行い、
   前記更新通知情報は、
   前記システム情報ブロックの更新を示す第１の更新通知、
   前記マルチキャスト制御チャネルの更新を示す第２の更新通知、
   前記マルチキャスト制御チャネル中で示される特定のＭＢＭＳサービスの更新を示す第３の更新通知、のうち少なくとも１つを含む
   請求項１に記載のユーザ装置。
3. 前記制御部は、特定のＭＢＭＳサービスの提供が終了されることを示す情報を前記基地局から受信する処理を行う
   請求項１に記載のユーザ装置。
4. 前記制御部は、前記基地局が管理するサービングセルに隣接する隣接セルが提供するＭＢＭＳサービスに対応付けられたグループＲＮＴＩを前記基地局から前記サービングセルを介して受信する処理を行い、
   前記グループＲＮＴＩは、前記マルチキャスト制御チャネルにより前記基地局から送信される
   請求項１に記載のユーザ装置。
5. 移動通信システムのための基地局であって、
   システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成されたユーザ装置に対して、ＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）を用いてＭＢＭＳサービスを提供する制御部を備え、
   前記制御部は、前記制限帯域幅以下の帯域幅を有する物理下りリンク制御チャネル（ＰＤＣＣＨ）の最大繰り返し回数及び前記制限帯域幅以下の帯域幅を有する物理下りリンク共有チャネル（ＰＤＳＣＨ）の最大繰り返し回数のうち少なくとも一方を示す第１情報を前記ユーザ装置に送信する処理を行い、
   前記第１情報は、前記ＳＣ−ＰＴＭ用のシステム情報ブロック又は前記ＳＣ−ＰＴＭ用のマルチキャスト制御チャネルにより送信される
   基地局。
6. システム送受信帯域よりも狭い制限帯域幅内で無線信号を送受信するように構成されるユーザ装置と、ＳＣ−ＰＴＭ（Ｓｉｎｇｌｅ Ｃｅｌｌ Ｐｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）を用いてＭＢＭＳサービスを提供する基地局と、を有する移動通信システムに用いられる方法であって、
   前記ユーザ装置が、前記制限帯域幅以下の帯域幅を有する物理下りリンク制御チャネル（ＰＤＣＣＨ）の最大繰り返し回数及び前記制限帯域幅以下の帯域幅を有する物理下りリンク共有チャネル（ＰＤＳＣＨ）の最大繰り返し回数のうち少なくとも一方を示す第１情報を前記基地局から受信し、
   前記第１情報は、前記ＳＣ−ＰＴＭ用のシステム情報ブロック又は前記ＳＣ−ＰＴＭ用のマルチキャスト制御チャネルにより前記基地局から送信される
   方法。

Images