特許 6390625 基地局装置、コアネットワーク装置、方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6390625

(24)【登録日】2018年8月31日

(45)【発行日】2018年9月19日

(54)【発明の名称】基地局装置、コアネットワーク装置、方法、及びプログラム

(51)【国際特許分類】

   H04W 24/04 20090101AFI20180910BHJP

   H04W 36/08 20090101ALI20180910BHJP

   H04W 92/04 20090101ALI20180910BHJP

   H04W 4/70 20180101ALI20180910BHJP

【ＦＩ】

   H04W24/04

   H04W36/08

   H04W92/04

   H04W4/70

【請求項の数】18

【全頁数】28

(21)【出願番号】特願2015-559621(P2015-559621)

(86)(22)【出願日】2014年9月4日

(86)【国際出願番号】JP2014004549

(87)【国際公開番号】WO2015114695

(87)【国際公開日】20150806

【審査請求日】2017年8月3日

(31)【優先権主張番号】特願2014-15868(P2014-15868)

(32)【優先日】2014年1月30日

(33)【優先権主張国】JP

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100103894

【弁理士】

【氏名又は名称】家入 健

(72)【発明者】

【氏名】二木 尚

【審査官】 新井 寛

(56)【参考文献】

【文献】 NTT DOCOMO，"Discussion on Multi-level PRACH Coverage Enhancement"，3GPP TSG-RAN WG1#75 R1-135509，２０１３年１１月 ２日，pp.1-7

【文献】 Ericsson，"Control of amount of coverage enhancement for MTC UE"，3GPP TSG-RAN WG1#74b R1-134648，２０１３年 ９月２８日，pp.1-4

【文献】 "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)"，3GPP TR 36.888 V12.0.0，２０１３年 ６月，pp.45-51

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｂ ７／２４ − ７／２６

Ｈ０４Ｗ ４／００ − ９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１−４

ＳＡ ＷＧ１−４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

無線通信手段と、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報をコアネットワークから受信し、前記M2M端末と前記無線通信手段の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御する制御手段と、
を備える基地局装置。

【請求項2】

前記制御手段は、前記M2M端末と前記無線通信手段の間の通信において前記所定のカバレッジ改善処理を実行するか否かを前記履歴情報に基づいて決定する、請求項１に記載の基地局装置。

【請求項3】

前記制御手段は、前記M2M端末との無線接続を確立する際に、又は前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に、前記履歴情報を前記コアネットワークから受信する、請求項１又は２に記載の基地局装置。

【請求項4】

前記制御手段は、さらに、前記M2M端末の無線接続を解放する際に、前記基地局装置において前記M2M端末ために前記所定のカバレッジ改善処理が実行されていたか否かを示す端末情報を前記コアネットワークに送信する、請求項３に記載の基地局装置。

【請求項5】

前記制御手段は、
前記M2M端末のモビリティの程度を示すモビリティ情報を前記履歴情報と共に前記コアネットワークから受信し、
前記履歴情報は前記所定のカバレッジ改善処理が実行されていたことを示し、且つ前記モビリティ情報は前記M2M端末が実質的に静止している端末であることを示す場合に、前記M2M端末と前記無線通信手段の間の通信において前記所定のカバレッジ改善処理を実行する、
請求項４に記載の基地局装置。

【請求項6】

前記所定のカバレッジ改善処理は、Enhanced Coverage Mode（ECM）をサポートする無線端末によって行われる処理を含む、請求項１〜５のいずれか１項に記載の基地局装置。

【請求項7】

前記所定のカバレッジ改善処理は、複数のサブフレームにわたってPhysical Uplink Shared Channel （PUSCH）を繰り返し送信すること、及び複数のサブフレームにわたってPhysical Downlink Shared Channel （PDSCH）を繰り返し送信すること、のうち少なくとも一方を含む、請求項１〜６のいずれか１項に記載の基地局装置。

【請求項8】

基地局装置であって、
無線通信手段と、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記M2M端末又はコアネットワークから受信し、前記M2M端末と前記無線通信手段の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御する制御手段と、
を備え、
前記制御手段は、さらに、前記基地局装置のセルから隣接セルへの前記M2M端末のハンドオーバの際に、前記M2M端末が前記所定のカバレッジ改善処理を実行していることを隣接基地局に通知する、基地局装置。

【請求項9】

基地局装置であって、
無線通信手段と、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記M2M端末又はコアネットワークから受信し、前記M2M端末と前記無線通信手段の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御する制御手段と、
を備え、
前記制御手段は、さらに、前記基地局装置のセルにおいて前記所定のカバレッジ改善処理がサポートされているか否かを隣接基地局に通知し、前記隣接基地局のセルにおいて前記所定のカバレッジ改善処理がサポートされているか否かを前記隣接基地局から通知される、基地局装置。

【請求項10】

コアネットワークに配置されるコアネットワーク装置であって、
制御メッセージを基地局との間で送受信するためのインタフェースと、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記インタフェースを介して前記基地局に送信する制御手段と、
を備えるコアネットワーク装置。

【請求項11】

前記制御手段は、前記M2M端末と前記コアネットワークの間のベアラを確立する手順が行われる間に、前記履歴情報を前記基地局に送信する、請求項１０に記載のコアネットワーク装置。

【請求項12】

前記M2M端末のモビリティの程度を示すモビリティ情報を前記インタフェースを介して前記基地局に送信する、請求項１０又は１１に記載のコアネットワーク装置。

【請求項13】

前記制御手段は、前記M2M端末の無線接続が解放される際に、前記基地局において前記M2M端末ために前記所定のカバレッジ改善処理が実行されていたか否かを示す端末情報を前記インタフェースを介して前記基地局から受信する、請求項１０〜１２のいずれか１項に記載のコアネットワーク装置。

【請求項14】

前記制御手段は、第１の基地局から受け取った前記端末情報を前記第１の基地局とは異なる第２の基地局に前記履歴情報として送信するよう動作する、請求項１３に記載のコアネットワーク装置。

【請求項15】

基地局により行われる方法であって、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報をコアネットワークから受信すること、及び
前記M2M端末と前記基地局の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御すること、
を備える方法。

【請求項16】

コアネットワークに配置されるコアネットワーク装置により行われる方法であって、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を基地局に送信すること、
を備える方法。

【請求項17】

基地局に関する方法をコンピュータに行わせるためのプログラムであって、
前記方法は、
Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報をコアネットワークから受信すること、及び
前記M2M端末と前記基地局の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御すること、
を備える、プログラム。

【請求項18】

コアネットワークに関する方法をコンピュータに行わせるためのプログラムであって、
前記方法は、Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を基地局に送信することを備える、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本明細書の開示は、カバレッジ改善の為の通信制御を行う無線通信システムに関する。

【背景技術】

【0002】

3rd Generation Partnership Project (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)) と呼ぶ。

【0003】

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））と呼ばれる。

【0004】

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によるデータ送信に用いられる上り物理チャネルである。

【0005】

PBCHの受信特性を改善するために検討されている処理の１つは、通常よりも所定回数だけ余分にPBCHによる報知情報の送信を繰り返すことである（非特許文献３）。PRACHの送信特性を改善するために検討されている処理の１つは、PRACH（つまりプリアンブル）の送信を所定回数だけ繰り返すことである（非特許文献４）。さらに、PDSCHの受信特性及びPUSCHの送信特性を改善するために検討されている処理の１つは、複数サブフレームに亘りPDSCH及びPUSCHを繰り返し送信することである（非特許文献５）。これらの処理により、通常UEよりも劣化することが予想されるMTC UEの通信特性が改善することが期待される。

【0006】

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を拒絶してもよい。

【先行技術文献】

【非特許文献】

【0007】

【非特許文献1】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月

【非特許文献2】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月

【非特許文献3】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

【非特許文献4】3GPP R1-135944, Vodafone, “Way Forward on PRACH for MTC enhanced coverage”, 3GPP TSG RAN WG1 #75, San Francisco, USA, 11-15 November 2013

【非特許文献5】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

【発明の概要】

【発明が解決しようとする課題】

【0008】

本件の発明者は、ECMにおけるカバレッジ改善処理をMTC UE（M2M端末）に適用する場合の様々な問題について検討した。例えば、PBCHの繰り返しはセル内のMTC UEに共通に適用されるのに対して、RACHの繰り返し並びにPDSCH/PUSCHの繰り返しは各MTC UEに個別に適用される。

【0009】

MTC UEに個別に適用されるカバレッジ改善処理（e.g., RACHの繰り返し、PDSCH/PUSCHの繰り返し）は、ECMを行うMTC UEの数が増加するほど多くの無線リソースを消費するため、MTC UEではない通常UEが使用できる無線リソースの減少を招くかもしれない。また、仮に無線品質の良好なMTC UEに対してMTC UE個別の処理（例えば、PDSCH/PUSCHの繰り返し）が適用されると、MTC UEの消費電力を無駄に増加させるかもしれない。したがって、MTC UEの無線品質（e.g., Reference Signal Received Power（RSRP）、Reference Signal Received Quality（RSRQ）、またはChannel Quality Indicator（CQI））を考慮して、ECMを実行するべきMTC UEを選択することが考えられる。例えば、無線品質が低いMTC UEに選択的にECM（つまり、ECMにおけるカバレッジ改善処理）を実行させればよい。

【0010】

しかし、ECMを実行するべきMTC UEを選択する処理は、いくらかの時間（例えば数100 ms）を要する可能性があり、例えば無線接続の確立手順（例えばRRC Connection establishment Procedure）の完了に要する時間を増大させるかもしれない。また、LTEの通常の手順に従うと、eNBは、MTC UEが通信を終えてコネクテッド状態（RRC_CONNECTED）からアイドル状態（RRC_IDLE）に戻るときにMTC UEに関して保持されていたコンテキストを解放（削除）する。したがって、eNBはMTC UEが通信のためにアイドル状態（RRC_IDLE）からコネクテッド状態（RRC_CONNECTED）に遷移するたびにECMの実行の要否を繰り返し判定しなければならないかもしれない。

【0011】

ここで、本明細書で使用されるアイドル状態及びコネクテッド状態の用語の定義を述べる。アイドル状態とは、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を含む。

【0012】

これに対してコネクテッド状態は、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を含む。

【0013】

したがって、本明細書に開示される実施形態が達成しようとする目的の１つは、MTC UE（M2M端末）にECM（つまり、ECMにおけるカバレッジ改善処理）を適用するか否かの判定の効率化に寄与する基地局、M2M端末（MTC UE）、方法、及びプログラムを提供することである。なお、この目的は、本明細書に開示される複数の実施形態が達成しようとする複数の目的の１つに過ぎないことに留意されるべきである。その他の目的又は課題と新規な特徴は、本明細書の記述又は添付図面から明らかにされる。

【課題を解決するための手段】

【0014】

一実施形態において、基地局装置は、無線通信部および制御部を含む。前記制御部は、Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記M2M端末又はコアネットワークから受信し、前記M2M端末と前記無線通信部の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御するよう構成されている。

【0015】

一実施形態において、コアネットワークに配置されるコアネットワーク装置は、インタフェース及び制御部を含む。前記インタフェースは、制御メッセージを基地局との間で送受信するよう構成されている。前記制御部は、Machine-to-machine（M2M）端末と前記コアネットワークの間のベアラを確立する手順が行われる間に、前記M2M端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記インタフェースを介して前記基地局に送信するよう構成されている。

【0016】

一実施形態において、M2M端末は、無線通信部及び制御部を含む。前記無線通信部は、基地局と通信するよう構成されている。前記制御部は、前記基地局との無線接続を確立する際に、又は前記基地局を経由する前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に、前記M2M端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記無線通信部を介して前記基地局に送信するよう構成されている。

【0017】

一実施形態において、基地局により行われる方法は、（ａ）Machine-to-machine（M2M）端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記M2M端末又はコアネットワークから受信すること、及び（ｂ）前記M2M端末と前記基地局の間の前記所定のカバレッジ改善処理を伴う通信を前記履歴情報に基づいて制御すること、を含む。

【0018】

一実施形態において、コアネットワークに配置されるコアネットワーク装置により行われる方法は、Machine-to-machine（M2M）端末と前記コアネットワークの間のベアラを確立する手順が行われる間に、前記M2M端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を基地局に送信することを含む。

【0019】

一実施形態において、M2M端末により行われる方法は、基地局との無線接続を確立する際に、又は前記基地局を経由する前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に、前記M2M端末の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報を前記基地局に送信することを含む。

【0020】

一実施形態において、プログラムは、コンピュータに読み込まれた場合に、上述したいずれかの方法をコンピュータに行わせるための命令群（ソフトウェアコード）を含む。

【発明の効果】

【0021】

上述の実施形態によれば、MTC UE（M2M端末）にECM（つまり、ECMにおけるカバレッジ改善処理）を適用するか否かの判定の効率化に寄与する基地局、M2M端末（MTC UE）、方法、及びプログラムを提供できる。なお、この効果は、本明細書に開示される複数の実施形態によってもたらされると期待される複数の効果の１つに過ぎないことに留意されるべきである。

【図面の簡単な説明】

【0022】

【図1】第１の実施形態に係る無線通信システムの構成例を示す図である。

【図2】第１の実施形態に係る通信手順の一例を示すシーケンス図である。

【図3】第２の実施形態に係る通信手順の一例を示すシーケンス図である。

【図4】第３の実施形態に係る通信手順の一例を示すシーケンス図である。

【図5】第４の実施形態に係る無線通信システムの構成例を示す図である。

【図6】第４の実施形態に係る通信手順の一例を示すシーケンス図である。

【図7】第５の実施形態に係る通信手順の一例を示すシーケンス図である。

【図8】本発明の実施形態に係るM2M端末（MTC UE）の構成例を示すブロック図である。

【図9】本発明の実施形態に係る基地局（eNB）の構成例を示すブロック図である。

【図10】本発明の実施形態に係るコアネットワークノードの構成例を示すブロック図である。

【発明を実施するための形態】

【0023】

以下では、具体的な実施形態について、図面を参照しながら詳細に説明する。各図面において、同一又は対応する要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略される。

【0024】

以下に説明される複数の実施形態は、独立に実施されることもできるし、適宜組み合わせて実施されることもできる。これら複数の実施形態は、互いに異なる新規な特徴を有している。したがって、これら複数の実施形態は、互いに異なる目的又は課題を解決することに寄与し、互いに異なる効果を奏することに寄与する。

【0025】

＜第１の実施形態＞
図１は、本実施形態に係る無線通信システムの構成例を示している。当該無線通信システムは通信サービス、例えば音声通信若しくはパケットデータ通信又はこれら両方を提供する。図１を参照すると、当該無線通信システムは、M2M端末１１（１１Ａ、１１Ｂ、１１Ｃ）、M2M端末ではない通常の無線端末１２、基地局１３、及びコアネットワーク１４を含む。無線端末１２は、例えば、携帯電話、スマートフォン、タブレットコンピュータ、又はノートブックPCである。M2M端末１１Ａ、１１Ｂ、及び１１Ｃ、並びに無線端末１２は、基地局１３のセル１３０内に位置している。なお、本実施形態では、当該無線通信システムが3GPP LTEのシステムであるとして説明する。すなわち、M2M端末１１はMTC UEに相当し、無線端末１２はMTC UEではない通常のUEに相当し、基地局１３はeNodeB (eNB)に相当し、コアネットワーク１４はEvolved Packet Core（EPC）に相当する。

【0026】

図１において、MTC UE１１Ａは、MTC UE１１Ｂに比べeNB１３からの距離が離れている為に、伝搬損が大きく無線品質が劣化することが想定される。また、MTC UE１１Ｃは建物（例えばビル）内に設置されており、屋外に設置される場合に比べて無線品質が劣化することが想定される。また、仮にMTC UE１１（１１Ａ、１１Ｂ、及び１１Ｃ）が、通常のUE１２に比べて限定的な能力又は機能（e.g., 最大送信電力が小さい、受信アンテナ数が少ない、高次変調をサポートしない等）を持つ場合、無線品質の劣化が更に顕著になることが予想される。したがって、本実施形態に係るMTC UE１１は、上述したEnhanced Coverage Mode（ECM）をサポートし、ECMにおけるカバレッジ改善処理を行うことができるよう構成されている。

【0027】

既に述べたように、ECMにおけるカバレッジ改善処理は、MTC UEの通信特性（通信品質）を改善又は向上する為の処理と言うこともできる。ECMにおけるカバレッジ改善処理は、既に述べたように、以下の（ａ）〜（ｄ）のうち少なくとも１つを含んでもよく、これらとは異なる他の処理、例えば（ｅ）〜（ｆ）を含んでもよい：
（ａ）通常よりも所定回数だけ余分にPBCHによる報知情報の送信を繰り返すこと、
（ｂ）PPACH（PRACHプリアンブル）の送信を所定回数だけ繰り返すこと、
（ｃ）複数サブフレームにわたってPDSCHの送信を繰り返すこと、
（ｄ）複数サブフレームにわたってPUSCHの送信を繰り返すこと、
（ｅ）PDSCH若しくはPUSCH又は両方の電力スペクトル密度（power spectral density（PSD））を高くすること（PSD boosting）、
（ｆ）PDSCH若しくはPUSCH又は両方の繰り返し送信の間に周波数ホッピングをすること。

【0028】

ここで、サブフレームとは、LTEの無線フレームを構成する単位である。１つの無線フレームの長さは１０ミリ秒であり、１つの無線フレームは１０個のサブフレーム（subframe）から構成されている。したがって、１つのサブフレームの長さは、１ミリ秒である。１つのサブフレームは、時間領域で１４個のシンボル（アップリンクであればsingle carrier frequency division multiple access (SC-FDMA) シンボル、ダウンリンクであれば orthogonal frequency division multiplexing (OFDM)シンボル）を含む。

【0029】

続いて以下では、本実施形態に係るECMのための通信制御について説明する。本実施形態に係るeNB１３は、MTC UE（M2M端末）１１の通信においてECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）が実行されていたか否かを示す履歴情報をEPC１４から受信する。そして、eNB１３は、EPC１４から受信された履歴情報に基づいて、ECMに関するカバレッジ改善処理を伴うMTC UE１１とeNB１３の間の通信を制御する。eNB１３は、EPC１４に配置されたコアネットワークノード（例えば、Mobility Management Entity（MME））からMTC UE１１の履歴情報を受信すればよい。

【0030】

例えば、eNB１３は、MTC UE１１とeNB１３の間の通信においてECMに関するカバレッジ改善処理を実行するか否かを、受信された履歴情報に基づいて決定してもよい。より具体的に述べると、eNB１３は、ECMにカバレッジ改善処理がMTC UE１１に対して行われていたことが履歴情報に示されていること応答して、ECMに関するカバレッジ改善処理の指示（e.g., ECM configuration）をMTC UE１１に送信してもよい。なお、eNB１３は、明示的な指示を送信すること無く、MTC UE１１においてECMが行われていることを前提にMTC UE１１との通信を行ってもよい。

【0031】

ECM configurationは、例えば、以下に示す情報のうち少なくとも１つを含んでもよい：
・報知情報（PBCH）の受信に関する設定情報、
・システム情報（System Information Block（SIB））の受信に関する設定情報、
・ページング（Paging Channel（PCH））の受信に関する設定情報、
・下り制御情報（Physical Downlink Control Channel（PDCCH））の受信に関する設定情報、
・下りデータ（PDSCH）の受信に関する設定情報、
・上り制御情報（Physical Uplink Control Channel（PUCCH））の送信に関する設定情報、
・上りデータ（PUSCH）の送信に関する設定情報、
・無線品質測定報告（Measurement Report）に関する設定情報。

【0032】

報知情報（PBCH）の受信に関する設定情報及びシステム情報（SIB）の受信に関する設定情報は、例えば、どのサブフレーム及び／又はどのOFDMシンボルで報知情報及び（どの種類の）システム情報が繰り返して送信されているかを示す情報でもよい。ページングの受信に関する設定情報は、例えば、どのサブフレームでページングが繰り返して送信されているかを示す情報でもよい。下り制御情報（PDCCH）の受信及び下りデータ（PDSCH）の受信に関する設定情報は、例えば、それらが何回繰り返して送信されるかを示す情報でもよいし、どのサブフレームで繰り返して送信されるかを示す情報でもよい。上り制御情報（PUCCH）の送信及び上りデータ（PUSCH）の送信に関する設定情報は、例えば、それらが何回繰り返して送信されるかを示す情報でもよいし、どのサブフレームで繰り返して送信されるかを示す情報でもよい。無線品質測定報告に関する設定情報は、ECMを実行している間に適用する無線品質の測定結果（measurement result）に対するオフセット値や閾値でもよいし、ECMを実行している間に適用する無線品質の測定結果の報告の判定におけるオフセット値や閾値でもよい。

【0033】

また、ECMで実行されるMTC UE１１の動作は、予め多段階（マルチレベル）に細分化して定義されてもよい。この場合、ECM configurationは、MTC UE１１が実行するべき動作の段階（レベル）を指定してもよい。

【0034】

一方、MTC UE１１は、一旦ECMの実行を指示された場合、RRC_CONNECTEDからRRC_IDLEになった後もECM configurationを継続して保持し、ECMを継続して実行してもよい。これに代えて、MTC UE１１は、滞在するセルで報知されているECM configurationを基にRRC_ IDLEになった後もECMを継続して実行してもよい。さらにMTC UE１１は、再びRRC_ CONNECTEDになった後に、既に保持しているECM configuration又は滞在するセルで報知されているECM configurationに基づいて自律的にECMを継続して実行してもよいし、eNB１３からECMの実行の指示を受けたことに応答してECMを実行してもよい。

【0035】

このように、eNB１３がMTC UE１１の履歴情報（MTC UE１１の過去の通信においてECMに関するカバレッジ改善処理が実行されていたか否かを示す）をEPC１４から受信し、この履歴情報を用いてMTC UE１１とのカバレッジ改善処理を伴う通信を制御することで以下に述べる効果が期待される。すなわち、eNB１３は、MTC UE１１に対してECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を適用するべきか否かを判定するために、MTC UE１１の無線品質（e.g., RSRP、RSRQ、CQI）を取得してこれを分析することを必ずしも必要としない。なぜなら、eNB１３と無線接続を確立したMTC UE１１に対してECMが適用できるか又はECMのカバレッジ改善処理が有効であるか否かを履歴情報に基づいて判定できるためである。したがって、本実施形態は、MTC UE１１に対してECMに関するカバレッジ改善処理を適用するべきか否かの判定に要する時間（遅延）を削減できる。

【0036】

次に、eNB１３がMTC UE１１の履歴情報をEPC１４から受信するタイミングの例について説明する。eNB１３は、MTC UE１１に対してECMに関するカバレッジ改善処理を適用するべきか否かを判定する際に、MTC UE１１の履歴情報をEPC１４から取得すればよい。例えば、eNB１３は、MTC UE１１との無線接続（Radio Resource Control (RRC) Connection）を確立する際に、言い換えるとMTC UE１１がアイドル状態（RRC_IDLE）からコネクテッド状態（RRC_CONNECTED）になるときに、履歴情報をEPC１４から受信してもよい。これに代えて、eNB１３は、MTC UE１１とEPC１４の間のベアラ（Evolved Packet System（EPS）ベアラ）の確立手順（e.g., attach procedure、service request procedure）が行われる間に、履歴情報をEPC１４から受信してもよい。これらの例によれば、eNB１３は、MTC UE１１との無線接続の確立手順、又はベアラ確立手順において、MTC UE１１に対してECMに関するカバレッジ改善処理を適用するべきか否かを速やかに判定することができる。

【0037】

続いて、MTC UE１１に関する端末情報（MTC UE１１とeNB１３の通信においてECMに関するカバレッジ改善処理が実行されていたか否かを示す）をEPC１４に保存する動作の例について説明する。eNB１３は、MTC UE１１の無線接続を解放する際に、ECMに関するカバレッジ改善処理が当該MTC UE１１のために実行されていたか否かを示す端末情報（UEコンテキスト）をEPC１４に送信してもよい。EPC１４に送られたUEコンテキストは、端末情報の送信元と同じeNB１３又は異なるeNB１３にMTC UE１１の履歴情報として送信される。言い換えると、eNB１３は、MTC UE１１に関するUEコンテキスト（MTC UE１１とeNB１３の通信においてECMに関するカバレッジ改善処理が実行されていたか否かを示す）を保存するためにEPC１４に送信し、当該UEコンテキストをEPC１４から読みだして利用できるよう構成されている。

【0038】

既に述べたように、MTC UE１１がコネクテッド状態（RRC_CONNECTED）であるときにeNB１３において保持されているMTC UE１１のコンテキストは、MTC UE１１がアイドル状態（RRC_IDLE）に遷移するときに解放（削除）される。したがって、eNB１３は、MTC UE１１がコネクテッド状態であるときにeNB１３において保持されていたUEコンテキスト（ECMに関するカバレッジ改善処理がMTC UE１１のために実行されていたか否かを示す）をEPC１４に保存しておくことで、将来のMTC UE１１のアクセス時に、EPC１４に保存されていたUEコンテキストを履歴情報として利用することができる。

【0039】

なお、本実施形態において、MTC UE１１は、図１に例示されているように、固定的に設置され実質的に静止した端末であってもよい。この場合、MTC UE１１は、１つのeNB１３の１つのセル内でコネクテッド状態（RRC_CONNECTED）とアイドル状態（RRC_IDLE）の間の遷移を繰り返す。しかしながら、これに代えて、MTC UE１１は、移動性を有する端末（例えば、自動車、鉄道車両、又は船舶などの輸送機械に搭載される端末）であってもよい。この場合、MTC UE１１は、同じeNB１３の複数のセルの間、又は異なるeNB１３のセル間を移動してもよい。MTC UE１１が移動する場合に想定されるシナリオを以下に述べる。まず、MTC UE１１は、あるeNB１３のセルにおいてRRC_CONNECTEDでECMの実行を指示され、ECMを利用してデータ通信を行った後にRRC_IDLEになる。次に、MTC UE１１は、RRC_IDLEの間に他のセルにセル再選択（Cell reselection）を行う。そして、MTC UE１１は、前回RRC_CONNECTEDになったセルとは別のセルで再びRRC_CONNECTEDになる。このとき、EPC１４は、MTC UE１１が新たに滞在しているセルを管理するeNB１３に対して、MTC UE１１がECMを実行していたか否かを示す情報（ECM status、履歴情報）を通知する。EPC１４は、当該MTC UE１１が過去にどのセルでECMを実行していたかを示すために、例えば物理セル識別子（Physical Cell Identity（PCI））又はグローバルセル識別子（Cell Global Identity（CGI））をeNB１３に通知してもよい。

【0040】

図２は、本実施形態に係るMTC UE１１、eNB１３、及びコアネットワークノード１４１の動作の一例を示すシーケンス図である。コアネットワークノード１４１は、EPC１４に配置されたノードである。コアネットワークノード１４１は、１つの物理的なエンティティであってもよいし複数のエンティティを含んでもよい。例えば、コアネットワークノード１４１は、MME若しくはHome Subscriber Server（HSS）又はこれら両方を含んでもよい。なお、図２は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。

【0041】

図２のステップＳ１０１では、eNB１３は、MTC UE１１のためにECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を行うことを判定し、ECMの設定情報（ECM configuration）をMTC UE１１に送信する。図２の例では、ECM configuration は、RRC Connection Reconfigurationメッセージを用いて送信される。ステップＳ１０２では、MTC UE１１は、eNB１３から受信したECM configurationに従ってECMの実行（つまり、カバレッジ改善処理（e.g., 繰り返されるPDSCHの受信、PUSCHの繰り返し送信））を開始する（ECM start）。ステップＳ１０３では、MTC UE１１は、ECM configurationに従ってデータ通信を行う（M2M data with ECM）。

【0042】

ステップＳ１０４では、eNB１３は、MTC UE１１をアイドル状態（RRC_IDLE）に戻すことが可能であると判断し、MTC UE１１に関するS1-APシグナリングコネクション及びS1ベアラ（又は無線アクセスベアラ）の解放をコアネットワークノード１４１に要求する（S1 UE Context Release Request）。ステップＳ１０５では、コアネットワークノード１４１は、eNB１３からの要求に応じてS1-APシグナリングコネクション及びS1ベアラを解放するが、MTC UE１１においてECMが実行されていたことを示すECM状態情報（ECM status）を保持する（Store ECM status）。ECM状態情報（ECM status）は、上述の履歴情報に相当する。ECM状態情報（ECM status）は、MTC UE１１のEPSベアラ・コンテキストと共にMMEにおいて保持されてもよい。また、ECM状態情報（ECM status）は、MMEを介してHSSに送信され、HSSにおいて保持されてもよい。ステップＳ１０６では、eNB１３は、RRC_IDLEになる指示をMTC UE１１に送信する（RRC Connection Release）。この指示の受信に応答して、MTC UE１１は、RRC_CONNECTEDからRRC_IDLEになる。

【0043】

ステップＳ１０７では、MTC UE１１は、周期的又は非周期的な通信タイミングが到来したことに応じて、通信を開始するために無線接続の確立要求をeNB１３に送信する（RRC Connection Request）。MTC UE１１は、耐遅延アクセスであることを示すために、“delayTolerantAccess”に指定されたEstablishment causeを伴うRRC Connection Requestを送信してもよい。図示されていない無線接続（RRC Connection）の確立手順の完了によって、MTC UE３１は、RRC_CONNECTEDになる。

【0044】

ステップＳ１０８では、eNB１３は、MTC UE１１のためにEPSベアラの確立要求をコアネットワークノード１４１に送信する（Initial UE message）。このInitial UE messageは、MTC UE１１からのNon-Access Stratum（NAS）メッセージ（e.g. NAS: Service Request、NAS: Attach Request）をカプセル化している。ステップＳ１０９では、コアネットワークノード１４１は、Initial UE message内にカプセル化されたNASメッセージの受信に応答して、MTC UE１１のための無線アクセスベアラを確立するのに必要な情報をeNB１３に送信する（Initial Context Setup Request）。

【0045】

ステップＳ１０９のメッセージは、例えば端末能力（UE radio capability）及びUEコンテキスト（UE context）を含んでもよい。このとき、UE contextは、MTC UE１１が過去にECMを実行していたことを示すECM状態情報（ECM status）を含んでもよい。さらに、UE contextは、MTC UE１１のモビリティ情報（mobility information）を含んでもよい。例えば、MTC UE１１が過去にECMを実行していたことがECM状態情報において示され、且つMTC UE１１が静止またはほぼ静止している端末であることがモビリティ情報において示されていることを条件として、eNB１３はMTC UE１１に対してECMを継続して実行することを決定してもよい。

【0046】

ステップＳ１１０では、eNB１３は、MTC UE１１にECMを実行させる為に、無線リソース設定情報（RRC Configuration）と共にECM設定情報（ECM configuration）を送信してもよい（RRC Connection Reconfiguration）。ステップＳ１１１では、MTC UE１１は、eNB１３からステップＳ１１０にて受信したECM設定情報、または以前に受信して保持していたECM設定情報を基にデータ通信を行う（M2M data with ECM）。

【0047】

＜第２の実施形態＞
本実施形態に係る無線通信システムの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。上述した第１の実施形態では、MTC UE１１の通信においてECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）が実行されていたか否かを示す履歴情報をeNB１３がEPC１４から受信する例を示した。これに代えて、本実施形態では、eNB２３は、MTC UE２１の通信においてECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）が実行されていたか否かを示す履歴情報をMTC UE２１から受信する。そして、eNB２３は、MTC UE２１から受信された履歴情報に基づいて、ECMに関するカバレッジ改善処理を伴うMTC UE２１とeNB２３の間の通信を制御する。例えば、eNB２３は、過去にECMを実行していたことをMTC UE２１から報告された場合、当該MTC UE２１に引き続きECMを実行させ続けてもよいし、改めてECMの実行が必要か否かを判定してもよい。

【0048】

本実施形態に係るMTC UE２１は、ECM実行の指示をeNB２３から受信した場合に、RRC_CONNECTEDからRRC_IDLEになった後もECM設定情報（ECM configuration）を保持してもよいし、ECMを実行していたことを記憶しておくだけでもよい。そして、MTC UE２１は、再びRRC_CONNECTEDになるとき、以前にECMを実行していたことをeNB２３に報告する。さらに、MTC UE２１は、RRC_CONNECTEDになる為のメッセージ（つまり、RRCコネクションの確立手順において送信されるメッセージ）を、ECMを実行しながら（つまり、ECMに特有のECMに関するカバレッジ改善処理を行いながら）送信又は受信してもよい。例えば、MTC UE２１は、ECM特有の無線リソースをPRACHプリアンブルの送信のために使用してもよい。また、MTC UE２１は、PRACHプリアンブルを自律的に繰り返し送信してもよい。

【0049】

本実施形態よれば、第１の実施形態と同様の効果が期待される。すなわち、本実施形態では、eNB２３がMTC UE２１の履歴情報（MTC UE２１の過去の通信においてECMに関するカバレッジ改善処理が実行されていたか否かを示す）をMTC UE２１自身から受信し、この履歴情報を用いてMTC UE２１とのカバレッジ改善処理を伴う通信を制御する。したがって、eNB２３は、MTC UE２１に対してECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を適用するべきか否かを判定するために、MTC UE２１の無線品質（e.g., RSRP、RSRQ、CQI）を取得してこれを分析することを必ずしも必要としない。なぜなら、eNB２３は、eNB２３と無線接続を確立したMTC UE２１に対してECMが適用できるか又はECMのカバレッジ改善処理が有効であるか否かを履歴情報に基づいて判定できるためである。したがって、本実施形態は、MTC UE２１に対してECMに関するカバレッジ改善処理を適用するべきか否かの判定に要する時間（遅延）を削減できる。

【0050】

次に、eNB２３がMTC UE２１の履歴情報をMTC UE２１から受信するタイミングの例について説明する。例えば、eNB２３は、MTC UE２１との無線接続（RRC Connection）を確立する手順において、言い換えるとMTC UE２１がアイドル状態（RRC_IDLE）からコネクテッド状態（RRC_CONNECTED）になるときに、履歴情報をMTC UE２１から受信してもよい。これに代えて、eNB２３は、MTC UE２１とEPCの間のベアラ（EPSベアラ）の確立手順（e.g., attach procedure、service request procedure）が行われる間に、履歴情報をMTC UE２１から受信してもよい。これらの例によれば、eNB２３は、MTC UE２１との無線接続の確立手順、又はベアラ確立手順において、MTC UE２１に対してECMに関するカバレッジ改善処理を適用するべきか否かを速やかに判定することができる。

【0051】

また、第１の実施形態で述べたのと同様に、本実施形態では、MTC UE２１は、移動性を有する端末（例えば、自動車、鉄道車両、又は船舶などの輸送機械に搭載される端末）であってもよい。この場合、MTC UE２１は、あるeNB２３のセルにおいてRRC_CONNECTEDでECMの実行を指示され、ECMを利用してデータ通信を行った後にRRC_IDLEになる。次に、MTC UE２１は、RRC_IDLEの間に他のセルにセル再選択（Cell reselection）を行う。そして、MTC UE２１は、前回RRC_CONNECTEDになったセルとは別のセルで再びRRC_CONNECTEDになる。このとき、MTC UE２１は、自身が新たに滞在しているセルを管理するeNB２３に対して、過去に自身がECMを実行していたか否かを示す情報（ECM status、履歴情報）を通知する。MTC UE２１は、当該MTC UE２１自身が過去にどのセルでECMを実行していたかを示すために、例えば物理セル識別子（PCI）又はグローバルセル識別子（CGI）をeNB２３に通知してもよい。

【0052】

図３は、本実施形態に係るMTC UE２１、eNB２３、及びコアネットワークノード２４１の動作の一例を示すシーケンス図である。コアネットワークノード２４１は、EPCに配置されたノード（e.g., MME若しくはHSS又はこれら両方）である。図３は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。

【0053】

図３のステップＳ２０１〜Ｓ２０３における処理は、図２のステップＳ１０１〜Ｓ１０３における処理と同様である。ステップＳ２０４では、eNB２３は、MTC UE２１をアイドル状態（RRC_IDLE）に戻すことを決定し、MTC UE２１に関するS1-APシグナリングコネクション及びS1ベアラ（又は無線アクセスベアラ）の解放をコアネットワークノード２４１に要求する（S1 UE Context Release Request）。コアネットワークノード２４１は、eNB２３からの要求に応じてS1-APシグナリングコネクション及びS1ベアラを解放する。ステップＳ２０５では、eNB２３は、RRC_IDLEになる指示をMTC UE２１に送信する（RRC Connection Release）。この指示の受信に応答して、MTC UE２１は、RRC_CONNECTEDからRRC_IDLEになる。

【0054】

ステップＳ２０６では、MTC UE２１は、周期的又は非周期的な通信タイミングが到来したことに応じて、通信を開始するために無線接続の確立要求をeNB２３に送信する（RRC Connection Request）。MTC UE２１は、耐遅延アクセスであることを示すために、“delayTolerantAccess”に指定されたEstablishment causeを伴うRRC Connection Requestを送信してもよい。ステップＳ２０７では、MTC UE２１は、過去にECMを実行していたことを示す履歴情報をeNB２３に報告する。このとき、MTC UE２１は、ECMを実行中であることeNB２３に併せて報告してもよい。

【0055】

図３の例では、ステップＳ２０７の履歴情報は、RRC Connection Setup Completeメッセージを用いて送信される。RRC Connection Setup Completeメッセージは、RRCコネクションの確立手順で送信される最終メッセージであるから、ステップＳ２０７の履歴情報は、RRCコネクションの確立手順の間に送信されるということができる。また、RRC Connection Setup Completeメッセージは、NASメッセージ（e.g., NAS: Service Request、NAS: Attach Request）を包含する。つまり、NASメッセージを包含するRRC Connection Setup Completeメッセージは、ベアラ確立手順の中で送信される最初のメッセージであるから、ステップＳ２０７の履歴情報は、ベアラ確立手順の間に送信されるということもできる。

【0056】

ステップＳ２０８では、eNB２３は、MTC UE２１のためにEPSベアラの確立要求をコアネットワークノード２４１に送信する（Initial UE message）。ステップＳ２０９では、コアネットワークノード２４１は、Initial UE message内にカプセル化されたNASメッセージの受信に応答して、MTC UE２１のための無線アクセスベアラを確立するのに必要な情報をeNB２３に送信する（Initial Context Setup Request）。ステップＳ２０９のメッセージは、例えば端末能力（UE radio capability）を含んでもよい。

【0057】

ステップＳ２１０では、eNB２３は、MTC UE２１にECMを実行させる為に、無線リソース設定情報（RRC Configuration）と共にECM設定情報（ECM configuration）を送信してもよい（RRC Connection Reconfiguration）。ステップＳ２１１では、MTC UE２１は、eNB２３からステップＳ２１０にて受信したECM設定情報、または以前に受信して保持していたECM設定情報を基にデータ通信を行う（M2M data with ECM）。

【0058】

＜第３の実施形態＞
本実施形態に係る無線通信システムの構成例は、第１の実施形態に関して説明された図１と同様とすればよい。本実施形態では、ECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を特定のMTC UE３１に適用するか否かをeNB３３において判定するための手法が説明される。本実施形態で説明される技術思想は、上述した第１又は第２の実施形態で説明された技術思想とは独立して使用されることができるし、これらの技術思想と組み合わせて使用されることもできる。

【0059】

本実施形態に係るeNB３３は、MTC UE３１の端末能力（UE capability）、MTC UE３１の端末情報（UE information）、MTC UE３１の通信特性（Communication performance）、及びMTC UE３１の無線品質（Radio quality）のうち少なくとも１つと、MTC UE３１から受信したアクセス要因（Access cause）とに基づいて、ECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を伴うMTC UE３１とeNB３３の間の通信を制御する。言い換えると、eNB３３は、MTC UE３１の端末能力、端末情報、通信特性、及び無線品質のうち少なくとも１つと、MTC UE３１から受信したアクセス要因とに基づいて、ECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を当該MTC UE３１に適用するか否かを判定する。

【0060】

アクセス要因、端末能力、端末情報、通信特性、及び無線品質の具体例を以下に述べる。ただし、アクセス要因、端末能力、端末情報、通信特性、及び無線品質の内容は、これらの例に限定されるものではない。

【0061】

アクセス要因は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・RRC接続確立の目的（Establishment cause）
・サービス種別（Service type）

【0062】

RRC接続確立の目的は、例えば、（ａ）緊急呼（emergency）、（ｂ）高優先度アクセス（highPriorityAccess）、（ｃ）端末終端通信の為のアクセス（mt-Access）、端末発信によるシグナリング（mo-Signalling）、（ｄ）端末発信によるデータ送信（mo-Data）、（ｅ）耐遅延アクセス（delayTolerantAccess）、（ｆ）低優先度アクセス（lowPriorityAccess）、（ｇ）小データ通信の為のアクセス（smallDataAccess）、（ｈ）小パケット通信の為のアクセス（smallPacketAccess）、（ｉ）限定的なアクセス（limitedAccess）、（ｊ）限定的なサービスの為のアクセス（limitedService）、（ｋ）M2M型アクセス（m2mAccess）、又は（ｌ）ECMによるアクセス（ecmAccess）、を指定してもよい。

【0063】

サービス種別は、例えば、（ａ）リアルタイムサービス、（ｂ）ノンリアルタイムサービス、又は（ｃ）M2M型通信、を指定してもよい。

【0064】

端末能力は、例えば以下の３つのうち少なくとも１つを含んでもよい。
・無線アクセス能力（Radio access capability）
・デバイス能力（Device capability）
・端末カテゴリ（UE category）

【0065】

無線アクセス能力は、例えば、（ａ）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が送信されないことで未サポートを示してもよい。

【0066】

デバイス能力は、例えば、（ａ）UEがMTC UEであることを示す情報、（ｂ）UEの通信性能が（通常UEに比べて）制限されていることを示す情報、又は（ｃ）特定の通信（例えばM2M型通信）のみを行うことを示す情報、を含んでもよい。

【0067】

端末カテゴリは、（ａ）3GPP LTEで規定される端末カテゴリのうちのいずれかを示す情報、又は（ｂ）3GPP LTEで規定されるアクセス階級（Access Class）のいずれかを示す情報、を含んでもよい。端末カテゴリ又はアクセス階級は、M2M型通信を行うMTC UE用に新たに規定してもよい。例えば、低コストで実装する為に機能制限されたMTC UEに対する新規カテゴリ（e.g., category 0）が規定されてもよいし、低頻度で通信を行うことを前提とする又は低頻度の通信のみを許可するアクセス階級（AC）が新たに規定されてもよい。

【0068】

端末情報は、例えば以下の３つのうち少なくとも１つを含んでもよい。
・端末種別（UE type）
・デバイス種別（Device type）
・端末コンテキスト（UE context）

【0069】

端末種別は、例えば、（ａ）UEが通常のUE（非MTC UE）とMTC UEのどちらであるかを示す情報、（ｂ）UEが移動するか否かを示す情報（又はUEが移動しないことを示す情報）、又は（ｃ）UEへの電力供給（power supply）があるか否かを示す情報、を含んでもよい。

【0070】

デバイス種別は、例えば、（ａ）UEに実装されたOperating System（OS）の種別を示す情報、又は（ｂ）UEが行うM2M型通信の種別を示す情報（つまり、M2Mのサブカテゴリ情報）、を含んでもよい。

【0071】

端末コンテキストは、例えば、（ａ）上述の端末能力の情報、（ｂ）UEに設定されたRRC制御情報（RadioResrouceConfigCommon IE及びRaioResourceConfigDediacted IEに含まれる情報等）、（ｃ）UEのモビリティに関する情報（mobility information）、（ｄ）UEがECMを実行しているか否かを示す情報（ECM execution information）、又は（ｅ）UEが以前（例えば前回RRC_CONNECTEDのとき）にECMを実行していたか否かを示す情報（ECM status information）、を含んでもよい。

【0072】

通信特性は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・特性測定結果（Performance measurement result (e.g., L2 measurement)）
・通信統計品質（Statistical communication quality (e.g., KPI)）

【0073】

特性測定結果は、例えば、（ａ）eNB３３（またはOperation Administration and Maintenance（OAM））におけるスループット測定結果（e.g., Scheduled IP Throughput）、（ｂ）パケットロス測定結果（Packet Loss Rate）、又は（ｃ）パケット廃棄測定結果（Packet Discard Rate）、を含んでもよい。

【0074】

通信統計品質は、例えば、（ａ）ハンドオーバ試行回数若しくはハンドオーバ試行率、（ｂ）ハンドオーバ成功率若しくはハンドオーバ失敗率、（ｃ）通信間隔若しくは通信頻度、（ｄ）パケット発生間隔若しくはパケット発生頻度、（ｅ）パケット到着間隔（packet inter-arrival time）若しくはパケット到着頻度（packet inter-arrival rate）、（ｆ）アクセス間隔若しくはアクセス頻度、又は（ｇ）RRC接続確立若しくはNAS接続確立の間隔若しくは頻度、を含んでもよい。

【0075】

無線品質は、例えば以下の２つのうち少なくとも１つを含んでもよい。
・参照信号の受信品質（Reference Signal (RS) received quality）
・通信路品質指標（CQI）

【0076】

参照信号（RS）の受信品質は、例えば、（ａ）UEにおける下りRSの受信電力（RSRP）、（ｂ）受信品質（RSRQ）、若しくは受信電力強度（RSSI）、又は（ｂ）UEが送信する上り参照信号（Sounding Reference Signal: SRS）のeNB３３における受信電力、を含んでもよい。

【0077】

eNB３３は、上述したMTC UE３１の端末能力又は端末情報をMTC UE３１自身から受信してもよいし、EPCから受信してもよい。

【0078】

本実施形態よれば、以下に述べる効果が期待される。すなわち、仮に、ECMに関するカバレッジ改善処理をMTC UE３１に適用するか否かをそのMTC UE３１のアクセス要因のみに基づいて判定したのでは、各MTC UE３１の状況を十分に考慮することができない問題がある。既に述べたように、想定されているECMに関するカバレッジ改善処理のうち、RACHの繰り返し並びにPDSCH/PUSCHの繰り返しは各MTC UEに個別に適用される。そして、MTC UEに個別に適用されるカバレッジ改善処理（例えば、RACHの繰り返し、PDSCH/PUSCHの繰り返し）は、ECMを行うMTC UEの数が増加するほど多くの無線リソースを消費する。このため、ECMを実行するべきか否かの判定は、MTC UE個別の状況を考慮して行われることが好ましい。本実施形態のeNB３３は、ECMを実行するべきか否かの判定において、MTC UE３１のアクセス要因だけでなく、MTC UE３１の端末能力、端末情報、通信特性、及び無線品質のうち少なとも１つをさらに考慮する。したがって、本実施形態は、ECMを実行するべきか否かをMTC UE個別の状況を考慮して行うことができる。

【0079】

図４は、本実施形態に係るMTC UE３１、eNB３３、及びコアネットワークノード３４１の動作の一例を示すシーケンス図である。コアネットワークノード３４１は、EPCに配置されたノード（e.g., MME若しくはHSS又はこれら両方）である。図４の例では、eNB３３は、MTC UE３１のアクセス要因（例えばEstablishment cause）、端末能力（例えばUE radio access capability）、及び端末情報（例えばUE type）に基づいて、ECMに関するカバレッジ改善処理をMTC UE３１に適用するか否かを判定する。なお、図４は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。

【0080】

図４に示されたMTC UE３１の初期状態は、RRC_IDLEである。ステップＳ３０１では、MTC UE３１は、周期的又は非周期的な通信タイミングが到来したことに応じて、通信を開始するために無線接続の確立要求をeNB２３に送信する（RRC Connection Request）。MTC UE３１は、耐遅延アクセスであることを示すために、“delayTolerantAccess”に指定されたEstablishment causeを伴うRRC Connection Requestを送信してもよい。図示されていない無線接続（RRC Connection）の確立手順の完了によって、MTC UE３１は、RRC_CONNECTEDになる。

【0081】

ステップＳ３０２では、eNB３３は、MTC UE３１のためにEPSベアラの確立要求をコアネットワークノード３４１に送信する（Initial UE message）。このInitial UE messageは、MTC UE３１からのNon-Access Stratum（NAS）メッセージ（e.g. NAS: Service Request）をカプセル化している。ステップＳ３０３では、コアネットワークノード３４１は、Initial UE message内にカプセル化されたNASメッセージの受信に応答して、MTC UE３１のための無線アクセスベアラを確立するのに必要な情報をeNB３３に送信する（Initial Context Setup Request）。ステップＳ３０３のメッセージは、例えば端末能力（UE radio capability）若しくは端末種別（UE type）又はこれら両方を含んでもよい。

【0082】

ステップＳ３０４では、eNB３３は、必要に応じて、端末能力の送信をMTC UE３１に要求する（UE Capability Enquiry）。ステップＳ３０５では、eNB３３からの要求に応答して、MTC UE３１は自身の端末能力をeNB３３に報告する（UE Capability Information）。ステップＳ３０５のメッセージは、例えばUE-EUTRA-capabilityを含んでもよい。

【0083】

ステップＳ３０６では、eNB３３は、MTC UE３１にECMを実行させるか否か（言い換えると、ECMに関するカバレッジ改善処理MTC UEに３１に適用するか否か）を決定する（ECM decision）。一例として、eNB３３は、MTC UE３1のestablishment causeがdelayTolerantAccessを示し、且つMTC UE３1のradio access capabilityがECMをサポートしていることを示すことを条件として、MTC UE３１にECMを実行させることを決定してもよい。

【0084】

ステップＳ３０７では、eNB３３は、MTC UE３１にECMを実行させる為に、無線リソース設定情報（RRC Configuration）と共にECM設定情報（ECM configuration）を送信する。ステップＳ３０８では、MTC UE３１は、eNB１３から受信した無線リソース設定情報及びECM設定情報に従ってECMを開始する（ECM start）。ステップＳ３０９では、MTC UE３１は、ECMに関するカバレッジ改善処理を行いながらデータ通信を行う（M2M data with ECM）。

【0085】

図４に示された手順は一例である。一例として、eNB３３は、アクセス要因（e.g., Establishment cause）、端末能力（e.g., UE radio access capability）、端末情報（e.g., UE type）に加えて、通信特性若しくは無線品質又はこれら両方をさらに考慮してもよい。具体的には、eNB３３は、始めに、MTC UE３１のアクセス要因、端末能力、及び端末情報に基づいて、当該MTC UE３１にECMを実行させることを決定してもよい。そしてその後に、eNB３３は、MTC UE３１の通信特性若しくは無線品質又はこれら両方に基づいて、当該MTC UE３１にECMを実行させ続けるか否かを判定してもよい。このように、eNB３１がMTC UE３１の通信特性又は無線品質を考慮することで、ECMの実行が必要であるか否かの判定をより適切にすることができる。

【0086】

例えば、eNB３３は、MTC UE３１の通信特性としてハンドオーバ試行回数（又は試行率）を取得し、それを基にMTC UE３１が静止またはほぼ静止していると判定した場合にはECMの実行を継続してもよい。反対に、MTC UE３１が移動していると判定した場合には、eNB３３は、MTC UE３１のECMの実行を中断（又は中止）してもよい。これに代えて又はこれと組み合わせて、eNB３３は、MTC UE３１の無線品質としてRSRPやCQIを取得し、それらが所定閾値よりも小さいと判定した場合にECMの実行を継続してもよい。反対に、MTC UE３１の無線品質が所定閾値よりも大きいと判定した場合には、eNB３３は、MTC UE３１のECMの実行を中断（又は中止）してもよい。

【0087】

また他の例として、eNB３３は、MTC UE３１にECMを実行させるか否かを始めに判定するときに、MTC UE３１の通信特性若しくは無線品質又はこれら両方を取得し、これらを考慮してMTC UE３１にECMを実行させるか否かを判定してもよい。このとき、eNB３１は、MTC UE３１の通信特性又は無線品質を新たに計測するのではなく、eNB３１又は他のネットワーク装置（e.g., OAM又はMME）に保存されていたMTC UE３１の過去の通信特性又は無線品質を利用してもよい。これにより、MTC UE３１にECMを実行させるか否かの判定が遅くなることでMTC UE３１の通信特性が劣化することを回避できる。

【0088】

＜第４の実施形態＞
本実施形態では、ECMをサポートするMTC UEのハンドオーバに関する制御が説明される。図５は、本実施形態に係る無線通信システムの構成例を示している。図５を参照すると、当該無線通信システムは、MTC UE４１、eNB４３、eNB４５、及びEPC４４を含む。MTC UE４１は、例えば自動車、鉄道車両、又は船舶などの輸送機械に搭載され、したがって移動性を有する。なお、図５は、ヘテロジーニアス・ネットワーク（HetNet）の例を示している。すなわち、eNB４３はセル４３０を管理し、eNB４５はセル４３０に比べて狭い範囲をカバーするセル４５０を管理する。例えば、eNB４３はマクロ基地局であり、eNB４５はピコ基地局である。しかしながら、本実施形態は、セル４３０とセル４５０が同程度の大きさを持つホモジーニアス・ネットワークに適用されてもよい。

【0089】

続いて以下では、本実施形態に係るECMのための通信制御について説明する。本実施形態に係るeNB４３は、ECMを実行中のMTC UE４１が自身のセル４３０から隣接セル４５０にハンドオーバする際に、MTC UE４１がECMを実行していること（言い換えると、ECMに関するカバレッジ改善処理を実行していること）をeNB４５に通知する。eNB４３は、MTC UE４１のためのハンドオーバ要求をeNB４５に送信する際に、MTC UE４１がECMを実行していること（言い換えると、ECMに関するカバレッジ改善処理を実行していること）をeNB４５に通知してもよい。eNB４５は、eNB４３からの通知に基づいて、MTC UE４１とeNB４５の間のECMを伴う通信を制御してもよい。例えば、eNB４５は、MTC UE４１とeNB４５の間の通信にECMを適用するか否かをeNB４３からの通知に基づいて判定してもよい。

【0090】

本実施形態よれば、以下に述べる効果が期待される。すなわち、本実施形態では、ハンドオーバのソース基地局（つまり、eNB４３）は、MTC UE４１がECMを実行しているか否かをターゲット基地局（つまり、eNB４５）に通知する。したがって、ターゲット基地局（eNB４５）は、MTC UE４１に対してECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）を適用するべきか否かを判定するために、MTC UE４１の無線品質（e.g., RSRP、RSRQ、CQI）を取得してこれを分析することを必ずしも必要としない。なぜなら、ターゲット基地局（eNB４５）は、ハンドオーバするMTC UE４１に対してECMが適用できるか又はECMのカバレッジ改善処理が有効であるか否かを、ソース基地局（eNB４３）からの通知に基づいて判定できるためである。したがって、本実施形態は、ハンドオーバするMTC UE４１に対してターゲット基地局（ターゲットセル）においてECMに関するカバレッジ改善処理を適用するべきか否かの判定に要する時間（遅延）を削減できる。

【0091】

図６は、本実施形態に係るMTC UE４１、eNB４３、及びeNB４５の動作の一例を示すシーケンス図である。図６は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。ステップＳ４０１では、MTC UE４１は、eNB４３のセル４３０に滞在している。eNB４３は、MTC UE４１にECMの設定情報（ECM configuration-1）を送信する。図６の例では、ECM configuration-1は、RRC Connection Reconfigurationメッセージを用いて送信される。ステップＳ４０２では、MTC UE４１は、eNB４３から受信したECM configurationに従ってECMの実行（つまり、カバレッジ改善処理（e.g., 繰り返されるPDSCHの受信、PUSCHの繰り返し送信））を開始する（ECM start）。ステップＳ４０３では、MTC UE４１は、ECM configurationに従ってデータ通信を行う（M2M data with ECM）。

【0092】

ステップＳ４０４では、eNB４３は、MTC UE４１を自身のセル４３０から隣接するeNB４５のセル４５０にハンドオーバさせることを決定する（HO decision）。ステップＳ４０５では、eNB４３は、MTC UE４１のためのハンドオーバ要求をeNB４５に送信する（Handover Request）。ステップＳ４０５で送信されるハンドオーバ要求は、ハンドオーバ対象となるMTC UE４１がECMを実行していることを示す情報（ECM activated）を含む。

【0093】

ステップＳ４０６では、eNB４３は、MTC UE４１の受け入れが可能である場合、eNB４３にハンドオーバ要求への承諾メッセージを送信する（Handover Request Acknowledge）。ステップＳ４０６で送信される承諾メッセージは、ターゲットセル４５０におけるECMの実行に必要なECM設定情報（ECM configuration-2）を含んでもよい。

【0094】

ステップＳ４０７では、eNB４３は、eNB４５からの承諾メッセージの受信に応じて、MTC UE４１にハンドオーバ指示を送信する（RRC Connection Reconfiguration）。ステップＳ４０７で送信されるメッセージ（RRC Connection Reconfiguration）は、ターゲットセル４５０におけるECMの実行に必要なECM設定情報（ECM configuration-2）を含んでもよい。

【0095】

ステップＳ４０８では、MTC UE４１は、セル４３０からセル４５０へのハンドオーバを実行し、ハンドオーバ完了のメッセージをターゲットeNB４５に送信する（RRC Connection Reconfiguration Complete/ Handover confirm）。図示していないが、MTC UE４１は、ステップＳ４０８で自身がECMを実行していたことを示す情報をeNB４５に送信してもよい。ステップＳ４０９では、MTC UE４１は、ステップＳ４０７にてソースeNB４３から受信したターゲットセル４５０に関するECM設定情報（ECM configuration-2）に従ってデータ通信を行う（M2M data with ECM）。

【0096】

図６は、ソースeNB４３とターゲットeNB４５の間に設けられたeNB間の直接インタフェース（つまり、X2 interface）を介してハンドオーバ要求メッセージ及びハンドオーバ要求への承諾メッセージが送信される例を示した。しかしながら、ハンドオーバに関するメッセージは、eNB４３及び４５の各々とEPC４４（つまり、MME）の間のインタフェース（つまり、S1-MME interface）を介して送信されてもよい。すなわち、MTC UE４１がECMを実行していることの通知（ソースeNB４３からターゲットeNB４５）、及びターゲットセル４５０に関するECM設定情報（ターゲットeNB４５からソースeNB４３）は、EPC４４を介して送信されてもよい。

【0097】

＜第５の実施形態＞
本実施形態では、隣接するeNB間でのECMサポート情報の共有について説明される。本実施形態に係るeNB５３は、自身のセル５３０がECM（言い換えると、ECMに関するカバレッジ改善処理）をサポートしているか否かを、eNB５５に通知する。なお、eNB５５は、eNB５３のセルの隣接セルを管理する基地局である。さらに、eNB５３は、eNB５５のセル５５０においてECM（言い換えると、ECMに関するカバレッジ改善処理）がサポートされているか否かをeNB５５から通知される。ECMをサポートしているか否かは、基地局単位（つまりeNB５３又は５５の全てのセルでサポート）で示されてもよいし、セル単位（つまりeNB５３又は５５の一部のセルでサポート、その他のセルでは未サポート）で示されてもよい。

【0098】

本実施形態よれば、以下に述べる効果が期待される。仮にサービングeNBが隣接eNB（隣接セル）におけるECMのサポート有無を知らなければ、サービングeNBは、ECMをサポートしている又はECMを実行しているMTC UEをハンドオーバ又はセル再選択によって隣接セルに帰属させることが有効であるか否かを十分に判断することができないおそれがある。例えば、サービングeNB（サービングセル）がECMをサポートしており、隣接eNB（隣接セル）がECMをサポートしていない場合、サービングeNBは自セルにおいてECMを実行しているMTC UEを隣接セルにハンドオーバさせないほうが当該MTC UEの通信特性の確保する上で有効であるかもしれない。これとは反対に、サービングeNB（サービングセル）がECMをサポートしておらず、隣接eNB（隣接セル）がECMをサポートしている場合、サービングeNBはECMをサポートしているMTC UEをハンドオーバ又はセル再選択によって隣接セルに帰属させるべきであるかもしれない。本実施形態ついてみると、eNB５３及びeNB５５は、ECMサポート有無を互いに知ることができる。したがって、eNB５３及び５５は、ECMをサポートしているMTC UE５１が適切なセルに滞在する又は適切なセルで通信を行うことに寄与することができる。

【0099】

例えば、eNB５３のセル５３０がECMをサポートしておらず、eNB５５のセル５５０がECMをサポートしている場合、eNB５３は、ECMをサポートしているMTC UEが隣接セル５５０に移動しやすくするように当該MTC UEに通知されるハンドオーバ・パラメータ又はセル再選択パラメータを調整すればよい。例えば、隣接セル５５０の無線品質に作用するCell Individual Offset（CIO）を大きくしてもよい。CIOは、LTEのハンドオーバ・パラメータの１つであり、CIOを大きくすることは、MTC UE５１のハンドオーバをトリガーする測定報告の送信条件を成立しやすくする。また、隣接セル５５０の無線品質に作用するQoffsetを小さくしてもよい。Qoffset は、LTEのセル再選択パラメータの１つであり、Qoffsetを小さくすることは、MTC UE５１が隣接セル５５０を再選択する条件を成立しやすくする。

【0100】

図７は、本実施形態に係るeNB５３及びeNB５５の動作の一例を示すシーケンス図である。図７は、本実施形態の説明に必要なメッセージのみを記載しており、LTEで規定された手順に含まれるいくつかのメッセージの図示を省略している。

【0101】

ステップＳ５０１では、eNB５３は、自身のセル５３０に隣接する（又は周辺の）セル５５０を管理するeNB５５と直接インタフェース（X2 interface）の確立をトリガーされる（X2 setup Triggered）。ステップＳ５０２では、eNB５３は、X2 interfaceの確立要求をeNB５５に送信する（X2 Setup Request）。ステップＳ５０２のメッセージは、eNB５３のセル５３０においてECMがサポートされている否かを示す。図７の例では、eNB５３は、ECMをサポートしていることを示す情報（ECM supported）を送信する。ECMをサポートしているか否かは、基地局単位（つまりeNB５３の全てのセルでサポート）で示されてもよいし、セル単位（つまりeNB５３の一部のセルでサポート、その他のセルでは未サポート）で示されてもよい。

【0102】

ステップＳ５０３では、eNB５５は、eNB５３からのX2 interfaceの確立要求に対する応答メッセージを送信する（X2 Setup Response）。ステップＳ５０３の応答メッセージは、eNB５５のセル５５０においてECMがサポートされている否かを示す。図７の例では、セル５５０はECMをサポートしていないため、ステップＳ５０３の応答メッセージは、ECMがサポートされていることを示す情報を含まない。なお、ステップＳ５０３の応答メッセージは、ECMがサポートされていないことを明示的に示す情報を含んでもよい。

【0103】

その後、ステップＳ５０４では、eNB５５の設定が更新され、eNB５５がECMをサポートするようになる。したがって、ステップＳ５０５では、eNB５５は、eNB設定の更新があったことをeNB５３に通知する（ENB Configuration Update）。ステップＳ５０５のメッセージは、eNB５５のセル５５０においてECMがサポートされていることを示す情報（ECM supported）を含む。ECMをサポートしているか否かは、基地局単位（つまりeNB５５の全てのセルでサポート）で示されてもよいし、セル単位（つまりeNB５５の一部のセルでサポート、その他のセルでは未サポート）で示されてもよい。ステップＳ５０６では、eNB５３は、eNB５３からのeNB設定の更新通知に対する応答メッセージを送信する（ENB Configuration Update Acknowledge）。

【0104】

最後に上述の実施形態に係るMTC UE、eNB、及びコアネットワークノード（e.g., MME若しくはHSS又はこれら両方）の構成例について説明する。第１〜第５の実施形態で説明されたMTC UE１１、２１、３１、及び４１の各々は、eNBと通信するためのトランシーバ、及び当該トランシーバに結合されたコントローラを含んでもよい。コントローラは、第１〜第５の実施形態で説明されたMTC UE１１、２１、３１、又は４１によるECMに関する通信制御を実行する。

【0105】

第１〜第５の実施形態で説明されたeNB１３、２３、３３、４３、４５、５３、及び５５の各々は、MTC UEを含む複数のUEと通信するためのトランシーバ、及び当該トランシーバに結合されたコントローラを含んでもよい。コントローラは、第１〜第５の実施形態で説明されたeNB１３、２３、３３、４３、４５、５３、又は５５によるECMに関する通信制御を実行する。

【0106】

第１〜第５の実施形態で説明されたコアネットワークノード１４１、２４１、及び３４１は、eNBと通信するためのインタフェース、及び当該インタフェースに結合されたコントローラを含んでもよい。コントローラは、第１〜第５の実施形態で説明されたコアネットワークノード１４１、２４１、又は３４１によるECMに関する通信制御を実行する。

【0107】

図８〜図１０は、第１の実施形態に係るMTC UE１１、eNB１３、及びコアネットワークノード１４１の構成例を示すブロック図である。図８を参照すると、MTC UE１１は、トランシーバ１１１及びコントローラ１１２を含む。トランシーバ１１１は、eNB１３と通信するよう構成されている。コントローラ１１２は、eNB１３からの指示に従って、MTC UE１１におけるECMに関するカバレッジ改善処理の実行を制御するよう構成されている。

【0108】

図９を参照すると、eNB１３は、トランシーバ１３１及びコントローラ１３２を含む。トランシーバ１３１は、MTC UE１１及び通常のUE１２を含む複数のUEと通信するよう構成されている。コントローラ１３２は、MTC UE１とeNB１３の間のECMに関するカバレッジ改善処理を伴う通信を制御するよう構成されている。具体的には、コントローラ１３２は、MTC UE（M2M端末）１１の通信においてECMに関するカバレッジ改善処理（e.g., PDSCH/PUSCHの繰り返し）が実行されていたか否かを示す履歴情報をEPC１４から受信する。そして、コントローラ１３２は、EPC１４から受信された履歴情報に基づいて、ECMに関するカバレッジ改善処理を伴うMTC UE１１とeNB１３の間の通信を制御する。

【0109】

図１０を参照すると、コアネットワークノード１４１は、インタフェース１４１１及びコントローラ１４１２を含む。インタフェース１４１１は、制御メッセージをeNB１３との間で送受信するために利用される。コントローラ１４１２は、インタフェース１４１１を介してeNB１３とシグナリング・メッセージを送受信するよう構成されている。具体的には、コントローラ１４１２は、MTC UE１１とEPC１４の間のEPSベアラを確立する手順が行われる間に、当該MTC UE１１の通信において所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報をインタフェース１４１１を介してeNB13に送信する。

【0110】

上述の実施形態に係るMTC UE、eNB、及びコアネットワークノードが有するコントローラの各々は、少なくとも１つのプロセッサ（e.g. マイクロプロセッサ、Micro Processing Unit（MPU）、Central Processing Unit（CPU））を含むコンピュータにプログラムを実行させることによって実現されてもよい。具体的には、シーケンス図等を用いて説明されたMTC UE、eNB、又はコアネットワークノードに関するアルゴリズムをコンピュータに行わせるための命令群を含む１又は複数のプログラムをコンピュータに供給すればよい。

【0111】

このプログラムは、様々なタイプの非一時的なコンピュータ可読媒体（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）によってコンピュータに供給されてもよい。一時的なコンピュータ可読媒体の例は、電気信号、光信号、及び電磁波を含む。一時的なコンピュータ可読媒体は、電線及び光ファイバ等の有線通信路、又は無線通信路を介して、プログラムをコンピュータに供給できる。

【0112】

＜その他の実施形態＞
上述の実施形態では、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の繰り返し）を実行してもよい。

【0113】

また、上述の実施形態ではECMを想定していたが、これらの実施形態で説明された技術思想は、ECMとは異なる何らかの特別な処理を無線ネットワーク（例えばeNB）がM2M端末（MTC UE）に実行させる場合に適用されてもよい。

【0114】

また、上述の実施形態では、通常端末（UE）とM2M端末（MTC UE）を例に説明してきたが、それぞれユーザ端末（user terminal）と非ユーザ端末（non-user terminal）とも呼ばれる。

【0115】

また、上述の実施形態では、主にLTEシステムに関して説明を行った。しかしながら、これらの実施形態は、LTEシステム以外の無線通信システム、例えば、3GPP UMTS、3GPP2 CDMA2000システム（1xRTT, HRPD）、GSM/GPRSシステム、又はWiMAXシステム等に適用されてもよい。

【0116】

上述の実施形態が3GPP UMTSに適用される場合、上述の実施形態におけるeNB（eNB１３、２３、３３、４３、４５、５３、又は５５）の動作は、NodeB若しくはRNC又はこれらの組み合わせによって行われてもよい。言い換えると、本明細書及び請求の範囲において使用される基地局との用語は、無線アクセスネットワークに配置される１つ又は複数のエンティティを意味し、一例においてUMTSのNodeB若しくはRNC又はこれらの組み合わせを意味する。

【0117】

さらに、上述した実施形態は本件発明者により得られた技術思想の適用に関する例に過ぎない。すなわち、当該技術思想は、上述した実施形態のみに限定されるものではなく、種々の変更が可能であることは勿論である。

【0118】

例えば、上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。

【0119】

（付記１）
M2M端末と通信する無線通信手段と、
前記M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記無線通信手段の間の所定のカバレッジ改善処理を伴う通信を制御する制御手段と、
を備える基地局装置。

【0120】

（付記２）
前記制御は、前記M2M端末と前記無線通信手段の間の通信において前記所定のカバレッジ改善処理を実行するか否かを決定することを含む、付記１に記載の基地局装置。

【0121】

（付記３）
前記制御は、前記所定のカバレッジ改善処理の実行を前記M2M端末に指示することを含む、付記１又は２に記載の基地局装置。

【0122】

（付記４）
前記制御手段は、さらに、前記所定のカバレッジ改善処理を前記M2M端末において実行中であることを示す通知を前記M2M端末から受信した場合に、前記M2M端末と前記無線通信手段の間の前記所定のカバレッジ改善処理を伴う通信を前記通知に基づいて制御する、付記１〜３のいずれか１項に記載の基地局装置。

【0123】

（付記５）
前記通知は、前記M2M端末との無線接続を確立する際に、又は前記M2M端末とコアネットワークの間のベアラを確立する手順が行われる間に前記M2M端末から前記基地局装置に送信される、付記４に記載の基地局装置。

【0124】

（付記６）
前記端末能力は、無線アクセス能力（Radio access capability）、デバイス能力（Device capability）、及び端末カテゴリ（UE category）のうち少なくとも１つを含む、付記１〜５のいずれか１項に記載の基地局装置。

【0125】

（付記７）
前記端末情報は、端末種別（UE type）、デバイス種別（Device type）、及び端末コンテキスト（UE context）のうち少なくとも１つを含む、付記１〜６のいずれか１項に記載の基地局装置。

【0126】

（付記８）
前記端末コンテキストは、前記端末能力に関する情報、前記M2M端末に設定されたRadio Resource Controlコネクション情報、前記M2M端末のモビリティに関する情報、及び前記M2M端末の通信において前記所定のカバレッジ改善処理が実行されていたか否かを示す履歴情報、のうち少なくとも１つを含む、付記７に記載の基地局装置。

【0127】

（付記９）
前記制御手段は、さらに、前記基地局装置のセルから隣接セルへの前記M2M端末のハンドオーバの際に、前記M2M端末が前記所定のカバレッジ改善処理を実行していることを隣接基地局に通知する、付記１〜８のいずれか１項に記載の基地局装置。

【0128】

（付記１０）
前記制御手段は、さらに、前記基地局装置において前記所定のカバレッジ改善処理がサポートされているか否かを隣接基地局に通知し、前記隣接基地局において前記所定のカバレッジ改善処理がサポートされているか否かを前記隣接基地局から通知される、付記１〜９のいずれか１項に記載の基地局装置。

【0129】

（付記１１）
Machine-to-machine（M2M）通信を行うM2M端末であって、
基地局と通信する無線通信手段と、
制御手段と、
を備え、
前記基地局は、前記M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記基地局の間の所定のカバレッジ改善処理を伴う通信を制御するよう構成され、
前記制御手段は、前記無線通信手段を介して前記基地局に前記アクセス要因を送信し、前記所定のカバレッジ改善処理の実行の指示を前記基地局から受信する、
M2M端末。

【0130】

（付記１２）
前記制御手段は、さらに、前記所定のカバレッジ改善処理の実行を指示された場合、前記所定のカバレッジ改善処理の停止の指示があるまで前記所定のカバレッジ改善処理を継続する、付記１１に記載のM2M端末。

【0131】

（付記１３）
前記制御手段は、さらに、前記所定のカバレッジ改善処理の実行を指示された場合、前記基地局との無線接続を解放した後も前記所定のカバレッジ改善処理を継続する、付記１１に記載のM2M端末。

【0132】

（付記１４）
前記制御手段は、さらに、前記所定のカバレッジ改善処理の実行を指示された場合、前記基地局との無線接続の確立と解放を繰り返す間も前記所定のカバレッジ改善処理を継続する、付記１１に記載のM2M端末。

【0133】

（付記１５）
前記制御手段は、さらに、前記基地局との無線接続を確立する際に、前記M2M端末において前記所定のカバレッジ改善処理が実行されているか否かを示す通知を前記基地局に送信する、付記１２〜１４のいずれか１項に記載のM2M端末。

【0134】

（付記１６）
基地局により行われる方法であって、
M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記基地局の間の所定のカバレッジ改善処理を伴う通信を制御すること、
を備える方法。

【0135】

（付記１７）
基地局を介してMachine-to-machine（M2M）通信を行うM2M端末により行われる方法であって、
前記基地局は、前記M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記基地局の間の所定のカバレッジ改善処理を伴う通信を制御するよう構成され、
前記方法は、
前記基地局に前記アクセス要因を送信すること、及び
前記所定のカバレッジ改善処理の実行の指示を前記基地局から受信すること、
を備える方法。

【0136】

（付記１８）
基地局に関する方法をコンピュータに行わせるためのプログラムであって、
前記方法は、M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記基地局の間の所定のカバレッジ改善処理を伴う通信を制御することを備える、
プログラム。

【0137】

（付記１９）
基地局を介してMachine-to-machine（M2M）通信を行うM2M端末に関する方法をコンピュータに行わせるためのプログラムであって、
前記基地局は、前記M2M端末の端末能力、前記M2M端末の端末情報、前記M2M端末の通信特性、及び前記M2M端末の無線品質のうち少なくとも１つと、前記M2M端末から受信したアクセス要因とに基づいて、前記M2M端末と前記基地局の間の所定のカバレッジ改善処理を伴う通信を制御するよう構成され、
前記方法は、
前記基地局に前記アクセス要因を送信すること、及び
前記所定のカバレッジ改善処理の実行の指示を前記基地局から受信すること、
を備える、プログラム。

【0138】

この出願は、２０１４年１月３０日に出願された日本出願特願２０１４−０１５８６８を基礎とする優先権を主張し、その開示の全てをここに取り込む。

【符号の説明】

【0139】

１１、２１、３１、４１ M2M端末（MTC UE）
１２ 無線端末（UE）
１３、２３、３３、４３、４５、５３、５５ 基地局（eNB）
１４、４４ コアネットワーク（EPC）
１３０、４３０、４５０ セル
１１１ トランシーバ
１１２ コントローラ
１３１ トランシーバ
１３２ コントローラ
１４１、２４１、３４１ コアネットワークノード
１４１１ インタフェース
１４１２ コントローラ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】