JP6741969B2 - 移動通信システム - Google Patents

Description

本発明は、マルチキャスト／ブロードキャストサービスを提供する移動通信システムに関する。

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

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

一実施形態に係る移動通信システムは、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する第１の無線端末と、前記限定周波数帯よりも広い周波数帯を用いて無線信号を送受信することが可能な第２の無線端末と、ＳＣ−ＰＴＭ伝送用の制御チャネルであるＳＣ−ＭＣＣＨによって、ＳＣ−ＰＴＭ伝送用のトラフィックチャネルであるＳＣ−ＭＴＣＨの設定情報を送信する基地局と、を備える。前記基地局は、前記ＳＣ−ＭＴＣＨの設定情報が変更され得るＳＣ−ＭＣＣＨ変更周期として、前記第１の無線端末に対して第１の周期を設定し、前記第２の無線端末に対して第２の周期を設定する。前記第１の周期は、前記第２の周期よりも長い。

一実施形態に係る移動通信システムは、繰り返し送信を含むカバレッジ強化技術を用いて、ＳＣ−ＰＴＭ伝送により無線端末にＭＢＭＳサービスを配信する基地局と、前記ＭＢＭＳサービスを受信する無線端末と、を備える。前記基地局は、前記ＳＣ−ＰＴＭ伝送用の複数の特定システム情報ブロックを送信する。前記複数の特定システム情報ブロックは、第１の特定システム情報ブロックと、適用されるカバレッジ拡張レベルが前記第１の特定システム情報ブロックとは異なる第２の特定システム情報ブロックと、を含む。

一実施形態に係る移動通信システムは、ＳＣ−ＰＴＭ伝送によりＭＢＭＳサービスを配信する基地局と、前記ＭＢＭＳサービスを受信する無線端末と、を備える。前記基地局は、前記ＳＣ−ＰＴＭ伝送用の特定システム情報ブロックを前記無線端末に送信する。前記無線端末は、前記特定システム情報ブロックに基づいて、前記ＳＣ−ＰＴＭ伝送に所定方式が用いられているか否かを判断する。前記所定方式は、ＰＤＣＣＨを用いない準静的スケジューリングをＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨに適用する第１の方式、同一セルが複数のＳＣ−ＭＣＣＨを用いる第２の方式、前記ＳＣ−ＭＣＣＨを用いずに前記特定システム情報ブロックにより前記ＳＣ−ＭＴＣＨのスケジューリングを行う第３の方式、のうち少なくとも１つを含む。

一実施形態に係る移動通信システムは、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する無線端末を備える。前記無線端末は、第１のセルから帯域幅情報を受信する。前記帯域幅情報は、前記第１のセルとは異なる第２のセルがＳＣ−ＰＴＭ伝送に用いる周波数帯域幅に関する情報である。

一実施形態に係る移動通信システムは、送受信する無線信号の帯域幅の上限が異なる複数の無線端末と、送信方式が異なる複数の制御情報を前記複数の無線端末に送信し、かつ、同一のデータを前記複数の無線端末に送信する基地局と、を備える。前記基地局は、前記同一のデータを運搬する同一のＰＤＳＣＨリソースをスケジューリングするためのスケジューリング情報を前記複数の制御情報に含める。

一実施形態に係る移動通信システムは、複数のサブフレームにわたって制御情報を繰り返し送信した後、データの繰り返し送信を開始する基地局と、前記制御情報を受信し、受信した制御情報に基づいて前記データを受信する無線端末と、を備える。前記基地局は、前記制御情報の繰り返し送信を終了する第１のサブフレームから前記データの送信を開始する第２のサブフレームまでのサブフレーム数を示す情報を前記無線端末に通知する。

一実施形態に係る移動通信システムは、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する無線端末を備える。前記無線端末は、前記限定周波数帯に専用の第１の参照信号を用いて前記無線信号の復調を行う第１の受信動作と、前記限定周波数帯に専用ではない第２の参照信号を用いて前記無線信号の復調を行う第２の受信動作と、の何れかを選択する。前記無線端末は、ＳＣ−ＰＴＭ受信を行う場合には、前記第１の受信動作ではなく前記第２の受信動作を選択する。

一実施形態に係る移動通信システムは、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する無線端末を備える。異なる限定周波数帯を用いてユニキャスト受信及びＳＣ−ＰＴＭ受信を同時に行う能力を前記無線端末が有する場合、前記無線端末は、前記能力を有することを示す能力情報を基地局に送信する。

一実施形態に係る移動通信システムは、アクセス規制を行うためのアクセス規制信号をブロードキャスト又はマルチキャストで送信する基地局と、前記アクセス規制信号に基づいて、前記基地局へのアクセスが規制されているか否かを判断する無線端末と、を備える。前記アクセス規制信号は、ユニキャスト通信よりもＭＢＭＳ受信を優先する第１の無線端末が前記基地局にアクセスすることを規制する第１の情報、又は前記ＭＢＭＳ受信よりも前記ユニキャスト通信を優先する第２の無線端末が前記基地局にアクセスすることを規制する第２の情報を含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１１は、ＳＩＢ２０、ＳＣ−ＭＣＣＨ、及びＳＣ−ＭＴＣＨを示す図である。

図１１に示すように、ＳＩＢ２０は、ＳＣ−ＭＣＣＨの取得に必要な情報（ＳＣ−ＭＣＣＨ Ｃｏｎｆｉｇ）を含む。ＳＩＢ２０は、１つのセルに１つのみ存在する。詳細については後述するが、１つのセルに複数のＳＩＢ２０が存在してもよい。

ＳＣ−ＭＣＣＨは、ＳＣ−ＭＴＣＨの取得に必要な情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を含む。当該情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）は、図１０に示すＳＣＰＴＭ設定情報（ＳＣＰＴＭ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）に相当する。ＳＣ−ＭＣＣＨは、１つのセルに１つのみ存在する。詳細については後述するが、１つのセルに複数のＳＣ−ＭＣＣＨが存在してもよい。或いは、ＳＣ−ＭＣＣＨを不要として、ＳＩＢ２０にＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇを含めてもよい。

ＳＣ−ＭＴＣＨは、ＭＢＭＳサービス（ＴＭＧＩ）ごとに設けられる。ＳＣ−ＭＴＣＨは、対応するＭＢＭＳサービスに属するデータ（マルチキャストデータ）を含む。

ＳＩＢ２０、ＳＣ−ＭＣＣＨ、及びＳＣ−ＭＴＣＨのそれぞれについて、物理レイヤにおいてＰＤＳＣＨを割り当てるためにＰＤＣＣＨが用いられる。詳細については後述するが、ＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨに準静的スケジューリングを導入することにより、ＳＣ−ＭＣＣＨに用いるＰＤＣＣＨ及び／又はＳＣ−ＭＴＣＨに用いるＰＤＣＣＨを不要としてもよい。

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

なお、ｅＭＴＣ ＵＥについて、６リソースブロックの帯域幅に限定された限定周波数帯は、「狭帯域（ＮＢ：ｎａｒｒｏｗｂａｎｄ）」と称される。ＮＢ−ＩｏＴ ＵＥについて、１リソースブロックの帯域幅に限定された限定周波数帯は、「キャリア」と称される。

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

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

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

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

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

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

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

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

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

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

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

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

（第１実施形態）
以下において、第１実施形態について説明する。第１実施形態は、上述した新たなカテゴリのＵＥ（ｅＭＴＣ ＵＥ及び／又はＮＢ−ＩｏＴ ＵＥ）を含む複数のＵＥ１００に対して、ＳＣ−ＰＴＭ伝送によりＭＢＭＳサービスのマルチキャスト配信を行うシナリオを想定する。

第１実施形態に係るｅＮＢ２００は、繰り返し送信を含むカバレッジ強化技術を用いて、ＳＣ−ＰＴＭ伝送によりＵＥ１００にＭＢＭＳサービスを配信する。ｅＮＢ２００は、ＳＣ−ＰＴＭ伝送用の複数の特定システム情報ブロックを送信する。以下において、特定システム情報ブロックがＳＩＢ２０である一例を説明するが、特定システム情報ブロックは、ＳＩＢ２０とは異なる新たなＳＩＢ（例えばＳＩＢ２２）であってもよい。

第１実施形態において、複数のＳＩＢ２０は、第１のＳＩＢ２０と、第１のＳＩＢ２０とはカバレッジ拡張レベル（ＣＥレベル）が異なる第２のＳＩＢ２０と、を含む。これにより、新たなカテゴリのＵＥ１００に対してＳＩＢ２０を適切に送信することができる。第１のＳＩＢ２０は、第２のＳＩＢ２０に適用されるＣＥレベルを示す情報、及び／又は第２のＳＩＢ２０に対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）を含む。これにより、ＵＥ１００は、第１のＳＩＢ２０に基づいて、第２のＳＩＢ２０を取得すべきか否かを判断することができる。第１のＳＩＢ２０は、第２のＳＩＢ２０のスケジューリング情報を含んでもよい。なお、第１のＳＩＢ２０に適用されるＣＥレベルは、固定であってもよいし、ＳＩＢ２０以外のＳＩＢ等によりＵＥ１００に通知されてもよい。

さらに、第１のＳＩＢ２０は、ＳＣ−ＭＣＣＨに適用されるＣＥレベルを示す情報、及び／又はＳＣ−ＭＣＣＨに対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）を含んでもよい。

第１のＳＩＢ２０に適用される第１のＣＥレベルは、第２のＳＩＢ２０に適用される第２のＣＥレベルよりも高くてもよい。言い換えると、第１のＳＩＢ２０には、第２のＳＩＢ２０に比べて多い繰り返し送信回数が適用され得る。これにより、ＵＥ１００は、第１のＳＩＢ２０をより確実に受信することができる。

図１４は、第１実施形態に係るＳＣ−ＰＴＭ伝送の第１の例を示す図である。

図１４に示すように、ｅＮＢ２００は、複数のＳＩＢ２０を送信する。第１の例において、第１のＳＩＢ２０（ＳＩＢ２０−ＮＢ）にはＣＥレベル３が適用されており、第２のＳＩＢ２０（ＳＩＢ２０−ＮＢ）にはＣＥレベル１が適用されている。なお、「−ＮＢ」は、ＮＢ−ＩｏＴ用であることを意味する。ここでは、第２のＳＩＢ２０が１つのみである一例を示しているが、適用されるＣＥレベルが異なる複数の第２のＳＩＢ２０が存在してもよい。また、第１のＳＩＢ２０及び第２のＳＩＢ２０がＮＢ−ＩｏＴ ＵＥ向けのＳＩＢ２０である一例を示しているが、第１のＳＩＢ２０及び第２のＳＩＢ２０は、ｅＭＴＣ ＵＥ向けのＳＩＢ２０であってもよい。

第１のＳＩＢ２０は、第２のＳＩＢ２０を指し示す（ｐｏｉｎｔｉｎｇ）ための情報を含む。当該ｐｏｉｎｔｉｎｇ情報は、第２のＳＩＢ２０に適用されるＣＥレベルを示す情報、第２のＳＩＢ２０に対応するＭＢＭＳサービスの識別子（ＴＭＧＩ）、第２のＳＩＢ２０のスケジューリング情報のうち、少なくとも１つを含む。第２のＳＩＢ２０のスケジューリング情報は、第２のＳＩＢ２０の周期（ｐｅｒｉｏｄｉｃｉｔｙ）及び／又は持続時間（ｄｕｒａｔｉｏｎ）を含んでもよい。また、第２のＳＩＢ２０のスケジューリング情報は、第２のＳＩＢ２０の開始サブフレーム、オフセット、変更周期（Ｍｏｄｉｆｉｃａｔｉｏｎ ｐｅｒｉｏｄ）、最大再送回数、周波数ホッピング設定のうち、少なくとも１つを含んでもよい。

また、第１の例において、ＳＣ−ＭＴＣＨのスケジューリング情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）をＳＩＢ２０に含めることにより、ＳＣ−ＭＣＣＨを不要としている。第１のＳＩＢ２０は、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨの取得に必要な情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を含む。また、第２のＳＩＢ２０は、ＴＭＧＩ＃１に対応するＳＣ−ＭＴＣＨ及びＴＭＧＩ＃２に対応するＳＣ−ＭＴＣＨの取得に必要な情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を含む。

図１５は、第１実施形態に係るＳＣ−ＰＴＭ伝送の第２の例を示す図である。

図１５に示すように、ｅＮＢ２００は、複数のＳＩＢ２０を送信する。第２の例において、第１のＳＩＢ２０（ＳＩＢ２０−ＮＢ）にはＣＥレベル３が適用されており、第２のＳＩＢ２０（ＳＩＢ２０−ＢＬ）にはＣＥレベル１が適用されている。なお、「−ＢＬ」は、ｅＭＴＣ用であることを意味する。ここでは、第１のＳＩＢ２０がＮＢ−ＩｏＴ ＵＥ向けのＳＩＢ２０であり、第２のＳＩＢ２０がｅＭＴＣ ＵＥ向けのＳＩＢ２０である一例を示している。第１のＳＩＢ２０は１キャリア（１リソースブロック）で送信され、第２のＳＩＢ２０は１ＮＢ（６リソースブロック）で送信される。よって、ｅＭＴＣ ＵＥは、第１のＳＩＢ２０を受信することが可能である。また、第１の例と同様に、第１のＳＩＢ２０は、第２のＳＩＢ２０を指し示すためのｐｏｉｎｔｉｎｇ情報を含む。

第２の例において、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨのスケジューリング情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を第１のＳＩＢ２０に含めることにより、第１のＳＩＢ２０に対応するＳＣ−ＭＣＣＨを不要としている。言い換えると、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨの設定は、第１のＳＩＢ２０により１ステップで行われる（Ｏｎｅ−ｓｔｅｐ ｃｏｎｆｉｇｕｒａｔｉｏｎ）。

第２の例において、第２のＳＩＢ２０は、複数のＳＣ−ＭＣＣＨのそれぞれのスケジューリング情報を含む。複数のＳＣ−ＭＣＣＨは、ＣＥレベル１が適用される第１のＳＣ−ＭＣＣＨと、カバレッジ強化技術が適用されない第２のＳＣ−ＭＣＣＨと、を含む。第１のＳＣ−ＭＣＣＨには、ＰＤＣＣＨを用いない準静的スケジューリング（Ｓｅｍｉ−ｓｔａｔｉｃ ｓｃｈｅｄｕｌｉｎｇ）が適用される。第２のＳＣ−ＭＣＣＨには、ＰＤＣＣＨを用いた動的スケジューリング（Ｄｙｎａｍｉｃ ｓｃｈｅｄｕｌｉｎｇ）が適用される。

第１のＳＣ−ＭＣＣＨは、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨ及びＴＭＧＩ＃２に対応するＳＣ−ＭＴＣＨの取得に必要な情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を含む。また、第２のＳＣ−ＭＣＣＨは、ＴＭＧＩ＃２に対応するＳＣ−ＭＴＣＨ及びＴＭＧＩ＃１に対応するＳＣ−ＭＴＣＨの取得に必要な情報（ＳＣ−ＭＴＣＨ Ｃｏｎｆｉｇ）を含む。ここで、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨは、第１のＳＩＢ２０（ＣＥレベル３）及び第１のＳＣ−ＭＣＣＨ（ＣＥレベル１）の両方でスケジューリングされている。このような場合、ＣＥレベルの高い第１のＳＩＢ２０に合わせるように、ＴＭＧＩ＃３に対応するＳＣ−ＭＴＣＨにはＣＥレベル３が適用されてもよい。同様な理由で、ＴＭＧＩ＃２に対応するＳＣ−ＭＴＣＨには、ＣＥレベル１が適用されてもよい。

なお、第１のＳＩＢ２０は、マスタＳＩＢ２０（ｓｉｂＴｙｐｅ２０−ｍａｓｔｅｒ）と称されてもよい。第２のＳＩＢ２０は、スレーブＳＩＢ２０（ｓｉｂＴｙｐｅ２０−ｓｌａｖｅ）と称されてもよい。

第１実施形態において、複数のＳＩＢ２０のそれぞれに適用されるＣＥレベルを固定としてもよい。一例として、カバレッジ強化技術が適用されない通常カバレッジ向けのＳＩＢ２０（ＳＩＢ２０−ＮＣ）と、ＣＥレベル１が適用されるＳＩＢ２０（ＳＩＢ２０−ＣＥ１）と、ＣＥレベル２が適用されるＳＩＢ２０（ＳＩＢ２０−ＣＥ２）と、・・・が存在してもよい。

第１実施形態において、複数のＳＩＢ２０は、システム情報ブロック・タイプ１（ＳＩＢ１）によりスケジューリングされてもよい。図１６は、第１実施形態に係るＳＩＢ１の例を示す図である。

図１６（ａ）に示すように、ＳＩＢ１は、ＳＩＢ１以外の各ＳＩＢのスケジューリング情報（Ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏ）を含む。ＳＩＢのスケジューリング情報は、周期（ｓｉ−Ｐｅｒｉｏｄｉｃｉｔｙ）及びマッピング情報（ｓｉｂ−ＭａｐｐｉｎｇＩｎｆｏ）を含む。マッピング情報（ｓｉｂ−ＭａｐｐｉｎｇＩｎｆｏ）は、ＳＩＢタイプ（ＳＩＢ−Ｔｙｐｅ）を含む。図１６（ａ）に示す例において、マッピング情報（ｓｉｂ−ＭａｐｐｉｎｇＩｎｆｏ）中のＳＩＢタイプ（ＳＩＢ−Ｔｙｐｅ）は、マスタＳＩＢ２０（ｓｉｂＴｙｐｅ２０−ｍａｓｔｅｒ）及びスレーブＳＩＢ２０（ｓｉｂＴｙｐｅ２０−ｓｌａｖｅ）を含む。或いは、図１６（ｂ）に示すように、マッピング情報（ｓｉｂ−ＭａｐｐｉｎｇＩｎｆｏ）中のＳＩＢタイプ（ＳＩＢ−Ｔｙｐｅ）は、カバレッジ強化技術が適用されないＳＩＢ２０（ＳＩＢ２０−ＮＣ）と、ＣＥレベル１が適用されるＳＩＢ２０（ＳＩＢ２０−ＣＥ１）と、ＣＥレベル２が適用されるＳＩＢ２０（ＳＩＢ２０−ＣＥ２）と、を含んでもよい。同様に、ＳＩＢ２０−ＣＥ３を含んでもよい。これらの情報は、上述したＳＩＢ２０の何れかによって報知（ブロードキャスト）されてもよい。

次に、第１実施形態に係るＵＥ１００の動作について説明する。

第１実施形態に係るＵＥ１００は、ＳＣ−ＰＴＭ伝送によりｅＮＢ２００から配信されるＭＢＭＳサービスを受信する。ＵＥ１００は、ＳＣ−ＰＴＭ伝送用のＳＩＢ２０（特定システム情報ブロック）をｅＮＢ２００から受信する。ＵＥ１００は、ＳＩＢ２０に基づいて、ＳＣ−ＰＴＭ伝送に所定方式が用いられているか否かを判断する。所定方式は、ＰＤＣＣＨを用いない準静的スケジューリングをＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨに適用する第１の方式、同一セルが複数のＳＣ−ＭＣＣＨを用いる第２の方式、ＳＣ−ＭＣＣＨを用いずにＳＩＢ２０によりＳＣ−ＭＴＣＨのスケジューリングを行う第３の方式、のうち少なくとも１つを含む。ＵＥ１００がＳＣ−ＭＣＣＨをｅＮＢ２００から受信する場合、ＵＥ１００は、ＳＣ−ＭＣＣＨに基づいて、ＳＣ−ＰＴＭ伝送に第１の方式及び／又は第２の方式が用いられているか否かを判断してもよい。

図１７は、第１実施形態に係るＵＥ１００の動作例を示す図である。

図１７に示すように、ステップＳ１０１において、ＵＥ１００は、ＳＩＢ１をｅＮＢ２００から受信する。ＵＥ１００は、ＳＩＢ１に基づいて、複数のＳＩＢ２０のスケジューリングを把握する。

ステップＳ１０２において、ＵＥ１００は、第１のＳＩＢ２０をｅＮＢ２００から受信する。ＵＥ１００は、第１のＳＩＢ２０に基づいて、第２のＳＩＢ２０の詳細情報（例えば、ＴＭＧＩ及びＣＥレベル等）を把握する。ＵＥ１００は、自身が興味を持つＭＢＭＳサービス（ＴＭＧＩ）に対応する第２のＳＩＢ２０を特定し、特定した第２のＳＩＢ２０を受信してもよい（ステップＳ１０３）。この場合、ＵＥ１００は、第２のＳＩＢ２０に適用されるＣＥレベルを特定し、特定したＣＥレベルで当該第２のＳＩＢ２０を受信してもよい。

ステップＳ１０４において、ＵＥ１００は、第１のＳＩＢ２０（及び第２のＳＩＢ２０）に基づいて、ＳＣ−ＰＴＭ伝送に所定方式が用いられているか否かを判断する。ＵＥ１００は、所定方式が用いられていると判断した場合、所定方式に従って受信を行う。

ＵＥ１００は、受信したＳＩＢ２０中でＳＣ−ＭＣＣＨの受信用設定が通知されていない場合、ＳＣ−ＭＣＣＨを用いずにＳＩＢ２０によりＳＣ−ＭＴＣＨのスケジューリングを行う第３の方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。

ＵＥ１００は、受信したＳＩＢ２０中でＳＣ−ＭＣＣＨの受信用設定（例えば、ｏｃｃａｓｉｏｎ、ｒｅｐｅｔｉｔｉｏｎ、ＮＢ／ｃａｒｒｉｅｒ番号、ＴＭＧＩ等）が複数通知されている場合、同一セルが複数のＳＣ−ＭＣＣＨを用いる第２の方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。

ＵＥ１００は、受信したＳＩＢ２０中でＳＣ−ＭＴＣＨの受信用設定（ｓｃｈｅｄｕｌｉｎｇ ｉｎｆｏ、ｒｅｐｅｔｉｔｉｏｎ等）が通知されている場合、ＳＣ−ＭＣＣＨを用いずにＳＩＢ２０によりＳＣ−ＭＴＣＨのスケジューリングを行う第３の方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。

ＵＥ１００は、受信したＳＩＢ２０中で第１の方式乃至第３の方式の少なくとも１つを指定する指定情報が通知されている場合、指定された方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。指定情報は、ＰＤＣＣＨ（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）を受信しなくてもよいことを示す情報又はＰＤＣＣＨ（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）を受信すべきことを示す情報を含んでもよい。

或いは、ＵＥ１００は、ＳＩＢ２０とは異なる新たなＳＩＢ（例えばＳＩＢ２２）を受信した場合、第１の方式乃至第３の方式のうち、予め定められた方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。

第３の方式が用いられていない場合、ステップＳ１０５において、ＵＥ１００は、受信したＳＩＢ２０に基づいてＳＣ−ＭＣＣＨを受信してもよい。この場合、ステップＳ１０６において、ＵＥ１００は、受信したＳＣ−ＭＣＣＨに基づいて、ＳＣ−ＰＴＭ伝送に第１の方式及び／又は第２の方式が用いられているか否かを判断してもよい。一例として、ＵＥ１００は、受信したＳＣ−ＭＣＣＨ中で第１の方式及び第２の方式の少なくとも１つを指定する指定情報が通知されている場合、指定された方式がＳＣ−ＰＴＭ伝送に用いられていると判断してもよい。指定情報は、ＰＤＣＣＨ（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）を受信しなくてもよいことを示す情報又はＰＤＣＣＨ（ＭＰＤＣＣＨ又はＮＰＤＣＣＨ）を受信すべきことを示す情報を含んでもよい。なお、ＵＥ１００は、受信したＳＣ−ＭＣＣＨにおいて、ＳＣ−ＭＴＣＨの受信用設定としてＣＥレベル情報（ｒｅｐｅｔｉｔｉｏｎ等）が含まれる場合、ＣＥレベル情報に基づいてＳＣ−ＭＴＣＨの受信を行なってもよい。

ステップＳ１０７において、ＵＥ１００は、ＳＩＢ２０及び／又はＳＣ−ＭＣＣＨに基づいて、ＳＣ−ＭＴＣＨを受信する。

（第２実施形態）
以下において、第２実施形態について、第１実施形態との相違点を主として説明する。第２実施形態は、ＳＣ−ＰＴＭ伝送により配信されるＭＢＭＳサービスを受信している又は受信に興味を持つ新たなカテゴリのＵＥ（ｅＭＴＣ ＵＥ及び／又はＮＢ−ＩｏＴ ＵＥ）が一のセルから他のセルに移動するシナリオを想定する。

第２実施形態に係るＵＥ１００は、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する。ＵＥ１００がｅＭＴＣ ＵＥである場合、限定周波数帯は、６リソースブロックの帯域幅に限定された「狭帯域（ＮＢ）」である。ＵＥ１００がＮＢ−ＩｏＴ ＵＥである場合、限定周波数帯は、１リソースブロックの帯域幅に限定された「キャリア」である。第２実施形態において、ＵＥ１００は、第１のセル（サービングセル）から、当該第１のセルとは異なる第２のセル（隣接セル）がＳＣ−ＰＴＭ伝送に用いる周波数帯域幅に関する帯域幅情報を受信する。これにより、ＵＥ１００は、第１のセルをサービングセルとして維持しつつ、隣接セルがＳＣ−ＰＴＭ伝送に用いる周波数帯域幅に関する情報を得ることができる。

第２実施形態において、帯域幅情報は、隣接セルが限定周波数帯でＳＣ−ＰＴＭ伝送を行っているか否かを示す基本情報を含んでもよい。基本情報は、６リソースブロックの帯域幅に限定された狭帯域（ＮＢ）でＳＣ−ＰＴＭ伝送を行っているか否か、及び／又は１リソースブロックの帯域幅に限定されたキャリアでＳＣ−ＰＴＭ伝送を行っているか否かを示すフラグ（例えば、ＥＮＵＭ （ＮＢ， Ｃａｒｒｉｅｒ， …））であってもよい。或いは、基本情報は、ＳＣ−ＰＴＭ伝送に用いられる（最大の）リソースブロック数を示す情報であってもよい。ＵＥ１００は、当該基本情報に基づいて、隣接セルにおいてＳＣ−ＰＴＭ受信が可能か否かを判断してもよい。これにより、ＵＥ１００は、隣接セルに移動する前に、隣接セルにおいてＳＣ−ＰＴＭ受信が可能か否かを判断することができる。隣接セルにおいてＳＣ−ＰＴＭ受信が不可である場合、ＳＣ−ＰＴＭ受信中のＵＥ１００は、隣接セルに移動する場合に、対応するＭＢＭＳサービスの受信を継続するための動作（例えば、ｅＮＢ２００への通知又はＲＲＣコネクティッド状態への遷移）を行うことができる。

第２実施形態において、帯域幅情報は、隣接セルがＳＣ−ＰＴＭ伝送に用いる限定周波数帯を示す詳細情報を含んでもよい。詳細情報は、狭帯域（ＮＢ）番号又はキャリア番号であってもよいし、リソースブロック番号であってもよいし、リソースブロックのビットマップであってもよい。限定周波数帯の周波数ホッピングが用いられる場合、詳細情報は、限定周波数帯の初期位置及びホッピングパターン情報を含んでもよい。ホッピングパターン情報は周波数ホッピングに関するパラメータ、例えば、ホッピング数、ホッピング幅、ホッピング周期のうち少なくとも１つを含む。ＵＥ１００は、詳細情報に基づいて、限定周波数帯において隣接セルからのＳＣ−ＰＴＭ受信を行ってもよい。これにより、ＵＥ１００は、隣接セルの全帯域幅を探索せずに、隣接セルがＳＣ−ＰＴＭ伝送に用いる限定周波数帯を特定して効率的なＳＣ−ＰＴＭ受信を行うことができる。一例として、ＵＥ１００は、隣接セルが限定周波数帯において送信するＳＩＢ２０及び／又はＳＣ−ＭＣＣＨを受信することにより、隣接セルで配信されるＭＢＭＳサービスに関する情報を得ることができる。他の例として、ＵＥ１００は、サービングセルから隣接セルに移動した際に、隣接セルから即座にＳＩＢ２０及び／又はＳＣ−ＭＣＣＨを受信することができる。

図１８は、第２実施形態に係る動作例を示す図である。図１８において、サービングセル及び隣接セルが異なるｅＮＢ２００により管理されている一例を示しているが、サービングセル及び隣接セルが同一のｅＮＢ２００により管理されていてもよい。

図１８に示すように、ステップＳ２０１において、ｅＮＢ２００−１（サービングセル）は、例えばＸ２インターフェイス上でｅＮＢ２００−２（隣接セル）から帯域幅情報を取得してもよい。帯域幅情報は、ｅＮＢ２００−２がＳＣ−ＰＴＭ伝送に現在用いている周波数帯域幅に関する情報である。或いは、ｅＮＢ２００−１は、帯域幅情報をＭＣＥ１１から取得してもよい。

ステップＳ２０２において、ｅＮＢ２００−１は、帯域幅情報をブロードキャスト又はマルチキャストでＵＥ１００に送信する。ｅＮＢ２００−１は、帯域幅情報をＳＣ−ＭＣＣＨにより送信してもよい。この場合、帯域幅情報は、ＳＣ−ＭＣＣＨ中のｓｃｐｔｍＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔ（図１０参照）に含まれてもよい。

帯域幅情報は、隣接セルが限定周波数帯でＳＣ−ＰＴＭ伝送を行っているか否かを示す基本情報、及び／又は隣接セルがＳＣ−ＰＴＭ伝送に用いる限定周波数帯を示す詳細情報を含む。詳細情報は、基本情報を兼ねてもよい。すなわち、詳細情報を受信したＵＥ１００は、隣接セルが限定周波数帯でＳＣ−ＰＴＭ伝送を行っていると判断してもよい。

帯域幅情報は、基本情報及び／又は詳細情報と関連付けられた情報として、以下の情報のうち少なくとも１つを含んでもよい。

・隣接セルが配信するＭＢＭＳサービスのＴＭＧＩ
・隣接セルのセルＩＤ
・隣接セルが属する周波数
・限定周波数帯の初期位置及びホッピングパターン情報。現在の限定周波数帯のホッピング位置を特定するためのサブフレーム情報（すなわち、今何回目のサブフレームであるかを示す情報）をさらに含んでもよい。また、隣接セルにおける繰り返し送信（ｒｅｐｅｔｉｔｉｏｎ）の途中から受信を開始できるように、１回目送信のサブフレームを示す開始位置情報をさらに含んでもよい。
・隣接セルにおけるＭＢＭＳサービスの配信開始時刻。一例として、ＭＢＭＳサービスがファームウェア配信である場合、ファームウェアの配信開始時刻である。

ステップＳ２０３において、ＵＥ１００は、ｅＮＢ２００−１から受信した帯域幅情報に基づいて、隣接セルにおいてＳＣ−ＰＴＭ受信が可能か否かを判断する。隣接セルにおいてＳＣ−ＰＴＭ受信が可能であると判断した場合、ＵＥ１００は、帯域幅情報に基づいて、隣接セルからのＳＣ−ＰＴＭ受信を行ってもよい（ステップＳ２０４）。

（第３実施形態）
以下において、第３実施形態について、第１及び第２実施形態との相違点を主として説明する。第３実施形態は、新たなカテゴリを含む様々なカテゴリのＵＥが混在するシナリオを想定する。

第３実施形態に係るｅＮＢ２００は、ＳＣ−ＰＴＭ伝送により複数のＵＥ１００にＭＢＭＳサービスを配信する。複数のＵＥ１００は、送受信する無線信号の帯域幅の上限が異なる。一例として、複数のＵＥ１００は、ｅＭＴＣ ＵＥ、ＮＢ−ＩｏＴ ＵＥ、及び一般ＵＥを含む。一般ＵＥは、限定周波数帯を用いるという制約が無いＵＥであり、システム帯域幅を全体的に用いて無線信号を送受信することが可能である。一般ＵＥは、カバレッジ強化技術が適用されないＵＥであってもよい。

ｅＮＢ２００は、このような複数のＵＥ１００に対して、送信方法が異なる複数の制御情報を送信し、かつ、当該複数のＵＥ１００に同一のデータを送信する。ｅＮＢ２００は、当該同一のデータを運搬する同一のＰＤＳＣＨリソースをスケジューリングするためのスケジューリング情報を当該複数の制御情報に含める。これにより、新たなカテゴリを含む様々なカテゴリのＵＥが混在する場合でも、同一のＰＤＳＣＨリソースを用いたＭＢＭＳ配信を行うことができる。スケジューリング情報は、ＤＲＸパラメータを含んでもよい。ｅＮＢ２００は、同一のＤＲＸパラメータを当該異なる制御情報に含めてもよい。

図１９は、第３実施形態に係るＳＣ−ＭＴＣＨスケジューリング動作例を示す図である。図１９において、ＵＥ１００−１は一般ＵＥのカテゴリに属し、ＵＥ１００−２はｅＭＴＣ ＵＥのカテゴリに属し、ＵＥ１００−３はＮＢ−ＩｏＴ ＵＥのカテゴリに属する。

図１９に示すように、ステップＳ３０１乃至Ｓ３０３において、ｅＮＢ２００は、異なる送信方法でＳＣ−ＭＴＣＨスケジューリング情報をＵＥ１００−１乃至ＵＥ１００−３に送信する。一例として、ＳＣ−ＭＴＣＨスケジューリング情報は、ＳＣ−ＭＴＣＨのためのＤＲＸパラメータを含むｓｃ−ｍｔｃｈ−ｓｃｈｅｄｕｌｉｎｇＩｎｆｏ（図１０参照）である。ＳＣ−ＭＴＣＨスケジューリング情報は、ＳＣ−ＭＴＣＨにより送信されてもよいし、ＳＩＢ２０により送信されてもよい（第１実施形態参照）。なお、ステップＳ３０１乃至Ｓ３０３の順番は、この順番に限定されない。

ステップＳ３０１で一般ＵＥ向けに送信されるＳＣ−ＭＴＣＨスケジューリング情報は、限定周波数帯で送信されなくてもよい。また、当該ＳＣ−ＭＴＣＨスケジューリング情報は、繰り返し送信が適用されなくてもよい。

ステップＳ３０２でｅＭＴＣ ＵＥ向けに送信されるＳＣ−ＭＴＣＨスケジューリング情報は、６リソースブロックの帯域幅に限定された狭帯域（ＮＢ）で送信される。また、当該ＳＣ−ＭＴＣＨスケジューリング情報は、繰り返し送信が適用される。

ステップＳ３０３でＮＢ−ＩｏＴ ＵＥ向けに送信されるＳＣ−ＭＴＣＨスケジューリング情報は、１リソースブロックの帯域幅に限定されたキャリアで送信される。また、当該ＳＣ−ＭＴＣＨスケジューリング情報は、繰り返し送信が適用される。

ここで、複数のＳＣ−ＭＴＣＨスケジューリング情報（ステップＳ３０１乃至Ｓ３０３）は、ＵＥ１００−１乃至ＵＥ１００−３に同一のＰＤＳＣＨリソースをスケジューリングするように設定されている。具体的には、複数のＳＣ−ＭＴＣＨスケジューリング情報は、ＵＥ１００−１乃至ＵＥ１００−３が同一のシステムフレーム番号（ＳＦＮ）の同一のサブフレーム番号でオン期間（Ｏｎ ｄｕｒａｔｉｏｎ）となるように、少なくとも１つのＤＲＸパラメータが同一の値に設定されている。ｅＤＲＸ（ｅｘｔｅｎｄｅｄ ＤＲＸ）により所定のハイパーシステムフレーム番号（Ｈ−ＳＦＮ）でのみオン期間が設定された場合でも、ＳＦＮ及びサブフレーム単位では同一タイミングでＰＤＳＣＨがスケジューリングされる。

ステップＳ３０４において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨスケジューリング情報によりスケジューリングしたサブフレームにおいて、ＳＣ−ＭＴＣＨに対応するＰＤＳＣＨ（データ）を送信する。

図２０は、第３実施形態に係るＰＤＳＣＨスケジューリング動作例を示す図である。図２０において、ｅＭＴＣ ＵＥ向けのＰＤＣＣＨであるＭＰＤＣＣＨ及びＮＢ−ＩｏＴ ＵＥ向けのＰＤＣＣＨであるＮＰＤＣＣＨを用いる一例を示しているが、必ずしもＭＰＤＣＣＨ及びＮＰＤＣＣＨを用いなくてもよい（第１実施形態参照）。

図２０に示すように、時間方向において、ｅＮＢ２００は、ＳＣ−ＭＴＣＨに対応するＰＤＳＣＨをサブフレーム＃３にスケジューリングする。周波数方向において、ｅＮＢ２００は、ＵＥ１００−３（ＮＢ−ＩｏＴ ＵＥ）の帯域幅、すなわち、１つのリソースブロック（ＲＢ）をＰＤＳＣＨリソースとしてスケジューリングする。

ここで、ＵＥ１００−１（一般ＵＥ）も狭帯域受信を行わなければならないため、ＵＥ１００−１（一般ＵＥ）にとって大きなスケジューリング遅延が生じ得る。よって、図２０に示すようなＰＤＳＣＨスケジューリングを行う場合、ｅＮＢ２００は、遅延を許容するデータをＳＣ−ＭＴＣＨで配信することが好ましい。一例として、ｅＮＢ２００は、（ＭＢＭＳベアラ毎に）ＭＣＥ１１から指定されたＱＣＩ（ＱｏＳ Ｃｌａｓｓ Ｉｄｅｎｔｉｔｙ）に基づいて、遅延を許容するデータを特定してもよい。

ＵＥ１００−１（一般ＵＥ）は、サブフレーム＃３において、一般ＵＥ向けのＰＤＣＣＨ（Ｌｅｇａｃｙ ＰＤＣＣＨ）を受信し、当該ＰＤＣＣＨが示すＰＤＳＣＨリソースを用いてデータを受信する。ＵＥ１００−２（ｅＭＴＣ ＵＥ）は、サブフレーム＃２においてＭＰＤＣＣＨを受信し、当該ＭＰＤＣＣＨが示すＰＤＳＣＨリソースを用いてデータを受信する。ＵＥ１００−３（ＮＢ−ＩｏＴ ＵＥ）は、サブフレーム＃１においてＮＰＤＣＣＨを受信し、当該ＮＰＤＣＣＨが示すＰＤＳＣＨリソースを用いてデータを受信する。なお、図２０のサブフレーム番号の対応は一例であり、適宜変更されてもよい。

ＵＥ１００−２（ｅＭＴＣ ＵＥ）及びＵＥ１００−３（ＮＢ−ＩｏＴ ＵＥ）は、ＳＣ−ＭＴＣＨスケジューリング情報によりスケジューリングされたサブフレームでＰＤＳＣＨがスケジューリングされると予測し、当該サブフレームよりも前にＰＤＣＣＨ（ＭＰＤＣＣＨ／ＮＰＤＣＣＨ）の監視を開始してもよい。ｅＮＢ２００は、何サブフレーム前からＰＤＣＣＨ監視を開始すべきかを示す情報をＵＥ１００−２（ｅＭＴＣ ＵＥ）及びＵＥ１００−３（ＮＢ−ＩｏＴ ＵＥ）に送信してもよい。或いは、ｅＮＢ２００は、ＭＰＤＣＣＨ及び／又はＮＰＤＣＣＨのスケジューリングを示す情報（サブフレーム情報及びリソースブロック情報等）をＵＥ１００に送信してもよい。このような情報は、ＳＩＢ２０又はＳＣ−ＭＴＣＨにより送信されてもよい。

なお、第１実施形態で説明したように、ＭＰＤＣＣＨ及びＮＰＤＣＣＨを用いない方式でＳＣ−ＭＴＣＨを送信する場合、ｅＮＢ２００は、ＳＩＢ２０又はＳＣ−ＭＴＣＨによりＰＤＳＣＨリソースのスケジューリングを示す情報（サブフレーム情報及びリソースブロック情報等）を送信してもよい。この場合、ｅＮＢ２００は、当該情報の内容を一般ＵＥ向けのＰＤＣＣＨ（Ｌｅｇａｃｙ ＰＤＣＣＨ）の内容と一致させてもよい。

（第３実施形態の変更例１）
現状のシステム仕様において、ＭＰＤＣＣＨの繰り返し送信が終了した後、２サブフレーム後にＰＤＳＣＨ送信を開始すると規定されている。このように２サブフレーム固定とすると、第３実施形態で説明したようなＰＤＳＣＨスケジューリングを適切に行うことができない虞がある。よって、ＭＰＤＣＣＨの繰り返し送信が終了してからＰＤＳＣＨ送信を開始するまでの間隔を可変とすることが望まれる。

図２１は、第３実施形態の変更例１を示す図である。

図２１に示すように、ｅＮＢ２００は、複数のサブフレームにわたって制御情報（ＭＰＤＣＣＨ）を繰り返し送信した後、データ（ＰＤＳＣＨ）の繰り返し送信を開始する。また、ｅＮＢ２００は、ＭＰＤＣＣＨの実際の繰り返し送信回数をＭＰＤＣＣＨ中でＵＥ１００に通知する。これとは別に、ｅＮＢ２００は、ＭＰＤＣＣＨの最大の繰り返し送信回数をＲＲＣシグナリングによりＵＥ１００に通知する。

ＵＥ１００は、ＭＰＤＣＣＨを受信し、受信したＭＰＤＣＣＨに基づいてＰＤＳＣＨを受信する。ｅＮＢ２００は、ＭＰＤＣＣＨの繰り返し送信を終了する第１のサブフレームからＰＤＳＣＨの送信を開始する第２のサブフレームまでのサブフレーム数を示す情報（Ｎ）をＵＥ１００に通知する。ｅＮＢ２００は、ＭＰＤＣＣＨ中でＮを通知してもよい。或いは、ｅＮＢ２００は、ＳＩＢ２０、ＳＣ−ＭＣＣＨ、又は他のＲＲＣシグナリング中でＮを通知してもよい。

Ｎは、３以上の値であってもよい。また、Ｎは、“１”を取り得る。この場合、終了サブフレームの直後に開始サブフレームが続くため、処理能力が高いＵＥ１００にのみＮ＝“１”を適用することが好ましい。

第１のサブフレームは、ＭＰＤＣＣＨの繰り返し送信を実際に終了するサブフレームであってもよい。この場合、第２のサブフレームの番号は、ＭＰＤＣＣＨ中で通知される実際の繰り返し送信回数を用いて決定される。一例として、第２のサブフレームの番号は、「初回送信サブフレームの番号＋実際の繰り返し送信回数＋Ｎ」により決定される。

或いは、第１のサブフレームは、ＭＰＤＣＣＨの繰り返し送信を終了するべきサブフレームであってもよい。この場合、第２のサブフレームの番号は、ＲＲＣシグナリングで通知される最大の繰り返し送信回数を用いて決定される。一例として、第２のサブフレームの番号は、「初回送信サブフレームの番号＋最大の繰り返し送信回数＋Ｎ」により決定される。

ｅＮＢ２００は、Ｎの値を固定値（例えば、“２”）とするか又は可変値とするかを指定する指定情報をＵＥ１００に通知してもよい。ｅＮＢ２００は、ＭＰＤＣＣＨ中で指定情報を通知してもよい。或いは、ｅＮＢ２００は、ＳＩＢ２０、ＳＣ−ＭＣＣＨ、又は他のＲＲＣシグナリング中で指定情報を通知してもよい。

第３実施形態の変更例１において、ＵＥ１００がｅＭＴＣ ＵＥであるシナリオを想定しているが、ＵＥ１００がＮＢ−ＩｏＴ ＵＥであるシナリオを想定してもよい。この場合、ＭＰＤＣＣＨをＮＰＤＣＣＨと読み替えてもよい。

（第３実施形態の変更例２）
第３実施形態の変更例２は、ＮＢ−ＩｏＴ ＵＥを含む様々なカテゴリのＵＥがＳＣ−ＰＴＭ受信を行うシナリオにおける下りリンク参照信号の取り扱いに関する。

ＮＢ−ＩｏＴ ＵＥは、ＮＢ−ＩｏＴ ＵＥ向けの参照信号であるＮＲＳ（ｎａｒｒｏｗｂａｎｄ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）を用いて復調を行う。但し、ＮＢ−ＩｏＴ ＵＥは、所定の動作モードにおいて、ＣＲＳ（ｃｅｌｌ−ｓｐｅｃｉｆｉｃ ｒｅｆｅｒｅｎｃｅ ｓｉｇｎａｌ）を用いて復調を行うことができる。

所定の動作モードは、ＬＴＥシステム帯域内でＮＢ−ＩｏＴのキャリア（１リソースブロック）が割り当てられるケース（「Ｉｎｂａｎｄ ｏｐｅｒａｔｉｏｎ」と称される）であって、ＮＢ−ＩｏＴとＬＴＥ（非ＮＢ−ＩｏＴ）とで同じセルＩＤを共有する動作モードである。このような動作モードは、Ｉｎｂａｎｄ−ＳａｍｅＰＣＩと称される。これに対し、「Ｉｎｂａｎｄ ｏｐｅｒａｔｉｏｎ」であって、ＮＢ−ＩｏＴとＬＴＥとで異なるセルＩＤを用いる動作モードは、ｉｎｂａｎｄ−ＤｉｆｆｅｒｅｎｔＰＣＩと称される。これらの動作モードは、ＮＢ−ＩｏＴ向けのマスタ情報ブロックであるＭａｓｔｅｒＩｎｆｏｒｍａｔｉｏｎＢｌｏｃｋ−ＮＢによりセルから報知される。

動作モードとしてＩｎｂａｎｄ−ＳａｍｅＰＣＩを通知されたＮＢ−ＩｏＴ ＵＥは、所定のアンテナポートを用いて送信されるＣＲＳを受信し、ＣＲＳを用いて復調（ＰＤＳＣＨの復調等）を行ってもよい。これに対し、動作モードとしてＩｎｂａｎｄ−ＤｉｆｆｅｒｅｎｔＰＣＩを通知されたＮＢ−ＩｏＴ ＵＥは、所定のアンテナポートとは異なるアンテナポートを用いて送信されるＮＲＳを受信し、ＮＲＳを用いて復調を行う。

このような前提下において、ＮＢ−ＩｏＴ ＵＥは、動作モードとしてＩｎｂａｎｄ−ＤｉｆｆｅｒｅｎｔＰＣＩを通知された場合であっても、ＳＣ−ＰＴＭ伝送（ＳＣ−ＭＴＣＨを伝送するＰＤＳＣＨ）においては、Ｉｎｂａｎｄ−ＳａｍｅＰＣＩを仮定して受信動作を行う。言い換えると、動作モードとしてＩｎｂａｎｄ−ＤｉｆｆｅｒｅｎｔＰＣＩを通知されたＮＢ−ＩｏＴ ＵＥは、ＳＣ−ＰＴＭ受信については、例外的にＣＲＳ（すなわち、ＬＴＥと同じアンテナポート、ＬＴＥと同じセルＩＤ）を用いて復調を行う。これにより、Ｉｎｂａｎｄ−ＤｉｆｆｅｒｅｎｔＰＣＩの場合であっても、ＮＢ−ＩｏＴ ＵＥと一般ＵＥ（及び／又はｅＭＴＣ ＵＥ）とが同一のＰＤＳＣＨリソースで受信を行うことを円滑化することができる。但し、ＮＢ−ＩｏＴ ＵＥは、ＬＴＥのセルＩＤ（ｅｕｔｒａ−ＣＲＳ−ＳｅｑｕｅｎｃｅＩｎｆｏ）を別途受信し、ＬＴＥのセルＩＤを把握している必要がある。

ＳＣ−ＰＴＭ用途の場合にはＣＲＳでの復調を必須として、ＮＲＳの送受信を行わないとしてもよい。この場合、ｅＮＢ２００は、ＮＲＳが配置されるべき所定のリソースエレメントに、ＮＲＳに代えてＰＤＳＣＨを配置してもよい。すなわち、ＬＴＥとＮＢ−ＩｏＴとでリソースエレメントマッピングを共通としてもよい。

ｅＮＢ２００は、ＮＢ−ＩｏＴ ＵＥがＳＣ−ＰＴＭの復調にＣＲＳを用いるべきか否かを示す情報を報知してもよい。当該情報は、ＣＲＳを用いるべきか否かの直接的な指示であってもよいし、暗示的な指示であってもよい。一例として、ｅｕｔｒａ−ＣＲＳ−ＳｅｑｕｅｎｃｅＩｎｆｏをＳＩＢ２０又はＳＣ−ＭＣＣＨに含めることにより、ｅｕｔｒａ−ＣＲＳ−ＳｅｑｕｅｎｃｅＩｎｆｏを暗示的な指示として用いてもよい。ＮＢ−ＩｏＴ ＵＥは、ＳＩＢ２０又はＳＣ−ＭＣＣＨ（の該当ＴＭＧＩ）において、ｅｕｔｒａ−ＣＲＳ−ＳｅｑｕｅｎｃｅＩｎｆｏが通知されている場合に、ＳＣ−ＰＴＭの復調にＣＲＳを用いる受信動作を行う。

或いは、動作モードがｉｎｂａｎｄ−ＳａｍｅＰＣＩの場合のみＳＣ−ＰＴＭに用いることができると規定されてもよい。

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

第４実施形態において、ＵＥ１００は、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する。上述したように、ＵＥ１００がｅＭＴＣ ＵＥである場合、限定周波数帯は、６リソースブロックの帯域幅に限定された「狭帯域（ＮＢ）」である。ＵＥ１００がＮＢ−ＩｏＴ ＵＥである場合、限定周波数帯は、１リソースブロックの帯域幅に限定された「キャリア」である。異なる限定周波数帯を用いてユニキャスト受信及びＳＣ−ＰＴＭ受信を同時に行う能力をＵＥ１００が有する場合、ＵＥ１００は、当該能力を有することを示す能力情報を例えばＲＲＣシグナリングによりｅＮＢ２００に送信する。これにより、ｅＮＢ２００は、新たなカテゴリのＵＥ１００がユニキャスト及びＳＣ−ＰＴＭの同時受信をサポートしているか否かを把握することができるため、適切なスケジューリングを行うことができる。

図２２は、第４実施形態に係るユニキャスト及びＳＣ−ＰＴＭの同時受信の例を示す図である。

図２２（ａ）に示すように、ＵＥ１００（ｅＭＴＣ ＵＥ）は、同一サブフレーム内で、２つのＮＢを用いてユニキャスト受信及びＳＣ−ＰＴＭ受信を行う能力を有し得る。ＳＣ−ＰＴＭ伝送（ＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨ）のためのＰＤＳＣＨが一方のＮＢに割り当てられ、ユニキャスト伝送のためのＰＤＳＣＨが他方のＮＢに割り当てられている。以下において、このような受信を「２ＮＢ受信」と称する。ＵＥ１００（ｅＭＴＣ ＵＥ）は、２ＮＢ受信をサポートすることを示す能力情報をｅＮＢ２００に送信する。

図２２（ｂ）に示すように、ＵＥ１００（ＮＢ−ＩｏＴ ＵＥ）は、同一サブフレーム内で、２つのキャリアを用いてユニキャスト受信及びＳＣ−ＰＴＭ受信を行う能力を有し得る。ＳＣ−ＰＴＭ伝送（ＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨ）のためのＰＤＳＣＨが一方のキャリアに割り当てられ、ユニキャスト伝送のためのＰＤＳＣＨが他方のキャリアに割り当てられている。以下において、このような受信を「２キャリア受信」と称する。ＵＥ１００（ＮＢ−ＩｏＴ ＵＥ）は、２キャリア受信をサポートすることを示す能力情報をｅＮＢ２００に送信する。

２ＮＢ受信又は２キャリア受信をサポートすることを示す能力情報として、一般ＵＥ向けに規定された能力情報であるｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎを用いてもよい。一般ＵＥからｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎを受信したｅＮＢ２００は、当該一般ＵＥがユニキャスト及びＳＣ−ＰＴＭの同時受信をサポートすると判断する。ｅＭＴＣ ＵＥからｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎを受信したｅＮＢ２００は、当該ｅＭＴＣ ＵＥが２ＮＢ受信をサポートすると判断する。ＮＢ−ＩｏＴ ＵＥからｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎを受信したｅＮＢ２００は、当該ＮＢ−ＩｏＴ ＵＥが２キャリア受信をサポートすると判断する。このような判断を行うために、ｅＮＢ２００は、各ＵＥから受信するＵＥカテゴリ情報を用いて各ＵＥのカテゴリを把握する。

但し、ｅＭＴＣ ＵＥは、ユニキャスト及びＳＣ−ＰＴＭの同時受信を１ＮＢ内で行い得る。図２３は、１ＮＢ内でのユニキャスト及びＳＣ−ＰＴＭの同時受信の例を示す図である。図２３に示すように、ｅＭＴＣ ＵＥは、ＳＣ−ＰＴＭ伝送（ＳＣ−ＭＣＣＨ又はＳＣ−ＭＴＣＨ）のためのＰＤＳＣＨがＮＢ内の一部のリソースブロックに割り当てられ、ユニキャスト伝送のためのＰＤＳＣＨが当該ＮＢ内の他のリソースブロックに割り当てられている。

よって、ｅＭＴＣ ＵＥについては、ユニキャスト及びＳＣ−ＰＴＭの同時受信を異なるＮＢで可能であるのか、又はユニキャスト及びＳＣ−ＰＴＭの同時受信を同一のＮＢで可能であるのかをｅＮＢ２００が把握できることが望ましい。よって、ユニキャスト及びＳＣ−ＰＴＭの同時受信を異なるＮＢで可能であることを示す能力情報と、ユニキャスト及びＳＣ−ＰＴＭの同時受信を同一のＮＢで可能であることを示す能力情報と、を別々に規定してもよい。

（第５実施形態）
以下において、第５実施形態について、第１乃至第４実施形態との相違点を主として説明する。第５実施形態においては、新たなカテゴリのＵＥが存在しないシナリオを想定してもよい。但し、新たなカテゴリのＵＥが存在するシナリオを想定してもよい。

第５実施形態において、ｅＮＢ２００は、アクセス規制を行うためのアクセス規制信号をブロードキャスト又はマルチキャストで送信する。ｅＮＢ２００は、ＳＩＢによりアクセス規制信号を送信してもよい。ＵＥ１００は、アクセス規制信号に基づいて、ｅＮＢ２００へのアクセスが規制されているか否かを判断する。アクセス規制信号は、ユニキャスト通信よりもＳＣ−ＰＴＭ受信を優先するＵＥ１００がｅＮＢ２００にアクセスすることを規制する第１の情報を含む。

上述したように、ＵＥ１００は、ＲＲＣアイドル状態及びＲＲＣコネクティッド状態の何れの状態でもＳＣ−ＰＴＭ受信を行うことが可能である。これに対し、ユニキャスト通信は、ＲＲＣコネクティッド状態であることが要求される。このため、ｅＮＢ２００が混雑している場合、ｅＮＢ２００は、ユニキャスト通信を行うＵＥ１００を優先するために、ＲＲＣコネクティッド状態でＳＣ−ＰＴＭ受信を行うＵＥ１００との接続を解放することが考えられる。よって、ｅＮＢ２００は、第１の情報を含むアクセス規制信号を送信することにより、ＳＣ−ＰＴＭ受信を優先するＵＥ１００がｅＮＢ２００に接続することを未然に防止することができる。

図２４は、第５実施形態に係るＵＥ１００の動作例を示す図である。

図２４に示すように、ステップＳ５０１において、ＵＥ１００は、第１の情報を含むアクセス規制信号をｅＮＢ２００から受信する。

ステップＳ５０２において、ＵＥ１００は、自身がユニキャスト通信よりもＳＣ−ＰＴＭ受信を優先するか否かを判断する。

ユニキャスト通信よりもＳＣ−ＰＴＭ受信を優先すると判断した場合（ステップＳ５０２：ＹＥＳ）、ステップＳ５０３において、ＵＥ１００は、アクセス規制信号を送信したｅＮＢ２００（セル）へのアクセスが規制されていると判断し、当該ｅＮＢ２００（セル）との接続を避ける。

一方、ユニキャスト通信よりもＳＣ−ＰＴＭ受信を優先しない判断した場合（ステップＳ５０２：ＮＯ）、ステップＳ５０４において、ＵＥ１００は、アクセス規制信号を送信したｅＮＢ２００（セル）へのアクセスが規制されていないと判断する。

アクセス規制信号は、ＳＣ−ＰＴＭ及びユニキャストの同時受信をサポートするＵＥ１００にのみ適用されてもよい。ＳＣ−ＰＴＭ及びユニキャストの同時受信をサポートするＵＥ１００であっても、ＳＣ−ＰＴＭよりもユニキャストを優先するのであれば、アクセスが規制されていないと判断する。なお、ユニキャストのみ意図しているＵＥ１００は、アクセスが規制されていないと判断する。

第５実施形態において、ＳＣ−ＰＴＭ伝送によりＭＢＭＳサービスを配信するシナリオを想定しているが、ＭＢＳＦＮ伝送によりＭＢＭＳサービスを配信するシナリオを想定してもよい。この場合、ＳＣ−ＰＴＭ受信をＭＢＳＦＮ受信と読み替えてもよい。

（第５実施形態の変更例）
第５実施形態において、ｅＮＢ２００が、ユニキャスト通信を行うＵＥ１００を優先すると仮定していた。しかしながら、ＳＣ−ＰＴＭを提供している周波数又はセルが限られている場合、ｅＮＢ２００が、ＳＣ−ＰＴＭを優先し、ユニキャスト通信による混雑を避けることをも考えられる。

よって、ｅＮＢ２００は、ＳＣ−ＰＴＭ受信よりもユニキャスト通信を優先するＵＥ１００がｅＮＢ２００にアクセスすることを規制する第２の情報を含むアクセス規制信号を送信してもよい。第２の情報を含むアクセス規制信号は、ＳＣ−ＰＴＭ及びユニキャストの同時受信をネットワーク（ｅＮＢ２００）が推奨しないことを示す信号とみなされてもよい。ＳＣ−ＰＴＭを提供している周波数又はセルはその分混雑するので、ｅＮＢ２００は、ユニキャストを避けて欲しい旨をアクセス規制信号によりＵＥ１００に通知する。第２の情報を含むアクセス規制信号を受信したＵＥ１００は、自身がＳＣ−ＰＴＭ受信よりもユニキャスト通信を優先する場合には、アクセス規制信号を送信したｅＮＢ２００（セル）へのアクセスが規制されていると判断し、当該ｅＮＢ２００との接続を避ける。この場合、ＵＥ１００は、当該セルとは別のセルを探索し、当該別のセルとの接続を試みてもよい。一方、ＳＣ−ＰＴＭを優先するＵＥ１００は、アクセス規制信号を送信したｅＮＢ２００（セル）へのアクセスが規制されていないと判断する。

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

上述した実施形態において、ＳＣ−ＰＴＭ伝送によりＭＢＭＳサービスを配信するシナリオについて主として説明した。しかしながら、ＭＢＳＦＮ伝送によりＭＢＭＳサービスを配信するシナリオに、上述した実施形態に係る動作を適用してもよい。

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

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

［付記１］
（１）はじめに
この付記では、ＲＲＣ設定の詳細について説明する。

（２）検討
（２．１）ＳＣ−ＭＴＣＨ受信のための基本設定
（２．１．１）提供スキーム
リリース１３では、ＳＩＢ２０とＳＣ−ＭＣＣＨをＳＣ−ＰＴＭ提供に適用した。すなわち、ＳＩＢ２０はＳＣ−ＭＣＣＨ受信のための設定を提供する。ＭＣＰＴＴのレイテンシ要件を満たす（すなわち、システム情報の頻繁な繰り返し／変更を無くし、４０／８０ｍｓでＳＣ−ＰＴＭ設定を取得するために、呼セットアップ時の遅延を減らす）ために「２ステップ設定」スキームが導入された。

考察１：リリース１３のＳＣ−ＰＴＭはＳＣ−ＭＣＣＨを採用し、ＭＣＰＴＴのレイテンシ要件を満たし、かつ、システム情報の頻繁な繰り返し／変更を最小化する。

ｅＮＢ−ＩｏＴ及びＦｅＭＴＣでは、リリース１３方式はリリース１４マルチキャスト拡張のベースラインとして再利用されることは疑いない。ＳＣ−ＭＣＣＨ設定（ＮＢ−ＩｏＴ用の新しいＳＩＢ２０−ＮＢ）のためにＳＩＢ２０（又は多少変更された変形）を使用することが合意されている。このスキームは、遅延に敏感なアプリケーションが将来特定される場合でも、柔軟性と適用性の観点から有益である。

考察２：リリース１３の設定スキーム、すなわちＳＩＢ２０及びＳＣ−ＭＣＣＨは、リリース１４のマルチキャスト拡張のために再使用される。

ＦｅＭＴＣ／ｅＮＢ−ＩｏＴのユースケース、すなわち「ファームウェア又はソフトウェア更新、グループメッセージ配信」に特有の最適化が必要かどうかについてさらに議論すべきである。３つの最適化が提案された。

・半静的リソース割り当て：
この最適化は、半静的に割り当てられたリソース上のＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨ送信に有効である。ＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨを搬送するＰＤＳＣＨは、少なくともＳＩＢ２０及び／又はＳＣ−ＭＣＣＨによって提供され、ＳＩ及び／又はＳＣ−ＭＣＣＨの変更期間中は静的であるサブフレームの機会に送信され、ＰＤＣＣＨ受信なしで復号することができると仮定することができる。この仮定によれば、ＳＣ−ＰＴＭ受信のためにＵＥの電力消費を低減することが有益であろう。例えば、ＵＥは、ＳＣ−ＰＴＭ送信がＰＤＳＣＨで送信されているかどうかを知るためにＭＰＤＣＣＨ（又はＮＰＤＣＣＨ）を連続的に監視する必要がないので、Ｒｘアクティブ期間は１／２受信時間だけ短縮することができる。また、ＳＣ−ＲＮＴＩ及び／又はＧ−ＲＮＴＩは、ＳＣ−ＭＣＣＨ及び／又はＳＣ−ＭＴＣＨを搬送するＰＤＳＣＨを受信するためにもはや必要でないので、この最適化により、他のワーキンググループにおける標準化の努力は回避され得る。すなわち、ＭＰＤＣＣＨ／ＮＰＤＣＣＨは、これらのＲＮＴＩを採用する必要がない。しかし、この欠点は、リリース１３方式で許容される動的スケジューリングと比較して、スペクトル効率が低いことである。

この最適化は、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴユースケースに適用可能であることに留意すべきである。これは、遅延許容アクセスとみなされ、リリース１３のＭＣＰＴＴとはまったく異なる要件があるためである。

・「ワンステップ」の設定：
この最適化はＳＣ−ＭＣＣＨを排除する。つまり、ＳＩＢ２０は直接ＳＣ−ＰＴＭ設定を提供する。また、この最適化は既存のＳＩ変更通知を再利用し、ＵＥの節電の観点から有益であるため、ＳＣ−Ｎ−ＲＮＴＩによる変更通知を排除する。さらに、ＳＣ−ＭＣＣＨ設定、すなわち、ＳＩＢ２０の内容をもはやブロードキャストする必要がないので、シグナリングのオーバーヘッドが全体的に低減される可能性がある。欠点は、ＳＣ−ＭＣＣＨ設定の提供のためにＳＩＢ２０自体のメッセージサイズが増加し、ＳＩ更新の数に制限がある、すなわちマルチキャスト設定の頻繁な変更を想定することができないことである。

但し、上記と同じ理由で、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴユースケースにも適用可能であることに留意すべきである。

複数のＳＣ−ＭＣＣＨ：
この最適化により、ＳＣ−ＭＣＣＨとＣＥレベル（例えば、反復回数）との関連付けが可能になる。例えば、ＣＥレベル１に関連する１つのＳＣ−ＭＣＣＨは、同じＣＥレベルに関連するＳＣ−ＰＴＭ設定を提供し、ＣＥレベル２に関連する別のＳＣ−ＭＣＣＨは、ＣＥレベル２を有するＳＣ−ＰＴＭ設定に関するものと想定することができる。前提として、スペクトル効率とＵＥ節電を改善することが有益であろう。いくつかの更なる最適化、例えば、複数のＳＣ−ＭＣＣＨ送信に使用されるＳＣ−ＲＮＴＩの数を最小限に抑える（又は排除する）ための準静的リソース割り当てとの組み合わせが考えられる。ＳＣ−ＭＣＣＨがもはや、例えば上記の「ワンステップ」設定では必要でなくても、この概念はＳＩＢ２０、すなわちＳＩＢ２０の複数のインスタンスに対して再使用され得る。

上記の考察によれば、最適化は有益であり、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴに特有のものである。また、ＮＷの柔軟性とＵＥの消費電力をさらに最適化するために、これらを共同で使用することもできる。例えば、図１５に例示されているように、合意された計画とＳＩＢ２０の最適化とを切り替えるためには標準化の努力が必要であるが、ベースラインに対してリリース１３の設定／概念を再利用できる場合には、あまり大きくないと予想される。したがって、最適化を考慮すべきであるが、それは基本スキームを構築した後とすべきである。

提案１：ＲＡＮ２は、基本的な設定スキーム、すなわち、必要な拡張を伴うリリース１３スキームの再使用に対する拡張として、半静的リソース割り当て、ＭＣＣＨを持たない「ワンステップ」設定及び複数のＭＣＣＨに基づく統合的な最適化を導入することを後に検討すべきである。

（２．１．２）ＤＲＸ
ＤＲＸは、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴの意図、すなわち、ＵＥの電力消費を最小限に抑えるための意図を調整するために考慮されるべきである。リリース１３のＳＣ−ＰＴＭでは、ＵＥがＤＬマルチキャストデータを受信する前に、ＳＣ−ＭＣＣＨ送信の機会を知るためにＳＩＢ２０を取得する必要があり、ＳＣ−ＭＣＣＨは、ＳＣ−ＰＴＭ受信のための詳細情報、すなわち、ＴＭＧＩ、対応するＧ−ＲＮＴＩ、ＳＣ−ＰＴＭスケジューリング情報などのＳＣ−ＭＴＣＨ−ＩｎｆｏＬｉｓｔを運搬する。

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

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

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

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

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

（２．１．３）ＳＣ−ＭＣＣＨ変更通知
ＳＣ−ＭＣＣＨ設定（ＮＢ−ＩｏＴ用の新しいＳＩＢ２０−ＮＢ）にＳＩＢ２０（又は多少変更された変形）を使用することが既に同意されているため、ＳＣ−ＭＣＣＨ変更通知の実行方法を検討する必要がある。リリース１３のＳＣ−ＰＴＭでは、それは、ＳＣ−ＭＣＣＨ機会で送信されるＳＣ−Ｎ−ＲＮＴＩでスクランブルされたＰＤＣＣＨによって通知される。同時に、ページング機会内に送信されるｅＭＴＣ及びＮＢ−ＩｏＴのＳＩ更新を通知するために、直接的な指示子（Ｄｉｒｅｃｔ Ｉｎｄｉｃａｔｉｏｎ）が導入される。したがって、リリース１４のＳＣ−ＭＣＣＨ変更通知メカニズムに再利用できる２つの候補がある。

リリース１３のＳＣ−ＰＴＭ通知では、ＳＣ−ＭＣＣＨ変更通知がＳＣ−ＭＣＣＨを用いて同じサブフレーム機会で送信されるので、ＵＥはＳＣ−Ｎ−ＲＮＴＩ及びＳＣ−ＲＮＴＩを同時に復号する必要があるが、これはＦｅＭＴＣ／ｅＮＢ−ＩｏＴのユースケースでは必要ないかもしれない。一方、リリース１３のｅＭＴＣ／ＮＢ−ＩｏＴ通知メカニズムは、これらのユースケースに対して既に最適化されている。したがって、直接的な指示子は、リリース１４におけるＳＣ−ＭＣＣＨ変更通知のために再使用されることが好ましい。

提案３：ＲＡＮ２は、ＳＣ−ＭＣＣＨ変更通知のための直接指示子メカニズムを拡張すべきである。

（２．１．４）ナローバンド／キャリア情報
ＲＡＮ２＃９５では、「ＳＣ−ＭＣＣＨとＳＣ−ＭＴＣＨの両方が、ＮＢ−ＩｏＴのためのアンカーキャリア及び／又は非アンカーキャリアでスケジューリングされる可能性があり」、「ＳＣ−ＭＣＣＨ及びＳＣ−ＭＴＣＨは、ＮＢ−ＩｏＴ及びＭＴＣ（狭帯域のＭＴＣ）のための異なるキャリア上にスケジューリングされる可能性がある」ことが合意された。したがって、ＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨはシステム帯域幅内のどこかで送信される可能性があり、電力消費の観点から、対象のＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨが送信される場所をＵＥが探索することは現実的ではない。既に考察されているように、ＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨがスケジュールされるＰＲＢ／キャリアに関する狭帯域（ナローバンド）／キャリア情報は、例えばＳＩＢ２０でブロードキャストされるべきである。

提案４：ＲＡＮ２は、ナローバンド／キャリア情報、すなわちＳＣ−ＭＣＣＨ／ＳＣ−ＭＴＣＨがどのＰＲＢ／キャリアにスケジューリングされているかをブロードキャストすべきかどうかについて議論すべきである。

このトピックにいくらか関連して、ＲＡＮ２は、「ＭＴＣの周波数ホッピングを考慮する必要がある」ことに合意した。周波数ホッピングは、周波数選択性フェージングに起因する受信エラーが、一般的に、１つのＵＥの観点（ユニキャスト）からの周波数ホッピング（及びエラー訂正コードなど）によって低減されるので、ユニキャストの場合と同様にマルチキャストにも有用であり得る。複数のユーザに対しても同じことが言える（マルチキャスト）。しかし、ＲＡＮ１の決定、例えば、マルチキャストの場合にどのくらいの利得が考察されるかに基づいて議論する必要がある。

考察４：周波数ホッピングの考慮は、ＲＡＮ１からの入力を待つ必要がある。

（２．２）サービス継続性
ＲＡＮ２＃９５では、「マルチキャストのサービス継続性は、ＮＢ−ＩｏＴ及びＭＴＣのアイドルモードのためのリリース１３のようにサポートされる必要がある」と合意された。現在の仕様では、ＳＣ−ＭＣＣＨは、ＳＣＰＴＭ−ＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔ内の隣接セル情報、すなわち物理セルＩＤ及び周波数を提供する。サービングセルがＳＣ−ＰＴＭを提供しないＴＭＧＩにＵＥが興味を持つ場合、ＵＥは、関心のあるＴＭＧＩを探索するために、隣接セルのＳＣ−ＭＣＣＨを復号する必要がある。

リリース１３のＭＣＰＴＴを対象とした既存のソリューションでは、ＵＥが隣接周波数にわたってＳＣ−ＭＣＣＨを復号する必要がある場合、ＵＥ（特に、このワークアイテムで扱われる拡張の１つである、移動性のＦｅＭＴＣ／ｅＮＢ ＩｏＴ ＵＥ）の電力消費は著しく影響を受ける。したがって、低消費電力でＦｅＭＴＣ／ｅＮＢ−ＩｏＴ ＵＥのモビリティを促進するために、ＮＷからの追加の支援を受けてサービスの継続性を最適化することについて議論することは価値がある。

考察５：ＭＣＰＴＴ ＵＥのためのリリース１３サービス継続性は、ＵＥの電力消費に関して、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴ ＵＥのために最適化する必要があり得る。

ＳＣ−ＰＴＭの研究段階では、以下のように、ＳＣ−ＰＴＭセルから別のＳＣ−ＰＴＭセルに移動するＵＥについて５つのソリューションが特定された。ソリューション１，２及び３は、主に、コネクティッドのＳＣ−ＰＴＭがサポートされている場合である。ソリューション４はＩＬＤＥ又はコネクティッドのいずれにも適用できるが、ソリューション５はアイドルにのみ適用できる。

−ソリューション１：ＵＥ実装。ＵＥは、ＳＣ−ＰＴＭ受信品質が閾値（例えば、ＲＳＲＱ、ＢＬＥＲに基づく閾値）以下に低下したときに、ユニキャストを介してグループ呼を受信することを要求することができる。閾値は、ＵＥ実装特有であってもよく、又はＵＥにおけるＧＣＳＥ／ＭＣＰＴＴアプリケーションの一部として定義されてもよい。このようなソリューションは、ＭＢＳＦＮ上のグループ呼のためにリリース１２ ＧＣＳＥで合意された。

−ソリューション２：ｅＮＢ支援ユニキャストベアラ要求。このソリューションは、ＵＥ実装特有のソリューションに類似しており、ｅＮＢは、適切な時点でグループ通話のユニキャストベアラを要求することを支援するために、トリガ基準（例えばＲＳＲＱ又はＢＬＥＲ閾値）をＵＥに提供する。

−ソリューション３（ＲＲＣコネクティッドのみ）：ハンドオーバ中の隣接セルＳＣ−ＰＴＭ制御情報の提供。ターゲットセルのＳＣ−ＰＴＭ制御情報は、存在する場合、ハンドオーバコマンドによってＵＥに提供することができ、ハンドオーバ後にターゲットセルＳＣ−ＰＴＭ制御情報を取得することによるサービス中断を回避することができる。

−ソリューション４：隣接セルＳＣ−ＰＴＭ制御情報のブロードキャスト。１つのセルは、隣接セルのＳＣ−ＰＴＭ制御情報をブロードキャストすることができ、セル再選択又はハンドオーバ後のターゲットセルＳＣ−ＰＴＭ制御情報の取得によって引き起こされるサービス中断を排除することができる。

−ソリューション５（ＲＲＣアイドルのみ）：ｅＮＢ支援ＲＲＣ接続確立。ｅＮＢは、ＵＥがＳＣ−ＰＴＭセルカバレッジから移動しようとしているときに、ＵＥがＲＲＣ接続確立を実行するのを支援するために、トリガ基準（例えば、ＲＳＲＰ又はＲＳＲＱ）をブロードキャストする。続いて、ソリューション３を適用する。

ＲＲＣ＿コネクティッド ＵＥの場合、ソリューション３が最も適切なソリューションであると考えられる。ＲＲＣアイドルのＵＥについては、ソリューション４又はソリューション５が考慮されてもよいが、効率性及び実現可能性の点で評価されていない。なお、ソリューション４に起因するオーバーヘッドは評価されていない（Ｎｏｔｅ １）。

ＵＥの節電と「ＮＢ−ＩｏＴとＭＴＣの両方でＲＲＣアイドルモードのマルチキャスト受信が必要」という合意とを考慮すると、隣接セルのＳＣ−ＭＣＣＨを復号することなくＵＥがＲＲＣアイドルにおいてＳＣ−ＰＴＭ受信を継続するので、最も適切なソリューションは、「隣接セルＳＣ−ＰＴＭ制御情報のブロードキャスト」となる。しかしながら、Ｎｏｔｅ １に注記されているように、サービングセルのＳＣ−ＭＣＣＨの大きなオーバーヘッドが問題になり得、狭帯域（ナローバンド）又は１つのキャリア動作においてより重大な問題になり得る。いずれにせよ、ＮＷシグナリングオーバーヘッド（すなわち、ＮＷ支援の度合い）とＵＥの電力消費との間のトレードオフがあるであろう。

考察６：ＵＥの電力消費とＮＷシグナリングオーバーヘッドとの間にはトレードオフがあり、ＳＣ−ＰＴＭのＴＲのソリューションはＦｅＭＴＣ／ｅＮＢ−ＩｏＴにとって最適ではないかもしれない。

サービス継続性のために提供される既存の情報は、ＳＣ−ＭＣＣＨ内のｓｃｐｔｍ−ＮｅｉｇｈｂｏｕｒＣｅｌｌＬｉｓｔであり、ＬＴＥ ＵＥ向けであって、削減された帯域幅、すなわち６ＰＲＢ及び１ＰＲＢ内でそれぞれ動作するｅＭＴＣ／ＮＢ−ＩｏＴ ＵＥ向けではない。したがって、同じレベルのリリース１３サービス継続性を保証するために、削減された帯域幅内で隣接セルがＳＣ−ＰＴＭを動作させるかどうかを知らせるために追加の支援が必要である。

提案５：ＲＡＮ２は、サービス継続性の基本機能のために、削減帯域幅情報が追加的にブロードキャストされるかどうか、すなわち、隣接セルが６ＰＲＢｓ／１ＰＲＢ内でＳＣ−ＰＴＭを提供するか否かを考慮すべきである。

さらなる最適化について、ＵＥの消費電力を最小限に抑えるために、ＳＣ−ＭＣＣＨで定義されている最も重要な情報をＳＩＢ２０に移行することが有益である。例えば、ＵＥが関心のある設定のみを受信することが可能であることは有効である。この意味で、隣接セルのＳＣ−ＰＴＭスケジューリング情報及びＴＭＧＩは、ＵＥ節電のための追加支援として機能することができる。その他の支援は更なる検討が必要である。

提案６：ＲＡＮ２は、近隣セルのＳＣ−ＰＴＭスケジューリング情報及び／又はＴＭＧＩがサービス継続性の最適化のための追加の支援としてサービングセルによってブロードキャストされるかどうかを検討すべきである。

（２．３）ワンショットマルチキャスト
ファームウェア／ソフトウェア更新のユースケースは、ブロードキャストサービスではなくマルチキャストタイプのサービスである。ファームウェアがファイルのセットであると仮定することもできるので、同じファームウェアが何度もマルチキャストされることは効率的ではない。現在のＭＢＭＳサービスでは、「アプリケーション／サービス層が、各サービスに対してＴＭＧＩ、セッションの開始及び終了時間、周波数及びＭＢＭＳサービスエリア識別子をＵＳＤで提供する」と仮定する。これは、潜在的にワンショットマルチキャスティングを可能にする。すなわち、適切な開始／終了時間をＵＳＤで設定することによって、１つのファームウェアが一度だけマルチキャストされる。しかし、スケジュールされたファームウェアの更新が動的に行われる間に、ＵＳＤがＵＥで頻繁にダウンロードされないと仮定されている。ファームウェアがいつ更新されるかを知るためにＵＥが頻繁にＵＳＤをダウンロードする必要がある場合、これはＵＥの電力消費に重大な影響を及ぼす。したがって、ＲＡＮレベルの最適化、例えば、拡張ＭＣＨスケジューリング情報ＭＡＣ制御要素の改良を含む開始／停止時間、ＴＭＧＩベースページングなどのようなＲＡＮレベル情報を検討することが必要であり、これらは相互作用してＵＥの既存のＵＳＤを補完することができる。

特に、ＳＣ−ＭＣＣＨ変更周期が例えばｅＤＲＸサイクルと整合するように延長されている場合には、少なくとも開始／停止時間はＵＥ節電に有用であり得る。ＲＡＮレベルの開始／終了時間情報を用いると、ＳＣ−ＰＴＭ機会が利用可能であっても、例えばＳＣ−ＭＴＣＨ−ＳｃｈｅｄｕｌｉｎｇＩｎｆｏであっても、ＵＥは例えばファームウェア配信のための最小持続時間でのみ起動する。

提案７：ＲＡＮ２は、ＲＡＮレベルの開始／終了時間情報が導入されるかどうかについて議論するべきである。

［付記２］
（１）はじめに
この付記において、ＦｅＭＴＣとｅＮＢ−ＩｏＴとの間の共通性に加えて、リリース１４マルチキャスト強化のための下位互換性設計の可能性と有用性を検討する。

（２）検討
ＲＡＮ２＃９５では、ＦｅＭＴＣとｅＮＢ−ＩｏＴとのマルチキャスト拡張の間に、アーキテクチャ、制御情報、データ伝送方式などの様々な観点から高い共通性を確保することが提案されている。さらに、リリース１３のＳＣ−ＰＴＭメカニズムを可能な限り再利用する提案／意図も多数存在している。結果として、ＦｅＭＴＣとｅＮＢ−ＩｏＴの間、及びリリース１３のＳＣ−ＰＴＭとリリース１４の改善との間の共通点は多くの合意で考慮されたが、詳細は異なり且つ更なる検討が必要でなければならない。

考察１：ＦｅＭＴＣとｅＮＢ−ＩｏＴとの間、リリース１３のＳＣ−ＰＴＭとリリース１４のマルチキャスト改善との間の共通性を可能な限り確保することは合理的である。

しかし、狭帯域（ナローバンド）又はキャリア内のマルチキャストが、リリース１３のＵＥへの下位互換性を保証する必要があるかどうかはまだ議論されていない。なぜなら、それは３ＧＰＰの原理で仮定されたものとは異なる種類の問題である可能性が高いからである。もちろん、リリース１３のｅＭＴＣ／ＮＢ−ＩｏＴ ＵＥ、すなわちカテゴリＭ１／ＮＢ１はＳＣ−ＰＴＭを受信することができないので、必要ではない。しかし、いくつかのＩｏＴユースケースに対しても配備され、リリース１４で拡張されたＳＣ−ＰＴＭ送信を受信したいと考えるリリース１３のＳＣ−ＰＴＭ対応ＵＥ、例えばカテゴリ０が存在することに気付くであろう。このようなマルチキャスト拡張の設計は、共通ファームウェア／グループメッセージがリリース１３のＳＣ−ＰＴＭ ＵＥ、リリース１４のＦｅＭＴＣ ＵＥ、及びｅＮＢ−ＩｏＴ ＵＥに配信される場合に有益である。例えば、異なるＵＥカテゴリを有する異なるデバイスが、共通のセンサを備えていてもよいし、同じアプリケーションのために動作する可能性が高い。

リリース１３のＳＣ−ＰＴＭ対応ＵＥは、ＦｅＭＴＣ／ｅＮＢ−ＩｏＴ ＵＥよりも強力である、すなわち、より広い帯域幅及びより良いプロセッサ能力を有すると仮定することができる。したがって、たとえそれが、例えば、「複雑さの低いマルチキャスト機能」であっても、狭帯域／キャリアにおけるマルチキャスト送信を受信する可能性がある。ＲＡＮ２は、「ＲＡＮ２は、ＳＣ−ＭＴＣＨがＰＤＣＣＨによってスケジューリングされた従来のＳＣ−ＭＴＣＨメカニズムをＮＢ−ＩｏＴ及びＭＴＣのマルチキャストに再利用して、柔軟なスケジューリングを実現することを前提としている」と同意した。ＳＣ−ＭＴＣＨは、リリース１３／リリース１４のＵＥ間の共通の物理チャネルであり得るＰＤＳＣＨで搬送される。ＭＰＤＣＣＨ／ＮＰＤＣＣＨがＳＣ−ＰＴＭに使用されているかどうかは依然として更なる検討が必要であるが、違いは、Ｌ１／Ｌ２制御チャネルが、ＳＣ−ＭＴＣＨについてＰＤＳＣＨ、リリース１３についてＰＤＣＣＨ、ＦｅＭＴＣについてＭＰＤＣＣＨ、又はｅＮＢ−ＩｏＴについてＮＰＤＣＣＨである。図２０に示すように、同じＰＤＳＣＨを複数のＬ１／Ｌ２制御チャネルが指し示すことができる場合、すべてのＵＥは、ＵＥカテゴリ、すなわちレガシー、ＦｅＭＴＣ又はｅＮＢ−ＩｏＴに関係なく、ＳＣ−ＭＴＣＨを搬送する同じＰＤＳＣＨを受信する。これらはＳＣ−ＰＴＭに対応している。スケジューリングはより複雑になるが、同じデータに対して異なるＰＤＳＣＨを割り当てるのに比べて、より優れたスペクトル効率を得ることは有益である。したがって、ＲＡＮ２は、ＮＷ実装がすべてのタイプのＵＥについてＳＣ−ＭＴＣＨ送信を調整することを可能にするか否かについて議論すべきである。

考察２：ＳＣ−ＭＴＣＨ送信は、ＮＷ実装によって、異なるＵＥカテゴリを有するＳＣ−ＰＴＭ対応ＵＥに対して潜在的に調整され得る。

提案１：ＲＡＮ２は、ｅＮＢ−ＩｏＴ ＵＥのためのＳＣ−ＭＴＣＨ送信が、リリース１３のＳＣ−ＰＴＭが可能なＵＥだけでなく、ＦｅＭＴＣ ＵＥとの受信互換性として設計されるべきかどうかについて議論すべきである。

提案１が合意可能であれば、少なくともＤＲＸ、すなわちＳＣ−ＰＴＭスケジューリング機会／オフセットの値は、リリース１３又はＦｅＭＴＣ／ｅＮＢ−ＩｏＴのいずれかに揃えなければならない。

［付記３］
（１）はじめに
本付記では、ＲＲＣコネクティッドにおけるＦｅＭＴＣ ＵＥのＳＣ−ＰＴＭ受信の必要性について述べる。

（２）検討
ＲＡＮ２＃９５では、ＲＲＣコネクティッドでのマルチキャスト受信がＵＥの複雑さと消費電力を増加させることが示唆されている。議論の中で、ＦｅＭＴＣ ＵＥのいくつかの仕様の影響と能力の低下が想定されていたが、ＦｅＭＴＣとｅＮＢ−ＩｏＴの違いが指摘された。ＦｅＭＴＣ ＵＥがＲＲＣコネクティッドでＳＣ−ＰＴＭを受信できるかどうかを更なる検討が必要である。

（２．１）正当化とユースケース
ＦｅＭＴＣのＷＩＤは、ＦｅＭＴＣのリリース１４拡張の正当性を以下のように特定している。

リリース１３では、センサ、メーター、スマートリーダーなどのデバイスを対象とした複雑さの低減、バッテリ寿命の延長、カバレッジの強化などの要件がある。音声対応ウェアラブルデバイスや健康状態監視デバイスなどの他のタイプのデバイス／ユースケースは、これらの要件の一部を共有している。しかし、これらのデバイスのサブセットは、１Ｍｂｐｓ以上の高いデータ転送速度、モビリティを必要とし、さらに遅延に敏感なサービスをサポートする可能性があるため、リリース１３の改善が完全にはカバーされていない。

上記のステートメントは主により高いデータレートをサポートすることを正当化するものであるが、リリース１４のＦｅＭＴＣの目的は複雑さ／消費電力を低くすることではなく、より高いパフォーマンスをサポートすることであり、リリース１３を目指している。これは、リリース１４のｅＮＢ ＩｏＴの目的、すなわち「極めて低いコストと複雑さを維持する」という追加の機能とはまったく異なる。

このワークアイテムは、リリース１３のＮＢ−ＩｏＴデザインから始まり、ＮＢ−ＩｏＴのために再設計できるＬＴＥに精通したいくつかのさらなる機能（ポジショニング及びマルチキャストなど）をサポートするよう拡張する。また、ＮＢ−ＩｏＴリソースをより効率的に使用できるようにするリリース１３技術の強化も行われる。これらの機能拡張は、ＮＢ−ＩｏＴネットワークのカバレッジと容量だけでなく、必要に応じてリリース１３のＮＢ−ＩｏＴ ＵＥの極めて低いコストと複雑さを維持するように設計される。

考察１：ＷＩＤは、ＦｅＭＴＣとｅＮＢ−ＩｏＴとの間のさまざまな正当性を特定し、より高いパフォーマンスを必要とするユースケースをカバーするＦｅＭＴＣを意図している。

ＦｅＭＴＣの対象となる有望なユースケースの１つは、音声ストリーミングである。したがって、ＲＲＣコネクティッドのＵＥは、ユニキャストを介してストリーミングタイプの通信を実行する可能性が高いが、ＵＥがＳＣ−ＰＴＭを介してファームウェア／グループメッセージを受信するためにＲＲＣアイドルに移行することを強制されると、ストリーミングセッションが解放され、ユーザエクスペリエンスが悪い。

考察２：ＳＣ−ＰＴＭ、例えば、ファームウェア／グループメッセージを受信するために、ユニキャスト、例えばストリーミングセッションを介した通信が解放されると、ユーザエクスペリエンスの悪化を引き起こす可能性がある。

別の例として、ファームウェアのダウンロード中に連続セッションを必要とする可能性のある監視カメラや位置追跡などのリアルタイム監視アプリケーション用にＦｅＭＴＣを実装することも期待できる。これらのユースケースは、ＲＡＮ２＃９５中の議論で示唆されているようにカテゴリ０のＵＥによってカバーされるかもしれないが、ＵＥベンダーの観点からそのようなユースケースに対して費用対効果の高いソリューションを適合させる柔軟性を維持することは依然として有益である。

したがって、ＦｅＭＴＣ ＵＥは、例えば、低消費電力重視のデバイス及び高性能重視のデバイスなどの様々なユースケースに適応するためのいくつかの選択肢を有するべきであるが、ｅＮＢ ＩｏＴ ＵＥに対しては必要ない／正当化されていない。さらに、ｅＮＢが、ＵＥをベースにしたメカニズム、例えばロードバランシングに頼るのではなく、様々なオプションでＵＥを完全に制御することが通常は好ましい。

提案１：ＲＡＮ２は、ＦｅＭＴＣ ＵＥがオプションでＲＲＣコネクティッドでＳＣ−ＰＴＭを受信することを許可されることに同意すべきである。

（２．２）仕様の影響
リリース１３のＳＣ−ＰＴＭは、ＳＣ−ＰＴＭとユニキャストとを同時に受信するかどうかをＵＥ能力依存と仮定した（すなわち、ｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ−ｒ１３）。能力が有効化されると、ＵＥは、同じサブフレームにおいてＤＬ−ＳＣＨの並列受信を実行することができる。ｅＭＴＣ ＵＥは狭帯域、すなわち６ＰＲＢ内の受信をサポートするので、ｅＮＢがＳＣ−ＰＴＭ及びユニキャストをＦＤＤ方式でスケジューリングすることは可能である。これは、１キャリア（すなわち、１ＰＲＢ）内での受信のみを想定するＮＢ−ＩｏＴ ＵＥとは異なる。さらに、ｅＮＢの実装によって、６ＰＲＢが利用可能であること、すなわち不連続なＳＣ−ＰＴＭ送信間のユニキャスト送信のスケジューリングを考慮して、ＳＣ−ＰＴＭ及びユニキャストをＴＤＤ方式でをスケジュールすることも可能である。

考察３：ＳＣ−ＰＴＭ及びユニキャストは、６ＰＲＢ動作のために、ＲＲＣコネクティッドのＦｅＭＴＣ ＵＥに対してスケジュールされることがある。

言い換えれば、並列受信がサポートされていない場合、ＵＥは、能力ビットを転送しないだけである（すなわち、ＦｅＭＴＣ ＵＥに対して「ＲＲＣ＿ＣＯＮＮＥＣＴＥＤモードでのマルチキャスト受信が要求されない」という同じ仮定）。

考察４：リリース１３のＳＣ−ＰＴＭには、ＵＥがＳＣ−ＰＴＭ及びユニキャストの並列受信をサポートしているかどうかを通知するための機能ビット、ｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ−ｒ１３がすでに存在する。

他のＭＢＭＳ関連手順に関して、ＭＢＭＳ興味インジケーション（ＭＢＭＳ Ｉｎｔｅｒｅｓｔ Ｉｎｄｉｃａｔｉｏｎ）は、ＵＥの興味のある周波数をｅＮＢに通知するために使用される。メッセージの本来の目的は、ＲＲＣコネクティッドにおけるサービス継続性、例えばＳＩＢ１５に基づくＵＥの興味のある周波数に応じたハンドオーバ決定であった。ＳＣ−ＰＴＭ受信がＲＲＣアイドルにおいてのみ許可されたとしても、ＭＢＭＳサービスが開始されたときに、ｅＮＢがＵＥをＩＤＬＥに解放するかどうかを決定するためのメッセージが必要である。したがって、ＭＢＭＳ興味インジケーションは、ＦｅＭＴＣ ＵＥがＣｏｎｎｅｃｔｅｄでＳＣ−ＰＴＭを受信することができるかどうかにかかわらず、常に必要である。言うまでもなく、ＵＥはＳＩＢ１５を取得する必要がある。したがって、ＳＩＢ１５−ＢＲなどのＳＩＢ１５の帯域幅縮小バージョンを提供する必要がある。これらは、ＲＡＮ２＃９５で識別される「ＭＴＣのための更なる検討が必要」とは別の問題である。

考察５：ＭＢＭＳ興味インジケーションは、ＲＲＣアイドルにおいてのみＳＣ−ＰＴＭ受信が許可され、ＦｅＭＴＣ ＵＥ（及びｅＮＢ−ＩｏＴ ＵＥ）が事前にＳＩＢ１５を取得する必要がある場合であっても必要である。

ＭＢＭＳカウント（ＭＢＭＳ Ｃｏｕｎｔｉｎｇ）手順では、ＭＢＭＳＣｏｕｎｔｉｎｇＲｅｑｕｅｓｔがＭＣＣＨ（ＳＣ−ＭＣＣＨではなく）にのみ含まれているため、システム帯域幅が最小（すなわち、１．４ＭＨｚ又は６ＰＲＢ）に設定されない限り、ＦｅＭＴＣ ＵＥに対してＰＭＭＳを開始することはできない。ＭＣＣＨを運搬するＰＭＣＨは、ＭＢＳＦＮサブフレーム内及びシステム帯域幅全体（例えば、１０ＭＨｚ ＢＷ（５０ＰＲＢ））の全体にわたって送信され、狭帯域（６ＰＲＢ）を超え、ＦｅＭＴＣ ＵＥで復号できない。したがって、ｅＮＢ／ＭＣＥがＦｅＭＴＣ ＵＥのためのＭＢＭＳカウント手順を開始する必要がある場合であっても、ＦｅＭＴＣ ＵＥ（ならびにｅＮＢ−ＩｏＴ ＵＥ）がＬＴＥ周波数で通常のＬＴＥ ＵＥ、すなわちｏｐｅｒａｔｉｏｎＭｏｄｅＩｎｆｏ−ｒ１３の「帯域内動作（ｉｎ−ｂａｎｄ ｏｐｅｒａｔｉｏｎ）」モードであり、ＦｅＭＴＣ ＵＥがＣｏｎｎｅｃｔｅｄでＳＣ−ＰＴＭを受信することが許可されているかどうかとは別の問題であり、ＲＲＣ接続した方がサポートしやすくなる。

考察６：ＭＢＭＳカウント要求は、「帯域内動作」モードにおいて、ＦｅＭＴＣ ＵＥ（及びｅＮＢ−ＩｏＴ ＵＥ）によっても復号化されないことがある。

したがって、仕様の観点から、ＦｅＭＴＣ ＵＥがＲＲＣコネクティッドでＳＣ−ＰＴＭを受信することを予期する大きな／特定のインパクトはない。

提案２：ＲＡＮ２は、ＦｅＭＴＣ ＵＥ（仕様に影響を与えずに）に対してｓｃｐｔｍ−ＰａｒａｌｌｅｌＲｅｃｅｐｔｉｏｎ−ｒ１３を再利用することに合意すべきである。

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

Claims (3)

1. 移動通信システムであって、
   所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する第１の無線端末と、
   前記限定周波数帯よりも広い周波数帯を用いて無線信号を送受信することが可能な第２の無線端末と、
   ＳＣ−ＰＴＭ伝送用の制御チャネルであるＳＣ−ＭＣＣＨによって、ＳＣ−ＰＴＭ伝送用のトラフィックチャネルであるＳＣ−ＭＴＣＨの設定情報を送信する基地局と、を備え、
   前記基地局は、前記ＳＣ−ＭＴＣＨの設定情報が変更され得るＳＣ−ＭＣＣＨ変更周期として、前記第１の無線端末に対して第１の周期を設定し、前記第２の無線端末に対して前記第１の周期よりも短い第２の周期を設定し、
   前記基地局は、コネクティッドモードにある前記第１の無線端末からＭＢＭＳ興味インジケーションを受信し、
   前記基地局は、前記ＭＢＭＳ興味インジケーションに基づいて、前記第１の無線端末をアイドルモードに遷移させるか否かを判断する 移動通信システム。
2. 基地局であって、
   ＳＣ−ＰＴＭ伝送用の制御チャネルであるＳＣ−ＭＣＣＨによって、ＳＣ−ＰＴＭ伝送用のトラフィックチャネルであるＳＣ−ＭＴＣＨの設定情報を送信する制御部を備え、
   前記制御部は、前記ＳＣ−ＭＴＣＨの設定情報が変更され得るＳＣ−ＭＣＣＨ変更周期として、第１の無線端末に対して第１の周期を設定し、第２の無線端末に対して前記第１の周期よりも短い第２の周期を設定し、
   前記第１の無線端末は、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する無線端末であり、
   前記第２の無線端末は、前記限定周波数帯よりも広い周波数帯を用いて無線信号を送受信することが可能な無線端末であり、
   前記制御部は、コネクティッドモードにある前記第１の無線端末からＭＢＭＳ興味インジケーションを受信し、
   前記制御部は、前記ＭＢＭＳ興味インジケーションに基づいて、前記第１の無線端末をアイドルモードに遷移させるか否かを判断する
   基地局。
3. 移動通信方法であって、
   基地局が、ＳＣ−ＰＴＭ伝送用の制御チャネルであるＳＣ−ＭＣＣＨによって、ＳＣ−ＰＴＭ伝送用のトラフィックチャネルであるＳＣ−ＭＴＣＨの設定情報を送信し、
   前記基地局が、前記ＳＣ−ＭＴＣＨの設定情報が変更され得るＳＣ−ＭＣＣＨ変更周期として、第１の無線端末に対して第１の周期を設定し、第２の無線端末に対して前記第１の周期よりも短い第２の周期を設定し、
   前記第１の無線端末は、所定リソースブロック数の帯域幅に限定された限定周波数帯を用いて無線信号を送受信する無線端末であり、
   前記第２の無線端末は、前記限定周波数帯よりも広い周波数帯を用いて無線信号を送受信することが可能な無線端末であり、
   前記基地局が、コネクティッドモードにある前記第１の無線端末からＭＢＭＳ興味インジケーションを受信し、
   前記基地局が、前記ＭＢＭＳ興味インジケーションに基づいて、前記第１の無線端末をアイドルモードに遷移させるか否かを判断する
   移動通信方法。

Images