JP6239791B2

JP6239791B2 - 基地局、プロセッサ及びユーザ端末

Info

Publication number: JP6239791B2
Application number: JP2016572081A
Authority: JP
Inventors: 真人藤代; 裕之安達; 空悟守田
Original assignee: Kyocera Corp
Current assignee: Kyocera Corp
Priority date: 2015-01-30
Filing date: 2016-01-27
Publication date: 2017-11-29
Anticipated expiration: 2036-01-27
Also published as: JP6276889B1; US10045395B2; EP3253129A4; JP2018038071A; US20170339723A1; WO2016121786A1; EP3253129A1; JPWO2016121786A1

Description

本発明は、移動通信システムにおける基地局、プロセッサ及びユーザ端末に関する。

移動通信システムの標準化プロジェクトである３ＧＰＰ（ＴｈｉｒｄＧｅｎｅｒａｔｉｏｎＰａｒｔｎｅｒｓｈｉｐＰｒｏｊｅｃｔ）において、マルチキャスト／ブロードキャスト伝送を実現する技術として、ＭＢＭＳ（ＭｕｌｔｉｍｅｄｉａＢｒｏａｄｃａｓｔＭｕｌｔｉｃａｓｔＳｅｒｖｉｃｅ）が仕様化されている。

ＭＢＭＳにおいて、複数のセルは、ＭＢＳＦＮ（Ｍｕｌｔｉｃａｓｔ−ＢｒｏａｄｃａｓｔＳｉｎｇｌｅ−ＦｒｅｑｕｅｎｃｙＮｅｔｗｏｒｋ）サブフレームと称される特別なサブフレームを使用して、同一のＭＢＳＦＮエリアに属する複数のセルが同一のマルチキャスト／ブロードキャストデータを送信する。ユーザ端末は、複数のセルから送信されるマルチキャスト／ブロードキャストデータを受信する。

ＭＢＭＳは、ＭＢＳＦＮサブフレームがＭＢＭＳ用となってしまうことに加えて、ＭＢＳＦＮサブフレームを動的に変更することが困難であるため、無線リソースの無駄が生じ易い。

一方で、無線リソースの利用効率を高めつつマルチキャスト伝送を実現するために、単一セルＰＴＭ（ＳＣＰＴＭ：Ｓｉｎｇｌｅ−ＣｅｌｌＰｏｉｎｔ−Ｔｏ−Ｍｕｌｔｉｐｏｉｎｔ）伝送が検討されている。ＭＢＳＦＮエリア単位でのマルチキャスト／ブロードキャスト伝送が適用されるＭＢＭＳとは異なり、ＳＣＰＴＭにはセル単位でのマルチキャスト伝送が適用される。また、ＳＣＰＴＭ伝送において、グループに属する複数のユーザ端末に対するマルチキャストデータを送信するために物理下りリンク共有チャネル（ＰＤＳＣＨ）が使用されることが想定されている。

３ＧＰＰ寄書「ＲＰ−１４２２０５」

第１特徴に係る基地局は、ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートする基地局である。前記基地局は、ユーザ端末へ信号を送信するトランスミッタと、第１の設定及び第２の設定を前記ユーザ端末に設定するコントローラと、を備える。前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含む。前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定である。前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。

第２特徴に係る装置は、ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートする基地局を制御する装置である。前記装置は、プロセッサを備える。前記プロセッサは、第１の設定及び第２の設定をユーザ端末に設定する処理を実行する。前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含む。前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定である。前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。

第３特徴に係るユーザ端末は、ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートするユーザ端末である。前記ユーザ端末は、基地局から信号を受信するレシーバと、コントローラと、を備える。前記レシーバは、第１の設定及び第２の設定を前記基地局から受信する。前記コントローラは、前記第１の設定及び前記第２の設定を設定する。前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含む。前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定である。前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である。

第１実施形態及び第２実施形態に係るＬＴＥシステムの構成図である。第１実施形態及び第２実施形態に係る無線インターフェイスのプロトコルスタック図である。第１実施形態及び第２実施形態に係る無線フレームの構成図である。第１実施形態及び第２実施形態に係るＵＥのブロック図である。第１実施形態及び第２実施形態に係るｅＮＢのブロック図である。第１実施形態及び第２実施形態に係るＳＣＰＴＭを説明するための図である。第１実施形態に係るＰＤＣＣＨ監視タイミングを説明するための図である。第１実施形態の動作パターン２に係るＤＲＸ−Ｃｏｎｆｉｇの内容を示す図である。第１実施形態の動作パターン３に係るサブフレーム設定情報の内容を示す図である。第１実施形態の動作パターン４において一部の変数を設定するための設定情報等を示す図である。第１実施形態の変更例１に係るシーケンス図である。第２実施形態に係るページングメッセージの構成例を示す図である。第２実施形態の動作パターン１を示すシーケンス図である。第２実施形態の動作パターン２を示すシーケンス図である。

［実施形態の概要］
本実施形態は、ＳＣＰＴＭ伝送を適切に行うことを可能とするユーザ端末及び基地局を提供することを目的とする。

第１実施形態に係るユーザ端末は、複数のユーザ端末を含むグループに属する。前記ユーザ端末は、物理下りリンク制御チャネルを間欠的に監視するＤＲＸ動作を制御する制御部と、前記物理下りリンク制御チャネルの監視結果に基づいて、物理下りリンク共有チャネルを介して基地局から前記複数のユーザ端末に送信されるマルチキャストデータを受信する受信部と、を備える。前記制御部は、前記グループのグループ識別子に基づいて、前記ＤＲＸ動作における前記物理下りリンク制御チャネルの監視タイミングを決定する。

第１実施形態において、前記受信部は、前記監視タイミングにおいて前記物理下りリンク制御チャネルを監視することにより、前記マルチキャストデータに対応するスケジューリング情報を受信する。

第１実施形態において、前記制御部は、前記グループ識別子に基づく前記監視タイミング及び前記グループ識別子に基づかない他の監視タイミングの両タイミングにおいて前記物理下りリンク制御チャネルを監視するよう制御する。

第１実施形態の変更例１において、前記グループ識別子は、前記基地局から取得したグループＲＮＴＩである。前記制御部は、前記ユーザ端末がＲＲＣコネクティッドモードからＲＲＣアイドルモードに遷移しても、前記グループＲＮＴＩを保持する。

第１実施形態の変更例２において、前記制御部は、前記グループ識別子に基づく前記監視タイミング及び前記グループ識別子に基づかない他の監視タイミングのうち、前記グループ識別子に基づく前記監視タイミングにおいてのみ前記物理下りリンク制御チャネルを監視するよう制御する。

第１実施形態の変更例２において、前記受信部は、前記マルチキャストデータが送信されるか否かを示す情報を含むページングメッセージを前記基地局から受信する。前記制御部は、前記ページングメッセージに基づいて、前記グループ識別子に基づく前記ＤＲＸ動作を開始する。

第１実施形態に係る基地局は、グループに属する複数のユーザ端末が在圏するセルを管理する。前記基地局は、物理下りリンク制御チャネルを介して、物理下りリンク共有チャネルのスケジューリング情報を送信し、前記物理下りリンク共有チャネルを介して前記複数のユーザ端末にマルチキャストデータを送信する送信部と、前記グループのグループ識別子に基づいて、前記物理下りリンク制御チャネルを前記複数のユーザ端末が監視する監視タイミングを特定する制御部と、を備える。

第１実施形態において、前記送信部は、前記監視タイミングにおいて、前記マルチキャストデータに対応する前記スケジューリング情報を送信する。

第１実施形態の変更例３において、前記送信部は、前記マルチキャストデータを送信するか否かを示す情報を含むページングメッセージを送信する。

第２実施形態に係るユーザ端末は、複数のユーザ端末を含むグループに属する。前記ユーザ端末は、ページングメッセージを基地局から受信する受信部と、前記ページングメッセージに基づいて、物理下りリンク共有チャネルを介してマルチキャストデータを受信するか否かを決定する制御部と、を備える。前記ページングメッセージは、前記マルチキャストデータが送信されるか否かに関する通知情報を含む。

第２実施形態において、前記通知情報は、前記マルチキャストデータの送信開始又は前記マルチキャストデータの送信終了を示す情報である。

第２実施形態において、前記通知情報は、前記マルチキャストデータの送信が開始されるグループ又は前記マルチキャストデータの送信が終了されるグループのグループ識別子である。

第２実施形態において、前記受信部は、前記マルチキャストデータの送信に使用される無線リソースに関するリソース情報を含むメッセージを前記基地局から受信する。前記制御部は、前記ページングメッセージに含まれる前記通知情報に基づき前記マルチキャストデータの送信開始が示される場合、前記リソース情報が示す無線リソースにより前記マルチキャストデータを受信する。

第２実施形態の動作パターン１において、前記メッセージは、ブロードキャストメッセージである。

第２実施形態の動作パターン２において、前記制御部は、前記マルチキャストデータの送信に使用される無線リソースの通知を前記基地局に要求する。前記メッセージは、前記要求に応じて送信されるユニキャストメッセージである。

第２実施形態の動作パターン３において、前記制御部は、前記ページングメッセージに基づいて、物理下りリンク制御チャネルを間欠的に監視するＤＲＸ動作を開始するか否かを決定する。前記ＤＲＸ動作における前記物理下りリンク制御チャネルの監視タイミングは、前記グループのグループ識別子に基づいて決定される。

第２実施形態に係る基地局は、グループに属する複数のユーザ端末が在圏するセルを管理する。前記基地局は、物理下りリンク共有チャネルを介してマルチキャストデータを送信するか否かを決定する制御部と、前記マルチキャストデータを送信するか否かに関する通知情報を含むページングメッセージを送信する送信部と、を備える。

第２実施形態において、前記送信部は、前記マルチキャストデータの送信に使用される無線リソースに関するリソース情報を含むメッセージをさらに送信する。

第２実施形態の動作パターン２において、前記送信部は、前記マルチキャストデータの送信に使用される無線リソースの通知をユーザ端末から要求された場合、該ユーザ端末に前記メッセージをユニキャストで送信する。

［第１実施形態］
以下において、３ＧＰＰ規格に基づく移動通信システムであるＬＴＥシステムに本発明を適用する場合の実施形態を説明する。

（ＬＴＥシステムの概要）
まず、ＬＴＥシステムのシステム構成について説明する。図１は、ＬＴＥシステムの構成図である。

図１に示すように、ＬＴＥシステムは、ＵＥ（ＵｓｅｒＥｑｕｉｐｍｅｎｔ）１００、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−ＵＭＴＳＴｅｒｒｅｓｔｒｉａｌＲａｄｉｏＡｃｃｅｓｓＮｅｔｗｏｒｋ）１０、及びＥＰＣ（ＥｖｏｌｖｅｄＰａｃｋｅｔＣｏｒｅ）２０を備える。

ＵＥ１００は、ユーザ端末に相当する。ＵＥ１００は、移動型の通信装置であり、セル（サービングセル）との無線通信を行う。ＵＥ１００の構成については後述する。

Ｅ−ＵＴＲＡＮ１０は、無線アクセスネットワークに相当する。Ｅ−ＵＴＲＡＮ１０は、ｅＮＢ２００（ｅｖｏｌｖｅｄＮｏｄｅ−Ｂ）を含む。ｅＮＢ２００は、基地局に相当する。ｅＮＢ２００は、Ｘ２インターフェイスを介して相互に接続される。ｅＮＢ２００の構成については後述する。

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

ＥＰＣ２０は、コアネットワークに相当する。ＥＰＣ２０は、ＭＭＥ（ＭｏｂｉｌｉｔｙＭａｎａｇｅｍｅｎｔＥｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−Ｇａｔｅｗａｙ）３００を含む。ＭＭＥは、ＵＥ１００に対する各種モビリティ制御等を行う。Ｓ−ＧＷは、データの転送制御を行う。ＭＭＥ／Ｓ−ＧＷ３００は、Ｓ１インターフェイスを介してｅＮＢ２００と接続される。Ｅ−ＵＴＲＡＮ１０及びＥＰＣ２０は、ネットワークを構成する。

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

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

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

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

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

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

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

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

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

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

下りリンクにおいて、各サブフレームの先頭数シンボルの区間は、主に下りリンク制御信号を伝送するための物理下りリンク制御チャネル（ＰＤＣＣＨ）として使用される領域である。また、各サブフレームの残りの部分は、主に下りリンクデータを伝送するための物理下りリンク共有チャネル（ＰＤＳＣＨ）として使用できる領域である。また、各サブフレームには、セル固有参照信号（ＣＲＳ：ＣｅｌｌｓｐｅｃｉｆｉｃＲｅｆｅｒｅｎｃｅＳｉｇｎａｌ）などの下りリンク参照信号が配置される。

上りリンクにおいて、各サブフレームにおける周波数方向の両端部は、主に上りリンク制御信号を伝送するための物理上りリンク制御チャネル（ＰＵＣＣＨ）として使用される領域である。各サブフレームにおける残りの部分は、主に上りリンクデータを伝送するための物理上りリンク共有チャネル（ＰＵＳＣＨ）として使用できる領域である。また、各サブフレームには、サウンディング参照信号（ＳＲＳ）などの上りリンク参照信号が配置される。

（ＵＥ１００の構成）
図４は、ＵＥ１００（ユーザ端末）の構成を示すブロック図である。図４に示すように、ＵＥ１００は、受信部１１０、送信部１２０、及び制御部１３０を備える。

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

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

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

ＵＥ１００は、ユーザインターフェイス及びバッテリを備えてもよい。ユーザインターフェイスは、ＵＥ１００を所持するユーザとのインターフェイスであり、例えば、ディスプレイ、マイク、スピーカ、及び各種ボタン等を含む。ユーザインターフェイスは、ユーザからの操作を受け付けて、該操作の内容を示す信号を制御部１３０に出力する。バッテリは、ＵＥ１００の各ブロックに供給すべき電力を蓄える。

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

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

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

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

バックホール通信部２４０は、他のｅＮＢ２００及び上述したネットワークエンティティとのバックホール通信に用いられる。

（単一セルＰＴＭ伝送の概要）
以下において、単一セルＰＴＭ伝送（ＳＣＰＴＭ）について説明する。ＳＣＰＴＭは、無線リソースの利用効率を高めつつマルチキャスト伝送を実現する。図６は、第１実施形態に係るＳＣＰＴＭ関連動作を説明するための図である。

図６に示すように、ＳＣＰＴＭにおいて、ｅＮＢ２００は、ＰＤＳＣＨを使用して、単一のセルによりマルチキャストデータを送信する。すなわち、ＭＢＳＦＮエリア単位でのマルチキャスト／ブロードキャスト伝送が適用されるＭＢＭＳとは異なり、ＳＣＰＴＭは、セル単位でのマルチキャスト伝送が適用される。

同一のマルチキャストデータを受信する複数のＵＥ１００（ＵＥ１００−１、ＵＥ１００−２…）は、ＵＥグループを構成する。当該ＵＥグループ内の各ＵＥ１００には、共通のグループ識別子が割り当てられている。グループ識別子は、例えばＴＭＧＩ（ＴｅｍｐｏｒａｒｙＭｏｂｉｌｅＧｒｏｕｐＩｄｅｎｔｉｔｙ）又はグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）である。グループ識別子は、ｅＮＢ２００（又はＭＣＥ１１）により割り当てられる。或いは、グループ識別子は、コアネットワーク（ＥＰＣ２０）のエンティティにより割り当てられてもよい。或いは、グループ識別子は、アプリケーションサーバ（例えば、ＧＧＳＡＳ３１）により割り当てられてもよい。

ＳＣＰＴＭが適用される典型的なアプリケーションは、グループ通信サービス（例えば、グループ通話サービス）である。グループ通信サービスにおいては、下りリンクにマルチキャスト伝送が適用され、上りリンクにユニキャスト伝送が適用され得る。

（ＤＲＸ動作の概要）
以下において、ＤＲＸ（ＤＲＸ：ＤｉｓｃｏｎｔｉｎｕｏｕｓＲｅｃｅｐｔｉｏｎ）動作について説明する。

ＵＥ１００は、バッテリを節約するために、ＤＲＸ動作を行うことが可能である。ＤＲＸ動作を行うＵＥ１００は、ＰＤＣＣＨを間欠的に監視する。通常、サブフレーム中のＰＤＣＣＨは、当該サブフレーム中のＰＤＳＣＨのスケジューリング情報（無線リソース及びトランスポートフォーマットの情報）を運搬する。

ＵＥ１００がＲＲＣアイドルモードである場合、ＵＥ１００は、着信があることを通知するページングメッセージを受信するためにＰＤＣＣＨを間欠的に監視するＤＲＸ動作を行う。ページングメッセージは、ＰＤＣＣＨの共通サーチスペースに含まれ得る。ＵＥ１００におけるＰＤＣＣＨ監視タイミングは、通常、ＵＥ１００の識別子（ＩＭＳＩ：ＩｎｔｅｒｎａｔｉｏｎａｌＭｏｂｉｌｅＳｕｂｓｃｒｉｂｅｒＩｄｅｎｔｉｔｙ）に基づいて定められる。このため、ＰＤＣＣＨ監視タイミングはＵＥ１００ごとに異なる場合が多い。

ＵＥ１００がＲＲＣコネクティッドである場合、ＵＥ１００は、通信すべきデータが所定期間存在しないときにＤＲＸ動作を行う。ＤＲＸ動作状態にあるＵＥ１００は、周期的に、すなわち、間欠的にＰＤＣＣＨを監視する。ＰＤＣＣＨを監視する期間は、ＤＲＸのＯＮ期間（Ｏｎ−ｄｕｒａｔｉｏｎ）と称される。また、Ｏｎ−ｄｕｒａｔｉｏｎが設定される周期は、ＤＲＸ周期（ＤＲＸサイクル）と称される。Ｏｎ−ｄｕｒａｔｉｏｎ及びＤＲＸサイクルは、ＲＲＣメッセージにより設定されたＤＲＸ設定（ＤＲＸ−Ｃｏｎｆｉｇ）に従う。このため、ＰＤＣＣＨ監視タイミングはＵＥ１００ごとに異なる場合が多い。

このように、ＵＥ１００は、バッテリを節約するためにＤＲＸ動作を行うことが可能である。一方で、上述したＳＣＰＴＭ伝送は、ＰＤＳＣＨを介してマルチキャストデータを送信する技術である。よって、ＤＲＸ動作を行う複数のＵＥ１００がマルチキャストデータを受信するためには、当該複数のＵＥ１００におけるＤＲＸ動作を揃えなければならない。しかしながら、ＤＲＸ動作の設定内容はＵＥ１００ごとに異なるため、ＳＣＰＴＭ伝送を適切に行うことが困難である。

（ＵＥ１００の動作）
以下において、第１実施形態に係るＵＥ１００の動作について説明する。具体的には、上述したＳＣＰＴＭ伝送及びＤＲＸ動作を両立するための動作について説明する。

第１実施形態に係るＵＥ１００は、複数のＵＥ１００を含むＵＥグループに属する。ＵＥグループは、ＳＣＰＴＭ伝送によるグループ通信を行うグループである。ＵＥ１００の制御部１３０は、ＰＤＣＣＨを間欠的に監視するＤＲＸ動作を制御する。ＵＥ１００の受信部１１０は、ＰＤＣＣＨの監視結果に基づいて、ＰＤＳＣＨを介してｅＮＢ２００から複数のＵＥ１００に送信されるマルチキャストデータ（以下、「ＳＣＰＴＭデータ」という）を受信する。

第１実施形態において、ＵＥ１００の制御部１３０は、自ＵＥグループのグループ識別子に基づいて、ＤＲＸ動作におけるＰＤＣＣＨ監視タイミングを決定する。このように、ＵＥ１００がグループ識別子に基づいてＰＤＣＣＨ監視タイミングを決定することにより、ＵＥグループごとにＰＤＣＣＨ監視タイミングを揃えることが可能となる。ＰＤＣＣＨ監視タイミングの決定動作の詳細については後述する。

なお、ＵＥ１００が複数のＵＥグループに属する場合、複数のＵＥグループに対応する複数のＰＤＣＣＨ監視タイミング設定（ＤＲＸ設定）が適用されてもよい。

ＵＥ１００の受信部１１０は、ＰＤＣＣＨ監視タイミングにおいてＰＤＣＣＨを監視することにより、ＳＣＰＴＭデータに対応するスケジューリング情報を受信する。これにより、スケジューリング情報に基づいてＰＤＳＣＨ（ＳＣＰＴＭデータ）を受信することができる。

第１実施形態において、ＵＥ１００の制御部１３０は、グループ識別子に基づくＰＤＣＣＨ監視タイミング及びグループ識別子に基づかないＰＤＣＣＨ監視タイミングの両タイミングにおいてＰＤＣＣＨを監視するよう制御する。

ここで、グループ識別子に基づかないＰＤＣＣＨ監視タイミングとは、既存３ＧＰＰ仕様に従った通常のＰＤＣＣＨ監視タイミングである。具体的には、ＵＥ１００がＲＲＣアイドルモードである場合、ＩＭＳＩに基づいて定められるＰＤＣＣＨ監視タイミングである。ＵＥ１００がＲＲＣコネクティッドモードである場合、通常のＤＲＸ−Ｃｏｎｆｉｇに基づいて定められるＰＤＣＣＨ監視タイミングである。

図７は、第１実施形態に係るＰＤＣＣＨ監視タイミングを説明するための図である。図７（ａ）に示すＰＤＣＣＨ監視タイミングは、通常のＰＤＣＣＨ監視タイミング（通常のＤＲＸ設定）である。図７（ｂ）に示すＰＤＣＣＨ監視タイミングは、グループ識別子に基づくＰＤＣＣＨ監視タイミング（グループＤＲＸ設定）である。図７（ｃ）に示すように、ＵＥ１００は、通常のＰＤＣＣＨ監視タイミング及びグループ識別子に基づくＰＤＣＣＨ監視タイミングの両タイミングにおいてＰＤＣＣＨを監視する。

（ｅＮＢ２００の動作）
以下において、第１実施形態に係るｅＮＢ２００の動作について説明する。具体的には、上述したＳＣＰＴＭ伝送及びＤＲＸ動作を両立するための動作について説明する。

第１実施形態に係るｅＮＢ２００は、ＵＥグループに属する複数のＵＥ１００が在圏するセルを管理する。ｅＮＢ２００の送信部２１０は、ＰＤＣＣＨを介して、ＰＤＳＣＨのスケジューリング情報を送信し、ＰＤＳＣＨを介して当該複数のＵＥ１００にＳＣＰＴＭデータを送信する。ｅＮＢ２００の制御部２３０は、当該ＵＥグループのグループ識別子に基づいて、ＰＤＣＣＨを当該複数のＵＥ１００が監視するＰＤＣＣＨ監視タイミングを特定する。具体的には、ｅＮＢ２００は、ＵＥ１００におけるＰＤＣＣＨ監視タイミングの決定動作と同様の決定動作を行うことにより、ＵＥ１００におけるＰＤＣＣＨ監視タイミングを特定する。ＰＤＣＣＨ監視タイミングの決定動作の詳細については後述する。

第１実施形態において、ｅＮＢ２００の送信部２１０は、特定したＰＤＣＣＨ監視タイミングにおいて、ＳＣＰＴＭデータに対応するスケジューリング情報を送信する。すなわち、マルチキャストデータを、ＰＤＣＣＨ監視タイミングに対応するサブフレームに割り当てる。これにより、ＵＥグループに属し、且つＤＲＸ動作を行うＵＥ１００が、スケジューリング情報を受信し、受信したスケジューリング情報に基づいてＰＤＳＣＨ（ＳＣＰＴＭデータ）を受信することができる。

（ＰＤＣＣＨ監視タイミングの決定動作）
以下において、第１実施形態に係るＰＤＣＣＨ監視タイミングの決定動作について説明する。

（１）動作パターン１
動作パターン１は、ＲＲＣアイドルモードのＤＲＸ動作におけるＰＤＣＣＨ監視タイミングを、ＩＭＳＩではなく、グループ識別子に基づいて決定する動作パターンである。ＲＲＣアイドルモードのＤＲＸ動作におけるＰＤＣＣＨ監視タイミング（ＰＤＣＣＨ監視サブフレーム）は、ＰａｇｉｎｇＯｃｃａｓｉｏｎ（ＰＯ）と称される。

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

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

ＳＦＮｍｏｄＴ＝（ＴｄｉｖＮ）＊（グループ識別子ｍｏｄＮ） …（１）

ここで、Ｔは、ページングメッセージを受信するためのＵＥ１００のＤＲＸサイクルであり、無線フレームの数で表される。Ｎは、ＴとｎＢのうち最小値である。ｎＢは、４Ｔ，２Ｔ，Ｔ，Ｔ／２，Ｔ／４，Ｔ／８，Ｔ／１６，Ｔ／３２から選択される値である。グループ識別子は、上述したように、ＴＭＧＩ又はグループＲＮＴＩである。グループ識別子をそのまま使用するのではなく、例えば「グループ識別子ｍｏｄ１０２４」により求められる値を使用してもよい。なお、ｅＮＢ２００以外の装置がグループ識別子を割り当てる場合、当該装置からｅＮＢ２００に割当グループ識別子が通知される。

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

ｉ＿ｓ＝ｆｌｏｏｒ（グループ識別子／Ｎ）ｍｏｄＮｓ …（２）

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

次に、表１または表２からＮｓ及びインデックスｉ＿ｓに対応するＰＯを求める。表１はＬＴＥＦＤＤシステムに適用され、表２はＬＴＥＴＤＤシステムに適用される。表１および表２において、Ｎ／Ａは非適用を表す。

動作パターン１に係るＰＤＣＣＨ監視タイミングの決定動作は、ＲＲＣアイドルモードの場合だけでなく、ＲＲＣコネクティッドモードの場合にも適用可能である。

（２）動作パターン２
動作パターン２は、ＲＲＣコネクティッドモードのＤＲＸ動作におけるＰＤＣＣＨ監視タイミングを定義するＤＲＸ−Ｃｏｎｆｉｇを、グループ識別子を指定してｅＮＢ２００からＵＥ１００に通知する動作パターンである。

図８は、動作パターン２に係るＤＲＸ−Ｃｏｎｆｉｇの内容を示す図である。ＤＲＸ−Ｃｏｎｆｉｇは、ＲＲＣメッセージによりｅＮＢ２００からＵＥ１００に通知される。図８に示すように、動作パターン２に係るＤＲＸ−Ｃｏｎｆｉｇは、グループＤＲＸ用のＤＲＸ−Ｃｏｎｆｉｇ（ＧｒｏｕｐＤＲＸ−Ｃｏｎｆｉｇ）として定義される。ＧｒｏｕｐＤＲＸ−Ｃｏｎｆｉｇは、図８の破線枠に示すように、当該ＧｒｏｕｐＤＲＸ−Ｃｏｎｆｉｇが適用されるグループ識別子（ＴＭＧＩ及び／又はグループＲＮＴＩ）を含む。ＵＥ１００は、自ＵＥグループのグループ識別子に対応するＧｒｏｕｐＤＲＸ−Ｃｏｎｆｉｇに基づいて、ＰＤＣＣＨ監視タイミング（Ｏｎ−ｄｕｒａｔｉｏｎ及びＤＲＸサイクル等）を決定する。

動作パターン２に係るＰＤＣＣＨ監視タイミングの決定動作は、ＲＲＣコネクティッドモードの場合だけでなく、ＲＲＣアイドルモードの場合にも適用可能である。

（３）動作パターン３
動作パターン３は、ＰＤＣＣＨ監視タイミングに対応するサブフレームを示す設定情報を、グループ識別子を指定してｅＮＢ２００からＵＥ１００に通知する動作パターンである。

図９は、動作パターン３に係るサブフレーム設定情報（ＳＣＰＴＭ−ＳｕｂｆｒａｍｅＣｏｎｆｉｇ）の内容を示す図である。図９に示すように、ＳＣＰＴＭ−ＳｕｂｆｒａｍｅＣｏｎｆｉｇは、ＰＤＣＣＨ監視タイミング（サブフレーム）を定義するパラメータに加えて、当該ＳＣＰＴＭ−ＳｕｂｆｒａｍｅＣｏｎｆｉｇが適用されるグループ識別子（ＴＭＧＩ及び／又はグループＲＮＴＩ）を含む。ＵＥ１００は、自ＵＥグループのグループ識別子に対応するＳＣＰＴＭ−ＳｕｂｆｒａｍｅＣｏｎｆｉｇに基づいて、ＰＤＣＣＨ監視タイミング（サブフレーム）を決定する。

動作パターン３に係るＰＤＣＣＨ監視タイミングの決定動作は、ＲＲＣコネクティッドモード及びＲＲＣアイドルモードの両方に適用可能である。

（４）動作パターン４
動作パターン４は、動作パターン１を変更した動作パターンである。

ＲＲＣアイドルモードのＤＲＸ動作においては、ページングメッセージの特性から以下が考慮されている。

・ＵＥの省電力化のため、長周期が用いられている。

・ページングに用いることができるサブフレームが限定されている。（最大で、０，４，５，９サブフレーム）

・ページングメッセージを送信できる無線フレームが限定される可能性がある。（ｎＢ＝Ｔ／２，，，，Ｔ／３２）

そのため、グループ通信（ＳＣＰＴＭ）の受信目的で、ページング設定（ＰＣＣＨＣｏｎｆｉｇ）及びＰａｇｉｎｇＦｒａｍｅ（ＰＦ）及びＰａｇｉｎｇＯｃｃａｓｉｏｎ（ＰＯ）算出式を流用するのは好ましくない虞がある。

よって、動作パターン４において、例えば以下の式を利用し、グループ通信用のパラメータを用いて、グループ通信の受信を行ってもよい。ＰＦ（ＲｅｃｅｐｔｉｏｎＦｒａｍｅと称されてもよい）は、下記の式（３）から求められる。

ＳＦＮｍｏｄＴ_{Ｇｒｏｕｐ}＝Ｔ_{Ｇｒｏｕｐ} ＊（ＵＥ＿ＩＤ_{Ｇｒｏｕｐ}ｍｏｄＴ_{Ｇｒｏｕｐ}） …（３）

また、ＰＯ（ＲｅｃｅｐｔｉｏｎＯｃｃａｓｉｏｎと称されてもよい）は、下記の式（４）から求められる。

ｉ＿ｓ_{Ｇｒｏｕｐ} ＝ＵＥ＿ＩＤ_{Ｇｒｏｕｐ}ｍｏｄＮｓ_{Ｇｒｏｕｐ} …（４）

ここで、式（３）及び（４）における変数について表３に示す。

通常のＲＲＣアイドルモードのＤＲＸとは異なり、式（３）において、ページング用のｎＢを無視し、任意の無線フレームが選択できるように変更されている。また、式（４）において、サブフレームの限定をグループ通信用に変更している。

図１０は、動作パターン４において一部の変数を設定するための設定情報（ＧｒｏｕｐＣｏｍｍ−Ｃｏｎｆｉｇ）等を示す図である。ＧｒｏｕｐＣｏｍｍ−Ｃｏｎｆｉｇは、ＲＲＣメッセージによりｅＮＢ２００からＵＥ１００に通知される。

図１０（ａ）に示すように、ＧｒｏｕｐＣｏｍｍ−Ｃｏｎｆｉｇは、グループ通信用の周期（ＤＲＸサイクル）である「ＧｒｏｕｐＰａｇｉｎｇＣｙｃｌｅ」、及び「ＧｒｏｕｐＯｃｃａｓｉｏｎ」を含む。図１０（ｂ）は、「ＧｒｏｕｐＯｃｃａｓｉｏｎ」の例を示し、図１０（ｃ）は、「ｉ＿ｓ_{Ｇｒｏｕｐ}」の例を示す。

なお、動作パターン４に係るＰＤＣＣＨ監視タイミングの決定動作は、ＲＲＣアイドルモードの場合だけでなく、ＲＲＣコネクティッドモードの場合にも適用可能である。

（第１実施形態のまとめ）
第１実施形態において、ＵＥ１００は、自ＵＥグループのグループ識別子に基づいて、ＤＲＸ動作におけるＰＤＣＣＨ監視タイミングを決定する。このように、ＵＥ１００がグループ識別子に基づいてＰＤＣＣＨ監視タイミングを決定することにより、ＵＥグループごとにＰＤＣＣＨ監視タイミングを揃えることが可能となる。

［第１実施形態の変更例１］
上述した第１実施形態において、ｅＮＢ２００（又はＭＣＥ１１）から割り当てられたグループＲＮＴＩをグループ識別子として使用する場合、ＵＥ１００がＲＲＣアイドルモードに遷移してもグループＲＮＴＩを保持することが好ましい。ＵＥグループ内の一部のＵＥ１００がＲＲＣアイドルモードに遷移しても、残りのＵＥ１００はＲＲＣコネクティッドモードであり得るため、ＵＥグループ内の各ＵＥ１００のＰＤＣＣＨ監視タイミングを合わせる必要があるからである。

よって、第１実施形態の変更例１において、ＵＥ１００の制御部１３０は、自ＵＥ１００がＲＲＣコネクティッドモードからＲＲＣアイドルモードに遷移しても、グループＲＮＴＩを保持する。そして、ＵＥ１００の制御部１３０は、保持しているグループＲＮＴＩに基づいて、ＰＤＣＣＨ監視タイミングを決定する。なお、グループＲＮＴＩは、例えば、ＲＲＣアイドルモードのＵＥ１００に対してＲＲＣメッセージ（又はＭＡＣメッセージ）によりｅＮＢ２００（又はＭＣＥ１１）が設定する。

また、グループＲＮＴＩの保持及び／又は解放に関する設定情報をｅＮＢ２００からＵＥ１００に通知してもよい。図１１は、第１実施形態の変更例１に係るシーケンス図である。図１１に示すように、ｅＮＢ２００は、ＵＥ１００とのＲＲＣ接続を解放するための「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ」メッセージに、グループＲＮＴＩの保持及び／又は解放に関する設定情報を含めてもよい。ｅＮＢ２００は、ＵＥ１００から受信するＧＣｉｎｄｉｃａｔｉｏｎに基づいて当該設定情報をＵＥ１００に送信してもよい。

当該設定情報は、グループＲＮＴＩの保持期間を定義するタイマ値を含む。ＵＥ１００は、ＲＲＣアイドルモードに遷移した際にタイマを起動し、当該タイマが設定タイマ値に達するまでグループＲＮＴＩを保持してもよい。なお、ＵＥ１００がＳＣＰＴＭの受信に興味を持っている場合には、タイマが満了するまでグループＲＮＴＩを保持し、ＵＥ１００がＳＣＰＴＭの受信に興味を持っていない場合には、タイマ値に達するか否かに関わらずグループＲＮＴＩを破棄してもよい。

また、図１１は、「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ」メッセージを使用してグループＲＮＴＩの保持及び／又は解放に関する設定を行うシーケンスであるが、「ＲＲＣＣｏｎｎｅｃｔｉｏｎＲｅｌｅａｓｅ」メッセージを使用しない方法も可能である。例えば、ＲＲＣコネクティッドモードの際にｅＮＢ２００から設定タイマ値を受信する、又はＵＥ１００に設定タイマ値を事前設定しておく。そして、ＲＲＣＣｏｎｅｃｔｉｏｎＲｅｌｅａｓｅの際にタイマを起動し、当該タイマ値が設定タイマ値に達した場合（満了した場合）、グループＲＮＴＩを解放する。

［第１実施形態の変更例２］
上述した第１実施形態において、ＵＥ１００の制御部１３０は、グループ識別子に基づくＰＤＣＣＨ監視タイミング及びグループ識別子に基づかないＰＤＣＣＨ監視タイミング（通常のＰＤＣＣＨ監視タイミング）の両タイミングにおいてＰＤＣＣＨを監視するよう制御していた。しかしながら、通常のＰＤＣＣＨ監視タイミングを適用せずに、グループ識別子に基づくＰＤＣＣＨ監視タイミングのみを適用してもよい。

第１実施形態の変更例２において、ＵＥ１００の制御部１３０は、グループ識別子に基づくＰＤＣＣＨ監視タイミング及びグループ識別子に基づかない他のＰＤＣＣＨ監視タイミング（通常のＰＤＣＣＨ監視タイミング）のうち、グループ識別子に基づくＰＤＣＣＨ監視タイミングにおいてのみＰＤＣＣＨを監視するよう制御する。ｅＮＢ２００の制御部２３０は、通常のＤＲＸ設定をＵＥ１００が破棄又は休止していると認識する。

この場合、ｅＮＢ２００は、通常のＰＤＣＣＨ監視タイミングに合わせてＵＥ１００に送信するべき情報を、グループ識別子に基づくＰＤＣＣＨ監視タイミングに合わせてＵＥ１００に送信することが好ましい。

［第１実施形態の変更例３］
上述した第１実施形態に係るＰＤＣＣＨ監視タイミングの決定動作（グループ識別子に基づくＤＲＸ動作）は、必ずしも常に実施しなくてもよい。例えば、ＳＣＰＴＭデータの送信が開始される前において、ＵＥ１００は、グループ識別子に基づくＤＲＸ動作を行わなくてもよい。

第１実施形態の変更例３において、ｅＮＢ２００の送信部２１０は、ＳＣＰＴＭデータを送信するか否かを示す情報を含むページングメッセージを送信する。ＵＥ１００の受信部１１０は、ＳＣＰＴＭデータが送信されるか否かを示す情報を含むページングメッセージをｅＮＢ２００から受信する。ＵＥ１００の制御部１３０は、ページングメッセージに基づいて、グループ識別子に基づくＤＲＸ動作を開始する。例えば、ＵＥ１００の制御部１３０は、ＳＣＰＴＭデータが送信されことを示す情報がページングメッセージに含まれている場合、グループ識別子に基づくＤＲＸ動作を開始する。このようなページングメッセージの詳細については、第２実施形態において説明する。

［第２実施形態］
第２実施形態について、第１実施形態との相違点を主として説明する。

上述した第１実施形態は、ＤＲＸ動作におけるＰＤＣＣＨ監視タイミングをグループ識別子に基づいて決定する実施形態である。これに対し、第２実施形態は、ＰＤＣＣＨ監視を行うか否かをページングメッセージにより制御する実施形態である。

（ＵＥ１００の動作）
以下において、第２実施形態に係るＵＥ１００の動作について説明する。

第２実施形態に係るＵＥ１００は、複数のＵＥ１００を含むＵＥグループに属する。ＵＥ１００の受信部１１０は、ページングメッセージをｅＮＢ２００から受信する。ＵＥ１００の制御部１３０は、ページングメッセージに基づいて、ＳＣＰＴＭデータを受信するか否かを決定する。ページングメッセージは、ＰＤＳＣＨを介して複数のＵＥ１００にＳＣＰＴＭデータが送信（すなわち、ＳＣＰＴＭ伝送）されるか否かに関する通知情報とＵＥグループのグループ識別子とを含む。

このように、ＳＣＰＴＭ伝送されるＳＣＰＴＭデータの利用可能性をｅＮＢ２００がページングメッセージにより通知することにより、該当するＵＥグループに属するＵＥ１００は、適切なタイミングでＳＣＰＴＭデータを受信することができる。

図１２は、第２実施形態に係るページングメッセージの構成例を示す図である。図１２の破線枠に示すように、通知情報は、ＳＣＰＴＭデータの送信開始（又はＳＣＰＴＭデータの送信終了）を示す通知情報（ｓｃ−ＰＴＭ−ｉｎｄｉｃａｔｉｏｎ）である。或いは、通知情報は、ＳＣＰＴＭデータの送信が開始されるＵＥグループ（又はＳＣＰＴＭデータの送信が終了されるＵＥグループ）のグループ識別子リスト（ＴＭＧＩ−Ｌｉｓｔ）である。ページングメッセージは、通知情報の設定変更の有無を示す情報をさらに含んでもよい。或いは、「通知情報の設定変更の有無」を「通知情報」に代えて送信してもよい。また、「設定変更の有無」とは、具体的には、ＳＣ−ＰＴＭ送信状態が開始から終了、又はその逆に変更したことを示すものであってもよい。

第２実施形態において、ＵＥ１００の受信部１１０は、ＳＣＰＴＭデータの送信に使用される無線リソースに関するリソース情報を含むメッセージをｅＮＢ２００から受信する。ＵＥ１００の制御部１３０は、ページングメッセージに含まれる通知情報に基づきＳＣＰＴＭデータの送信開始が示される場合、リソース情報が示す無線リソースによりマルチキャストデータを受信する。必要に応じて、マルチキャストデータの受信に先立ち、ＰＤＣＣＨを監視する。このようなシーケンスの詳細については後述する。

（ｅＮＢ２００の動作）
以下において、第２実施形態に係るｅＮＢ２００の動作について説明する。

第２実施形態に係るｅＮＢ２００は、ＵＥグループに属する複数のＵＥ１００が在圏するセルを管理する。ｅＮＢ２００の制御部２３０は、ＰＤＳＣＨを介してＳＣＰＴＭデータを送信（すなわち、ＳＣＰＴＭ伝送）するか否かを決定する。ｅＮＢ２００の送信部２１０は、ＳＣＰＴＭデータを送信するか否かに関する通知情報とグループのグループ識別子とを含むページングメッセージを送信する。

上述したように、通知情報は、ＳＣＰＴＭデータの送信開始（又はＳＣＰＴＭデータの送信終了）を示す情報である。或いは、通知情報は、ＳＣＰＴＭデータの送信が開始されるグループ（又はＳＣＰＴＭデータの送信が終了されるグループ）のグループ識別子リストである。

第２実施形態において、ｅＮＢ２００の送信部２１０は、ＳＣＰＴＭデータの送信に使用される無線リソースに関するリソース情報を含むメッセージをさらに送信する。

（動作シーケンス）
以下において、第２実施形態に係る動作シーケンスについて説明する。

（１）動作パターン１
図１３は、第２実施形態の動作パターン１を示すシーケンス図である。動作パターン１において、ＳＣＰＴＭデータの送信に使用される無線リソースに関するリソース情報を含むメッセージは、ブロードキャストメッセージ（ブロードキャストＲＲＣメッセージ）である。このようなブロードキャストＲＲＣメッセージをＳＩＢＸと称する。

図１３に示すように、ステップＳ２１１において、ｅＮＢ２００は、特定のＵＥグループに対するＳＣＰＴＭデータの送信開始を決定する。ｅＮＢ２００は、ＳＣＰＴＭデータの送信開始を示す情報及び当該特定のＵＥグループのグループ識別子を含むページングメッセージを送信する。当該特定のＵＥグループに属するＵＥ１００は、ページングメッセージを受信し、マルチキャストデータの受信を決定する。

ＵＥ１００は、ＳＩＢＸを受信するために、先ずＳＩＢ１をｅＮＢ２００から受信し、ＳＩＢ１に基づいてＳＩＢＸのスケジューリング情報を取得する。

ステップＳ２１２において、ｅＮＢ２００は、ＳＣＰＴＭデータの送信に使用される無線リソースに関するリソース情報を含むＳＩＢＸを送信する。ＳＩＢＸは、ＵＥグループ（グループ識別子）ごとのリソース情報を含む。ＵＥ１００は、ＳＩＢＸを受信し、自ＵＥグループに対応するリソース情報を取得する。ＳＩＢＸは、第１実施形態に係る動作を行うためのグループＲＮＴＩを含んでもよい。

リソース情報は、ＳＣＰＴＭデータの送信に使用されるサブフレームを示す情報を含む。ＳＣＰＴＭデータの送信に使用されるサブフレームとは、ＳＣＰＴＭデータが送信される可能性のあるサブフレームであってもよい。この場合、ＵＥ１００は、当該サブフレームにおいてＰＤＣＣＨを監視する。なお、サブフレームを示す情報は、ビットマップ形式で表現されてもよい。例えば、ＳＣＰＴＭデータの送信に使用されるサブフレームを「１」、ＳＣＰＴＭデータの送信に使用されないサブフレームを「０」とするビットからなるビットマップである。

或いは、リソース情報は、より詳細な情報であってもよい。例えば、リソース情報は、ＳＣＰＴＭデータの送信に使用される無線リソース（サブフレーム、リソースブロック）及びトランスポートフォーマット等の情報を含む。この場合、ＵＥ１００は、必ずしも当該サブフレームにおいてＰＤＣＣＨを監視することを要しない。

ステップＳ２１３において、ｅＮＢ２００は、ＳＩＢＸにおけるリソース情報で示した無線リソースを使用して、ＳＣＰＴＭデータを送信する。ＵＥ１００は、ＳＩＢＸにおけるリソース情報に基づいて、ＳＣＰＴＭデータを受信する。

（２）動作パターン２
図１４は、第２実施形態の動作パターン２を示すシーケンス図である。動作パターン２において、ＳＣＰＴＭデータの送信に使用される無線リソースに関するリソース情報を含むメッセージは、ユニキャストメッセージ（例えば、個別ＲＲＣメッセージ）である。

図１４に示すように、ステップＳ２２１において、ｅＮＢ２００は、特定のＵＥグループに対するＳＣＰＴＭデータの送信開始を決定する。ｅＮＢ２００は、ＳＣＰＴＭデータの送信開始を示す情報及び当該特定のＵＥグループのグループ識別子を含むページングメッセージを送信する。当該特定のＵＥグループに属するＵＥ１００は、ページングメッセージを受信し、マルチキャストデータの受信を決定する。

ステップＳ２２２において、ＵＥ１００は、ＳＣＰＴＭデータの送信に使用される無線リソースの通知をｅＮＢ２００に要求する。このようなメッセージは、例えばグループ通信興味通知である。グループ通信興味通知は、ＵＥ１００が興味を持つグループ通信に対応するグループ識別子（例えば、ＴＭＧＩ）を含んでもよい。グループ通信興味通知は、具体的には、「ＧＣｉｎｄｉｃａｔｉｏｎ」であってよく、「ＧＣｉｎｄｉｃａｔｉｏｎ」はＴＭＧＩリストを含んでもよい。

ステップＳ２２３において、ｅＮＢ２００は、ＵＥ１００からの要求に応じて、リソース情報を含むユニキャストメッセージをＵＥ１００に送信する。例えば、ｅＮＢ２００は、グループ通信興味通知に含まれるグループ識別子に対応するリソース情報をユニキャストメッセージによりＵＥ１００に通知する。リソース情報の構成については、動作パターン１と同様である。

ステップＳ２２４において、ｅＮＢ２００は、ユニキャストメッセージにおけるリソース情報で示した無線リソースを使用して、ＳＣＰＴＭデータを送信する。ＵＥ１００は、ユニキャストメッセージにおけるリソース情報に基づいて、ＳＣＰＴＭデータを受信する。

（３）動作パターン３
動作パターン３は、上述した第１実施形態の変更例３と同様の動作パターンである。ＵＥ１００は、ページングメッセージに基づいて、ＤＲＸ動作を開始するか否かを決定する。ＤＲＸ動作におけるＰＤＣＣＨ監視タイミングは、自ＵＥグループのグループ識別子に基づいて決定される。

（第２実施形態のまとめ）
上述したように、ＳＣＰＴＭ伝送されるＳＣＰＴＭデータの利用可能性をｅＮＢ２００がページングメッセージにより通知することにより、該当するＵＥグループに属するＵＥ１００は、適切なタイミングでＳＣＰＴＭデータを受信することができる。

［その他の実施形態］
上述した第１実施形態及び第２実施形態は、別個独立して実施される場合に限定されない。第１実施形態及び第２実施形態を組み合わせて実施してもよい。

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

［付記］
（導入）
単一セルポイントツーマルチポイント（ＰＴＭ）伝送のサポートに関する新たな研究アイテムが承認された。人気のビデオ／アプリのダウンロード、モバイル広告及び車のための交通情報等の商用ユースケースと、クリティカル通信とについて、本研究アイテムは、Ｒｅｌ−１２のｅＭＢＭＳベースのメカニズムと比較して、グループ通信のためのよりフレキシブルな／効率的な無線インターフェイスを検討する。Ｒｅｌ−１３の研究における大きな課題の一つは、ＰＤＳＣＨを介した「動的マルチキャスト」として期待され、研究の目的は以下のように特定される。

ユーザグループ（すなわち、特定のサービス／コンテンツに共通の興味を持っているユーザ）を対象とする、ＰＤＳＣＨを介したＤＬマルチキャストを、ＵＥが受信するための方法を研究する。

単一セルＰＴＭ伝送に対して、ＨＡＲＱフィードバックとＣＳＩレポートがまだ必要であるかを検討し、もしそうであれば可能な解決策を特定する。

サービスの継続性の側面を研究する。

本付記において、ＰＤＳＣＨが単一セルＰＴＭのために使われることを想定し、単一セルＰＴＭ受信の観点から、幾つかの可能な問題が特定された。

（検討）
本研究アイテムに対する我々の理解に基づいて、アイドルモード又はコネクティッドモードの何れで、ＵＥが単一セルＰＴＭ受信を行うことが目的である。ＳＩＤは、解決策が、同じセル内のＭＢＳＦＮ配置を補完することができるべきであることを明確に言及するので、アイドルモードのＵＥは、単一セルＰＴＭ信号とｅＭＢＭＳ受信との両方を受信できるべきである。プッシュツートークのようなクリティカル通信のためのユースケースを考慮し、音声データを送信するコネクティッドモードのＵＥは、単一セルＰＴＭ伝送を受信する可能性がある。従って、単一セルＰＴＭ受信は、アイドルモードとコネクティッドモードとの両方において行われるべきである。

提案１：単一セルＰＴＭ受信がアイドルモードとコネクティッドモードとの両方において行われると仮定すべきである。

単一セルＰＴＭでのマルチキャスト送信のためにＰＤＣＣＨが仮定される場合に、ＤＲＸ、ＰＤＣＣＨ監視等の下記の問題が考慮されるべきである。ＤＲＸから独立して行われるｅＭＢＭＳ受信と比較して、コネクティッドモードにおける単一セルＰＴＭ受信における課題の一つは、既存のＤＲＸメカニズム内に該受信が動作できるようにすることである。課題は、ＤＲＸと単一セルＰＴＭとの間のサブフレーム揃いに由来する。ＭＢＳＦＮサブフレームは、通常のサブフレームから完全に分離されているが、単一セルＰＴＭ伝送は、ＰＤＣＣＨにマッピングされ、ＰＤＣＣＨによってスケジュールされることができるため、単一セルＰＴＭ伝送は、通常のサブフレーム内で発生する可能性がある。

現在のアイドルモード手順において、ＵＥ−ＩＤによってランダム化されるページングの機会のみにおいてＵＥがＰＤＣＣＨを監視するように要求されるが、コネクティッドモードのＵＥは、個別シグナリングを介してサービングセルによって制御され、アクティブ時間の間にＰＤＣＣＨを監視するように要求される。同じグループ内の全てのＵＥに対して適用可能であるＰＴＭ伝送の機会を決定するために、更なる検討が必要である。換言すると、同じグループに割り当てられている全てのＵＥに対して、ＰＤＣＣＨを監視する機会が揃うべきである。

提案２：ＰＤＳＣＨが単一セルＰＴＭ伝送のために想定される場合、同じグループに割り当てられている全てのＵＥに対して、ＰＤＣＣＨを監視する機会を十分に揃える方法が検討されるべきである。

以下の選択肢が考えられる。

選択肢１：アイドルモード及びコネクティッドモードにおいて、既存のＤＲＸメカニズムを拡張する。

選択肢２：既存のＤＲＸメカニズムから独立する新たなＤＲＸメカニズムを導入する。

選択肢３：スマートｅＮＢ実装に任せる。

ｅＮＢの観点から見れば後方互換性に影響を与える（例えば、特にアイドルモードにおいて、ＤＲＸ機会を変更することが困難であるかもしれない）が、選択肢１を基準メカニズムとして考えることができる。

標準化のための工夫がより多くなると予期されるが、ＤＲＸルールがグループＩＤ（例えば、ＴＭＧＩ又はグループＲＮＴＩ等）と関連している場合、選択肢２がより簡単な方法であるかもしれない。

標準化の観点から見れば、選択肢３が最も簡単な選択肢であると考えられる。

しかしながら、ｅＮＢが同じグループに属するアイドルＵＥのＵＥ−ＩＤを知ることのできる方法と、コネクティッドモードの全てのＵＥに対してページング機会をＤＲＸＯｎ期間に揃える方法と、が検討されるべきである。選択肢３における、データ配信に興味を持っている全てのＵＥをサポートする困難と、選択肢１における、後方互換性に与える影響と、に起因して、アイドルとコネクティッド両方のＵＥのためのＳＣ−ＰＴＭ受信をサポートする新たなＤＲＸメカニズムが必要であるかを検討すべきである。

提案３：単一セルＰＴＭ伝送のための新たなＤＲＸメカニズムが必要であるかを検討すべきである。

（結論）
この付記において、単一セルＰＴＭのためのＤＲＸ揃いの問題が検討された。

ＤＲＸ揃いの問題を解決するための基礎として使用され得る３つの選択肢が提供される。

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

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

Claims

ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートする基地局であって、
ユーザ端末へ信号を送信するトランスミッタと、
第１の設定及び第２の設定を前記ユーザ端末に設定するコントローラと、を備え、
前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定であり、
前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含み、
前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定であり、
前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である基地局。
ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートする基地局を制御する装置であって、
プロセッサを備え、
前記プロセッサは、第１の設定及び第２の設定をユーザ端末に設定する処理を実行し、
前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定であり、
前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含み、
前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定であり、
前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定である装置。
ＳＣ−ＰＴＭ（ＳｉｎｇｌｅＣｅｌｌＰｏｉｎｔＴｏＭｕｌｔｉｐｏｉｎｔ）をサポートするユーザ端末であって、
基地局から信号を受信するレシーバと、
コントローラと、を備え、
前記レシーバは、第１の設定及び第２の設定を前記基地局から受信し、
前記コントローラは、前記第１の設定及び前記第２の設定を設定し、
前記第１の設定は、前記ＳＣ−ＰＴＭにより前記基地局から送信されるマルチキャストデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定であり、
前記第１の設定は、前記ＰＤＣＣＨを前記ユーザ端末が受信する期間であるＯｎ−ｄｕｒａｔｉｏｎｔｉｍｅｒを含み、
前記第１の設定は、前記ＳＣ−ＰＴＭにより同一のマルチキャストデータを受信する複数のユーザ端末に共通に割り当てられるグループＲＮＴＩ（ＲａｄｉｏＮｅｔｗｏｒｋＴｅｍｐｏｒａｒｙＩｄｅｎｔｉｆｉｅｒ）に対応する設定であり、
前記第２の設定は、前記基地局が他の送信方法により送信されるデータを受信するための制御信号が伝送される物理下りリンク制御チャネル（ＰＤＣＣＨ）を前記ユーザ端末が間欠的に監視することに関する設定であるユーザ端末。