(57)【要約】【課題】カバレッジ改善処理の必要性をM2M端末において判定できるようにするための改良を提供する。【解決手段】ユーザ装置は、カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶ物理下りリンク共有チャネル（ＰＤＳＣＨ）に関する情報を含むマスタ情報ブロックメッセージを、基地局から物理ブロードキャストチャネル（ＰＢＣＨ）において受信する。当該ＰＤＳＣＨに関する情報は、当該ＰＤＳＣＨの繰り返し送信回数を示すために使われる。ユーザ装置は、当該システム情報ブロックタイプ１メッセージを含む１又は複数のシステム情報ブロックメッセージを基地局からＰＤＳＣＨにおいて受信する。そして、ユーザ装置は、カバレッジエンハンスメントのために特有な無線リソースを用いて繰り返しを伴うランダムアクセスプリアンブルを基地局へ送信する。【選択図】図２
2018170782.tif 000002
【特許請求の範囲】
【請求項１】
カバレッジエンハンスメントを実行可能なユーザ装置であって、
基地局と通信するよう構成されたトランシーバと、
コントローラとを有し、
前記コントローラは、前記トランシーバを介して、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶ物理下りリンク共有チャネル（Physical Downlink Shared Channel: PDSCH）に関する情報を含むマスタ情報ブロックメッセージを、前記基地局から物理ブロードキャストチャネル（Physical Broadcast Channel: PBCH）において受信し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを含む１又は複数のシステム情報ブロックメッセージを、前記基地局から前記PDSCHにおいて受信し、
前記カバレッジエンハンスメントのために特有な無線リソースを用いて繰り返しを伴うランダムアクセスプリアンブルを、前記基地局へ送信し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数を示すために使われる、
ユーザ装置。
【請求項２】
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数、及び当該PDSCHが送信されるサブフレームの両方を示すために使われる請求項１に記載のユーザ装置。
【請求項３】
基地局であって、
カバレッジエンハンスメントを実行可能なユーザ装置と通信するよう構成されたトランシーバと、
コントローラとを有し、
前記コントローラは、前記トランシーバを介して、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶ物理下りリンク共有チャネル（Physical Downlink Shared Channel: PDSCH）に関する情報を含むマスタ情報ブロックメッセージを、物理ブロードキャストチャネル（Physical Broadcast Channel: PBCH）において前記ユーザ装置へ報知し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを含む１又は複数のシステム情報ブロックメッセージを、前記PDSCHにおいて前記ユーザ装置へ報知し、
前記カバレッジエンハンスメントのために特有な無線リソースを用いて繰り返しを伴うランダムアクセスプリアンブルを、前記ユーザ装置から受信し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数を示すために使われる、
基地局。
【請求項４】
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数、及び当該PDSCHが送信されるサブフレームの両方を示すために使われる請求項３に記載の基地局。
【請求項５】
カバレッジエンハンスメントを実行可能なユーザ装置の制御方法であって、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶ物理下りリンク共有チャネル（Physical Downlink Shared Channel: PDSCH）に関する情報を含むマスタ情報ブロックメッセージを、基地局から物理ブロードキャストチャネル（Physical Broadcast Channel: PBCH）において受信し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを含む１又は複数のシステム情報ブロックメッセージを、前記基地局から前記PDSCHにおいて受信し、
前記カバレッジエンハンスメントのために特有な無線リソースを用いて繰り返しを伴うランダムアクセスプリアンブルを、前記基地局へ送信することを含み、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数を示すために使われる、
ユーザ装置の制御方法。
【請求項６】
基地局の制御方法であって、
カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶ物理下りリンク共有チャネル（Physical Downlink Shared Channel: PDSCH）に関する情報を含むマスタ情報ブロックメッセージを、物理ブロードキャストチャネル（Physical Broadcast Channel: PBCH）において前記カバレッジエンハンスメントを実行可能なユーザ装置へ報知し、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを含む１又は複数のシステム情報ブロックメッセージを、前記PDSCHにおいて前記ユーザ装置へ報知し、
前記カバレッジエンハンスメントのために特有な無線リソースを用いて繰り返しを伴うランダムアクセスプリアンブルを、前記ユーザ装置から受信することを含み、
前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHに関する情報は、前記カバレッジエンハンスメントのためのシステム情報ブロックタイプ１メッセージを運ぶPDSCHの繰り返し送信回数を示すために使われる、
基地局の制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本明細書の開示は、カバレッジ改善の為の通信制御を行う無線通信システムに関する。
【背景技術】
【０００２】
3GPP Long Term Evolution（LTE）では、近年のモバイルトラフィックの急激な増大による通信品質の低下の改善及びさらなる高速通信の実現のための技術の標準化が行われている。さらに、今後予想される膨大な数のMachine to Machine (M2M) 端末のLTEネットワークへの接続による制御シグナリング負荷の増大を回避する技術の標準化も行われている（非特許文献１）。ここで、M2M端末は、例えば人が介在せずに通信を行う端末を指す。M2M端末は、機械（e.g., 自動販売機、ガスメータ、電気メータ、自動車、鉄道車両、船舶）及びセンサ（e.g., 環境、農業、交通等に関するセンサ）等の様々な機器に搭載される。LTEでは、M2M端末による通信をMachine Type Communication (MTC) と呼び、MTCを行う端末をMTC端末 (MTC User Equipment (MTC UE)) と呼ぶ。
【０００３】
M2Mのサービス事業者は膨大な数のM2M端末を市場に配布する必要があるが、M2M端末1台あたりにかけられるコストに制限がある。この為に、M2M端末は、低コストで実装されること、低消費電力で通信が行えること、等が要求される。また、MTC UEの１つのuse caseとして、建物内（例えばビル内）に固定的又は静的に設置されたまま通信を行う場合が想定される。この場合、MTC UEの無線品質が常に低い可能性があり、一般的に移動性を有する通常のUE（e.g., 携帯電話、スマートフォン、タブレットコンピュータ、ノートブック・パーソナルコンピュータ（ノートブックPC））に比べカバレッジ改善の為の技術が必要となる。また、低コスト化する為の機能制限としては、例えば最大送信電力が小さい、受信アンテナ数が少ない、高次変調方式（e.g. 64 Quadrature Amplitude Modulation（64QAM））をサポートしない、使用可能な無線帯域幅が狭帯域（e.g. 1.25 MHz）である、などが考えられ、これによりMTC UEの最大伝送レートが低下する。そこで、LTEでは、通常UEに比べ劣ることが予想されるMTC UEの通信特性（つまり、カバレッジ）を改善する為の技術の標準化が行われている（非特許文献２）。以下では、LTEで検討されているMTC UEのカバレッジを改善する為の技術の一例を説明する。尚、以下に説明されるMTC UEのためのカバレッジ改善技術（カバレッジ改善処理）は、MTC UEの通信特性又は通信品質を改善又は向上する為の処理と言うこともできる。これらの特別なカバレッジ改善技術を適用するUEの状態は、カバレッジ改善モード（Enhanced Coverage Mode（ECM））と呼ばれる。
【０００４】
ECMにより改善される特性は、Physical Broadcast Channel（PBCH）の受信特性、Physical Random Access Channel（PRACH）プリアンブルの送信特性（つまりeNBにおける検出特性）、Physical Downlink Shared Channel（PDSCH）の受信特性、Physical Uplink Shared Channel（PUSCH）の送信特性、等がある。PBCHは、eNBによるセル内共通の報知情報の送信に用いられる下り報知チャネルである。PRACHは、UEの無線基地局（eNB）への初期アクセスに用いられる上り物理チャネルである。PDSCHは、UEによるデータ受信に用いられる下り物理チャネルである。PUSCHは、UEによるデータ送信に用いられる上り物理チャネルである。
【０００５】
PBCHの受信特性を改善するために検討されている処理の１つは、通常よりも所定回数だけ余分にPBCHによる報知情報の送信を繰り返すことである（非特許文献３）。PRACHの送信特性を改善するために検討されている処理の１つは、PRACH（つまりプリアンブル）の送信を所定回数だけ繰り返すことである（非特許文献４）。さらに、PDSCHの受信特性及びPUSCHの送信特性を改善するために検討されている処理の１つは、複数サブフレームに亘りPDSCH及びPUSCHを繰り返し送信することである（非特許文献５）。これらの処理により、通常UEよりも劣化することが予想されるMTC UEの通信特性が改善することが期待される。
【０００６】
ECMにおけるこれらのカバレッジ改善処理は、耐遅延アクセス（delay tolerant access）を行うMTC UEを対象として行われることが想定されている。delay tolerant accessは、RRC Connection Requestメッセージ内で指定される新たなEstablishmentCauseとして定義され、例えばオーバーロードを制御するために使用される。delay tolerant accessは、delay tolerantなMTCアプリケーションを実行するMTC UEを主に意図している。例えば、メータリングサービス（検針サービス）は、検針レポートの遠隔システムへの送信をリアルタイムで（又は厳密な通信サイクルで）行う必要性がなく、検針レポートの送信において長い遅延を許容するかもしれない。eNBは、delay tolerant accessに対してオーバーロード制御を適用する場合、delay tolerant access に指定されたEstablishmentCauseを伴うRRC Connection Requestメッセージによって送られたRRC Connection Requestを拒絶してもよい。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】3GPP TR 37.868 V11.0.0 (2011-09), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on RAN Improvements for Machine-type Communications; (Release 11)”, 2011年9月
【非特許文献２】3GPP TR 36.888 V12.0.0 (2013-06), “3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Study on provision of low-cost Machine-Type Communications (MTC) User Equipments (UEs) based on LTE (Release 12)”, 2013年6月
【非特許文献３】3GPP R1-135943, Vodafone, “Way Forward on P-BCH for MTC enhanced coverage”, 3GPP TSG RAN WG1 #75, San Francisco, USA, 11-15 November 2013
【非特許文献４】3GPP R1-135944, Vodafone, “Way Forward on PRACH for MTC enhanced coverage”, 3GPP TSG RAN WG1 #75, San Francisco, USA, 11-15 November 2013
【非特許文献５】3GPP R1-136001, Vodafone et al. “Way forward on PDCCH, PDSCH, PUCCH and PUSCH for MTC enhanced coverage”, 3GPP TSG RAN WG1 #75, San Francisco, USA, 11-15 November 2013
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本件の発明者は、ECMにおけるカバレッジ改善処理をMTC UE（M2M端末）に適用する場合の様々な問題について検討した。例えば、PBCHの繰り返しはセル内のMTC UEに共通に適用されるのに対して、RACHの繰り返し並びにPDSCH/PUSCHの繰り返しは各MTC UEに個別に適用される。
【０００９】
一例において、ECM、特にMTC UE個別のカバレッジ改善処理（e.g., RACHの繰り返し、PDSCH/PUSCHの繰り返し）、が特定のMTC UEのために必要とされるか否かはeNBによって判定されてもよい。例えば、PDSCH/PUSCHの繰り返しは、eNBによる無線リソースの割り当てを必要とするから、MTC UE個別のカバレッジ改善処理の必要性がeNBにおいて判断されることは妥当性があるかもしれない。
【００１０】
しかしながら、別の視点から考慮すると、ECMの必要性がeNBにおいて判定されることは問題を生じる可能性がある。例えば、仮に特定のMTC UEに対するECM（特にMTC UE個別のカバレッジ改善処理）の必要性がeNBにより判定されるまでMTC UEがECMを開始できないとすると、その特定のMTC UEはECMによる通信特性の改善をeNBでの判定が終わるまで享受できない。したがって、MTC UEがECMによる通信特性の改善を享受できるまでの遅延時間が大きくなるおそれがある。さらに、最悪のケースを考慮すると、MTC UEからeNBへの最初のアクセス（e.g., PRACHを用いたランダムアクセス、又は無線接続（Radio Resource Control (RRC) Connection）の確立手順）すら失敗してしまうかもしれない。
【００１１】
したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、MTC UEのための特別なカバレッジ改善処理（e.g., ECMでのカバレッジ改善処理）の必要性をMTC UEにおいて判定できるようにするために改良されたMTC UE（M2M端末）、基地局、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。
【課題を解決するための手段】
【００１２】
一実施形態において、M2M端末は、無線通信部及び制御部を含む。前記無線通信部は、基地局と通信するよう構成されている。前記制御部は、第１の通知を前記基地局から受信するとともに、前記第１の通知の受信後に前記基地局との無線接続を確立する際に、又は前記第１の通知の受信後に前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に、第２の通知を前記基地局に送信するよう構成されている。前記第１の通知は、前記M2M端末が滞在する前記基地局のセルにおいて所定のカバレッジ改善処理がサポートされるか否かを示す。前記第２の通知は、前記所定のカバレッジ改善処理が前記M2M端末によって必要とされていること又は実行されていることを示す。
【００１３】
一実施形態において、基地局は、無線通信部および制御部を含む。前記無線通信部は、M2M端末と通信するよう構成されている。前記制御部は、前記M2M端末が滞在する前記基地局のセルにおいて前記M2M端末のための所定のカバレッジ改善処理がサポートされることを示す第１の通知を前記無線通信部を介して送信するよう構成されている。
【００１４】
一実施形態において、M2M端末により行われる方法は、（ａ）第１の通知を基地局から受信すること、及び（ｂ）前記第１の通知の受信後に前記基地局との無線接続を確立する際に、又は前記第１の通知の受信後に前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に、第２の通知を前記基地局に送信すること、を含む。前記第１の通知は、前記M2M端末が滞在する前記基地局のセルにおいて所定のカバレッジ改善処理がサポートされるか否かを示す。前記第２の通知は、前記所定のカバレッジ改善処理が前記M2M端末によって必要とされていること又は実行されていることを示す。
【００１５】
一実施形態において、基地局により行われる方法は、M2M端末が滞在する前記基地局のセルにおいて前記M2M端末のための所定のカバレッジ改善処理がサポートされることを示す第１の通知を前記セル内に送信することを含む。
【００１６】
一実施形態において、プログラムは、コンピュータに読み込まれた場合に、上述したいずれかの方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。
【発明の効果】
【００１７】
上述の実施形態によれば、MTC UEのための特別なカバレッジ改善処理の必要性をMTC UEにおいて判定できるようにするために改良されたMTC UE（M2M端末）、基地局、方法、及びプログラムを提供できる。なお、この効果は、本明細書に開示される複数の実施形態によってもたらされると期待される複数の効果の１つに過ぎないことに留意されるべきである。
【図面の簡単な説明】
【００１８】
【図１】第１の実施形態に係る無線通信システムの構成例を示す図である。
【図２】第１の実施形態に係る通信手順の一例を示すシーケンス図である。
【図３】第１の実施形態に係る通信手順の他の例を示すシーケンス図である。
【図４】第２の実施形態に係る通信手順の一例を示すシーケンス図である。
【図５】第３の実施形態に係る通信手順の一例を示すシーケンス図である。
【図６】第４の実施形態に係る通信手順の一例を示すシーケンス図である。
【図７】本発明の実施形態に係るM2M端末（MTC UE）の構成例を示すブロック図である。
【図８】本発明の実施形態に係る基地局（eNB）の構成例を示すブロック図である。
【発明を実施するための形態】
【００１９】
以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。
【００２０】
以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。
【００２１】
＜第１の実施形態＞
図１は、本実施形態に係る無線通信システムの構成例を示している。当該無線通信システムは通信サービス、例えば音声通信若しくはパケットデータ通信又はこれら両方を提供する。図１を参照すると、当該無線通信システムは、M2M端末１１（１１Ａ、１１Ｂ、１１Ｃ）、M2M端末ではない通常の無線端末１２、基地局１３、及びコアネットワーク１４を含む。無線端末１２は、例えば、携帯電話、スマートフォン、タブレットコンピュータ、又はノートブックPCである。M2M端末１１Ａ、１１Ｂ、及び１１Ｃ、並びに無線端末１２は、基地局１３のセル１３０内に位置している。なお、本実施形態では、当該無線通信システムが3GPP LTEのシステムであるとして説明する。すなわち、M2M端末１１はMTC UEに相当し、無線端末１２はMTC UEではない通常のUEに相当し、基地局１３はeNodeB (eNB)に相当し、コアネットワーク１４はEvolved Packet Core（EPC）に相当する。
【００２２】
図１において、MTC UE１１Ａは、MTC UE１１Ｂに比べeNB１３からの距離が離れている為に、伝搬損が大きく無線品質が劣化することが想定される。また、MTC UE１１Ｃは建物（例えばビル）内に設置されており、屋外に設置される場合に比べて無線品質が劣化することが想定される。また、仮にMTC UE１１（１１Ａ、１１Ｂ、及び１１Ｃ）が、通常のUE１２に比べて限定的な能力又は機能（e.g., 最大送信電力が小さい、受信アンテナ数が少ない、高次変調をサポートしない等）を持つ場合、無線品質の劣化が更に顕著になることが予想される。したがって、本実施形態に係るMTC UE１１は、上述したEnhanced Coverage Mode（ECM）をサポートし、ECMにおけるカバレッジ改善処理を行うことができるよう構成されている。
【００２３】
既に述べたように、ECMにおけるカバレッジ改善処理は、MTC UEの通信特性（通信品質）を改善又は向上する為の処理と言うこともできる。ECMにおけるカバレッジ改善処理は、既に述べたように、以下の（ａ）〜（ｄ）のうち少なくとも１つを含んでもよく、これらとは異なる他の処理、例えば（ｅ）〜（ｆ）を含んでもよい：
（ａ）通常よりも所定回数だけ余分にPBCHによる報知情報の送信を繰り返すこと、
（ｂ）PPACH（PRACHプリアンブル）の送信を所定回数だけ繰り返すこと、
（ｃ）複数サブフレームにわたってPDSCHの送信を繰り返すこと、
（ｄ）複数サブフレームにわたってPUSCHの送信を繰り返すこと、
（ｅ）PDSCH若しくはPUSCH又は両方の電力スペクトル密度（power spectral density（PSD））を高くすること（PSD boosting）、
（ｆ）PDSCH若しくはPUSCH又は両方の繰り返し送信の間に周波数ホッピングをすること。
【００２４】
ここで、サブフレームとは、LTEの無線フレームを構成する単位である。１つの無線フレームの長さは１０ミリ秒であり、１つの無線フレームは１０個のサブフレーム（subframe）から構成されている。したがって、１つのサブフレームの長さは、１ミリ秒である。１つのサブフレームは、時間領域で１４個のシンボル（アップリンクであればsingle carrier frequency division multiple access (SC-FDMA) シンボル、ダウンリンクであれば orthogonal frequency division multiplexing (OFDM)シンボル）を含む。
【００２５】
続いて以下では、本実施形態に係るECMのための通信制御について説明する。本実施形態に係るeNB１３は、MTC UE（M2M端末）のための所定のカバレッジ改善処理（つまり、ECMでのカバレッジ改善処理）がeNB１３のセル１３０においてサポートされることを示す第１の通知をセル１３０内に送信する。第１の通知において、ECMがサポートされているか否かは、基地局単位（つまりeNB１３の全てのセルでサポート）で示されてもよいし、セル単位で示されてもよい。一方、MTC UE１１は、第１の通知をeNB１３から受信する。そしてMTC UE１１は、第１の通知を受信した後に第２の通知をeNB１３に送信する。MTC UE１１は、eNB１３から第１の通知を受信したことに応答して、第２の通知を送信してもよい。ここで、第２の通知は、eNB１３との無線接続（RRC Connection）を確立する際に、又はMTC UE１１とEPC１４の間のベアラ（Evolved Packet System（EPS）ベアラ）を確立する手順が行われる間にMTC UE１１からeNB１３に送信される。さらに、当該第２の通知は、ECMでのカバレッジ改善処理がMTC UE１１によって必要とされていること又は実行されていることを示す。
【００２６】
本実施形態によれば、以下に述べる効果が期待される。すなわち、仮にMTC UE１１に対するECM（特に、特定のMTC UE１１に個別のカバレッジ改善処理）の必要性がeNB１３により判定されるまでMTC UE１１がECMを開始できないとすると、MTC UE１１はECMによる通信特性の改善をeNB１３での判定が終わるまで享受できない。したがって、MTC UE１１がECMによる通信特性の改善を享受できるまでの遅延時間が大きくなるおそれがある。さらに、最悪のケースを考慮すると、MTC UE１１からeNB１３への最初のアクセス（例えば、PRACHを用いたランダムアクセス、又は無線接続（RRC Connection）の確立手順）すら失敗してしまうかもしれない。
【００２７】
これらの問題に対処するため、本実施形態に係るeNB１３は、上述の第１の通知をセル１３０内に送信する。したがって、本実施形態に係るMTC UE１１は、eNB１３のセル１３０がECMをサポートしていることを知ることができ、無線接続（RRC Connection）の確立の際に、又はEPSベアラ確立手順の間に、ECMでのカバレッジ改善処理がMTC UE１１によって必要とされていること又は実行されていることを示す第２の通知をeNB１３に通知することができる。MTC UE１１を含むUEは、一般的に、周期的又は非周期的な通信機会が到来したことに応じてアイドル状態（RRC_IDLE）からコネクテッド状態（RRC_CONNECTED）になる前に、アイドル状態で無線品質を測定している。したがって、MTC UE１１は、アイドル状態において第１の通知をeNBから受信し、アイドル状態において測定された無線品質を用いてECMの要否を通信機会の到来に先立って事前に判定してもよい。そうすれば、通信機会の到来した後にeNB１３におけるECMの要否の判定を待つことに起因する遅延時間（ECM開始までの遅延時間）の削減に寄与できる。
【００２８】
ここで、本明細書で使用されるアイドル状態及びコネクテッド状態の用語の定義を述べる。アイドル状態とは、UEとeNBの間の無線接続が解放された状態である。したがって、eNBはアイドル状態のUEに関する情報（UEコンテキスト）を有していない。アイドル状態のUEの位置は、コアネットワークにおいて位置登録エリア（e.g., トラッキングエリア又はルーティングエリア）単位で把握されている。コアネットワークは、アイドル状態のUEにページングによって到達できる。また、アイドル状態のUEは、eNBとの間でユニキャストデータ転送を行うことができない。したがって、アイドル状態のUEは、ユニキャストデータ転送を行うためにコネクテッド状態に遷移しなければならない。アイドル状態の例は、（１）Universal Terrestrial Radio Access Network（UTRAN）におけるRRC idle state、 （２）Evolved UTRAN（E-UTRAN）におけるRRC_IDLE state、及び（３）WiMAX（IEEE 802.16-2004）、モバイルWiMAX（IEEE 802.16e-2005）、及びWiMAX2（IEEE 802.16m）におけるIdle stateを含む。
【００２９】
これに対してコネクテッド状態は、UEがeNBに接続した状態である。したがって、eNBは、コネクテッド状態のUEに関する情報（UEコンテキスト）を保持している。コネクテッド状態のUEの位置は、コアネットワークにおいてセル単位（又は基地局単位）で把握されている。コネクテッド状態のUEは、一般的に、eNBとの間でユニキャストデータ転送を行うことができる。ただし、UTRANにおけるCELL_PCH state及びURA_PCH stateは、UEのコンテキストが基地局（NodeB）によって保持されているが、アップリンク及びダウンリンクともにUEには個別チャネルが割り当てられていない状態である。コネクテッド状態の例は、（１）UTRANにおけるRRC connected state、（２）E-UTRANにおけるRRC_CONNECTED state、及び（３）WiMAX、モバイルWiMAX及びWiMAX2におけるConnected stateを含む。なお、UTRANにおけるRRC connected stateは、CELL_DCH state、CELL_FACH state、CELL_PCH sate、及びURA_PCH stateを含む。
【００３０】
続いて以下では、上述した第１の通知のeNB１３からMTC UE１１への送信方法、及び第２の通知のMTC UE１１からeNB１３への送信方法の具体例について順に説明する。
【００３１】
第１の通知は、eNB１３との無線接続（RRC connection）を有していない、つまりアイドル状態のMTC UE１１において受信可能なブロードキャストチャネルで送信されることが好ましい。言い換えると、第１の通知は、アイドル状態のMTC UE１１が受信可能なブロードキャスト情報であることが好ましい。具体的には、LTEの論理チャネルの１つであるBroadcast Control Channel（BCCH）が第１の通知の送信のために使用されてもよい。
【００３２】
さらに述べると、第１の通知は、アイドル状態（RCC_IDLE）かつデタッチ状態（EMM-DEREGISTERED）のMTC UE１１においても受信可能なブロードキャストチャネルで送信されることが好ましい。デタッチ状態（EMM-DEREGISTERED）は、LTEのEPS Mobility Management（EMM）状態を表している。すなわち、デタッチ状態（EMM-DEREGISTERED）は、UEがコアネットワーク（e.g., EPC）内のモビリティ管理要素（e.g., Mobility Management Entity（MME））に登録されておらず、UEのモビリティ管理が行われていない状態を意味する。デタッチ状態のUEは、MMEにおいて位置情報が把握されていないため、コアネットワーク（EPC）からページングによって到達可能でない（unreachable）。デタッチ状態のUEは、通信を行うために、初期セル選択（つまり、初期セルサーチ）を行い、eNBと無線接続を確立し、コアネットワーク（EPC）への位置登録を行わなければならない。なお、BCCHは、アイドル状態（RCC_IDLE）かつデタッチ状態（EMM-DEREGISTERED）のMTC UE１１においても受信可能である。
【００３３】
BCCHは、トランスポートチャネルであるBroadcast Channel（BCH）又はDownlink Shared Channel（DL-SCH）にマッピングされる。さらに、BCCHがマッピングされたBCHは、物理チャネルであるPhysical Broadcast Channel（PBCH）を用いてeNB１３から送信される。PBCHは、各無線フレームの先頭サブフレームの予め定められたリソースブロックを使用して送信され、４０ミリ秒周期（４無線フレーム周期）で更新される。PBCHを用いて送信されるブロードキャスト情報は、Master Information Block（MIB）である。したがって、第１の通知は、MIBに含まれてよい。
【００３４】
一方、BCCHがマッピングされたDL-SCHは、物理チャネルであるPhysical Downlink Shared Channel（PDSCH）を用いてeNB１３から送信される。PDSCHの通常の用途は、ユーザデータの送信であるが、PDSCHの特別な用途（special uses）の１つとしてBCCH（つまりブロードキャスト情報）の送信が規定されている。BCCH（ブロードキャスト情報）のために使用されるリソースブロックは、Physical Downlink Control Channel（PDCCH）内の制御メッセージによって示される。PDSCHを用いて送信されるブロードキャスト情報は、System Information Blocks（SIBs）である。したがって、第１の通知は、既存のSIBsのいずれか、例えばSystem Information Block Type 1（SIB1）に含まれてもよい。また、第１の通知は、M2M、MTC UE、又はECMのために新たに定義されたSIBに含まれてもよい。
【００３５】
第１の通知は、eNB１３のセル１３０によるECMのサポートの有無を明示的に示してもよいし（e.g., フラグビット）、暗示的に示してもよい。第１の通知において、ECMがサポートされているか否かは、基地局単位（つまりeNB１３の全てのセルでサポート）で示されてもよいし、セル単位で示されてもよい。暗示的な第１の通知は、ECMでのカバレッジ改善処理のための設定情報（ECM radio resource configuration又はECM configuration）を含んでもよい。
【００３６】
ECM radio resource configuration又はECM configurationは、例えば、以下に示す情報のうち少なくとも１つを含んでもよい：
・報知情報（PBCH）の受信に関する設定情報、
・システム情報（System Information Block（SIB））の受信に関する設定情報、
・ページング（Paging Channel（PCH））の受信に関する設定情報、
・下り制御情報（Physical Downlink Control Channel（PDCCH））の受信に関する設定情報、
・下りデータ（PDSCH）の受信に関する設定情報、
・上り制御情報（Physical Uplink Control Channel（PUCCH））の送信に関する設定情報、
・上りデータ（PUSCH）の送信に関する設定情報、
・無線品質測定報告（Measurement Report）に関する設定情報。
【００３７】
報知情報（PBCH）の受信に関する設定情報及びシステム情報（SIB）の受信に関する設定情報は、例えば、どのサブフレーム及び／又はどのOFDMシンボルで報知情報及び（どの種類の）システム情報が繰り返して送信されているかを示す情報でもよい。ページングの受信に関する設定情報は、例えば、どのサブフレームでページングが繰り返して送信されているかを示す情報でもよい。下り制御情報（PDCCH）の受信及び下りデータ（PDSCH）の受信に関する設定情報は、例えば、それらが何回繰り返して送信されるかを示す情報でもよいし、どのサブフレームで繰り返して送信されるかを示す情報でもよい。上り制御情報（PUCCH）の送信及び上りデータ（PUSCH）の送信に関する設定情報は、例えば、それらが何回繰り返して送信されるかを示す情報でもよいし、どのサブフレームで繰り返して送信されるかを示す情報でもよい。無線品質測定報告に関する設定情報は、ECMを実行している間に適用する無線品質の測定結果（measurement result）に対するオフセット値や閾値でもよいし、ECMを実行している間に適用する無線品質の測定結果の報告の判定におけるオフセット値や閾値でもよい。
【００３８】
次に、第２の通知について説明する。第２の通知は、例えば、無線接続（RRC connection）の確立を要求するための要求メッセージ、つまりRRC Connection Requestメッセージを用いて送信されてもよい。RRC Connection Requestメッセージは、RRC connectionの確立手順の最初に送信されるメッセージであるから、第２の通知は、無線接続（RRC connection）の確立手順の間に送信されるということもできる。なお、別の視点からみると、RRC Connection Requestメッセージは、ランダムアクセス手順（Random Access Channel（RACH） procedure）の第３ステップで送信される。したがって、RRC Connection Requestメッセージが利用される場合、第２の通知は、ランダムアクセス手順（RACH procedure）の間に送信されるということもできる。
【００３９】
他の例において、第２の通知は、無線接続（RRC connection）の確立完了を示す完了メッセージ、つまりRRC Connection Setup Complete メッセージを用いて送信されてもよい。RRC Connection Setup Completeメッセージは、RRCコネクションの確立手順で送信される最終メッセージであるから、第２の通知は、無線接続（RRC connection）の確立手順の間に送信されるということもできる。また、RRC Connection Setup Completeメッセージは、NASメッセージ（e.g., NAS: Service Request、NAS: Attach Request）を包含する。NASメッセージを包含するRRC Connection Setup Completeメッセージは、EPSベアラの確立手順で送信される最初のメッセージである。したがって、RRC Connection Setup Complete メッセージが使用される場合、第２の通知は、ベアラ確立手順の間に送信されるということもできる。
【００４０】
第２の通知の送信のためにRRC Connection Requestメッセージ又はRRC Connection Setup Complete メッセージを利用することで、MTC UE１１は、自身がECMを必要としていること又は実行していることを、無線接続の確立手順の間に速やかにeNB１３に通知することができる。したがって、例えば、eNB１３は、MTC UE１１のために確立する無線接続の設定にECM設定を含めることができ、ECMのカバレッジ改善処理を伴うMTC UE１１との通信を速やかに開始できる。尚、無線接続（RRC connection）の確立という観点から、RRC Connection Setup Completeメッセージと同様に、RRC Connection Reestablishment Completeメッセージを利用して第２の通知の送信を行ってもよいことは言うまでもない。
【００４１】
さらに他の例において、第２の通知は、無線接続（RRC connection）の確立に先立って行われるランダムアクセス手順（RACH procedure）において送信されてもよい。具体的には、ランダムアクセス手順（RACH procedure）の第１ステップにおけるPRACHプリアンブルの送信が第２の通知のために利用されてもよい。この場合、第２の通知は、PRACHのための複数の無線リソースのうち、ECMのために割り当てられた特別な無線リソース（e.g., 時間、周波数、符号、又はプリアンブル系列）を使用することで、MTC UE１によってECMが必要とされていること又は実行されていることを暗示してもよい。
【００４２】
PRACHではPRACHプリアンブルしか送信できないため、MTC UE１によって要求又は実行されるECMの詳細（例えば、複数のカバレッジ改善処理のうちどれが具体的に必要であるか）を示すことは難しいかもしれない。したがって、この用途には、上述のRRC Connection Requestメッセージ又はRRC Connection Setup Complete メッセージが適しているかもしれない。しかしながら、第２の通知のためにPRACHプリアンブルを利用することで、RRC Connection Requestメッセージ又はRRC Connection Setup Complete メッセージを利用する場合に比べて、MTC UE１におけるECMの要否又は実行状況をeNB１３により早く伝えることができる利点がある。
【００４３】
続いて以下では、MTC UE１１においてECMの要否を判定する処理の具体例を説明する。MTC UE１１は、eNB１３からの第１の通知に基づいてeNB１３のセル１３０がECMをサポートしていることを認識した場合に、MTC UE１１においてECM（つまり、ECMでのカバレッジ改善処理）が必要であるか否かを判定すればよい。
【００４４】
MTC UE１１は、ECMが必要であることを判定した場合に、ECMでの複数のカバレッジ改善処理のうちで実行可能である処理を開始してもよい。例えば、MTC UE１１は、繰り返し送信されるPBCHを受信すること、若しくはランダムアクセス手順においてPRACHプリアンブルを繰り返し送信すること、又はこれら両方を開始してもよい。したがって、第１の通知は、MTC UE１１によってECMが実行されていることを示してもよい。
【００４５】
一方、例えば、PDSCH/PUSCHの繰り返しは、eNB１３による無線リソースの割り当てを必要とする。したがって、eNB１３での対処が必要なカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）については、MTC UE１１は、その必要性をeNB１３に報告すればよい。また、実行可能である処理（e.g., PBCHの繰り返し受信、PRACHプリアンブルの繰り返し送信）を含む全てのECMでのカバレッジ改善処理に関して、MTC UE１１は、それらの必要性をeNB１３に報告してもよい。したがって、第１の通知は、MTC UE１１によってECMが必要とされることを示してもよい。
【００４６】
MTC UE１１におけるECM（ECMでのカバレッジ改善処理）の要否の判定は、例えば、MTC UE１１のアクセス要因（Access cause）、端末能力（UE capability）、端末情報（UE information）、通信特性（Communication performance）、及び無線品質（Radio quality）の少なくとも１つを考慮して行われてもよい。
【００４７】
アクセス要因、端末能力、端末情報、通信特性、及び無線品質の具体例を以下に述べる。ただし、アクセス要因、端末能力、端末情報、通信特性、及び無線品質の内容は、これらの例に限定されるものではない。
【００４８】
アクセス要因は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・RRC接続確立の目的（Establishment cause）
・サービス種別（Service type）
【００４９】
RRC接続確立の目的は、例えば、（ａ）緊急呼（emergency）、（ｂ）高優先度アクセス（highPriorityAccess）、（ｃ）端末終端通信の為のアクセス（mt-Access）、端末発信によるシグナリング（mo-Signalling）、（ｄ）端末発信によるデータ送信（mo-Data）、（ｅ）耐遅延アクセス（delayTolerantAccess）、（ｆ）低優先度アクセス（lowPriorityAccess）、（ｇ）小データ通信の為のアクセス（smallDataAccess）、（ｈ）小パケット通信の為のアクセス（smallPacketAccess）、（ｉ）限定的なアクセス（limitedAccess）、（ｊ）限定的なサービスの為のアクセス（limitedService）、（ｋ）M2M型アクセス（m2mAccess）、又は（ｌ）ECMによるアクセス（ecmAccess）、を指定してもよい。
【００５０】
サービス種別は、例えば、（ａ）リアルタイムサービス、（ｂ）ノンリアルタイムサービス、又は（ｃ）M2M型通信、を指定してもよい。
【００５１】
端末能力は、例えば以下の３つのうち少なくとも１つを含んでもよい。
・無線アクセス能力（Radio access capability）
・デバイス能力（Device capability）
・端末カテゴリ（UE category）
【００５２】
無線アクセス能力は、例えば、（ａ）UEが3GPP LTEで規定されている端末機能をサポートしているか否かを示す情報（例えばフラグビット）、又は（ｂ）UEがECMをサポートしているか否かを示す情報、を含んでもよい。UEがECMをサポートしているか否かを示すために、例えば、“EcmSupport”という情報要素（Information Element（IE））が定義されてもよい。例えば、“EcmSupport”のtrue値は、ECMがサポートされていること（Supported）を示し、false値はECMがサポートされていないこと（NotSupported）を示す。また、“EnhancedCoverageMode”というIEが定義されてもよい。例えば、EcmSupportがSupportedと設定されているとき、UEがECMをサポートしていることを表す。また、UEがECMを未サポートである場合、EcmSupportがNotSupportedと設定さてもよいし、当該IEが送信されないことで未サポートを示してもよい。
【００５３】
デバイス能力は、例えば、（ａ）UEがMTC UEであることを示す情報、（ｂ）UEの通信性能が（通常UEに比べて）制限されていることを示す情報、又は（ｃ）特定の通信（例えばM2M型通信）のみを行うことを示す情報、を含んでもよい。
【００５４】
端末カテゴリは、（ａ）3GPP LTEで規定される端末カテゴリのうちのいずれかを示す情報、又は（ｂ）3GPP LTEで規定されるアクセス階級（Access Class）のいずれかを示す情報、を含んでもよい。端末カテゴリ又はアクセス階級は、M2M型通信を行うMTC UE用に新たに規定してもよい。例えば、低コストで実装する為に機能制限されたMTC UEに対する新規カテゴリ（e.g., category 0）が規定されてもよいし、低頻度で通信を行うことを前提とする又は低頻度の通信のみを許可するアクセス階級（AC）が新たに規定されてもよい。
【００５５】
端末情報は、例えば以下の３つのうち少なくとも１つを含んでもよい。
・端末種別（UE type）
・デバイス種別（Device type）
・端末コンテキスト（UE context）
【００５６】
端末種別は、例えば、（ａ）UEが通常のUE（非MTC UE）とMTC UEのどちらであるかを示す情報、（ｂ）UEが移動するか否かを示す情報（又はUEが移動しないことを示す情報）、又は（ｃ）UEへの電力供給（power supply）があるか否かを示す情報、を含んでもよい。
【００５７】
デバイス種別は、例えば、（ａ）UEに実装されたOperating System（OS）の種別を示す情報、又は（ｂ）UEが行うM2M型通信の種別を示す情報（つまり、M2Mのサブカテゴリ情報）、を含んでもよい。
【００５８】
端末コンテキストは、例えば、（ａ）上述の端末能力の情報、（ｂ）UEに設定されたRRC制御情報（RadioResrouceConfigCommon IE及びRaioResourceConfigDediacted IEに含まれる情報等）、（ｃ）UEのモビリティに関する情報（mobility information）、（ｄ）UEがECMを実行しているか否かを示す情報（ECM execution information）、又は（ｅ）UEが以前（例えば前回RRC_CONNECTEDのとき）にECMを実行していたか否かを示す情報（ECM status information）、を含んでもよい。
【００５９】
通信特性は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・特性測定結果（Performance measurement result (e.g., L2 measurement)）
・通信統計品質（Statistical communication quality (e.g., KPI)）
【００６０】
特性測定結果は、（ａ）ブロック誤り率測定結果（Block Error Rate）、（ｂ）パケット誤り率測定結果（Packet Error Rate）、（ｃ）スループット測定結果（e.g., Scheduled IP Throughput）、（ｄ）パケットロス測定結果（Packet Loss Rate）、又は（ｅ）パケット廃棄測定結果（Packet Discard Rate）を含んでもよい。
【００６１】
通信統計品質は、例えば、（ａ）ハンドオーバ試行回数若しくはハンドオーバ試行率、（ｂ）ハンドオーバ成功率若しくはハンドオーバ失敗率、（ｃ）通信間隔若しくは通信頻度、（ｄ）パケット発生間隔若しくはパケット発生頻度、（ｅ）パケット到着間隔（packet inter-arrival time）若しくはパケット到着頻度（packet inter-arrival rate）、（ｆ）アクセス間隔若しくはアクセス頻度、又は（ｇ）RRC接続確立若しくはNAS接続確立の間隔若しくは頻度、を含んでもよい。
【００６２】
無線品質は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・参照信号の受信品質（Reference Signal (RS) received quality）
・通信路品質指標（CQI）
【００６３】
参照信号（RS）の受信品質は、例えば、UEにおける下りRSの受信電力（RSRP）、（ｂ）受信品質（RSRQ）、又は受信電力強度（RSSI）、を含んでもよい。
【００６４】
MTC UE１１がECMの要否を判定するタイミングには様々なバリエーションがある。例えば、MTC UE１１は、MTC UE１１の電源がONになったとき、MTC UE１１がアイドル状態（RRC_IDLE）で初期セル選択（つまり、初期セルサーチ）を行っているとき、又はMTC UE１１がアイドル状態（RRC_IDLE）でセル再選択を行っているときに、ECMの要否を判定してもよい。MTC UE１１がアイドル状態であるときに予めECMの要否を判定することで、通信機会の到来した後にeNB１３におけるECMの要否の判定を待つことに起因する遅延時間（ECM開始までの遅延時間）の削減に寄与できる。
【００６５】
これに代えて、MTC UE１１は、周期的又は非周期的な通信機会（例えば、周期的な通信許可期間、非周期的な上り送信データの発生、又はページングの受信）が到来したときに、無線接続の確立のためにeNB１３にアクセスするのに先立ってECMの要否を判定してもよい。また、MTC UE１１は、無線接続の確立のためにeNB１３にアクセスしている間（e.g., RACH access procedureの間、又はRRC Connection establishment procedureの間）に、ECMの要否を判定してもよい。さらにまた、MTC UE１１は、無線接続（RRC connection）が確立された後にECMの要否を判定してもよい。
【００６６】
また、ECMに関して実行される動作（つまり、MTC UE１１又はeNB１３の受信又は送信の制御）は、予め多段階（マルチレベル）に細分化して定義されてもよい。この場合、MTC UE１１は、ECMが必要であるか否か（又はECMを実行するか否か）の判定だけでなく、どの段階（レベル）の動作が必要であるか（又はどの段階の動作を実行するか）を決定し、決定された段階（レベル）を第２の通知においてeNB１３に報告してもよい。eNB１３は、MTC UE１１からの第２の通知に基づき、MTC UE１１から報告されたECMの動作段階（レベル）を許容してもよいし、MTC UE１１から報告されたECMの動作段階（レベル）とは異なる段階を決定し、決定した段階をMTC UE１１に通知してもよい。つまり、eNB１３は、MTC UE１１が行うべきECMの動作段階を最終的に確定する権限を有してもよい。
【００６７】
また、MTC UE１１がECMを実行すると判定した場合、またはeNB１３がMTC UE１１にECMを実行させると判定した場合に、MTC UE１１は、RRC_CONNECTEDからRRC_IDLEになった後もECMを継続して実行してもよい。また、MTC UE１１は、MTC UE１１がECMを実行すると判定した場合、またはeNB１３がMTC UE１１にECMを実行させると判定した場合に、耐遅延アクセス（delay tolerant access）を行う間においてECMを継続して実行してもよい。
【００６８】
また、MTC UE１１は、始めにECMが必要か否か（又はECMを実行するか否か）を判定した後に、自身の通信特性又は無線品質を基にECMを継続して実行するか否かを判定してもよい。例えば、MTC UE１１は、MTC UE１１の通信特性としてブロック誤り率若しくはパケット誤り率又はこれら両方を取得し、これらが所定閾値よりも小さいと判定した場合にECMを中断（又は中止）してもよい。これに代えて又はこれと組み合わせて、MTC UE１１は、無線品質としてRSRP若しくはRSRQ又はこれら両方を取得し、これらが所定閾値よりも大きいと判定した場合にECMを中断（又は中止）してもよい。
【００６９】
図２は、本実施形態に係るMTC UE１１及びeNB１３の動作の一例を示すシーケンス図である。なお、図２は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。
【００７０】
図２のステップＳ１０１では、eNB１３は、ECMをサポートしていることを示す第１の通知をセル１３０内にブロードキャストする（System Information Block Type 1x）。第１の通知は、図２に示されているように、SIBsのいずれかに含まれてもよい。また、既に述べたように、第１の通知は、eNB１３（又はeNB１３のセル１３０）によるECMのサポートの有無を明示的に示してもよいし（e.g., フラグビット）、暗示的に示してもよい。暗示的な第１の通知は、ECMにおいて使用される無線リソースの設定情報（ECM radio resource configuration）を含んでもよい。
【００７１】
ステップＳ１０２では、MTC UE１１は、ECMが必要であるか否か（又はECMを実行するか否か）を判定する（ECM decision）。既に述べたように、MTC UE１１は、例えば、周期的又は非周期的な通信機会（例えば、周期的な通信許可期間、非周期的な上り送信データの発生、又はページングの受信）が到来したことに応じて、ステップＳ１０２の判定を行ってもよい。これに代えて、MTC UE１１は、MTC UE１１の電源がONになったとき、MTC UE１１がアイドル状態（RRC_IDLE）で初期セル選択（つまり、初期セルサーチ）を行っているとき、又はMTC UE１１がアイドル状態（RRC_IDLE）でセル再選択を行っているときに、ステップＳ１０２の判定を行ってもよい。
【００７２】
ステップＳ１０２の判定は、既に述べたように、様々なパラメータを考慮して行うことができる。例えば、当該判定は、MTC UE１１が滞在するセル１３０（又は当該セルを管理するeNB１３）でECMがサポートされているか否かに基づいて行われてもよい。当該判定は、MTC UE１１自身の端末能力（又はデバイス能力）としてECMをサポートしているか否かに基づいて行われてもよい。当該判定は、eNB１３へのアクセス要因が耐遅延アクセス（delay tolerant access）であるか否かに基づいて行われてもよい。当該判定は、MTC UE１１の無線品質が所定閾値よりも小さいか否かに基づいて行われてもよい。
【００７３】
図２は、MTC UE１１によってECMが必要とされるケースを示している。したがって、ステップＳ１０３では、MTC UE１１は、ECMの実行を開始する（ECM start）。そして、ステップＳ１０４〜Ｓ１０８では、MTC UE11は、ECMの動作（カバレッジ改善処理）を行いながらeNB１３にアクセスする。
【００７４】
具体的には、ステップＳ１０４では、MTC UE１１は、ランダムアクセスのプリアンブル送信を行う（PRACH Preamble）。図２の例では、PRACHプリアンブルの送信のために、ECMに特有の無線リソース（例えば時間・周波数や符号、プリアンブル系列など）が割り当てられている、又は利用可能である。したがって、MTC UE１１は、ECMに特有の無線リソースを使用してPRACHプリアンブルを送信する。
【００７５】
ステップＳ１０５では、eNB１３は、PRACHプリアンブルの検出に応答して、ランダムアクセス応答を送信する（Random Access Response）。なお、eNB１３は、PRACHプリアンブルがECMに特有の無線リソースにおいて受信されたことで、当該プリアンブルの送信元UEがECMを実行していることを認識できる。したがって、ランダムアクセス応答の送信に利用される無線リソース又はランダムアクセス応答の送信形態（e.g., PDCCH又はPDSCHの繰り返し送信）は、ECMに特有のものでもよい。ただし、eNB１３は、PRACHプリアンブル検出の時点では、プリアンブルの送信元UEを特定することはできない。PRACHプリアンブルは、送信元UEの識別子を含んでいないためである。
【００７６】
ステップＳ１０６では、MTC UE１１は、ランダムアクセス応答の受信に応答して、無線接続（RRC connection）の確立要求メッセージを送信する（RRC Connection Request）。ステップＳ１０６では、MTC UE１１は、耐遅延アクセス（delay tolerant access）であることをeNB１３に報告してもよい。また、MTC UE１１は、RRC Connection Requestメッセージの送信のために、ECMに特有の無線リソースまたは送信形態（e.g., PDSCHの繰り返し送信）を利用してもよい。
【００７７】
ステップＳ１０７では、eNB１３は、MTC UE１１からのRRC Connection Requestに応答して、無線接続（RRC connection）の確立の為に必要な設定情報を送信する（RRC Connection Setup）。ステップＳ１０８では、MTC UE１１は、無線接続（RRC connection）の確立完了を示す完了メッセージを送信する（RRC Connection Setup Complete）。ステップＳ１０７及びＳ１０８では、ECMに特有の無線リソースまたは送信形態が利用されてもよい。
【００７８】
ステップＳ１０９では、eNB１３は、無線リソース設定情報（Radio Resource Configuration）をMTC UE１１に送信する。ステップＳ１０８の送信は、図示されていないMTC UE１１からのNASメッセージ（e.g., NAS: Service Request、NAS: Attach Request）に基づくEPSベアラの確立手順の中で行われる。ステップＳ１０８で送信される無線リソース設定情報は、ECMの実行に必要なECM設定情報（ECM configuration）を含んでもよい。ECM設定情報（ECM configuration）は、例えば、EPSベアラ確立後のユーザデータ又は制御データ（e.g., Hybrid Automatic Repeat Request（HARQ）ACK/NACK、及びChannel State Information（CSI））の送信に適用されるカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）に関する設定情報を含む。
【００７９】
ステップＳ１１０では、MTC UE１１は、無線リソース設定情報及びECM設定情報に従って、ECMでのカバレッジ改善処理を伴うデータ通信を行う（M2M data with ECM）。
【００８０】
図３は、本実施形態に係るMTC UE１１及びeNB１３の動作の他の例を示すシーケンス図である。なお、図３は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。
【００８１】
図３のステップＳ２０１〜Ｓ２０３における処理は、図２のステップＳ１０１〜Ｓ１０３における処理と同様である。ステップＳ２０４では、MTC UE１１は、ランダムアクセスのプリアンブル送信を行う（PRACH Preamble）。図３の例では、PRACHプリアンブルの送信のために、ECMに特有の無線リソースを利用できない。したがって、MTC UE１１は、通常のUE１２と同様のリソースを用いてPRACHプリアンブルを送信する。ステップＳ２０５では、eNB１３は、PRACHプリアンブルの検出に応答して、ランダムアクセス応答を送信する（Random Access Response）。
【００８２】
ステップＳ２０６では、MTC UE１１は、ランダムアクセス応答の受信に応答して、無線接続（RRC connection）の確立要求メッセージを送信する（RRC Connection Request）。ステップＳ２０６では、MTC UE１１は、耐遅延アクセス（delay tolerant access）であることをeNB１３に報告してもよい。さらに、MTC UE１１は、ステップＳ２０６のRRC Connection Requestメッセージを用いて、ECMを実行していることを示す第２の通知（ECM activated）を送信してもよい。第２の通知を送信するために、例えば、ECM status（又はECM process、ECM flag）という情報要素（Information Element（IE））が定義されてもよい。例えば、ECM statusがtrue値又は“Activated”に設定されているとき、MTC UE１１がECMを実行していることを示す。反対に、ECM statusがfalse値又は“Not-activated”に設定されているとき、ECMが実行されていないことを示してもよい。また、第２の通知は、１ビットフラグであってもよく、値が１であるときECMが実行されていることを示し、値が０であるときECMが実行されていないことを示してもよい。
【００８３】
ステップＳ２０１〜Ｓ２０６の間は、MTC UE１１は所定の下りリンクのメッセージ（e.g., ページング、報知情報（PBCHやSIB）など）をECMに特有の処理を用いて受信してもよい。
【００８４】
ステップＳ２０７では、eNB１３は、MTC UE１１からのRRC Connection Requestに応答して、無線接続（RRC connection）の確立の為に必要な設定情報を送信する（RRC Connection Setup）。ステップＳ２０８では、MTC UE１１は、無線接続（RRC connection）の確立完了を示す完了メッセージを送信する（RRC Connection Setup Complete）。なお、第２の通知（ECM activated）は、ステップＳ２０６のRRC Connection Requestメッセージに代えて、ステップＳ２０８のRRC Connection Setup Completeメッセージを用いて送信されてもよい。
【００８５】
ステップＳ２０９及びＳ２１０における処理は、図２のステップＳ１０９及びＳ１１０における処理と同様である。
【００８６】
＜第２の実施形態＞
本実施形態に係る無線通信システムの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。本実施形態では、第１の実施形態で説明された詳細シーケンスの変形例が説明される。図２及び図３に示された具体例では、ECMの実行までがMTC UE１１において判定され、eNB１３はMTC UE１１による判定に基本的に従う例を示した。しかしながら、MTC UE１１による判定は必ずしも正しいとは限らないケースがあるかもしれない。本実施形態に係るeNB２３は、MTC UE２１による判定に完全に従うのでなく、MTC UE２１から要求されているECMが真に必要であるか否かを追加的に判定する。
【００８７】
図４は、本実施形態に係るMTC UE２１及びeNB２３の動作の一例を示すシーケンス図である。なお、図４は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。
【００８８】
図４のステップＳ３０１における処理は、図２のステップＳ１０１における処理と同様である。ステップＳ３０２では、MTC UE２１は、ECMが必要であるか否かを判定する（ECM decision）。図４は、MTC UE２１によってECMが必要とされるケースを示している。したがって、ステップＳ３０３では、MTC UE２１は、無線接続（RRC connection）の確立要求メッセージを送信する（RRC Connection Request）。なお、図４では、ランダムアクセス手順の第１及び第２ステップ（つまり、PRACHプリアンブルの送信、及びRandom Access Responseの返信）の図示は省略されている。
【００８９】
ステップＳ３０３では、MTC UE２１は、耐遅延アクセス（delay tolerant access）であることをeNB２３に報告してもよい。さらに、MTC UE２１は、ステップＳ３０３のRRC Connection Requestメッセージを用いて、自身にてECMが必要とされていることを示す第２の通知（ECM Request）を送信してもよい。この第２の通知（ECM Request）は、MTC UE２１のためのECM（ECMでのカバレッジ改善処理）の実行をeNB２３に要求する。
【００９０】
ステップＳ３０４では、eNB２３は、MTC UE２１からのRRC Connection Requestに応答して、無線接続（RRC connection）の確立の為に必要な設定情報を送信する（RRC Connection Setup）。ステップＳ３０５では、MTC UE２１は、無線接続（RRC connection）の確立完了を示す完了メッセージを送信する（RRC Connection Setup Complete）。なお、第２の通知（ECM Request）は、ステップＳ３０３のRRC Connection Requestメッセージに代えて、ステップＳ３０５のRRC Connection Setup Completeメッセージを用いて送信されてもよい。
【００９１】
ステップＳ３０６では、eNB２３は、MTC UE２１のためにECMが必要であるか否か（又はMTC UE２１のためにECMを実行させるか否か）を判定する（ECM decision）。ステップＳ３０６の判定において、eNB２３は、第１の実施形態で説明したMTC UE１１におけるECMの要否判定と同様のパラメータを用いればよい。
【００９２】
図４は、MTC UE２１のためにECMが必要である（又はECMを実行する）とeNB２３において判断されるケースを示している。したがって、ステップＳ３０７では、eNB２３は無線リソース設定情報（Radio Resource Configuration）をMTC UE２１に送信する（RRC Connection Reconfiguration）。ステップＳ３０７の送信は、図示されていないMTC UE２１からのNASメッセージ（e.g., NAS: Service Request、NAS: Attach Request）に基づくEPSベアラの確立手順の中で行われてもよい。ステップＳ３０７で送信される無線リソース設定情報は、ECMの実行に必要なECM設定情報（ECM configuration）を含んでもよい。また、ステップＳ３０７で送信される無線リソース設定情報は、MTC UE２１に対してECMの実行を明示的に指示する情報を含んでもよい。
【００９３】
ステップＳ３０８では、MTC UE２１は、ステップＳ３０７でのeNB２３からの明示的又は暗示的な指示に応答して、ECMの実行を開始する（ECM start）。ステップＳ３０９では、MTC UE２１は、無線リソース設定情報及びECM設定情報に従って、ECMでのカバレッジ改善処理を伴うデータ通信を行う（M2M data with ECM）。
【００９４】
＜第３の実施形態＞
本実施形態に係る無線通信システムの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。本実施形態では、第１及び第２の実施形態で説明された詳細シーケンス（図２、図３、及び図４）の変形例が説明される。
【００９５】
本実施形態で説明される手順は、図２（又は図３）と図４の手順の組み合わせであると言うことができる。すなわち、本実施形態に係るMTC UE３１は、ECMの要否を自身で判定し、その判定に基づいてECMの実行を開始するとともに、ECMが必要であること（又はECMを実行中であること）をeNB３３に通知する（第２の通知）。eNB３３は、MTC UE３１からの第２の通知に応答してMTC UE３１に対するECMの要否を判定する。eNB３３は、ECMが必要と判定した場合にECM設定情報をMTC UE３１に送信し、ECMが不要と判定した場合にECMの中断（又は中止）指示をMTC UE３１に送信する。このようなECMの制御手順によれば、MTC UE３１は、自身の判断に基づいてECMを速やかに開始できる。さらに、eNB３３は、MTC UE３１におけるECM要否判定の妥当性を検証することができ、妥当でない判定を取り消す（つまり、ECMを停止する）ことができる。
【００９６】
図５は、本実施形態に係るMTC UE３１及びeNB３３の動作の一例を示すシーケンス図である。なお、図５は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。
【００９７】
図５のステップＳ４０１〜Ｓ４０３における処理は、図２のステップＳ１０１〜Ｓ１０３における処理と同様である。ステップＳ４０４では、MTC UE３１は、無線接続（RRC connection）の確立完了を示す完了メッセージを送信する（RRC Connection Setup Complete）。なお、図５では、ランダムアクセス手順の第１〜第４ステップ（つまり、MTC UE３１によるPRACHプリアンブルの送信からeNB３３によるRRC Connection Setupメッセージの送信まで）の図示を省略している。
【００９８】
MTC UE３１は、ステップＳ４０４のRRC Connection Setup Completeメッセージを用いて、自身にてECMが必要とされていることを示す第２の通知（ECM Request）を送信してもよい。この第２の通知（ECM Request）は、MTC UE３１のためのECM（ECMでのカバレッジ改善処理）の実行をeNB３３に要求する。なお、第２の通知（ECM Request）は、ステップＳ４０４のRRC Connection Setup Completeメッセージに代えて、図示が省略されているRRC Connection Requestメッセージを用いて送信されてもよい。
【００９９】
ステップＳ４０５では、eNB３３は、MTC UE３１のためにECMが必要であるか否か（又はMTC UE３１のためにECMを実行させるか否か）を判定する（ECM decision）。ステップＳ４０５の判定において、eNB３３は、第１の実施形態で説明したMTC UE１１におけるECMの要否判定と同様のパラメータを用いればよい。
【０１００】
ステップＳ４０６〜Ｓ４０７は、MTC UE３１のためにECMが必要である（又はECMを実行する）とeNB３３において判断されたケースを示している（図５のケース１）。ステップＳ４０６では、eNB３３は、無線リソース設定情報（Radio Resource Configuration）をMTC UE３１に送信する（RRC Connection Reconfiguration）。ステップＳ４０６で送信される無線リソース設定情報は、ECMの実行に必要なECM設定情報（ECM configuration）を含んでもよい。また、ステップＳ４０６で送信される無線リソース設定情報は、MTC UE３１に対してECMの実行を明示的に指示する情報を含んでもよい。ステップＳ４０７では、MTC UE３１は、無線リソース設定情報及びECM設定情報に従って、ECMでのカバレッジ改善処理を伴うデータ通信を行う（M2M data with ECM）。
【０１０１】
一方、ステップＳ４０８〜Ｓ４１０は、MTC UE３１のためにECMが必要でない（又はECMを中断・中止する）とeNB３３において判断されたケースを示している（図５のケース２）。ステップＳ４０８では、eNB３３は無線リソース設定情報（Radio Resource Configuration）をMTC UE３１に送信する（RRC Connection Reconfiguration）。ステップＳ４０８で送信される無線リソース設定情報は、ECMの実行を中断（又は中止）する指示（ECM deactivated）を含む。ステップＳ４０９では、MTC UE３１は、ECMの実行を中断（又は中止）する（ECM stop）。そして、ステップＳ４１０では、MTC UE３１は、ECMでのカバレッジ改善処理を行わずにデータ通信を行う（M2M data without ECM）。
【０１０２】
＜第４の実施形態＞
本実施形態に係る無線通信システムの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。本実施形態では、第３の実施形態で説明された詳細シーケンス（図５）の変形例が説明される。
【０１０３】
本実施形態に係るMTC UE４１は、第３の実施形態に係るMTC UE３１と同様に、ECMの要否を自身で判定し、その判定に基づいてECMの実行を開始するとともに、ECMが必要であること（又はECMを実行中であること）をeNB４３に通知する（第２の通知）。ただしその後、MTC UE４１は、eNB４３による判定を待つために、ECMの実行を中断（又は中止）する。この点において、本実施形態は第３の実施形態と異なる。例えば、MTC UE４１は、eNB４３にアクセスしてから無線接続（RRC connection）を確立するまでの間はECMでのカバレッジ改善処理（e.g., PBCHの繰り返し受信、PRACHプリアンブルの繰り返し送信、PDSCH/PUSCHの繰り返し）を行い、その後にECMの実行を中断してもよい。言い換えると、MTC UE４１は、少なくともランダムアクセス手順（RACH procedure）及びRRC connectionの確立手順の間においてECMを実行し、その後にECMの実行を中断してもよい。
【０１０４】
本実施形態に係るeNB４３は、第３の実施形態に係るeNB３３と同様に、MTC UE４１からの第２の通知に応答してMTC UE４１に対するECMの要否を判定する。そして、eNB４３は、ECMが必要と判定した場合にECM設定情報をMTC UE４１に送信し、ECMが不要と判定した場合にECMの中断（又は中止）指示をMTC UE４１に送信する。MTC UE４１は、eNB４３からECM設定情報を受信したことに応じて、中断（中止）していたECMを改めて開始する。
【０１０５】
このようなECMの制御手順によれば、第３の実施形態と同様に、MTC UE４１は自身の判断に基づいてECMを速やかに開始できる。特に、少なくとも無線接続（RRC connection）を確立するまでの間においてECMを暫定的に実行することで、MTC UE４１がeNB４３への最初のアクセス（e.g., PRACHを用いたランダムアクセス、又はRRC Connectionの確立）に失敗することを回避できる。一方、eNB４３はMTC UE４１におけるECM要否判定の妥当性を検証することができ、妥当である場合にのみ選択的にECMを開始できる。
【０１０６】
図６は、本実施形態に係るMTC UE４１及びeNB４３の動作の一例を示すシーケンス図である。なお、図６は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。
【０１０７】
図６のステップＳ５０１〜Ｓ５０４における処理は、図５のステップＳ４０１〜Ｓ４０４における処理と同様である。ステップＳ５０５では、MTC UE４１は、ステップＳ５０４の後、すなわちRRC connectionの確立後、ECM（つまり、ECMでのカバレッジ改善処理）の実行を中断又は中止する（ECM Stop）。
【０１０８】
ステップＳ５０６における処理は、図５のステップＳ４０５における処理と同様である。すなわち、eNB４３は、MTC UE４１のためにECMが必要であるか否か（又はMTC UE４１のためにECMを実行させるか否か）を判定する（ECM decision）。
【０１０９】
ステップＳ５０７〜Ｓ５０９は、MTC UE４１のためにECMが必要である（又はECMを実行する）とeNB４３において判断されたケースを示している（図６のケース１）。ステップＳ５０７における処理は、図５のステップＳ４０６における処理と同様である。すなわち、eNB４３は、無線リソース設定情報（Radio Resource Configuration）をMTC UE４１に送信する（RRC Connection Reconfiguration）。ステップＳ５０８では、MTC UE４１は、eNB４３からの指示に応答して、ECMの実行を開始（又は再開）する（ECM start）。そして、ステップＳ５０９では、MTC UE４１は、無線リソース設定情報及びECM設定情報に従って、ECMでのカバレッジ改善処理を伴うデータ通信を行う（M2M data with ECM）。
【０１１０】
一方、ステップＳ５１０及びＳ５１１は、MTC UE４１のためにECMが必要でないとeNB４３において判断されたケースを示している（図６のケース２）。ステップＳ５１０では、eNB４３は無線リソース設定情報（Radio Resource Configuration）をMTC UE４１に送信する（RRC Connection Reconfiguration）。ステップＳ５１１で送信される無線リソース設定情報は、ECMが実行されないことを明示的に示してもよい。ステップＳ５１１では、MTC UE４１は、ECMでのカバレッジ改善処理を行わずにデータ通信を行う（M2M data without ECM）。
【０１１１】
最後に上述の実施形態に係るMTC UE及びeNBの構成例について説明する。第１〜第４の実施形態で説明されたMTC UE１１、２１、３１、及び４１の各々は、eNBと通信するためのトランシーバ、及び当該トランシーバに結合されたコントローラを含んでもよい。コントローラは、第１〜第４の実施形態で説明されたMTC UE１１、２１、３１、又は４１によるECMに関する通信制御を実行する。
【０１１２】
第１〜第４の実施形態で説明されたeNB１３、２３、３３、及び４３の各々は、MTC UEを含む複数のUEと通信するためのトランシーバ、及び当該トランシーバに結合されたコントローラを含んでもよい。コントローラは、第１〜第４の実施形態で説明されたeNB１３、２３、３３、又は４３によるECMに関する通信制御を実行する。
【０１１３】
図７及び図８は、第１の実施形態に係るMTC UE１１及びeNB１３の構成例を示すブロック図である。図７を参照すると、MTC UE１１は、トランシーバ１１１及びコントローラ１１２を含む。トランシーバ１１１は、eNB１３と通信するよう構成されている。コントローラ１１２は、eNB１３からの指示に従って、MTC UE１１におけるECMに関するカバレッジ改善処理の実行を制御するよう構成されている。具体的には、コントローラ１１２は、第１の通知をeNB１３からトランシーバ１１１を介して受信するよう構成されている。さらに、コントローラ１１２は、第１の通知の受信後にeNB１３との無線接続（RRC connection）を確立する際に、又は第１の通知の受信後にEPSベアラの確立手順が行われる間に、第２の通知をeNB１３にトランシーバ１１１を介して送信するよう構成されている。
【０１１４】
図８を参照すると、eNB１３は、トランシーバ１３１及びコントローラ１３２を含む。トランシーバ１３１は、MTC UE１１及び通常のUE１２を含む複数のUEと通信するよう構成されている。コントローラ１３２は、MTC UE１とeNB１３の間のECMに関するカバレッジ改善処理を伴う通信を制御するよう構成されている。具体的には、コントローラ１３２は、MTC UE１１のための所定のカバレッジ改善処理（つまり、ECMでのカバレッジ改善処理）がeNB１３のセル１３０においてサポートされることを示す第１の通知をトランシーバ１３１を介して送信するよう構成されている。
【０１１５】
上述の実施形態に係るMTC UE及びeNBが有するコントローラの各々は、少なくとも１つのプロセッサ（e.g. マイクロプロセッサ、Micro Processing Unit（MPU）、Central Processing Unit（CPU））を含むコンピュータにプログラムを実行させることによって実現されてもよい。具体的には、シーケンス図等を用いて説明されたMTC UE及びeNBに関するアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムをコンピュータに供給すればよい。
【０１１６】
このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（non-transitory computer readable medium）を用いて格納され、コンピュータに供給することができる。非一時的なコンピュータ可読媒体は、様々なタイプの実体のある記録媒体（tangible storage medium）を含む。非一時的なコンピュータ可読媒体の例は、磁気記録媒体（例えばフレキシブルディスク、磁気テープ、ハードディスクドライブ）、光磁気記録媒体（例えば光磁気ディスク）、Compact Disc Read Only Memory（CD-ROM）、CD-R、CD-R/W、半導体メモリ（例えば、マスクROM、Programmable ROM（PROM）、Erasable PROM（EPROM）、フラッシュROM、Random Access Memory（RAM））を含む。また、プログラムは、様々なタイプの一時的なコンピュータ可読媒体（transitory computer readable medium）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。
【０１１７】
＜その他の実施形態＞
上述の実施形態では、MTC UEにおいて特別な動作モード、つまりEnhanced Coverage Mode（ECM）が設定され、ECMに関するカバレッジ改善処理（e.g., RACHの繰り返し、PDSCH/PUSCHの繰り返し）がMTC UEにおいて行われることを前提として説明された。しかしながら、MTC UEは、特別なカバレッジ改善処理（e.g., RACHの繰り返し、PDSCH/PUSCHの繰り返し）を実行できるよう構成されていればよく、特別な動作モード（つまり、ECM）を設定されることは必ずしも必要ではない。言い換えると、MTC UE１１、２１、３１、及び４１は、ECMのような特別な動作モードを設定することなく、或いは特別な動作モードを指示されることなく、無線リソース設定を行うことで特別なカバレッジ改善処理（e.g., RACHの繰り返し、PDSCH/PUSCHの繰り返し）を実行してもよい。
【０１１８】
また、上述の実施形態ではECMを想定していたが、これらの実施形態で説明された技術思想は、ECMとは異なる何らかの特別な処理を無線ネットワーク（例えばeNB）がM2M端末（MTC UE）に実行させる場合に適用されてもよい。
【０１１９】
また、上述の実施形態では、通常端末（UE）とM2M端末（MTC UE）を例に説明してきたが、それぞれユーザ端末（user terminal）と非ユーザ端末（non-user terminal）とも呼ばれる。
【０１２０】
また、上述の実施形態では、主にLTEシステムに関して説明を行った。しかしながら、これらの実施形態は、LTEシステム以外の無線通信システム、例えば、3GPP UMTS、3GPP2 CDMA2000システム（1xRTT, HRPD）、GSM/GPRSシステム、又はWiMAXシステム等に適用されてもよい。
【０１２１】
上述の実施形態が3GPP UMTSに適用される場合、上述の実施形態におけるeNB（eNB１３、２３、３３、又は４３）の動作は、NodeB若しくはRNC又はこれらの組み合わせによって行われてもよい。言い換えると、本明細書及び請求の範囲において使用される基地局との用語は、無線アクセスネットワークに配置される１つ又は複数のエンティティを意味し、一例においてUMTSのNodeB若しくはRNC又はこれらの組み合わせを意味する。
【０１２２】
さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。
【０１２３】
この出願は、２０１４年１月３０日に出願された日本出願特願２０１４−０１５８６６を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０１２４】
１１、２１、３１、４１  M2M端末（MTC UE）
１３、２３、３３、４３  基地局（eNB）
１４  コアネットワーク（EPC）
１３０  セル
１１１  トランシーバ
１１２  コントローラ
１３１  トランシーバ
１３２  コントローラ
【図１】
2018170782.tif 000003
【図２】
2018170782.tif 000004
【図３】
2018170782.tif 000005
【図４】
2018170782.tif 000006
【図５】
2018170782.tif 000007
【図６】
2018170782.tif 000008
【図７】
2018170782.tif 000009
【図８】
2018170782.tif 000010