"コアネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置を含む複数の端末装置群とを備える通信システムであって、前記基地局装置は、複数の前記通信端末装置から前記コアネットワークに宛てて送信されたデータを受信すると、受信したデータを集線する集線処理を前記複数の端末装置群にわたって行い、前記集線処理によって得られたデータを前記コアネットワークに送信することを特徴とする通信システム。前記基地局装置は、前記集線処理によって得られたデータを、送信可能な期間として予め定める許可期間に前記コアネットワークに送信することを特徴とする請求項1に記載の通信システム。前記基地局装置は、前記集線処理によって得られたデータを、送信可能な無線リソースとして予め定める許可リソースを用いて、前記コアネットワークに送信することを特徴とする請求項1に記載の通信システム。前記基地局装置は、前記通信端末装置から予め定めるメッセージまたは信号を受信すると、前記集線処理によって得られたデータを前記コアネットワークに送信することを特徴とする請求項1に記載の通信システム。前述のように、非特許文献9には、eNBが、同じMTCDグループのMTCDに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregationことで、シグナリングメッセージをコンパクトにすることが開示されている。しかし、eNBの傘下に多くのMTCDグループが存在する場合には、非特許文献9に開示されている方法を用いたとしても、前述のコアネットワークにおいて混雑状態が生じるという問題が再発する。本発明の目的は、eNBの傘下に多くのMTCDグループが存在する場合でも、多数のMTCDから、あるいは多数のMTCDへ同時にデータを通信する状況が生じたときのコアネットワークの混雑状態を緩和することができる通信システムを提供することである。本発明の通信システムは、コアネットワークに接続される基地局装置と、前記基地局装置に無線通信可能に接続される通信端末装置を含む複数の端末装置群とを備える通信システムであって、前記基地局装置は、複数の前記通信端末装置から前記コアネットワークに宛てて送信されたデータを受信すると、受信したデータを集線する集線処理を前記複数の端末装置群にわたって行い、前記集線処理によって得られたデータを前記コアネットワークに送信することを特徴とする。本発明の通信システムによれば、基地局装置は、複数の通信端末装置からコアネットワークに宛てて送信されたデータを受信すると、受信したデータを集線する集線処理を複数の端末装置群にわたって行い、集線処理によって得られたデータをコアネットワークに送信する。このように複数の端末装置群にわたって集線処理を行うので、基地局装置の傘下に多数の端末装置群が存在する場合でも、基地局装置からコアネットワークへの通信回数またはデータ量を削減することができる。これによって、基地局装置の傘下に多数の端末装置群が存在する場合でも、これらに含まれる多数の通信端末装置との間でデータを通信する状況が生じたときのコアネットワークの混雑を緩和することができる。また、通信端末装置からコアネットワークに宛てて送信されるデータは、基地局装置によって集線処理されてからコアネットワークに送信されるので、通信端末装置が無線環境の悪い場所に設置されている場合であっても、基地局装置が起点となって、通信端末装置と通信することができる。したがって、通信端末装置と基地局装置との間に、たとえば集中装置のような装置を別途設ける必要がないので、通信システムの複雑化を回避することができる。この発明の目的、特徴、局面、および利点は、以下の詳細な説明と添付図面とによって、より明白となる。実施の形態1.図7は、現在3GPPにおいて議論されているLTE方式の移動体通信システムの全体的な構成を示すブロック図である。現在3GPPにおいては、CSGClosedSubscriberGroupセルE-UTRANのHome-eNodeBHome-eNB;HeNB、UTRANのHome-NBHNBと、non-CSGセルE-UTRANのeNodeBeNB、UTRANのNodeBNB、GERANのBSSとを含めたシステムの全体的な構成が検討されており、E-UTRANについては、図7のような構成が提案されている非特許文献14.6.1章参照。図7について説明する。移動端末装置以下移動端末またはUserEquipmentUEという71は、基地局装置以下基地局という72と無線通信可能であり、無線通信で信号の送受信を行う。移動端末装置は、通信端末装置に相当する。以下、移動端末装置を通信端末という場合がある。基地局72は、マクロセルであるeNB72-1と、ローカルノードであるHome-eNB72-2とに分類される。eNB72-1は、大規模基地局装置に相当し、移動端末UE71と通信可能な範囲であるカバレッジとして、比較的大きい大規模カバレッジを有する。Home-eNB72-2は、小規模基地局装置に相当し、カバレッジとして、比較的小さい小規模カバレッジを有する。eNB72-1は、MME、あるいはS-GW、あるいはMMEおよびS-GWを含むMME/S-GW部以下MME部という場合がある73とS1インタフェースにより接続され、eNB72-1とMME部73との間で制御情報が通信される。ひとつのeNB72-1に対して、複数のMME部73が接続されてもよい。eNB72-1間は、X2インタフェースにより接続され、eNB72-1間で制御情報が通信される。Home-eNB72-2は、MME部73とS1インタフェースにより接続され、Home-eNB72-2とMME部73との間で制御情報が通信される。ひとつのMME部73に対して、複数のHome-eNB72-2が接続される。あるいは、Home-eNB72-2は、HeNBGWHomeeNBGateWay74を介してMME部73と接続される。Home-eNB72-2とHeNBGW74とは、S1インタフェースにより接続され、HeNBGW74とMME部73とはS1インタフェースを介して接続される。ひとつまたは複数のHome-eNB72-2がひとつのHeNBGW74と接続され、S1インタフェースを通して情報が通信される。HeNBGW74は、ひとつまたは複数のMME部73と接続され、S1インタフェースを通して情報が通信される。さらに現在3GPPでは、以下のような構成が検討されている。Home-eNB72-2間のX2インタフェースはサポートされない。MME部73からは、HeNBGW74はeNB72-1として見える。Home-eNB72-2からは、HeNBGW74はMME部73として見える。Home-eNB72-2が、HeNBGW74を介してMME部73に接続されるか否かに関係なく、Home-eNB72-2とMME部73との間のインタフェースは、S1インタフェースで同じである。複数のMME部73にまたがるような、Home-eNB72-2へのモビリティ、あるいはHome-eNB72-2からのモビリティはサポートされない。Home-eNB72-2は、唯一のセルをサポートする。図8は、本発明に係る移動端末図7の移動端末71の構成を示すブロック図である。図8に示す移動端末71の送信処理を説明する。まず、プロトコル処理部801からの制御データ、およびアプリケーション部802からのユーザデータが、送信データバッファ部803へ保存される。送信データバッファ部803に保存されたデータは、エンコーダー部804へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部803から変調部805へ直接出力されるデータが存在してもよい。エンコーダー部804でエンコード処理されたデータは、変調部805にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部806へ出力され、無線送信周波数に変換される。その後、アンテナ807から基地局72に送信信号が送信される。また、移動端末71の受信処理は、以下のとおりに実行される。基地局72からの無線信号がアンテナ807により受信される。受信信号は、周波数変換部806にて無線受信周波数からベースバンド信号に変換され、復調部808において復調処理が行われる。復調後のデータは、デコーダー部809へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部801へ渡され、ユーザデータはアプリケーション部802へ渡される。移動端末71の一連の処理は、制御部810によって制御される。よって制御部810は、図8では省略しているが、各部801~809と接続している。図9は、本発明に係る基地局図7の基地局72の構成を示すブロック図である。図9に示す基地局72の送信処理を説明する。EPC通信部901は、基地局72とEPCMME部73、HeNBGW74などとの間のデータの送受信を行う。他基地局通信部902は、他の基地局との間のデータの送受信を行う。Home-eNB72-2間のX2インタフェースはサポートされない方向であるため、Home-eNB72-2では、他基地局通信部902が存在しないことも考えられる。EPC通信部901および他基地局通信部902は、それぞれプロトコル処理部903と情報の受け渡しを行う。プロトコル処理部903からの制御データ、ならびにEPC通信部901および他基地局通信部902からのユーザデータおよび制御データは、送信データバッファ部904へ保存される。送信データバッファ部904に保存されたデータは、エンコーダー部905へ渡され、誤り訂正などのエンコード処理が施される。エンコード処理を施さずに、送信データバッファ部904から変調部906へ直接出力されるデータが存在してもよい。エンコードされたデータは、変調部906にて変調処理が行われる。変調されたデータは、ベースバンド信号に変換された後、周波数変換部907へ出力され、無線送信周波数に変換される。その後、アンテナ908より一つもしくは複数の移動端末71に対して送信信号が送信される。また、基地局72の受信処理は以下のとおりに実行される。ひとつもしくは複数の移動端末71からの無線信号が、アンテナ908により受信される。受信信号は、周波数変換部907にて無線受信周波数からベースバンド信号に変換され、復調部909で復調処理が行われる。復調されたデータは、デコーダー部910へ渡され、誤り訂正などのデコード処理が行われる。デコードされたデータのうち、制御データはプロトコル処理部903あるいはEPC通信部901、他基地局通信部902へ渡され、ユーザデータはEPC通信部901および他基地局通信部902へ渡される。基地局72の一連の処理は、制御部911によって制御される。よって制御部911は、図9では省略しているが、各部901~910と接続している。現在3GPPにおいて議論されているHome-eNB72-2の機能を以下に示す非特許文献14.6.2章参照。Home-eNB72-2は、eNB72-1と同じ機能を有する。加えて、HeNBGW74と接続する場合、Home-eNB72-2は、適当なサービングHeNBGW74を発見する機能を有する。Home-eNB72-2は、1つのHeNBGW74に唯一接続する。つまり、HeNBGW74との接続の場合は、Home-eNB72-2は、S1インタフェースにおけるFlex機能を使用しない。Home-eNB72-2は、1つのHeNBGW74に接続されると、同時に別のHeNBGW74や別のMME部73に接続しない。Home-eNB72-2のTACとPLMNIDは、HeNBGW74によってサポートされる。Home-eNB72-2をHeNBGW74に接続すると、UEattachmentでのMME部73の選択は、Home-eNB72-2の代わりに、HeNBGW74によって行われる。Home-eNB72-2は、ネットワーク計画なしで配備される可能性がある。この場合、Home-eNB72-2は、1つの地理的な領域から別の地理的な領域へ移される。したがって、この場合のHome-eNB72-2は、位置によって、異なったHeNBGW74に接続する必要がある。図10は、本発明に係るMMEの構成を示すブロック図である。図10では、前述の図7に示すMME部73に含まれるMME73aの構成を示す。PDNGW通信部1001は、MME73aとPDNGWとの間のデータの送受信を行う。基地局通信部1002は、MME73aと基地局72との間のS1インタフェースによるデータの送受信を行う。PDNGWから受信したデータがユーザデータであった場合、ユーザデータは、PDNGW通信部1001から、ユーザプレイン通信部1003経由で基地局通信部1002に渡され、1つあるいは複数の基地局72へ送信される。基地局72から受信したデータがユーザデータであった場合、ユーザデータは、基地局通信部1002から、ユーザプレイン通信部1003経由でPDNGW通信部1001に渡され、PDNGWへ送信される。PDNGWから受信したデータが制御データであった場合、制御データは、PDNGW通信部1001から制御プレイン制御部1005へ渡される。基地局72から受信したデータが制御データであった場合、制御データは、基地局通信部1002から制御プレイン制御部1005へ渡される。HeNBGW通信部1004は、HeNBGW74が存在する場合に設けられ、情報種別によって、MME73aとHeNBGW74との間のインタフェースIFによるデータの送受信を行う。HeNBGW通信部1004から受信した制御データは、HeNBGW通信部1004から制御プレイン制御部1005へ渡される。制御プレイン制御部1005での処理の結果は、PDNGW通信部1001経由でPDNGWへ送信される。また、制御プレイン制御部1005で処理された結果は、基地局通信部1002経由でS1インタフェースにより1つあるいは複数の基地局72へ送信され、またHeNBGW通信部1004経由で1つあるいは複数のHeNBGW74へ送信される。制御プレイン制御部1005には、NASセキュリティ部1005-1、SAEベアラコントロール部1005-2、アイドルステートIdleStateモビリティ管理部1005―3などが含まれ、制御プレインに対する処理全般を行う。NASセキュリティ部1005―1は、NASNonAccessStratumメッセージのセキュリティなどを行う。SAEベアラコントロール部1005―2は、SAESystemArchitectureEvolutionのベアラの管理などを行う。アイドルステートモビリティ管理部1005―3は、待受け状態LTE-IDLE状態、単にアイドルとも称されるのモビリティ管理、待受け状態時のページング信号の生成および制御、傘下の1つあるいは複数の移動端末71のトラッキングエリアTAの追加、削除、更新、検索、トラッキングエリアリストTAList管理などを行う。MME73aは、UEが登録されているregistered追跡領域トラッキングエリア:TrackingArea:TAに属するセルへ、ページングメッセージを送信することで、ページングプロトコルに着手する。MME73aに接続されるHome-eNB72-2のCSGの管理やCSG-IDの管理、そしてホワイトリスト管理は、アイドルステートモビリティ管理部1005―3で行ってもよい。CSG-IDの管理では、CSG-IDに対応する移動端末とCSGセルとの関係が管理追加、削除、更新、検索される。例えば、あるCSG-IDにユーザアクセス登録された一つまたは複数の移動端末と該CSG-IDに属するCSGセルとの関係であってもよい。ホワイトリスト管理では、移動端末とCSG-IDとの関係が管理追加、削除、更新、検索される。例えば、ホワイトリストには、ある移動端末がユーザ登録した一つまたは複数のCSG-IDが記憶されてもよい。これらのCSGに関する管理は、MME73aの中の他の部分で行われてもよい。MME73aの一連の処理は、制御部1006によって制御される。よって制御部1006は、図10では省略しているが、各部1001~1005と接続している。現在3GPPにおいて議論されているMME73aの機能を以下に示す非特許文献14.6.2章参照。MME73aは、CSGClosedSubscriberGroupsのメンバーの1つ、あるいは複数の移動端末のアクセスコントロールを行う。MME73aは、ページングの最適化Pagingoptimizationの実行をオプションとして認める。図11は、本発明に係るHeNBGWである図7に示すHeNBGW74の構成を示すブロック図である。EPC通信部1101は、HeNBGW74とMME73aとの間のS1インタフェースによるデータの送受信を行う。基地局通信部1102は、HeNBGW74とHome-eNB72-2との間のS1インタフェースによるデータの送受信を行う。ロケーション処理部1103は、EPC通信部1101経由で渡されたMME73aからのデータのうちレジストレーション情報などを、複数のHome-eNB72-2に送信する処理を行う。ロケーション処理部1103で処理されたデータは、基地局通信部1102に渡され、ひとつまたは複数のHome-eNB72-2にS1インタフェースを介して送信される。ロケーション処理部1103での処理を必要とせず通過透過させるだけのデータは、EPC通信部1101から基地局通信部1102に渡され、ひとつまたは複数のHome-eNB72-2にS1インタフェースを介して送信される。HeNBGW74の一連の処理は、制御部1104によって制御される。よって制御部1104は、図11では省略しているが、各部1101~1103と接続している。現在3GPPにおいて議論されているHeNBGW74の機能を以下に示す非特許文献14.6.2章参照。HeNBGW74は、S1アプリケーションについてリレーする。Home-eNB72-2へのMME73aの手順の一部分であるが、HeNBGW74は、移動端末71に関係しないS1アプリケーションについて終端する。HeNBGW74が配置されるとき、移動端末71に無関係な手順がHome-eNB72-2とHeNBGW74との間、そしてHeNBGW74とMME73aとの間を通信される。HeNBGW74と他のノードとの間でX2インタフェースは設定されない。HeNBGW74は、ページングの最適化Pagingoptimizationの実行をオプションとして認める。次に移動体通信システムにおける一般的なセルサーチ方法の一例を示す。図12は、LTE方式の通信システムにおいて移動端末UEが行うセルサーチから待ち受け動作までの概略を示すフローチャートである。移動端末は、セルサーチを開始すると、ステップST1201で、周辺の基地局から送信される第一同期信号P-SS、および第二同期信号S-SSを用いて、スロットタイミング、フレームタイミングの同期をとる。P-SSとS-SSとを合わせて、同期信号SSには、セル毎に割り当てられたPCIPhysicalCellIdentityに1対1に対応するシンクロナイゼーションコードが割り当てられている。PCIの数は現在504通りが検討されており、この504通りのPCIを用いて同期をとるとともに、同期がとれたセルのPCIを検出特定する。次に同期がとれたセルに対して、ステップST1202で、基地局からセル毎に送信される参照信号RScellspecificReferenceSignal:CRSを検出し受信電力RSRPとも称される。の測定を行う。参照信号RSには、PCIと1対1に対応したコードが用いられており、そのコードで相関をとることによって他セルと分離できる。ステップST1201で特定したPCIから、該セルのRS用のコードを導出することによって、RSを検出し、RS受信電力を測定することが可能となる。次にステップST1203で、ステップST1202までで検出されたひとつ以上のセルの中から、RSの受信品質が最もよいセル例えば、RSの受信電力が最も高いセル、つまりベストセルを選択する。次にステップST1204で、ベストセルのPBCHを受信して、報知情報であるBCCHを得る。PBCH上のBCCHには、セル構成情報が含まれるMIBMasterInformationBlockがのる。したがってPBCHを受信してBCCHを得ることで、MIBが得られる。MIBの情報としては、例えば、DLダウンリンクシステム帯域幅送信帯域幅設定transmissionbandwidthconfiguration:dlbandwidthとも呼ばれる、送信アンテナ数、SFNSystemFrameNumberなどがある。次にステップST1205で、MIBのセル構成情報をもとに該セルのDL-SCHを受信して、報知情報BCCHの中のSIBSystemInformationBlock1を得る。SIB1には、該セルへのアクセスに関する情報や、セルセレクションに関する情報、他のSIBSIBk;k≧2の整数のスケジューリング情報が含まれる。また、SIB1には、TACTrackingAreaCodeが含まれる。次にステップST1206で、移動端末は、ステップST1205で受信したSIB1のTACと、移動端末が既に保有しているTATrackingAreaリスト内のTACとを比較する。比較した結果、ステップST1205で受信したTACがTAリスト内に含まれるTACと同じならば、該セルで待ち受け動作に入る。比較して、ステップST1205で受信したTACがTAリスト内に含まれなければ、移動端末は該セルを通してコアネットワークCoreNetwork,EPCMMEなどが含まれるへ、TAUTrackingAreaUpdateを行うためにTAの変更を要求する。コアネットワークは、TAU要求信号とともに移動端末から送られてくる該移動端末の識別番号UE-IDなどをもとに、TAリストの更新を行う。コアネットワークは、移動端末に更新後のTAリストを送信する。移動端末は、受信したTAリストにて移動端末が保有するTACリストを書き換える更新する。その後、移動端末は、該セルで待ち受け動作に入る。LTEやUMTSUniversalMobileTelecommunicationSystemにおいては、CSGClosedSubscriberGroupセルの導入が検討されている。前述したように、CSGセルに登録したひとつまたは複数の移動端末のみにアクセスが許される。CSGセルと登録されたひとつまたは複数の移動端末とがひとつのCSGを構成する。このように構成されたCSGには、CSG-IDと呼ばれる固有の識別番号が付される。なお、ひとつのCSGには、複数のCSGセルがあってもよい。移動端末は、どれかひとつのCSGセルに登録すれば、そのCSGセルが属するCSGの他のCSGセルにはアクセス可能となる。また、LTEでのHome-eNBやUMTSでのHome-NBが、CSGセルとして使われることがある。CSGセルに登録した移動端末は、ホワイトリストを有する。具体的には、ホワイトリストはSIMSubscriberIdentityModule/USIMに記憶される。ホワイトリストには、移動端末が登録したCSGセルのCSG情報が格納される。CSG情報として具体的には、CSG-ID、TAITrackingAreaIdentity、TACなどが考えられる。CSG-IDとTACとが対応付けられていれば、どちらか一方でよい。また、CSG-IDおよびTACと、GCIGlobalCellIdentityとが対応付けられていればGCIでもよい。以上から、ホワイトリストを有しない本発明においては、ホワイトリストが空emptyの場合も含める移動端末は、CSGセルにアクセスすることは不可能であり、non-CSGセルのみにしかアクセスできない。一方、ホワイトリストを有する移動端末は、登録したCSG-IDのCSGセルにも、non-CSGセルにもアクセスすることが可能となる。3GPPでは、全PCIPhysicalCellIdentityを、CSGセル用とnon-CSGセル用とに分割PCIスプリットと称するすることが議論されている非特許文献5参照。またPCIスプリット情報は、システム情報にて基地局から傘下の移動端末に対して報知されることが議論されている。非特許文献5は、PCIスプリットを用いた移動端末の基本動作を開示する。PCIスプリット情報を有していない移動端末は、全PCIを用いて例えば504コード全てを用いてセルサーチを行う必要がある。これに対して、PCIスプリット情報を有する移動端末は、当該PCIスプリット情報を用いてセルサーチを行うことが可能である。また3GPPでは、ハイブリッドセルのためのPCIは、CSGセル用のPCI範囲の中には含まれないことが決定されている非特許文献110.7章参照。3GPPでは、移動端末がCSGセルをセレクション、あるいはリセレクションする方法について2つのモードが存在する。1つ目は、自動Automaticモードである。自動モードの特徴を以下に示す。移動端末内の許可CSGリストAllowedCSGIDListを利用して、セレクション、あるいはリセレクションを行う。PLMNの選択が完了した後、non-CSGセル、あるいは許可CSGリストに存在するCSGIDを伴うCSGセルである場合にのみ、選択している該PLMN中の1つのセルにキャンプオンする。移動端末の許可CSGリストが空であるならば、移動端末は、CSGセルの自立autonomousサーチ機能を停止する非特許文献35.2.4.8.1章参照。2つ目は、手動Manualモードである。手動モードの特徴を以下に示す。移動端末は、現在選択されているPLMNで利用可能なCSGのリストを、ユーザに示す。移動端末がユーザに提供するCSGのリストは、移動端末に保存されている許可CSGリストに含まれるCSGに限られない。ユーザが該CSGのリストに基づいてCSGを選定した後、移動端末は、選択されたCSGIDを伴うセルへキャンプオンし、登録registerを試みる非特許文献35.2.4.8.1章参照。HeNBおよびHNBに対しては、様々なサービスへの対応が求められている。例えば、オペレータは、ある決められたHeNBおよびHNBに移動端末を登録させ、登録した移動端末のみにHeNBおよびHNBのセルへのアクセスを許可することで、該移動端末が使用できる無線リソースを増大させて、高速に通信を行えるようにする。その分、オペレータは、課金料を通常よりも高く設定する、といったサービスである。このようなサービスを実現するため、登録した加入した、メンバーとなった移動端末のみがアクセスできるCSGセルClosedSubscriberGroupcellが導入されている。CSGセルClosedSubscriberGroupcellは、商店街やマンション、学校、会社などへ数多く設置されることが要求される。例えば、商店街では店舗毎、マンションでは部屋毎、学校では教室毎、会社ではセクション毎にCSGセルを設置し、各CSGセルに登録したユーザのみが該CSGセルを使用可能とするような使用方法が要求されている。HeNB/HNBは、マクロセルのカバレッジ外での通信を補完するためだけでなく、上述したような様々なサービスへの対応が求められている。このため、HeNB/HNBがマクロセルのカバレッジ内に設置される場合も生じる。3GPPにおいて、MTC技術の検討が進められている非特許文献8参照。MTCは、従来の人対人HumantoHuman:H2Hの通信と異なり、機械対機械MachinetoMachine:M2Mの通信である。すなわち、ヒューマンインタラクションHumanInteraction、つまり人と人とのやり取りを必要としない。MTC技術を用いたサービス以下MTCサービスというの応用例として、ガス、電力、水道などのメータリングMetering、すなわち計測や、輸送管理および発注管理TrackingTracingなどがある。MTCサービスの特徴として、MTC用のデバイスMTCDevice:MTCDの数が膨大であることがある。一例として、1つのセルの傘下に3万台以上のMTCDが存在することが想定されている。3GPPでは、MTCのアーキテクチャが検討されている3GPPR3-100315以下非特許文献10という参照。図13は、3GPPで検討されているMTCのアーキテクチャの一例を示す図である。LTEの通信システムだけでなく、WCDMAの通信システムでもMTCサービスのサポートが検討されている。図13において、MTCD1301~1304と、NB/eNB1305との間は、インタフェースUu1311~1314で接続されている。SGSN/MMEServingGPRSSupportNodeMobilityManagementEntity1306は、NB/eNB1305とIuPS/S1インタフェース1315で接続されている。図示していないが、NBとSGSNとの間には、無線ネットワーク制御装置RadioNetworkController:RNCが存在している。NBとRNCとの間は、Iubインタフェースで接続され、RNCはIuPSインタフェースを介してSGSNに接続される。HLR/HSSHomeLocationRegisterHomeSubscriberServer1307は、Gr/S6aインタフェース1316を介して、SGSN/MME1306と接続される。通信オペレータ領域1317には、NB/eNB1305、SGSN/MME1306、およびHLR/HSS1307などが含まれる。MTCサーバ1308は、通信オペレータ領域1317に含まれる。MTCサービスを行うMTCユーザ1309は、アプリケーションプログラムインタフェースApplicationProgramInterface:API1310を介して、MTCサーバ1308と接続される。MTCサーバ1308が通信オペレータ領域1317のいずれのノードに接続されるかについては、3GPPにおいて現在検討中である。MTCサービス用の情報は、MTCユーザ1309によって、MTCサーバ1308から、通信オペレータ領域1317のノードであるNB/eNB1305、SGSN/MME1306、HLR/HSS1307を用いて、MTCD1301~1304へ通知される。逆にMTCD1301~1304からの情報は、通信オペレータ領域1317のノードであるNB/eNB1305、SGSN/MME1306、HLR/HSS1307を用いて、MTCサーバ1308へ通知され、MTCユーザ1309によって該情報が利用される。MTCサービスでは、多数のMTCDから、あるいは多数のMTCDへ同時にデータを通信する状況が生じる。このような状況は、例えば、1日1回午前1時に検針データをMTCDからMTCサーバに送信する場合、あるいは検針データを送信することをMTCサーバからMTCDに要求する場合などに生じる。他の例としては、全てのMTCDに対して、一斉にソフトウェアのバージョンアップのためのデータを送信する場合などがある。従来の通信方式では、H2H通信に最適化されているので、多数のMTCDが同時にデータを通信する状況に対する対策は、為されていない。多数のMTCDから、あるいは多数のMTCDへ同時にデータを通信する状況では、無線ネットワークRadioNetwork、コアネットワークCoreNetworkにおいて混雑状態が生じてしまうという問題が発生する。すなわち、これらのネットワークが過負荷状態となってしまうという問題が発生する。例えば、MTCサーバから一斉に多数のMTCDに検針データを送信することを要求するような場合、MTCD1301~1304から、通信オペレータ領域1317のノードであるNB/eNB1305、SGSN/MME1306、HLR/HSS1307を用いて、MTCサーバ1308へ多数のデータが送信される。このような状況では、NB/eNB1305とSGSN/MME1306との間の通信に、過負荷状態が発生する。これによって、通信リソース不足、あるいはNB/eNB1305およびSGSN/MME1306の処理の過負荷状態が発生するという問題が生じる。前記コアネットワークにおける混雑状態の発生という課題に対して、前述の非特許文献9では、以下の解決策が開示されている。eNBが、同じグループのMTCDに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregationことで、シグナリングメッセージをコンパクトにすることが記載されている。具体的には、eNBが、事前に決められた時間、あるいは多くの非アクセスストラタムNonAccessStratum:NASシグナリングメッセージNASSignalingmessagesが到着するまで、MTCDからのNASシグナリングメッセージを引き止める方法が記載されている。しかし、非特許文献9には、eNBの傘下に多くのMTCDグループが存在する場合の課題については示唆されておらず、解決策も開示されていない。また、eNBでMTCDからのシグナリングメッセージを引き止め、寄せ集めた後、コアネットワーク側へ送信する方法についても開示されていない。前記コアネットワークにおける混雑状態の発生という課題に対して、3GPPS2-101008以下非特許文献11というでは、以下の解決策が開示されている。同じMTCDグループ内のMTCDが、MTCDではないUEに対する1つのネットワーク資源を共有することが記載されている。しかし、非特許文献11には、eNBの傘下に多くのMTCDグループが存在する場合の課題については示唆されておらず、解決策も開示されていない。また非特許文献11には、MTCDからMTCサーバへのメッセージに、ソースアドレスとしての移動加入者識別番号InternationalMobileSubscriberIdentity:IMSIとMTCDの番号、セル番号をマッピングすることが開示されている。しかし、同じMTCDグループ内のMTCDが、1つのネットワーク資源を共有する方法については開示されていない。3GPPR2-103269以下非特許文献12というには、MTCDが地下に設置されている場合などは、個々のMTCDとeNBとの間のチャネル品質が悪く、直接の通信は不適切であるという問題が記載されている。このような問題に対して、非特許文献12では、eNBとは別に、eNBとMTCDとの間に集中装置concentratorを設置することが開示されている。しかし、非特許文献12には、集中装置からeNBへ送信する方法については開示されていない。実施の形態1で解決する課題について、以下に説明する。eNBの傘下に多くのMTCDグループが存在する場合においては、前述の非特許文献9に開示された方法、すなわちeNBが、同じMTCDグループのMTCDに共通のシグナリングメッセージを引き止め、寄せ集める方法では、シグナリングメッセージを削減することができない。実施の形態1では、eNBの傘下に多くのMTCDグループが存在する場合でも、多数のMTCDからのデータを通信する状況が生じたときに、コアネットワークの混雑の緩和が可能な通信システムについて開示する。本実施の形態の通信システムは、移動体通信システムである。MTCDグループは、端末装置群に相当する。実施の形態1での解決策を以下に示す。HeNBが、傘下のMTCDからコアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータを集線concentrateする集線処理を行う。HeNBは、傘下のMTCDからコアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータをそのまま送信するのではなく、また中継するのではなく、また経由させるのではなく、集線する。これによって、HeNBの傘下に、属するMTCDグループが異なるMTCDが多く存在する場合であっても、集線処理を行うことが可能となる。したがって、HeNBの傘下に、属するMTCDグループが異なるMTCDが多く存在する状況下であっても、コアネットワークにおける混雑を緩和することができる。また、HeNBがクローズドアクセスモードClosedaccessmode、あるいはハイブリッドアクセスモードHybridaccessmodeで動作する場合、同じCSGに属するMTCDからコアネットワークへのデータを集線するようにしてもよい。これによって、HeNBは、傘下のMTCDのうち、自HeNBと同じCSGへ登録しているMTCDからのデータのみを処理することができ、CSGメンバーのみアクセス可能なセルとして動作するというクローズドアクセスモードの趣旨に沿った処理となる。また、HeNBがハイブリッドアクセスモードで動作する場合、オープンアクセスモードOpenaccessmodeはMTCD以外の移動端末が用い、クローズドアクセスモードはMTCDが用いるようにしてもよい。MTCDは、同じCSGのHeNBへのみアクセスが許されるようにしてもよい。この場合、HeNBは、クローズドアクセスモードでアクセスする通信端末からコアネットワークへのデータを集線するようにしてもよい。HeNBで行う処理は、eNBが行っても同じ効果を得ることができる。以下では、便宜上、HeNBを中心に説明する。HeNBとMTCDとの間の通信方法の具体例として、以下の1,2の2つを開示する。13GPPによって標準規格化された移動体通信システムの通信方法。23GPPによって標準規格化された移動体通信システム以外の通信方法。3GPPによって標準規格化された移動体通信システム以外の通信方法の具体例として、以下の1~5の5つを開示する。1赤外線通信。2同軸ケーブルによる通信。3光ファイバーによる通信。4ブルートゥースBluetooth登録商標による通信。5ジグビーZigBee登録商標による通信。HeNBにおける集線処理の対象である、MTCDからコアネットワークへのデータの具体例について、以下に開示する。まず、集線処理の対象となるデータの内容の具体例として、以下の1,2の2つを開示する。1制御データ。2ユーザデータ。次に、集線処理の対象となるシグナリングの具体例として、以下の1,2の2つを開示する。1NASシグナリング、あるいはNASメッセージ。2RRCシグナリング、あるいはRRCメッセージ。HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、以下の1~3の3つを開示する。以下の説明では、MTCD以外の移動端末UEをノーマルUEと称することもある。1MTCDとノーマルUEとで用いる識別子を別体系とする。例えば、現行のUE-IDとは別にMTCD-IDを新設する。現行のUE-IDをノーマルUE用の識別子とし、MTCD-IDをMTCD用の識別子としてもよい。2MTCDか否かを区別するためのインジケータ以下MTCDインジケータとも称するを新設する。MTCDインジケータの具体例として、以下のa~gの7つを開示する。aMTCDであるか、ノーマルUEであるかを示すインジケータ。bMTCDであるか否かを示すインジケータ。MTCDでない旨を示すインジケータが含まれていれば、HeNBは該UEをノーマルUEと判断する。cノーマルUEであるか否かを示すインジケータ。ノーマルUEでない旨を示すインジケータが含まれていれば、HeNBは該UEをMTCDと判断する。dMTCDである旨を示すインジケータ。MTCDである旨を示すインジケータが含まれていなければ、HeNBは該UEをノーマルUEと判断する。eMTCDでない旨を示すインジケータ。MTCDでない旨を示すインジケータが含まれていなければ、HeNBは該UEをMTCDと判断する。fノーマルUEである旨を示すインジケータ。ノーマルUEである旨を示すインジケータが含まれていなければ、HeNBは該UEをMTCDと判断する。gノーマルUEでない旨を示すインジケータ。ノーマルUEでない旨を示すインジケータが含まれていなければ、HeNBは該UEをノーマルUEと判断する。33GPPによって標準規格化された移動体通信システム以外の通信方法でアクセスしてきたか否かで判断する。3GPPによって標準規格化された移動体通信システム以外の通信方法でアクセスしてきた移動端末は、MTCDと判断する。以上に述べたHeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例のうち、具体例1、具体例2-d、具体例2-g、および具体例3は、現行のUEがノーマルUEであれば、新規に追加するパラメータや処理が不要となる。したがって、具体例1、具体例2-d、具体例2-g、または具体例3を用いることによって、現行のUEの仕様変更を伴わずに課題を解決することができる。UEがMTCDであるか、MTCD以外であるかの区別をHeNBへ通知する方法の具体例として、以下の1,2の2つを開示する。1RRCメッセージ、あるいはRRCシグナリングを用いて、該UEがMTCDであるかMTCD以外であるかの区別をHeNBへ通知する。RRCメッセージ、あるいはRRCシグナリングに前記別体系とした識別子を用いる。またRRCメッセージ、あるいはRRCシグナリングにMTCDインジケータをマッピングする。RRCシグナリングの具体例としては、RRCConnectionRequest非特許文献2参照などがある。後述する具体例2と比較して、本具体例1は、HeNBが集線処理の対象であるコアネットワークへのデータを受信する前に、MTCDであるか否かの判断が可能となる。したがって、HeNBでの集線処理における制御遅延を防止することができる。2集線処理を行うコアネットワークへのデータを用いて、該UEがMTCDであるか、MTCD以外であるかの区別をHeNBへ通知する。コアネットワークへのデータに、前記別体系とした識別子を用いる。またコアネットワークへのデータに、MTCDインジケータをマッピングする。ここで、コアネットワークデータへのヘッダー/フッダーに、前記別体系とした識別子を用いるようにしてもよい。また、コアネットワークデータへのヘッダー/フッダーに、MTCDインジケータをマッピングするようにしてもよい。コアネットワークデータのヘッダー/フッダーを用いて、該UEがMTCDであるかMTCD以外であるかの区別が可能となれば、HeNBがMTCDからコアネットワークへのメッセージの中身を常に解釈しなくてよくなる。したがって、HeNBの処理の負荷を軽減することができる。集線処理の具体例として、以下の1~4の4つを開示する。1NASシグナリング、あるいはNASメッセージを終端し、別途MMEへ通知する。この際、不要なデータを削減してMMEへ通知してもよい。これによって、HeNBからコアネットワークへの通信量が削減でき、コアネットワークの混雑を緩和することができる。2NASシグナリング、あるいはNASメッセージを解釈し、別途MMEへ通知する。この際、不要なデータを削減してMMEへ通知してもよい。これによって、HeNBからコアネットワークへの通信量が削減でき、コアネットワークの混雑を緩和することができる。31つ、あるいは複数のMTCDからのコアネットワークへのデータを、まとめてMMEへ通知する。これによって、HeNBからコアネットワークへの通信回数が削減でき、コアネットワークの混雑を緩和することができる。4前記1~3の組み合わせ。HeNBがNASシグナリングを終端する概念について、図14および図15を用いて説明する。まず、図14を用いて、従来の技術におけるUE-MME間の制御データのプロトコルスタックについて説明する。図14は、従来の技術におけるUE-MME間の制御データのプロトコルスタックを示す図である。UEとHeNBとの間のインタフェースは、LTE-Uu1401として定義されている非特許文献1、3GPPTS23.401V10.0.0以下非特許文献13という参照。HeNBとMMEとの間のインタフェースは、S1-MME1402として定義されている非特許文献13参照。UE、HeNB、MMEに、レイヤ1L1プロトコル1403-1,1403-2,1403-3,1403-4が存在する。UE、HeNBに、MACMediumAccessControlプロトコル1404-1,1404-2が存在する。HeNB、MMEに、レイヤ2L2プロトコル1405-1,1405-2が存在する。UE、HeNBに、RLCRadioLinkControlプロトコル1406-1,1406-2が存在する。HeNB、MMEに、IPInternetProtocol1407-1,1407-2が存在する。UE、HeNBに、PDCPPacketDataConvergenceProtocol1408-1,1408-2が存在する。HeNB、MMEに、SCTPStreamControlTransportProtocolforthecontrolplane1409-1,1409-2が存在する。UE、HeNBに、RRCRadioResourceControlプロトコル1410-1,1410-2が存在する。HeNB、MMEに、S1-APS1ApplicationProtocol1411-1,1411-2が存在する。HeNB内の各プロトコル層において、中継Relay1412が行われる。UE、MMEに、NASNonAccessStratumプロトコル1413-1,1413-2が存在する。NASプロトコルは、移動性管理の機能と、ユーザプレーンベアラの起動、変更、非活性化をサポートする。次に図15を用いて、実施の形態1におけるMTCD-MME間の制御データのプロトコルスタックについて説明する。図15は、実施の形態1におけるMTCD-MME間の制御データのプロトコルスタックを示す図である。図15において、図14に示すプロトコル層に対応する部分については、同一の参照符を付して、共通する説明を省略する。MTCDとHeNBとの間のインタフェースは、LTE-Uu1401として定義されている。MTCDに、レイヤ1L1プロトコル1403-1、MACプロトコル1404-1、RLCプロトコル1406-1、PDCP1408-1、RRCプロトコル1410-1、MTC用NASプロトコル1501-1が存在する。ここで、MTC用NASプロトコルは、MMEまで至っていないが、便宜上NASという文言を用いることとする。HeNB内に、レイヤ1L1プロトコル1403-2、MACプロトコル1404-2、RLCプロトコル1406-2、PDCP1408-2、RRCプロトコル1410-2、MTC用NASプロトコル1501-2が存在する。HeNB内にMTC用NASプロトコル1501-2が存在することによって、HeNBが前述の集線1504を行うことができる。HeNB内の各プロトコル層において、中継1412が行われる。HeNB、MMEに、S1-AP1502-1,1502-2,1502-3が存在する。図15では、HeNB内のS1-APを、S1-AP1502-1とS1-AP1502-3とに分離して記載しているが、HeNB内のS1-APは、1つであってもよい。MMEには、ノーマルUE用NASプロトコル1503が存在する。実施の形態1におけるノーマルUE-MME間の制御データのプロトコルスタックについては、従来の技術と同様であるので、説明を省略する図14参照。但し、MMEにノーマルUE用NASプロトコル1503が存在する図15参照。次に、実施の形態1を用いた具体的な動作例を、図16および図17を用いて説明する。本動作例では、HeNBにおける集線処理の対象である、MTCDからコアネットワークへのデータの具体例として、NASシグナリングの場合について開示する。また、HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestにMTCDインジケータをマッピングする場合について開示する。また、集線処理の具体例として、1つ、あるいは複数のMTCDからのコアネットワークへのデータを、まとめてMMEへ通知する場合について開示する。まず図16を用いて、実施の形態1におけるHeNBの集線処理の具体例について説明する。図16は、実施の形態1における集線処理に関するHeNBの処理手順を示すフローチャートである。ステップST1601において、HeNBは、UEからRRCメッセージRRCConnectionRequestを受信したか否かを判断する。HeNBは、UEからRRCメッセージを受信したと判断した場合は、ステップST1602へ移行する。HeNBは、UEからRRCメッセージを受信していないと判断した場合は、ステップST1601の判断処理を繰り返す。ステップST1602において、HeNBは、ステップST1601で受信したRRCメッセージにマッピングされるMTCDインジケータを確認し、ステップST1603に移行する。ステップST1603において、HeNBは、ステップST1602で確認したMTCDインジケータに基づいて、RRCメッセージをMTCDから受信したか否か、すなわち、ステップST1601で受信したRRCメッセージを送信したUEがMTCDであるか否かを判断する。HeNBは、RRCメッセージをMTCDから受信した、すなわちRRCメッセージを送信したUEがMTCDであると判断した場合は、ステップST1604へ移行する。HeNBは、RRCメッセージをMTCDから受信していない、すなわちRRCメッセージを送信したUEがMTCDではないと判断した場合は、ステップST1605へ移行する。ステップST1604において、HeNBは、MTCDからコアネットワークへのデータを集線処理する。ステップST1604の処理を終了した後は、HeNBは、全ての処理手順を終了する。ステップST1605において、HeNBは、UEからコアネットワークへのデータを集線処理しない。すなわちデータは、HeNB経由で、UEからコアネットワークへ送信される。ステップST1605の処理を終了した後は、HeNBは、全ての処理手順を終了する。次に図17を用いて、実施の形態1における移動体通信システムのシーケンスの具体例について説明する。図17は、実施の形態1における移動体通信システムのシーケンスを示す図である。HeNBの傘下に、m個のノーマルUEとn個のMTCDとが存在するとする。ここで、mおよびnは、それぞれ自然数を示す。m個のノーマルUEを、ノーマルUE_1~ノーマルUE_mで表し、n個のMTCDを、MTCD_1~MTCD_nで表す。ステップST1701において、ノーマルUE_1は、HeNBに、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestを送信する。ステップST1702において、ノーマルUE_mは、HeNBに、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestを送信する。このように本実施の形態では、ノーマルUE_1~ノーマルUE_mのうち、ノーマルUE_1およびノーマルUE_mが、コアネットワークへの送信データが発生したとして、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestをHeNBに送信するものとする。ステップST1703において、MTCD_1は、HeNBに、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestを送信する。ステップST1704において、MTCD_nは、HeNBに、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestを送信する。このように本実施の形態では、MTCD_1~MTCD_nのうち、MTCD_1およびMTCD_nが、コアネットワークへの送信データが発生したとして、MTCDインジケータを含むRRCメッセージであるRRCConnectionRequestをHeNBに送信するものとする。ステップST1705において、HeNBは、受信したRRCConnectionRequestに含まれるMTCDインジケータを確認し、RRCメッセージがMTCDからのデータであるか否かを判断する。HeNBは、MTCDからのデータであると判断した場合は、ステップST1707へ移行する。HeNBは、MTCDからのデータではないと判断した場合は、ステップST1706へ移行する。本動作例においては、ステップST1701はノーマルUE_1からのRRCメッセージの送信処理であるので、ステップST1705では、MTCDからのデータではないと判断され、ステップST1706へ移行する。また、ステップST1702はノーマルUE_mからのRRCメッセージの送信処理であるので、ステップST1705では、MTCDからのデータではないと判断され、ステップST1706へ移行する。また、ステップST1703はMTCD_1からのRRCメッセージの送信処理であるので、ステップST1705では、MTCDからのデータであると判断され、ステップST1707へ移行する。また、ステップST1704はMTCD_nからのRRCメッセージの送信処理であるので、ステップST1705では、MTCDからのデータであると判断され、ステップST1707へ移行する。ステップST1706において、HeNBは、傘下のMTCD以外の移動端末UEであるノーマルUEからコアネットワークへのデータを集線処理しない設定とする。本動作例では、HeNBは、傘下のMTCD以外のUEについて、UEからのNASシグナリングを集線処理しない設定、具体的には、ノーマルUEからコアネットワークへのNASシグナリングを集線処理しない設定とする。ステップST1707において、HeNBは、傘下のMTCDからコアネットワークへのデータを集線処理する設定とする。本動作例では、HeNBは、傘下のUEのうちのMTCDについて、UEからのNASシグナリングを集線処理する設定、具体的には、MTCDからコアネットワークへのNASシグナリングを集線処理する設定とする。ステップST1708において、ノーマルUE_1は、HeNB経由でMMEへ、コアネットワークへのデータであるNASシグナリングを送信する。HeNBは、ステップST1706において、ノーマルUE_1からのNASシグナリングの集線処理を行わない設定になっているので、ノーマルUE_1から送信されたNASシグナリングは、そのままHeNB経由でMMEへ通知される。ステップST1709において、ノーマルUE_mは、HeNB経由でMMEへ、コアネットワークへのデータであるNASシグナリングを送信する。HeNBは、ステップST1706において、ノーマルUE_mからのNASシグナリングの集線処理を行わない設定になっているので、ノーマルUE_mから送信されたNASシグナリングは、そのままHeNB経由でMMEへ通知される。同様に、他のノーマルUEからHeNB経由でMMEへNASシグナリングが送信された場合、他のノーマルUEから送信されたNASシグナリングは、そのままHeNB経由でMMEへ通知される。ステップST1710において、MTCD_1は、MMEへ、コアネットワークへのデータであるNASシグナリングを送信する。HeNBは、ステップST1707において、MTCD_1からのNASシグナリングの集線処理を行う設定になっているので、MTCD_1から送信されたNASシグナリングは、ステップST1712において集線処理が行われる。また、ステップST1712、あるいはステップST1707において、HeNBが通常のRRCConnectionRequestを受信した場合の処理非特許文献2参照を省略してもよい。また、ステップST1712において、HeNBは、RRCConnectionRequestを送信したMTCDに対して、RRCConnectionrejectを通知してもよい。また、RRCConnectionrejectに、MTCDからコアネットワークへのデータを受信した旨を示す情報をマッピングしてもよい。またRRCConnectionrejectに、MTCDからコアネットワークへのデータの再送を要求する情報をマッピングしてもよい。ステップST1711において、MTCD_nは、MMEへ、コアネットワークへのデータであるNASシグナリングを送信する。HeNBは、ステップST1707において、MTCD_nからのNASシグナリングの集線処理を行う設定になっているので、MTCD_nから送信されたNASシグナリングは、ステップST1712において集線処理が行われる。同様に、他のMTCDからMMEへNASシグナリングが送信された場合、他のMTCDから送信されたNASシグナリングは、ステップST1712において集線処理が行われる。ステップST1712において、HeNBは、傘下のMTCDからのコアネットワークへのデータであるNASシグナリングの集線処理を行う。ステップST1713において、HeNBは、MTCD_1、MTCD_nからコアネットワークへのデータであるMMEへのデータをまとめて、MMEに通知する。実施の形態1により、以下の効果を得ることができる。実施の形態1によれば、HeNBが、傘下のMTCDからコアネットワークへのデータを集線する集線処理を行う。このとき、MTCDグループにわたって集線処理を行う。つまり、MTCDグループとは無関係に集線処理を行うので、HeNBの傘下に多くのMTCDグループが存在する場合であっても、HeNBからコアネットワークへの通信回数、あるいはデータ量を削減することができる。これによって、HeNBの傘下に多くのMTCDグループが存在し、多数のMTCDからデータを通信する状況が生じた場合であっても、コアネットワークの混雑を緩和することが可能な移動体通信システムを得ることができる。また、MTCDが3GPPによって標準規格化された移動体通信システムとしての無線環境の悪い場所に設定されている場合であっても、非特許文献12に示す集中装置のように別途エンティティを設ける必要がなく、HeNBが起点となって3GPP網を用いてMTCユーザ、MTCサーバと通信することが可能となる。別途エンティティを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。実施の形態1変形例1.前述の実施の形態1を用いた場合、以下の課題が発生する。集線処理を行うことで、集線処理を行わない場合と比較して、MTCDからコアネットワークへのデータの伝達に遅延が発生する。遅延が発生する具体例を、前述の図17を用いて説明する。集線処理を行わないノーマルUE_1からコアネットワークへのNASシグナリングは、ステップST1708において、そのままHeNB経由でMMEへ通知される。これに対して、集線処理を行うMTCD_1からコアネットワークへのNASシグナリングは、ステップST1712において、HeNB内で集線処理が行われてから、ステップST1713において、別途HeNBからMMEへ通知される。このように、集線処理を行うと、HeNB内で制御遅延が発生する。一般的にMTCDは、遅延に寛容なものが多いと考えられているが、遅延発生に敏感なMTCDも考えられる。具体例としては、地震発生を感知する機能を搭載したMTCDなどである。そのような遅延発生に敏感なMTCDに、前述の実施の形態1を用いることによって遅延が発生することは、MTCDサービス上問題がある。実施の形態1の変形例1での解決策を以下に示す。実施の形態1での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1と同様とする。HeNBは、傘下のMTCDのうち、遅延が許されるMTCDから、コアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータを集線concentrateする。HeNBは、傘下のMTCDのうち、遅延が許されないMTCDから、コアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータは集線しない。HeNBは、傘下のMTCDのうち、優先順位が低いMTCDLowpriorityMTCDから、コアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータを集線concentrateする。HeNBは、傘下のMTCDのうち優先順位が高いMTCDHighpriorityMTCDから、コアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへのデータは集線しない。HeNBが、傘下の移動端末UEが優先順位の低いMTCDであるか否かを区別する方法の具体例を、以下に開示する。優先順位を表すインジケータ以下優先順位インジケータとも称するを新設する。優先順位インジケータの具体例として、以下のa~gの7つを開示する。a優先順位が高いか、低いかを示すインジケータ。b優先順位が低いか否かを示すインジケータ。優先順位が低くないことを示すインジケータが含まれていれば、HeNBは、MTCDを優先順位が高いと判断する。c優先順位が高いか否かを示すインジケータ。優先順位が高くないことを示すインジケータが含まれていれば、HeNBは、MTCDを優先順位が低いと判断する。d優先順位が低いMTCDである旨を示すインジケータ。優先順位が低いMTCDである旨を示すインジケータが含まれていなければ、HeNBは、MTCDを優先順位が高いMTCDであると判断する。e優先順位が低いMTCDでない旨を示すインジケータ。優先順位が低いMTCDでない旨を示すインジケータが含まれていなければ、HeNBは、MTCDを優先順位が低いMTCDであると判断する。f優先順位が高いMTCDである旨を示すインジケータ。優先順位が高いMTCDである旨を示すインジケータが含まれていなければ、HeNBは、MTCDを優先順位が低いMTCDであると判断する。g優先順位が高いMTCDでない旨を示すインジケータ。優先順位が高いMTCDでない旨を示すインジケータが含まれていなければ、HeNBは、MTCDを優先順位が高いMTCDであると判断する。ここで優先順位について低い、あるいは高いと記載したが、優先順位インジケータが2値である必要はない。優先順位が複数あってもよい。優先順位インジケータは、例えば整数で示されてもよい。具体例として、優先順位インジケータが、0、1、2、3と示され、数字が大きいほど優先順位が高いとする。この具体例の場合、優先順位インジケータが0または1のMTCDは、集線処理による制御遅延に寛容であるとして、HeNBは、該MTCDからコアネットワークへのデータを集線concentrateする。これに対し、優先順位インジケータが2または3のMTCDは、集線処理による制御遅延に敏感であるとして、HeNBは、該MTCDからコアネットワークへのデータは集線しない。MTCDが優先順位の低いMTCDであるか否かの区別を、HeNBへ通知する方法の具体例として、以下の1,2の2つを開示する。1RRCメッセージ、あるいはRRCシグナリングを用いて、MTCDが優先順位の低いMTCDであるか、優先順位の高いMTCDであるかの区別をHeNBへ通知する。またRRCメッセージ、あるいはRRCシグナリングに、優先順位インジケータをマッピングする。RRCシグナリングの具体例としては、RRCConnectionRequest非特許文献2参照などがある。後述する具体例2と比較して、本具体例1は、HeNBが、集線処理の対象であるコアネットワークへのデータを受信する前に、MTCDであるか否かの判断が可能となる。したがって、HeNBでの集線処理における制御遅延を防止することができる。2集線処理を行うコアネットワークへのデータを用いて、MTCDが優先順位の低いMTCDであるか、優先順位の高いMTCDであるかの区別をHeNBへ通知する。またコアネットワークへのデータ以下コアネットワークデータという場合があるに、優先順位インジケータをマッピングする。また、コアネットワークデータのヘッダーまたはフッターに、優先順位インジケータをマッピングするようにしてもよい。コアネットワークデータのヘッダーまたはフッターを用いて、UEがMTCDであるか、MTCD以外であるかの区別が可能となれば、HeNBがMTCDからコアネットワークへのメッセージの中身を常に解釈しなくてよくなる。これによって、HeNBの処理の負荷を軽減することができる。次に、実施の形態1の変形例1を用いた具体的な動作例を、図18を用いて説明する。図18は、実施の形態1の変形例1における集線処理に関するHeNBの処理手順を示すフローチャートである。図18において、図16に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBにおける集線処理の対象である、MTCDからコアネットワークへのデータの具体例として、NASシグナリングの場合について開示する。また、HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestにMTCDインジケータをマッピングする場合について開示する。また、HeNBが、傘下のMTCDが優先順の低いMTCDであるか、優先順位の高いMTCDであるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestに優先順位インジケータをマッピングする場合について開示する。HeNBは、前述のステップST1601~ステップST1603の処理を順次行う。本変形例では、HeNBは、ステップST1603において、UEがMTCDであると判断した場合は、ステップST1801へ移行し、UEがMTCDではないと判断した場合は、ステップST1605へ移行する。ステップST1801において、HeNBは、RRCメッセージにマッピングされる優先順位インジケータを確認し、ステップST1802へ移行する。ステップST1802において、HeNBは、ステップST1801で確認した優先順位インジケータに基づいて、RRCメッセージを優先順位が低いMTCDから受信したか否か、すなわち、ステップST1601で受信したRRCメッセージを送信したMTCDが優先順位の低いMTCDであるか否かを判断する。HeNBは、RRCメッセージを優先順位が低いMTCDから受信した、すなわちMTCDが優先順位の低いMTCDであると判断した場合は、ステップST1604へ移行し、前述の処理を行う。HeNBは、RRCメッセージを優先順位が低いMTCDから受信していない、すなわちMTCDが優先順位の低いMTCDではないと判断した場合は、ステップST1605へ移行し、前述の処理を行う。実施の形態1の変形例1における移動体通信システムのシーケンスの具体例については、図17に示すステップST1705とステップST1706との間に、図18に示すステップST1801およびステップST1802が設けられること以外は、図17に示す実施の形態1における移動体通信システムのシーケンスと同様であるので、図示および説明を省略する。実施の形態1の変形例1によって、実施の形態1の効果に加えて、以下の効果を得ることができる。遅延に寛容なMTCDについては、実施の形態1と同様の処理を実行することによって、実施の形態1と同様に、コアネットワークの混雑を緩和することができる。さらに、遅延発生に敏感なMTCDについては、HeNBによる集線処理を行わないようにすることができるので、集線処理による制御遅延の影響を受けないようにすることができる。実施の形態1変形例2.実施の形態1の変形例2では、前述の実施の形態1の開始時期および終了時期について開示する。実施の形態1の変形例2での解決策を以下に示す。実施の形態1での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1と同様とする。コアネットワークであるMME、SGSNなどの指示によって、実施の形態1の処理の実行を開始する。コアネットワークであるMME、SGSNなどの指示によって、実施の形態1の処理の実行を停止する。コアネットワークであるMME、SGSNなどが、HeNBへ実施の形態1の処理以下集線処理とも称するの開始以下集線ONとも称するを指示するきっかけトリガの具体例として、以下の1~3の3つを開示する。1コアネットワークであるMME、SGSNなどのエンティティ、すなわち構成要素が過負荷Overloadとなった場合。2コアネットワークであるMME、SGSNなどの処理負荷が閾値以上となった場合。コアネットワークであるMME、SGSNなどのMTCD関連の処理負荷が閾値以上となった場合としてもよい。3通信量が閾値以上となった場合。MTCD関連の通信量が閾値以上となった場合としてもよい。通信量は、MMEとHeNBとの間の通信量としてもよい。またSGSNとHeNBとの間の通信量としてもよい。コアネットワークが、集線処理の停止以下集線OFFとも称するを指示するきっかけの具体例として、以下の1~3の3つを開示する。1コアネットワークであるMME、SGSNなどのエンティティが過負荷Overloadでなくなった場合。2コアネットワークであるMME、SGSNなどの処理負荷が閾値未満となった場合。コアネットワークであるMME、SGSNなどのMTCD関連の処理負荷が閾値未満となった場合としてもよい。3通信量が閾値未満となった場合。MTCD関連の通信量が閾値未満となった場合としてもよい。通信量は、MMEとHeNBとの間の通信量としてもよい。またSGSNとHeNBとの間の通信量としてもよい。コアネットワークであるMME、SGSNなどが、HeNBへの集線ON、あるいは集線OFFの指示に用いるプロトコルの具体例としては、S1-APなどがある。コアネットワークであるMME、SGSNなどが、HeNBへ集線ONを指示するシグナリングの具体例として、以下の1~4の4つを開示する。1集線ON、あるいは開始、あるいはスタートを示すシグナリングを新設する。2NASメッセージの終端ON、あるいは開始、あるいはスタートを示すシグナリングを新設する。3NASメッセージの解釈ON、あるいは開始、あるいはスタートを示すシグナリング新設する。4既存のS1-APシグナリングであるOverloadStartを用いる3GPPTS36.413V9.3.0以下非特許文献14という参照。現在の規格では、MMEからOverloadStartを受信したeNBは、傘下の移動端末からのRRC接続RRCConnectionなどを拒絶する処理などを行う。これに対し、本実施の形態1の変形例2では、MMEからOverloadStartを受信したeNBは、傘下のMTCDに対して集線処理を行う。具体例4は、具体例1~3と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。また、現在のOverloadStartの規格は、eNB傘下の移動端末からのアクセス自体を拒絶する。これに対し、具体例4は、ノーマルUE以外のUEであるMTCDからのデータを集線処理することによって、通信回数の削減、あるいは通信量の削減を行い、コアネットワーク側の過負荷状態を緩和させる。ノーマルUEからのデータは、通常通りコアネットワーク側へ送信するようにしてもよい。これによって、eNBの傘下の移動端末からのアクセス自体は拒絶されないようにすることができる。したがって、ユーザフレンドリーな移動体通信システムを構築することができる。コアネットワークであるMME、SGSNなどが、HeNBへ集線OFFを指示するシグナリングの具体例として、以下の1~4の4つを開示する。1集線OFF、あるいは停止、あるいはストップを示すシグナリングを新設する。2NASメッセージの終端OFF、あるいは停止、あるいはストップを示すシグナリングを新設する。3NASメッセージの解釈OFF、あるいは停止、あるいはストップを示すシグナリングを新設する。4既存のS1-APシグナリングであるOverloadstopを用いる非特許文献14参照。現在の規格では、MMEからOverloadstopを受信したeNBは、MMEに対して通常の操作を開始する。これに対し、本実施の形態1の変形例2では、MMEからOverloadstopを受信したeNBは、傘下のMTCDに対して集線処理を停止する。具体例4は、具体例1~3と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。また、MMEの過負荷状態が解消した場合には、ノーマルUE以外のUEであるMTCDからのデータについても、遅延が発生し得る集線処理を停止することができる。したがって、ユーザフレンドリーな移動体通信システムを構築することができる。次に、実施の形態1の変形例2を用いた具体的な動作例を、図19を用いて説明する。図19は、実施の形態1の変形例2における移動体通信システムのシーケンスを示す図である。HeNBの傘下に、MTCD_1~MTCD_nが存在するとする。本動作例では、コアネットワークであるMME、SGSNなどが、HeNBへ集線処理の開始を指示するきっかけの具体例として、通信量が閾値以上となった場合について開示する。また、コアネットワークであるMME、SGSNなどが、HeNBへ集線処理の停止を指示するきっかけの具体例として、通信量が閾値未満となった場合について開示する。コアネットワークであるMME、SGSNなどが、HeNBへ集線ONを指示するシグナリングの具体例として、集線ONを示すシグナリングを新設する場合について開示する。また、コアネットワークであるMME、SGSNなどが、HeNBへ集線OFFを指示するシグナリングの具体例として、集線OFFを示すシグナリングを新設する場合について開示する。ステップST1901において、MMEは、MMEとHeNBとの間の通信量が閾値以上となったか否かを判断する。MMEは、前記通信量が閾値以上となったと判断した場合は、ステップST1902へ移行する。MMEは、前記通信量が閾値以上となっていない、すなわち閾値未満であると判断した場合は、ステップST1904へ移行する。ステップST1902において、MMEは、HeNBへ集線ONを示すシグナリングを通知する。ステップST1904において、MMEは、HeNBへ集線OFFを示すシグナリングを通知する。ステップST1906において、HeNBは、集線ONを示すシグナリングを受信したか否かを判断する。集線ONを示すシグナリングを受信したと判断した場合は、ステップST1903へ移行する。集線ONを示すシグナリングを受信していないと判断した場合は、ステップST1905へ移行する。また、図示はしていないが、ステップST1906において集線ONを示すシグナリングを受信していないと判断した後に、HeNBは、集線OFFを示すシグナリングを受信したか否かを判断してもよい。集線OFFを示すシグナリングを受信したと判断した場合に、ステップST1905へ移行するようにしてもよい。集線OFFを示すシグナリングを受信していないと判断した場合は、通常の処理を行うようにしてもよい。ステップST1903において、HeNBは、傘下のMTCDからコアネットワークへのデータに対する集線処理を実行する。また、ステップST1903において、HeNBが通常のRRCConnectionRequestを受信した場合の処理非特許文献2参照を省略してもよい。また、ステップST1903において、HeNBは、RRCConnectionRequestを送信したMTCDに対して、RRCConnectionrejectを通知してもよい。また、RRCConnectionrejectに、MTCDからコアネットワークへのデータを受信した旨を示す情報をマッピングしてもよい。またRRCConnectionrejectに、MTCDからコアネットワークへのデータの再送を要求する情報をマッピングしてもよい。ステップST1905において、HeNBは、傘下のMTCDからコアネットワークへのデータに対する集線処理を実行しない。本変形例では、実施の形態1と組み合わせた例について主に記載したが、実施の形態1の変形例1とも組み合わせて用いることができる。実施の形態1の変形例2によって、実施の形態1の効果に加えて、以下の効果を得ることができる。本実施の形態1の変形例2を用いることによって、コアネットワークの混雑、あるいはコアネットワークのエンティティに過負荷が発生した場合に、コアネットワークの意思によって、HeNBの集線処理を開始することができる。集線処理の開始によって、移動端末へのサービスは継続したまま、コアネットワークの混雑を緩和することができる。また、コアネットワークの混雑が緩和、あるいはコアネットワークのエンティティの過負荷が解消された場合には、コアネットワークの意思によって、HeNBの集線処理を停止することができる。常に、傘下のMTCDからコアネットワークへのデータを集線する方法である実施の形態1と比較して、集線処理の停止によって、集線処理で発生するMTCDサービスへの制御遅延が解消され、ユーザフレンドリーな移動体通信システムを構築することができる。実施の形態1変形例3.前述の実施の形態1の変形例2を用いた場合、以下の課題が発生する。集線処理を行う能力を有するHeNBと、集線処理を行う能力を有していないHeNBとが存在する場合を考える。集線処理を行う能力を有していないHeNBに対して、コアネットワークであるMME、SGSNなどが、実施の形態1の変形例2の処理を実行して、集線処理の開始や停止の指示を通知することは無駄となる。具体的には、コアネットワークからHeNBまでの通信リソースの無駄、およびコアネットワークの処理の無駄が発生する。実施の形態1の変形例3での解決策を以下に示す。実施の形態1および実施の形態1の変形例2での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1および実施の形態1の変形例2と同様とする。HeNBが、MTCDからのデータの集線処理に関する能力情報をコアネットワークであるMME、SGSNなどへ通知する。コアネットワークは、MTCDからのデータの集線処理を行う能力があるHeNBに対して、前述の実施の形態1の変形例2の処理を実行する。HeNBがコアネットワークへ通知する集線処理に関する能力情報の具体例として、以下の1~3の3つを開示する。1MTCDからのデータを集線することができるか否かの情報。あるいは、MTCDからのデータを集線することができる旨の情報。あるいは、MTCDからのデータを集線することができない旨の情報。2NASシグナリングを解釈することができるか否かの情報。あるいは、NASシグナリングを解釈することができる旨の情報。あるいは、NASシグナリングを解釈することができない旨の情報。3NASシグナリングを終端することができるか否かの情報。あるいは、NASシグナリングを終端することができる旨の情報。あるいは、NASシグナリングを終端することができない旨の情報。前記集線処理に関する能力情報の具体例のうち、1のMTCDからのデータを集線することができる旨の情報、2のNASシグナリングを解釈することができる旨の情報、および3のNASシグナリングを終端することができる旨の情報を用いることは、集線処理を行う能力を有していないHeNBが、前記集線処理に関する能力情報をコアネットワークへ通知する必要がない点において有効である。HeNBが、集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、以下の1~3の3つを開示する。1HeNB設置時。HeNBの集線処理を行う能力に変更が生じることがない場合、通信リソースの無駄が発生しないという効果を得ることができる。2周期的。HeNBの集線処理を行う能力に変更が生じる場合に有効である。また、周期的に能力情報が通知されるので、通信エラーに強いという効果を得ることができる。3HeNBの能力変更時。HeNBの集線処理を行う能力に変更が生じる場合に有効である。具体例2と比較して、能力変更時のみの通知であるので、通信リソースの無駄が発生しないという効果を得ることができる。HeNBが、集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例として、以下の1~3の3つを開示する。1新たにS1シグナリング、あるいはS1メッセージを設ける。制御用のS1シグナリングを設けるようにしてもよい。また、受信側であるMME、SGSNなどからの応答メッセージ不要のS1シグナリングを設けるようにしてもよい。応答メッセージ不要のS1シグナリングは、クラス2Class2とも称される非特許文献14参照。また移動端末とは無関係のS1シグナリングを設けるようにしてもよい。移動端末とは無関係のS1シグナリングは、nonUEassociatedSignallingとも称される非特許文献14参照。新たに設けるS1シグナリングにマッピングするパラメータとしては、前記HeNBがコアネットワークへ通知する集線処理に関する能力情報がある。2新たにS1シグナリング、あるいはS1メッセージを設ける。制御用のS1シグナリングを設けるようにしてもよい。また、受信側であるMME、SGSNなどからの応答メッセージが必要なS1シグナリングを設けるようにしてもよい。応答メッセージ必要なS1シグナリングは、クラス1Class1とも称される非特許文献14参照。また移動端末とは無関係のS1シグナリングを設けるようにしてもよい。新たに設けるS1シグナリングにマッピングするパラメータとしては、前記HeNBがコアネットワークへ通知する集線処理に関する能力情報がある。3既存のS1シグナリングを用いる。既存の制御用のS1シグナリングを用いるようにしてもよい。また、既存の移動端末とは無関係のS1シグナリングを用いるようにしてもよい。既存のS1シグナリングに追加が必要なパラメータとしては、前記HeNBがコアネットワークへ通知する集線処理に関する能力情報がある。具体例1,2と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。次に、既存のS1シグナリングの具体例として、以下のa,bの2つを開示する。aS1SETUPREQUEST非特許文献14参照。S1SETUPREQUESTの目的は、eNBとMMEとが、S1インタフェースを正しく共同利用するのに必要なアプリケーションレベルのデータを交換することである。既に含まれているパラメータは、eNBのCSG-ID、グローバルセル識別子およびTACなどのように、eNB固有の情報である。HeNBの集線処理に関する能力情報も、HeNB固有の情報である。したがって、HeNBが集線処理に関する能力情報をコアネットワークへ通知するためにS1SETUPREQUESTを用いることによって、受信するMMEがHeNB固有の情報を一度に得ることができる。これによって、MMEの処理負荷の軽減、また移動体通信システムとしての制御遅延防止という効果を得ることができる。beNBConfigurationUpdate非特許文献14参照。eNBConfigurationUpdateの目的は、eNBとMMEとが、S1インタフェースを正しく共同利用するのに必要なアプリケーションレベルのデータを更新することである。既に含まれているパラメータは、eNBのCSG-IDおよびTACなどのように、eNB固有の情報である。HeNBの集線処理に関する能力情報も、HeNB固有の情報である。したがって、HeNBが集線処理に関する能力情報をコアネットワークへ通知するためにeNBConfigurationUpdateを用いることによって、受信するMMEがHeNB固有の情報を一度に得ることができる。これによって、MMEの処理負荷の軽減、また移動体通信システムとしての制御遅延防止という効果を得ることができる。次に、実施の形態1の変形例3を用いた具体的な動作例を、図20を用いて説明する。図20は、実施の形態1の変形例3における移動体通信システムのシーケンスを示す図である。図20において、図19に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、HeNB設置時について開示する。ステップST2001において、HeNBが設置される。ステップST2002において、HeNBは、MMEへHeNBの集線処理に関する能力情報を通知する。集線処理に関する能力情報を受信したMMEは、該情報を記憶および管理する。ステップST2003において、MMEは、ステップST2002で受信した集線処理に関する能力情報に基づいて、HeNBが集線処理を行う能力があるか否かを判断する。MMEは、HeNBが集線処理を行う能力があると判断した場合は、ステップST1901へ移行する。MMEは、HeNBが集線処理を行う能力がないと判断した場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。ステップST2003でHeNBが集線処理を行う能力があると判断された後は、前述の図19と同様に、MMEおよびHeNBによって、ステップST1901~ステップST1906の各処理が行われる。本変形例では、図20に示すように、ステップST2003の処理後にステップST1901の処理を行うようにしているが、ステップST2003の処理とステップST1901の処理とは任意の順番で行ってもよく、ステップST1901の処理後にステップST2003の処理を行うようにしてもよい。本変形例では、実施の形態1および実施の形態1の変形例2と組み合わせた例について主に記載したが、実施の形態1の変形例1とも組み合わせて用いることができる。実施の形態1の変形例3によって、実施の形態1および実施の形態1の変形例2の効果に加えて、以下の効果を得ることができる。集線処理を行う能力を有していないHeNBに対して、コアネットワークが集線処理の開始や停止の指示を通知することを防止することができる。これによって、コアネットワークからHeNBまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。実施の形態1変形例4.本実施の形態1の変形例4では、実施の形態1の変形例3と同じ課題について別の解決策を開示する。実施の形態1の変形例4での解決策を以下に示す。実施の形態1および実施の形態1の変形例2での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1および実施の形態1の変形例2と同様とする。実施の形態1の変形例4では、集線処理を行う能力を有するHeNBに対しても、集線処理を行う能力を有していないHeNBに対しても、コアネットワークであるMME、SGSNなどは、前述の実施の形態1の変形例2の処理を実行する。集線処理の開始や停止の指示を受信したHeNBにおいて、集線処理を行う能力を有するか否かで動作を異ならせる。集線処理を行う能力を有するHeNBの動作の具体例としては、実施の形態1、実施の形態1の変形例1、および実施の形態1の変形例2がある。集線処理を行う能力を有していないHeNBの動作の具体例を、以下に開示する。まず、コアネットワークであるMME、SGSNなどから集線処理の開始指示を受信したHeNBの動作の具体例として、以下の1~4の4つを開示する。1傘下の移動端末からコアネットワークであるMME、SGSNなどへのデータの送受信を停止、あるいは拒否する。MMEへのデータの具体例として、NASメッセージ、NASシグナリングがある。2傘下の移動端末からのRRC接続関連のシグナリングを拒否する。RRC接続関連のシグナリングの具体例として、RRCCONNECTIONREQUEST、RRCCONNECTIONReestablishmentRequest非特許文献2参照などがある。3現行のMMEからOverloadStartを受信したときの動作を行う非特許文献14参照。具体的には、緊急emergency呼以外のRRC接続設立を拒絶する。4前記1~3の組み合わせ。コアネットワークであるMME、SGSNなどから集線処理の停止指示を受信したHeNBの動作の具体例としては、通常の動作を行うことが挙げられる。次に、実施の形態1の変形例4を用いた具体的な動作例を、図21を用いて説明する。図21は、実施の形態1の変形例4における移動体通信システムのシーケンスを示す図である。図21において、図19に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、コアネットワークがHeNBへ集線ONを指示するシグナリングの具体例として、既存のS1-APシグナリングであるOverloadStartを用いる場合について開示する。また、コアネットワークがHeNBへ集線OFFを指示するシグナリングの具体例として、既存のS1-APシグナリングであるOverloadstopを用いる場合について開示する。また、集線処理を行う能力を有していないHeNBが、コアネットワークから集線処理の開始指示を受信した場合の動作例として、現行のOverloadStartを受信したときの動作を行う場合について開示する。ステップST1901において、MMEは、MMEとHeNBとの間の通信量が閾値以上となったか否かを判断する。MMEは、前記通信量が閾値以上となったと判断した場合は、ステップST2101へ移行する。MMEは、前記通信量が閾値以上となっていない、すなわち閾値未満であると判断した場合は、ステップST2104へ移行する。ステップST2101において、MMEは、HeNBへOverloadStartを通知する。ステップST2104において、MMEは、HeNBへOverloadStopを通知する。ステップST2107において、HeNBは、OverloadStartを受信したか否かを判断する。OverloadStartを受信したと判断した場合は、ステップST2102へ移行する。OverloadStartを受信していないと判断した場合は、ステップST2105へ移行する。図示はしていないが、ステップST2107において、OverloadStartを受信していないと判断した後に、HeNBは、OverloadStopを受信したか否かを判断してもよい。そして、OverloadStopを受信したと判断した場合に、ステップST2105へ移行し、OverloadStopを受信していないと判断した場合は、ステップST2106へ移行するようにしてもよい。ステップST2102において、HeNBは、自セルが集線処理を行う能力を有するか否かを判断する。HeNBは、集線処理を行う能力を有すると判断した場合は、ステップST1903へ移行する。HeNBは、集線処理を行う能力を有していないと判断した場合は、ステップST2103へ移行する。ステップST1903において、HeNBは、傘下のMTCDからコアネットワークへのデータに対する集線処理を実行して、処理を終了する。ステップST2103において、HeNBは、傘下の移動端末からの緊急emergency呼以外のRRC接続設立を拒絶して、処理を終了する。ステップST2105において、HeNBは、自セルが集線処理を行う能力を有するか否かを判断する。HeNBは、集線処理を行う能力を有すると判断した場合は、ステップST1905へ移行する。HeNBは、集線処理を行う能力を有していないと判断した場合は、ステップST2106へ移行する。ステップST1905において、HeNBは、傘下のMTCDからコアネットワークへのデータに対する集線処理を実行しない。ステップST2106において、HeNBは、通常動作を行う。ステップST2105の判断処理を省略して、集線処理を行う能力の有無とは無関係に、ステップST2104においてMMEからOverloadStopを受信したHeNBが、ステップST2106へ移行して通常動作を行うようにしてもよい。本変形例では、実施の形態1および実施の形態1の変形例2と組み合わせた例について主に記載したが、実施の形態1の変形例1とも組み合わせて用いることができる。実施の形態1の変形例4によって、実施の形態1および実施の形態1の変形例2の効果に加えて、以下の効果を得ることができる。実施の形態1の変形例3と比較して、HeNBが自セルの集線処理に関する能力情報をコアネットワークへ通知する必要がなくなり、HeNBとコアネットワークとの間の通信リソースを有効に活用することができる。またコアネットワークが、傘下のHeNBの集線処理に行う能力の有無を記憶し、集線処理に関する能力の有無によって動作を分ける必要がなくなり図20のステップST2003参照、コアネットワークの処理の負荷を軽減することができる。また、コアネットワークの混雑が発生し、コアネットワークがHeNBへ集線ONを指示するシグナリングを通知した場合、HeNBが集線処理を行う能力を有するか否かに関わらず、HeNBとコアネットワークとの間の通信、あるいはコアネットワークの処理負荷の軽減につながる動作が開始される図21のステップST2103、ステップST1903参照。したがって、HeNBが集線処理を行う能力を有するか否かに関わらず、コアネットワークの混雑を回避することが可能となる。実施の形態2.本実施の形態2では、実施の形態1を用いてHeNBによって集線処理を行った後、HeNBからコアネットワークであるMME、SGSNなどへデータを送信する具体的な方法について開示する。実施の形態2での解決策を以下に示す。HeNBがきっかけtriggerあるいは起点となって、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータを送信する。HeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータの送信のトリガとなる条件の具体例として、以下の1,2の2つを開示する。1HeNBが、傘下のMTCDからの上りデータの受信とは無関係に、傘下のMTCDからのデータをコアネットワークへ送信する。該送信は、MTCD用リソースで行うようにしてもよい。MTCD用リソースの具体例としては、MTCD用の通信が許可された時間、あるいは許可された期間、あるいは許可されたリソースなどがある。MTCD用の通信が許可された時間または期間は、許可期間に相当する。MTCD用の通信が許可されたリソースは、許可リソースに相当する。MTCD用リソースの設定は、コアネットワークであるMME、SGSN、MTCサーバなどがHeNBへ設定、あるいは更新してもよいし、静的に決定、すなわち予め決定されていてもよい。前述の非特許文献9では、eNBがMTCDからのメッセージを受信した時点から、決められた時間だけメッセージを保留する。これに対し、本具体例では、HeNBがMTCDからのメッセージを受信した時点と無関係に、MTCD用の通信が許可された時間などに、コアネットワークへ送信を行う。したがって本具体例では、コアネットワーク側が、HeNBからMTCD用の送信が行われる可能性のある時間を把握することが可能となる。非特許文献9では、コアネットワーク側で、eNBがMTCDからメッセージを受信する時点を把握することが不可能であるので、MTCDからメッセージを受信した時点を基準として、eNBからMTCD用の送信が行われる可能性のある時間を把握することは不可能である。したがって、非特許文献9と比較して、本具体例では、コアネットワークがMTCDによる負荷の調整を容易に行うことができる。また、3GPPTR23.888V0.5.1以下非特許文献15というでは、ネットワークオペレータがMTCDに対して、予め定義された期間periodのみネットワークにアクセスすることを許可することが開示されている。これに対し、本具体例では、MTCDに対してネットワークへアクセスすることを許可する期間の設定を必要としない。したがって、コアネットワークから、多数存在するMTCDへの許可期間の通知、あるいは設定が不要となるので、無線リソースを有効に活用することができる。さらに、本具体例では、コアネットワークの各MTCDの時間管理、あるいはコアネットワークとMTCDとの同期確立が不要となるので、通信システムが複雑化することを回避することができる。2HeNBが、傘下のMTCDからの上りデータの受信をきっかけに、傘下のMTCDからのデータをコアネットワークであるMME、SGSN、MTCサーバなどへ送信する。MTCDからの上りデータの具体例として、以下のa,bの2つを開示する。aRRCメッセージ、RRCシグナリングの受信。非特許文献9では、eNBがNASシグナリングの受信をきっかけに、MTCDからのデータをコアネットワークへ送信することが開示されている。本具体例では、RRCシグナリングの受信をきっかけにして、MTCDからのデータをコアネットワークへ送信する。これによって、非特許文献9と比較して、早い段階で集線処理の準備を行うことが可能となる。RRCメッセージを受信した時点から、予め決められた時間の経過後、あるいはコアネットワークから設定された時間の経過後に、傘下のMTCDからのデータをコアネットワークへ送信するようにしてもよい。あるいは、予め決められた回数、傘下のMTCDからのRRCメッセージを受信した場合に、傘下のMTCDからのデータをコアネットワークへ送信するようにしてもよい。b3GPPによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータの受信。本具体例によって、MTCDが、3GPPで標準規格化された移動体通信システムとしての無線環境の悪い場所に設定されている場合であっても、前記の具体例2のように、HeNBが傘下のMTCDからの上りデータの受信をきっかけとして、傘下のMTCDからのデータをコアネットワークへ送信することが可能となる。3GPPによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータを受信した時点から、予め決められた時間の経過後に、あるいはコアネットワークから設定された時間の経過後に、傘下のMTCDからのデータをコアネットワークへ送信するようにしてもよい。あるいは、予め決められた回数、傘下のMTCDから3GPPによって標準規格化された移動体通信システム以外の通信方式で送信された上りデータを受信した場合に、傘下のMTCDからのデータをコアネットワークへ送信するようにしてもよい。HeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをS-GW経由で送信する際のシグナリングの具体例を、以下に開示する。ユーザデータグラムプロトコルUserDatagramProtocol:UDPを用いて送信する非特許文献13参照。該データはユーザデータであってもよい。HeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由で送信する際のシグナリングの具体例を、以下に開示する。S1インタフェースS1-MMEあるいはS1-Uとも称されるを用いる。該データは制御データであってもよい。S1インタフェースを用いて、傘下のMTCDからコアネットワークへのデータを送信する際の更なる具体例を、以下に開示する。新たにS1シグナリング、あるいはS1メッセージを設ける。制御用のS1シグナリングを設けるようにしてもよい。また、受信側であるMME、SGSNなどからの応答メッセージ不要のS1シグナリングを設けるようにしても良い。応答メッセージ不要のS1シグナリングは、クラス2Class2とも称される非特許文献14参照。また移動端末とは無関係のS1シグナリングを設けるようにしてもよい。移動端末とは無関係のS1シグナリングは、nonUEassociatedSignalingとも称される非特許文献14参照。新たに設けるS1シグナリングにマッピングするパラメータの具体例として、以下の1~8の8つを開示する。1HeNBの識別子。受信側で、どのHeNB経由のデータであるかを識別可能となるので、PCIPhysicalCellIdentity、CGICellGlobalIdentityなどであってもよい。2MTCDの識別子。受信側で、どのMTCDからのデータであるかを識別可能となるので、IMSI、MTCDの製造番号などであってもよい。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。3MTC用のPDUProtocolDataUnit。PDUとは、同位レイヤ間で意味を持つデータの固まりである。これによって、新たに設けるS1シグナリングに、MTCDからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。4MTC用のSDUServiceDataUnit。SDUとは、上位レイヤから転送依頼されたデータの固まりである。これによって、新たに設けるS1シグナリングに、MTCDからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。5サービスの種類、あるいはサービスの識別子。これによってサービス別にデータの送信先が異なる場合などに対応することができる。また、1つのMTCDで複数のサービスに対応する場合であっても、サービス別にデータの送信先が異なる場合などに対応することができる。6どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。具体例としては、MTCサーバの識別子、あるいはMTCユーザの識別子。これによって、送信先を適切に変更することができる。7前記5と前記6との組み合わせを示す識別子、あるいはインデックス。8前記1~7の組み合わせ。次に、実施の形態2を用いた具体的な動作例を、図22を用いて説明する。図22は、実施の形態2における移動体通信システムのシーケンスを示す図である。図22において、図17および図19に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBが、傘下のMTCDからコアネットワークへのデータの送信のトリガとなる条件の具体例として、HeNBが、傘下のMTCDからの上りデータの受信とは無関係に、傘下のMTCDからのデータをコアネットワークへ送信する場合について開示する。またコアネットワークへの送信は、MTCD用の通信が許可された期間において行われる場合について開示する。ステップST2201において、MMEは、HeNBが傘下のMTCDからのデータをコアネットワークへ送信することが許可された期間を表す期間情報をHeNBへ通知する。換言すれば、MMEは、MTCD用の通信を許可する期間を表す期間情報をHeNBへ通知する。次に、MTCD_1が前述のステップST1703の処理を行い、MTCD_nが前述のステップST1704の処理を行う。MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、前述のステップST1705およびステップST1903の処理を行う。ステップST1903の処理を終了した後は、ステップST2202へ移行する。ステップST2202において、HeNBは、ステップST2201で受信した期間情報に基づいて、MTCD用の通信が許可された期間であるか否かを判断する。HeNBは、MTCD用の通信が許可された期間であると判断した場合は、ステップST2203へ移行する。HeNBは、MTCD用の通信が許可された期間でないと判断した場合は、ステップST2202の判断処理を繰り返す。ステップST2203において、HeNBは、傘下のMTCDからコアネットワークへのデータを、S1インタフェースを用いてMMEへ送信する。本動作例では、実際には、ステップST1703の処理の後に、ステップST1705、ステップST1903およびステップST2202に相当する処理が行われるが、理解を容易にするために、図示および説明を省略している。また、ステップST1705において、MTCDからのデータではないと判断された場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。あるいは、ステップST1705において、MTCDからのデータではないと判断された場合は、ステップST2202と同様の処理を行い、MTCD用の通信が許可された期間に、MTCDからのデータは無いことを示してもよい。例えば、emptyを通知してもよい。これによって、MMEが、MTCD用の通信が許可された期間に何らかのデータを受信することになり、HeNBとMMEとの間の通信エラーを低減することができる。また、ステップST2202の判断処理を繰り返している間、HeNBが別途、傘下のMTCDからRRCメッセージを受信し、ステップST1705、ステップST1903およびステップST2202に相当する処理が行われることも考えられるが、理解を容易にするために、説明を省略している。次に、実施の形態2を用いた具体的な動作例を、図23を用いて説明する。図23は、実施の形態2における移動体通信システムのシーケンスを示す図である。図23において、図17および図22に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBが、傘下のMTCDからコアネットワークへのデータの送信のトリガとなる条件の具体例として、HeNBが、傘下のMTCDからの上りデータの受信をきっかけに、傘下のMTCDからのデータをコアネットワークへ送信する場合について開示する。また上りデータの具体例としては、RRCシグナリングである場合について開示する。ステップST2301において、MMEは、RRCメッセージを受信したときから、MTCDからのデータをコアネットワークへ送信するまでの時間をHeNBに設定する。換言すれば、MMEは、RRCメッセージを受信してから集線処理するまでの時間である集線処理時間をHeNBに設定する。次に、ステップST1703において、MTCD_1がRRCConnectionRequestをHeNBに送信する処理を行い、ステップST1704において、MTCD_nがRRCConnectionRequestをHeNBに送信する処理を行う。MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、前述のステップST1705およびステップST1903の処理を行う。ステップST1903の処理を終了した後は、HeNBは、ステップST2302へ移行する。ステップST2302において、HeNBは、RRCメッセージの受信から、ステップST2301で設定された集線処理時間が経過したか否かを判断する。HeNBは、集線処理時間が経過したと判断した場合は、ステップST2203へ移行する。HeNBは、集線処理時間が経過していないと判断した場合、ステップST2302の判断処理を繰り返す。本動作例では、HeNBは、ステップST2302において、集線処理時間が経過したか否かを判断する処理を行うが、前回、傘下のMTCDからコアネットワークへのデータを送信してから最初に受信したRRCメッセージの受信から、集線処理時間が経過したか否かを判断する処理を行うようにしてもよい。本動作例では、実際には、ステップST1703の処理の後に、ステップST1705、ステップST1903およびステップST2302に相当する処理が行われるが、理解を容易にするために、説明を省略している。また、ステップST1705において、MTCDからのデータではないと判断された場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。あるいは、ステップST1705において、MTCDからのデータではないと判断された場合は、ステップST2202と同様の処理を行い、MTCD用の通信が許可された期間に、MTCDからのデータは無いことを示してもよい。例えば、emptyを通知してもよい。これによって、MMEが、MTCD用の通信が許可された期間に何らかのデータを受信することになり、HeNBとMMEとの間の通信エラーを低減することができる。また、ステップST2302の判断処理を繰り返している間、HeNBが別途、傘下のMTCDからRRCメッセージを受信し、ステップST1705、ステップST1903およびステップST2302に相当する処理が行われることも考えられるが、理解を容易にするために、説明を省略している。本実施の形態では、実施の形態1と組み合わせた例について主に記載したが、本実施の形態は、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態1の変形例4とも組み合わせて用いることができる。また、本実施の形態は、非特許文献9に開示されているeNBがMTCDグループに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregation際にも用いることができる。実施の形態2によって、以下の効果を得ることができる。HeNBが、傘下のMTCDからコアネットワークへのデータを集線処理した後、HeNBからコアネットワークへデータを送信する方法を確立することができる。実施の形態2変形例1.実施の形態2の変形例1では、実施の形態2におけるHeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由でS1インタフェースを用いて送信する際の他の具体例を開示する。新たにS1シグナリング、あるいはS1メッセージを設ける。制御用のS1シグナリングを設けるようにしてもよい。また、受信側であるMME、SGSNなどからの応答メッセージが必要なS1シグナリングを設けるようにしてもよい。応答メッセージが必要なS1シグナリングは、クラス1Class1とも称される非特許文献14参照。HeNBが、MMEからの応答メッセージにおいて、成功を示すメッセージ、たとえばSuccessfulメッセージあるいはAckメッセージを受信した場合、次のデータの送信を行うようにしてもよい。HeNBが、MMEからの応答メッセージにおいて、失敗を示すメッセージ、たとえばUnsuccessfulメッセージ、failureメッセージあるいはNackメッセージを受信した場合、再送を行うようにしてもよい。また、移動端末とは無関係のS1シグナリングを設けるようにしてもよい。移動端末とは無関係のS1シグナリングは、nonUEassociatedSignalingとも称される非特許文献14参照。新たに設けるS1シグナリングにマッピングするパラメータの具体例は、前述の実施の形態2と同様であるので、説明を省略する。次に、実施の形態2の変形例1を用いた具体的な動作例を、図24を用いて説明する。図24は、実施の形態2の変形例1における移動体通信システムのシーケンスを示す図である。図24において、図17および図22に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBが、傘下のMTCDからコアネットワークへの送信のトリガとなる条件の具体例として、HeNBが、傘下のMTCDからの上りデータの受信とは無関係に、傘下のMTCDからのデータをコアネットワークへ送信する場合について開示する。またコアネットワークへの送信は、MTCD用の通信が許可された期間において行われる場合について開示する。MMEが前述のステップST2201の処理を行う。次に、ステップST1703において、MTCD_1がRRCConnectionRequestをHeNBに送信する処理を行い、ステップST1704において、MTCD_nがRRCConnectionRequestをHeNBに送信する処理を行う。MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、前述のステップST1705およびステップST1903の処理を行う。ステップST1903の処理を終了した後は、HeNBは、前述のステップST2202およびステップST2203の処理を行う。次に、ステップST2401において、ステップST2203でHeNBからクラス1のS1インタフェースを用いたシグナリングによって傘下のMTCDからコアネットワークへのデータを受信したMMEは、受信したデータのメッセージに対する応答メッセージをHeNBへ送信する。次に、ステップST2402において、HeNBは、成功を示すメッセージ、たとえばAckメッセージを受信したか否かを判断する。具体的には、HeNBは、ステップST2401で受信した応答メッセージが成功を示すメッセージであるか否か、たとえばAckメッセージであるか否かを判断する。HeNBは、応答メッセージが成功を示すメッセージであると判断した場合、たとえばAckメッセージであると判断した場合は、ステップST2404へ移行する。HeNBは、応答メッセージが成功を示すメッセージでないと判断した場合、すなわち、失敗を示すメッセージ、たとえばNackメッセージであると判断した場合は、ステップST2403へ移行する。ステップST2403において、HeNBは、ステップST2203で送信した傘下のMTCDからコアネットワークへのデータをMMEへ再送し、ステップST2402へ戻って判断処理を繰り返す。ステップST2404において、HeNBは、傘下のMTCDからコアネットワークへの次のデータを、S1インタフェースを用いてMMEへ送信する。本変形例では、実施の形態1と組み合わせた例について主に記載したが、本変形例は、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態1の変形例4とも組み合わせて用いることができる。また、本変形例は、非特許文献9に開示されているeNBがMTCDグループに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregation際にも用いることができる。実施の形態2の変形例1によって、以下の効果を得ることができる。HeNBが、傘下のMTCDからコアネットワークへのデータを集線処理した後、HeNBからコアネットワークへデータを送信する方法を確立することができる。実施の形態2変形例2.実施の形態2の変形例2では、実施の形態2におけるHeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由でS1インタフェースを用いて送信する際の他の具体例を開示する。既存のS1シグナリング、あるいはS1メッセージを用いる。既存の制御用のS1シグナリングを用いるようにしてもよい。また、既存の移動端末とは無関係のS1シグナリングを用いるようにしてもよい。HeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由でS1インタフェースを用いて送信する際に、既存のS1シグナリングに必要なパラメータの具体例として、以下の1~5の5つを開示する。1HeNBの識別子。2MTCDの識別子。集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。3MTC用のPDU、あるいはSDU。集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。4サービスの種類、あるいはサービスの識別子。5どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。次に、既存のS1シグナリングの具体例として、以下のa,bの2つを開示する。aS1SETUPREQUEST非特許文献14参照。S1SETUPREQUESTにマッピングされるパラメータには、前述の既存のS1シグナリングに必要なパラメータの具体例1のHeNBの識別子であるGlobaleNBIDが既に含まれる。したがって、S1SETUPREQUESTに新たに追加が必要なパラメータは、前述の具体例2のMTCDの識別子、前述の具体例3のMTC用のPDUあるいはSDU、前述の具体例4のサービスの種類、あるいはサービスの識別子、および前述の具体例5のどのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報である。MTCDの識別子は、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。MTC用のPDUあるいはSDUは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。S1SETUPREQUESTに対するMMEからの成功を示す応答メッセージであるS1SETUPRESPONSE中に、MTCDからのデータを正常に受信した旨を示すパラメータを追加してもよい。正常に受信した旨を示すパラメータを含むS1SETUPRESPONSEを受信したHeNBは、次のMTCDからのデータを送信するようにしてもよい。あるいは、正常に受信した旨を示すパラメータを新設せず、S1SETUPRESPONSEを受信したHeNBは、次のMTCDからのデータを送信するようにしてもよい。S1SETUPREQUESTに対するMMEからの失敗を示す応答メッセージであるS1SETUPFAILURE中に、MTCDからのデータを正常に受信できなかった旨を示すパラメータを追加してもよい。正常に受信できなかった旨を示すパラメータを含むS1SETPUPFAILUREを受信したHeNBは、同じMTCDからのデータを再送するようにしてもよい。あるいは、正常に受信できなかった旨を示すパラメータを新設せず、S1SETUPFAILUREを受信したHeNBは、同じMTCDからのデータを再送するようにしてもよい。beNBConfigurationUpdate非特許文献14参照。eNBConfigurationUpdateにマッピングされるパラメータには、前述の既存のS1シグナリングに必要なパラメータの具体例1のHeNBの識別子であるeNBNameが既に含まれる。したがって、S1SETUPREQUESTに新たに追加が必要なパラメータは、前述の具体例2のMTCDの識別子、前述の具体例3のMTC用のPDUあるいはSDU、前述の具体例4のサービスの種類、あるいはサービスの識別子、および前述の具体例5のどのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報である。MTCDの識別子は、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。MTC用のPDUあるいはSDUは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。eNBConfigurationUpdateに対するMMEからの成功を示す応答メッセージであるeNBConfigurationUpdateAcknowledge中に、MTCDからのデータを正常に受信した旨を示すパラメータを追加してもよい。正常に受信した旨を示すパラメータを含むeNBConfigurationUpdateAcknowledgeを受信したHeNBは、次のMTCDからのデータを送信するようにしてもよい。あるいは、正常に受信した旨を示すパラメータを新設せず、eNBConfigurationUpdateAcknowledgeを受信したHeNBは、次のMTCDからのデータを送信するようにしてもよい。eNBConfigurationUpdateに対するMMEからの失敗を示す応答メッセージであるeNBConfigurationUpdateFAILURE中に、MTCDからのデータを正常に受信できなかった旨を示すパラメータを追加してもよい。正常に受信できなかった旨を示すパラメータを含むeNBConfigurationUpdateFAILUREを受信したHeNBは、同じMTCDからのデータを再送するようにしてもよい。あるいは、正常に受信できなかった旨を示すパラメータを新設せず、eNBConfigurationUpdateFAILUREを受信したHeNBは、同じMTCDからのデータを再送するようにしてもよい。本変形例では、実施の形態1と組み合わせた例について主に記載したが、本変形例は、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態1の変形例4とも組み合わせて用いることができる。また、本変形例は、非特許文献9に開示されているeNBがMTCDグループに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregation際にも用いることができる。実施の形態2の変形例2によって、実施の形態2の効果に加えて、以下の効果を得ることができる。実施の形態2および実施の形態2の変形例1と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。実施の形態2変形例3.実施の形態2の変形例3では、実施の形態2におけるHeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由でS1インタフェースを用いて送信する際の他の具体例を開示する。既存のS1シグナリング、あるいはS1メッセージを用いる。既存の制御用のS1シグナリングを用いるようにしてもよい。また、既存の移動端末と関係があるS1シグナリングを用いるようにしてもよい。既存の移動端末と関係があるS1シグナリングは、UEassociatedSignallingとも称される非特許文献14参照。HeNBが、傘下のMTCDからコアネットワークであるMME、SGSN、MTCサーバなどへのデータをMME経由でS1インタフェースを用いて送信する際に、既存のS1シグナリングに必要なパラメータの具体例として、以下の1~9の9つを開示する。1HeNBの識別子。受信側で、どのHeNB経由のデータであるかを識別可能となるので、PCIPhysicalCellIdentity、CGICellGlobalIdentityなどであってもよい。2MTCDの識別子。受信側で、どのMTCDからのデータであるかを識別可能となるので、IMSI、MTCDの製造番号などであってもよい。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。3MTC用のPDU。PDUとは、同位レイヤ間で意味を持つデータの固まりである。PDUを用いることによって、新たに設けるS1シグナリングに、MTCDからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。4MTC用のSDU。SDUとは、上位レイヤから転送依頼されたデータの固まりである。SDUを用いることによって、新たに設けるS1シグナリングに、MTCDからコアネットワークへのデータをマッピングすることが可能となる。本パラメータは、集線処理を行うMTCDの数だけ、すなわち集線処理を行うMTCDの数と同数あってもよい。5S1シグナリングが、MTC用であることを示すインジケータ。あるいは、S1シグナリングが、ノーマルUEとは無関係であることを示すインジケータ。本パラメータが存在することで、HeNBが、傘下のMTCDからコアネットワークへのデータ送信用に、S1シグナリングを用いているか否かを判断することが可能となる。これによって、MTCDからコアネットワークへのデータ送信時には、S1シグナリング中のノーマルUEに関するパラメータを含めなくてもよい、あるいはノーマルUEに関するパラメータは無意味な情報であることを示すなどの動作が可能となる。6サービスの種類、あるいはサービスの識別子。これによって、サービス別にデータの送信先が異なる場合などに対応することができる。また、1つのMTCDで複数のサービスに対応する場合であっても、サービス別にデータの送信先が異なる場合などに対応することができる。7どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。具体例としては、MTCサーバの識別子、あるいはMTCユーザの識別子。これによって、送信先を適切に変更することができる。8前記6と前記7との組み合わせを示す識別子、あるいはインデックス。9前記1~8の組み合わせ。次に、既存のS1シグナリングの具体例として、以下のa,bの2つを開示する。aInitialUEMessage非特許文献14参照。現行の規格では、eNBは、上りNASメッセージを受信したとき、NASのPDUを含むInitialUEMessageを用いて、MMEへ該メッセージを送信する。したがってHeNBが、傘下のMTCDからコアネットワークへのデータをMMEへInitialUEMessageを用いて送信することは、同様の目的で現行の規格と同様のS1シグナリングを用いることができることになる。これによって、移動体通信システムが複雑化することを回避することができる。但し、HeNBが上りNASメッセージを受信しない場合においても、本変形例を用いることができる。次に、InitialUEMessageに追加および変更が必要なパラメータについて説明する。InitialUEMessageにマッピングされるパラメータには、1HeNBの識別子であるCGIが既に含まれる。したがってInitialUEMessageに新たに追加が必要なパラメータの具体例としては、以下の2~8がある。2MTCDの識別子。3MTC用のPDU。4MTC用のSDU。InitialUEMessageには、NAS-PDUが既に含まれる。例えば、S1シグナリングがMTC用であれば、NAS-PDUをMTC用のPDUとしてもよい。5S1シグナリングが、MTC用であることを示すインジケータ。6どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。7どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。8前記6と前記7との組み合わせを示す識別子、あるいはインデックス。InitialUEMessageに含まれるパラメータにおいて変更が必要なパラメータは、eNBUES1APIDである。現行の規格では、eNBは移動端末に使用されるために固有のeNBUES1APIDを割り当て、InitialUEMessage中にマッピングする。eNBUES1APIDとは、S1インタフェース上で移動端末に関連する固有の識別子である。HeNBにおいて集線処理をした後に、HeNBからコアネットワークへデータを送信する場合、送信されるデータには、複数のMTCDからのデータが含まれる場合がある。つまり、移動端末固有にはS1インタフェースを用いない。したがって、eNBUES1APIDをHeNBが割り当て不可能な状況が発生する。また、現行の規格ではInitialUEMessageにはeNBUES1APIDを必ずマッピングする必要がある。つまり、集線処理によって複数のMTCDからのデータを1つのinitialUEMessageで送信するような場合、eNBUES1APIDの取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばS1シグナリングがMTC用であれば、eNBUES1APIDはマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、HeNBの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。bUplinkNASTransport非特許文献14参照。現行の規格では、eNBは、移動端末に関連するS1インタフェースによる接続が存在するMMEに送信すべきNASメッセージを受信したとき、NASのPDUを含むUplinkNASTransportを用いてMMEへ該メッセージを送信する。したがって、HeNBが、傘下のMTCDからコアネットワークへのデータをMMEへUplinkNASTransportを用いて送信することは、同様の目的で現行の規格と同様のS1シグナリングを用いることができることになる。これによって、移動体通信システムが複雑化することを回避することができる。但し、HeNBが上りNASメッセージを受信しない場合においても、本変形例を用いることができる。また、S1インタフェースによる接続が存在しない場合においても、本変形例を用いることができる。次に、UplinkNASTransportに追加および変更が必要なパラメータについて説明する。UplinkNASTransportにマッピングされるパラメータには、1HeNBの識別子であるCGIが既に含まれる。したがってInitialUEMessageに新たに追加が必要なパラメータの具体例としては、以下の2~8がある。2MTCDの識別子。3MTC用のPDU。4MTC用のSDU。UplinkNASTransportには、NAS-PDUが既に含まれる。例えば、S1シグナリングがMTC用であれば、NAS-PDUをMTC用のPDUとしてもよい。5S1シグナリングが、MTC用であることを示すインジケータ。6どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。7どのMTCサーバ向けのデータであるか、あるいはどのMTCユーザ向けのデータであるかを示す情報。8前記6と前記7との組み合わせを示す識別子、あるいはインデックス。UplinkNASTransportに含まれるパラメータにおいて変更が必要なパラメータとして、以下のb1,b2の2つを開示する。b1eNBUES1APID。現行の規格では、eNBは移動端末に使用されるために固有のeNBUES1APIDを割り当て、UplinkNASTransport中にマッピングする。eNBUES1APIDとは、S1インタフェース上で該移動端末に関連する固有の識別子である。HeNBにおいて集線処理をした後に、HeNBからコアネットワークへデータを送信する場合、送信されるデータには、複数のMTCDからのデータが含まれる場合がある。つまり、移動端末固有にはS1インタフェースを用いない。これによって、eNBUES1APIDをHeNBが割り当て不可能な状況が発生する。また、現行の規格では、UplinkNASTransportにはeNBUES1APIDを必ずマッピングする必要がある。つまり、集線処理によって複数のMTCDからのデータを1つのUplinkNASTransportで送信するような場合、eNBUES1APIDの取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばS1シグナリングがMTC用であれば、eNBUES1APIDはマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、HeNBの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。b2MMEUES1APID。MMEUES1APIDとは、S1インタフェース上で移動端末に関連する固有の識別子である。HeNBにおいて集線処理をした後に、HeNBからコアネットワークへデータを送信する場合、送信されるデータには、複数のMTCDからのデータが含まれる場合がある。つまり、移動端末固有にはS1インタフェースを用いない。これによって、MMEUES1APIDをHeNBが割り当て不可能な状況が発生する。また、現行の規格では、UplinkNASTransportにはMMEUES1APIDを必ずマッピングする必要がある。つまり、集線処理によって、複数のMTCDからのデータを1つのUplinkNASTransportで送信するような場合、MMEUES1APIDの取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばS1シグナリングがMTC用であれば、MMEUES1APIDはマッピングされていても、受信側で無効なパラメータ、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、HeNBの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。本変形例では、実施の形態1と組み合わせた例について主に記載したが、本変形例は、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態1の変形例4とも組み合わせて用いることができる。また、本変形例は、非特許文献9に開示されているeNBがMTCDグループに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregation際にも用いることができる。実施の形態2の変形例3によって、実施の形態2の効果に加えて、以下の効果を得ることができる。実施の形態2および実施の形態2の変形例1と比較して、新たなシグナリングを設ける必要がない点において、移動体通信システムが複雑化することを回避することができるという利点がある。実施の形態2変形例4.前述の実施の形態2を用いた場合、以下の課題が発生する。集線処理を行う能力を有するHeNBと、集線処理を行う能力を有していないHeNBとが存在する場合を考える。集線処理を行う能力を有していないHeNBへコアネットワークであるMME、SGSNなどが実施の形態2の処理を実行して、S1インタフェースを介してMTCD用の通信として許可された時間、あるいは許可された期間、あるいは許可されたリソースを通知することは無駄となる。具体的には、コアネットワークからHeNBまでの通信リソースの無駄、およびコアネットワークの処理の無駄が発生する。実施の形態2の変形例4での解決策を以下に示す。実施の形態1および実施の形態2での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1および実施の形態2と同様とする。HeNBは、MTCDからのデータの集線処理に関する能力情報をコアネットワークであるMME、SGSNなどへ通知する。コアネットワークは、MTCDからのデータの集線処理を行う能力があるHeNBに対して、実施の形態2を実行して、MTCD用リソースの通知を実行する。また、コアネットワークは、集線処理を行うHeNBのみに対して、実施の形態2を実行して、MTCD用リソースの通知を実行するようにしてもよい。また、実施の形態1の変形例2を実行する場合、コアネットワークがHeNBへ集線処理の開始を指示する際に、MTCD用リソースの通知を実行するようにしてもよい。その場合、集線ONの指示とともに、MTCD用リソースを通知してもよい。実施の形態1の変形例2で開示した、コアネットワークがHeNBへ集線ONを指示するシグナリングの具体例として、パラメータにMTCD用リソースを追加してもよい。HeNBがコアネットワークへ通知する集線処理に関する能力情報の具体例は、実施の形態1の変形例3と同様であるので説明を省略する。HeNBが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、以下の1~5の5つを開示する。1HeNB設置時。HeNBの集線処理を行う能力に変更が生じることがない場合、通信リソースの無駄が発生しないという効果を得ることができる。2周期的。HeNBの集線処理を行う能力に変更が生じる場合に有効である。また、周期的に能力情報が通知されるので、通信エラーに強いという効果を得ることができる。3HeNBの能力変更時。HeNBの集線処理を行う能力に変更が生じる場合に有効である。具体例3は、具体例2と比較して、能力変更時のみの通知であるので、通信リソースの無駄が発生しないという効果を得ることができる。4HeNBが集線処理を開始するとき。あるいは集線処理の開始前。集線処理に関する能力情報として、集線処理を開始する旨を通知してもよい。集線処理を行う能力を有するHeNBであっても、傘下にMTCDが存在しなければ、コアネットワークからのMTCD用リソースの通知は無駄となる。具体例4は、具体例1~3と比較して、実際にMTCD用リソースが必要なHeNBにのみ、コアネットワークがMTCD用リソースを通知することが可能となる。したがって、本具体例4は、よりコアネットワークからHeNBまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。5集線処理を終了の際。集線処理に関する能力情報として、集線処理を終了する旨を通知してもよい。具体例4と具体例5とは、組み合わせて用いることができる。HeNBが集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例は、実施の形態1の変形例3と同様であるので説明を省略する。その際、具体例2を用い、応答メッセージが必要なS1シグナリングを設けた場合、応答メッセージにMTCD用リソースをマッピングするようにしてもよい。これによって、通信手順を省略することができ、HeNBやコアネットワークの処理の負荷を軽減することができるとともに、通信リソースを有効に活用することができる。また、具体例3を用い、既存の応答メッセージが必要な既存のS1シグナリングを設けた場合、応答メッセージにMTCD用リソースをマッピングするようにしてもよい。これによって、通信手順を省略することができ、HeNBやコアネットワークの処理の負荷を軽減することができるとともに、通信リソースを有効に活用することができる。応答メッセージの具体例としては、S1SETUPRESPONSE、S1SETUPFAILUREENBCONFIGURATIONUPDATEACKNOWLEDGEeNBConfigurationUpdateFAILUREなどがある。MTCD用リソースの解放の方法についての具体例として、以下の1~3の3つを開示する。1MTCD用リソースについて有効期間を、予め決定しておく。有効期間を経過した場合、コアネットワークは、MTCD用リソースを解放する。2コアネットワークが、HeNBへ、MTCD用リソースの通知を行う場合、あわせて該リソースの有効期間を通知する。有効期間を経過した場合、コアネットワークは、MTCD用リソースを解放する。3HeNBが集線処理に関する能力情報をコアネットワークへ通知するタイミングの前述の具体例5を用いた場合、該通知を受信したコアネットワークは、MTCD用リソースを解放する。前記具体例1~3を用いて、MTCD用リソースを解放することで、無駄なリソースを確保する必要が無くなる。また、解放した通信リソースは、他の通信、例えばノーマルUE用の通信に用いることができる。これによって、通信リソースを有効に活用することができる。前記具体例1および2については、HeNBが集線処理を行っている場合においても有効期間が経過し、コアネットワークにおいてMTCD用リソースが解放される場合が考えられる。したがって、HeNBがMTCD用リソースを要求することができるようにしてもよい。MTCD用リソースの要求情報をコアネットワークへ通知する際のシグナリングの具体例は、実施の形態1の変形例3で開示したHeNBが、集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例を用いることができるので、説明を省略する。実施の形態2の変形例3を用いた具体的な動作例を、図25を用いて説明する。図25は、実施の形態2の変形例3における移動体通信システムのシーケンスを示す図である。図25において、図17、図20および図22に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、HeNB設置時について開示する。また、HeNBは、集線処理能力を有することとする。HeNBが集線処理に関する能力情報をコアネットワークへ通知する際のシグナリングの具体例として、既存のS1シグナリングであるS1SETUPREQUESTを用いる場合について開示する。また、S1SETUP手順は成功したとして、MTCD用リソースをS1SETUPREQUESTの応答メッセージであるS1SETUPRESPONSEを用いて通知する場合について開示する。ステップST2001において、HeNBが設置される。ステップST2501において、HeNBは、MMEへHeNBの集線処理に関する能力情報を通知する。この通知にはS1SETUPREQUESTを用いる。S1SETUPREQUESTのパラメータとして、集線処理に関する能力情報をマッピングする。ステップST2003において、MMEは、ステップST2501で受信した集線処理に関する能力情報に基づいて、HeNBが集線処理を行う能力があるか否かを判断する。MMEは、集線処理を行う能力があると判断した場合は、ステップST2502へ移行する。MMEは、集線処理を行う能力がないと判断した場合は、ステップST2503へ移行する。本動作例では、HeNBは集線処理能力を有するので、集線処理を行う能力があると判断され、ステップST2502へ移行する。ステップST2502において、MMEは、HeNBへMTCD用リソースを通知する。この通知にはS1SETUPRESPONSEを用いる。S1SETUPRESPONSEのパラメータとして、MTCD用リソースをマッピングする。ステップST2503において、MMEは、HeNBへS1SETUPRESPONSEを通知する。S1SETUPRESPONSEのパラメータとして、MTCD用リソースはマッピングしない。つまり、ステップST2503でHeNBへ通知されるS1SETUPRESPONSEには、MTCD用リソースを含まない。次に、ステップST1703において、MTCD_1がRRCConnectionRequestをHeNBに送信する処理を行い、ステップST1704において、MTCD_nがRRCConnectionRequestをHeNBに送信する処理を行う。MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、前述のステップST1705およびステップST1903の処理を行う。ステップST1903の処理を終了した後は、HeNBは、ステップST2504へ移行する。ステップST2504において、HeNBは、ステップST2502で受信した、MTCD用リソースであるか否かを判断する。HeNBは、MTCD用リソースであると判断した場合は、ステップST2203へ移行し、HeNBが、傘下のMTCDからコアネットワークへのデータをMMEへS1インタフェースを用いて送信する。HeNBは、MTCD用リソースでないと判断した場合は、ステップST2504の判断処理を繰り返す。本変形例では実施の形態1および実施の形態2と組み合わせた例について主に記載したが、本変形例は、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3、実施の形態1の変形例4、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3とも組み合わせて用いることができる。また、本変形例は、非特許文献10に開示されているeNBがMTCDグループに共通のシグナリングメッセージを引き止めholdback、寄せ集めるaggregation際にも用いることができる。実施の形態2の変形例4によって、実施の形態2の効果に加えて、以下の効果を得ることができる。集線処理を行う能力を有していないHeNBに対して、コアネットワークがMTCD用リソースを通知することを防止することができる。これによって、コアネットワークからHeNBまでの通信リソースを有効に活用することができるとともに、コアネットワークの処理の負荷を軽減することができる。実施の形態3.本実施の形態3では、実施の形態1を実行した際のページングPaging方法について開示する。本実施の形態3では、HeNBとMTCDとの間の通信方法として、3GPPによって標準規格化された移動体通信システムを用いた場合について開示する。実施の形態3を用いた具体的な動作例を、図26を用いて説明する。図26は、実施の形態3における移動体通信システムのシーケンスを示す図である。図26において、図17に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBで集線処理を行うMTCDからコアネットワークへのデータの具体例として、NASシグナリングの場合について開示する。また、HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestにMTCDインジケータをマッピングする場合について開示する。まず、ステップST1703において、MTCD_1がRRCConnectionRequestをHeNBに送信する処理を行い、ステップST1704において、MTCD_nがRRCConnectionRequestをHeNBに送信する処理を行う。MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、前述のステップST1705およびステップST1707の処理を行う。ステップST1707の処理を終了した後は、ステップST2601へ移行する。本動作例では、ステップST1703の処理の後に、ステップST1705、ステップST1707およびステップST2202に相当する処理が行われるが、理解を容易にするために、説明を省略している。また、ステップST1705において、MTCDからのデータではないと判断された場合は、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。ステップST2601において、MTCD_1は、HeNBへ、MTCD_1の識別子を含むアタッチメッセージを送信する。アタッチの詳細な方法については、非特許文献13に開示されている。ステップST2602において、MTCD_nは、HeNBへ、MTCD_nの識別子を含むアタッチメッセージを送信する。ステップST2603において、HeNBは、ステップST2601で受信したMTCD_1からのアタッチメッセージと、ステップST2602で受信したMTCD_nからのアタッチメッセージとを集線処理する。本動作例では、集線処理として、複数のMTCDからコアネットワークへのデータであるアタッチメッセージを、まとめてMMEへ通知することとする。ステップST2604において、HeNBは、ステップST2603で集線処理を行うことによって集線されたアタッチメッセージをMMEへ通知する。アタッチメッセージには、集線処理の対象となったMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、HeNBの識別子と、TAIとが含まれる。アタッチメッセージの通知方法としては、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3を用いることができる。ステップST2605において、MMEは、HSSHomeSubscriberServerへ、アタッチメッセージとして受信したMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子を通知する。HSSとは、3GPP移動体通信網における加入者情報データベースであり、認証情報および在圏情報の管理を行うエンティティである。ステップST2606において、HSSは、アタッチ処理されたMTCDの識別子であるMTCD_1の識別子とMTCD_nの識別子とを登録し、管理する。ステップST2607において、MMEは、MTCD_1宛の着信を受信したとする。着信の詳細な方法については、非特許文献13および非特許文献14に開示されている。着信には、MTCD_1の識別子が含まれる。これによって、MTCD_1単体に着信させることができる。ステップST2608において、MMEは、MTCD_1のトラッキングエリアリストTAIListとも称されるを検索する。ステップST2609において、MMEは、HeNBへ、MTCD_1宛のページングを通知する。ページングには、MTCD_1のトラッキングエリアリストと、MTCD_1の識別子とが含まれる。MTCD_1の識別子が含まれることによって、MTCD_1単体に着信させることができる。ステップST2610において、HeNBは、ステップST2609で受信したページングに含まれるMTCD_1のトラッキングエリアリストTAIListに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。HeNBは、自HeNBが含まれると判断した場合は、ステップST2611へ移行する。HeNBは、自HeNBが含まれないと判断した場合は、ステップST2611の処理を行わない。ステップST2611において、HeNBは、MTCD_1宛のページングを通知する。ページングは、3GPPによって標準規格化された移動体通信システムにおいて通知する。具体的には、ページングメッセージは、論理チャネルであるPCCHにマッピングされ、PCCHは、トランスポートチャネルであるPCHへマッピングされ、PCHは、物理チャネルであるPDSCHへマッピングされる。PDCCHで全移動端末共通のページングインジケータを送信する。ページングインジケータが送信されたPDCCHによって、前記ページングメッセージがマッピングされたPDSCHのリソースが割り当てられる。ページングの通知の詳細な方法については、非特許文献1、非特許文献2および非特許文献16に開示されている。本実施の形態では、実施の形態1、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3と組み合わせた例について主に記載したが、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態2の変形例4とも組み合わせて用いることができる。以上に述べた実施の形態3では、実施の形態1を実行し、HeNBとMTCDとの間の通信方法として、3GPPによって標準規格化された移動体通信システムを用いた場合のページングPaging方法について開示している。実施の形態3を実行することによって、3GPPによって標準規格化された移動体通信システムを用いた場合に、ページングPagingを実現することができる。実施の形態4.本実施の形態4では、実施の形態1を実行した際のページングPaging方法について開示する。本実施の形態4では、HeNBとMTCDとの間の通信方法として、3GPPによって標準規格化された移動体通信システム以外の通信システムを用いた場合について開示する。実施の形態4での解決策を以下に示す。実施の形態1での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1と同様とする。HeNBは、3GPPによって標準規格化された移動体通信システム以外の通信システムを用いてアクセスしてきたMTCDからのデータを集線処理し、3GPPによって標準規格化された移動体通信システムのプロトコルを用いて、コアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへ通知する。HeNBは、集線処理を行ったMTCDの識別子を記憶し、MMEから集線処理を行ったMTCDの識別子を含んだページングメッセージを受信したときには、傘下のMTCDへ着信を通知する。集線処理の具体例として、以下の1~3の3つを開示する。13GPPによって標準規格化された移動体通信システム以外の通信システムによるアクセスを、3GPPによって標準規格化された移動体通信システムのプロトコルに乗せ変える。3GPPによって標準規格化された移動体通信システム以外の通信システムによるアクセスがあった場合、アクセス内容を解釈し、アクセス内容に即した3GPPによって標準規格化された移動体通信システムのプロトコルを選定し、プロトコルに必要なパラメータをコアネットワークであるMME、あるいはSGSN、あるいはMTCサーバなどへ通知する。21つ、あるいは複数のMTCDからのコアネットワークへのデータを、まとめてMMEへ通知する。これによって、HeNBからコアネットワークへの通信回数を削減することができ、コアネットワークの混雑を緩和することができる。31と2との組み合わせ。集線処理の具体例について、前記の具体例1を選択した場合における、3GPPによって標準規格化された移動体通信システム以外の通信システムによるアクセス内容と、アクセス内容に即した3GPPによって標準規格化された移動体通信システムのプロトコルとの組み合わせの具体例として、以下のa~hの8つを開示する。以下の説明では、3GPPによって標準規格化された移動体通信システム以外の通信システムを3GPP以外と称し、3GPPによって標準規格化された移動体通信システムを3GPP内と称することもある。a3GPP以外でMTCDの電源ONを通知してきた場合、3GPP内でAttachprocedureを選定。Attachprocedureの詳細は、非特許文献13に開示されている。b3GPP以外でMTCDの設置を通知してきた場合、3GPP内でAttachprocedureを選定。c3GPP以外でMTCDの位置の登録を通知してきた場合、3GPP内でAttachprocedureを選定。d3GPP以外でMTCDの移動を通知してきた場合、3GPP内でTrackingAreaUpdateprocedureを選定。TrackingAreaUpdateprocedureの詳細は、非特許文献13に開示されている。e3GPP以外でMTCDの通信要求、あるいは発呼要求、あるいは着呼応答を通知してきた場合、3GPP内でServiceRequestproceduresを選定。ServiceRequestproceduresの詳細は、非特許文献13に開示されている。f3GPP以外でMTCDの電源OFFを通知してきた場合、3GPP内でDetachprocedureを選定。Detachprocedureの詳細は、非特許文献13に開示されている。g3GPP以外でMTCDの設置解除を通知してきた場合、3GPP内でDetachprocedureを選定。h3GPP以外でMTCDの故障を通知してきた場合、3GPP内でDetachprocedureを選定。集線処理の具体例について、前記の具体例1を選択した場合における、プロトコルに必要なパラメータの具体例として、以下のa~dの4つを開示する。a3GPP内においてAttachprocedureを選定した場合、以下のa1~a4。a1MTCDの識別子。a2HeNBの識別子。a3HeNBのトラッキングエリア。a4前記a1~a3の組み合わせ。b3GPP内においてTrackingAreaUpdateprocedureを選定した場合、以下のb1~b4。b1MTCDの識別子。b2HeNBの識別子。b3HeNBのトラッキングエリア。b4前記b1~b3の組み合わせ。cServiceRequestproceduresを選定した場合、以下のc1~c4。c1MTCDの識別子。c2HeNBの識別子。c3HeNBのトラッキングエリア。c4前記c1~c3の組み合わせ。dDetachprocedureを選定した場合、d1MTCDの識別子。実施の形態4を用いた具体的な動作例を、図27を用いて説明する。図27は、実施の形態4における移動体通信システムのシーケンスを示す図である。図27において、図17および図26に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、集線処理の具体例としては、前記の具体例3である具体例1と具体例2との組み合わせを用いた場合について開示する。また、3GPP以外によるアクセス内容と、アクセス内容に即した3GPP内のプロトコルとの組み合わせの具体例としては、3GPP以外でMTCDの設置を通知してきた場合、および3GPP内でAttachprocedureを選定した場合について開示する。また、3GPP以外によるアクセスを3GPP内のプロトコルに乗せ変える場合における、Attachprocedureに必要なパラメータの具体例として、前記の具体例aのa1MTCDの識別子、a2HeNBの識別子、a3HeNBのトラッキングエリアとした場合について開示する。ステップST2701において、MTCD_1は、HeNBへ、MTCD_1の識別子を含むMTCDの設置通知を送信する。ステップST2702において、MTCD_nは、HeNBへ、MTCD_nの識別子を含むMTCDの設置通知を送信する。ステップST2703において、HeNBは、ステップST2702におけるMTCD_nの識別子を含むMTCDの設置通知を3GPP以外で受信したか否かを確認し、前記MTCDの設置通知が、MTCDからのデータであるか否かを判断する。HeNBは、MTCDの識別子を含むMTCDの設置通知を3GPP以外で受信したと判断した場合は、MTCDからのデータであると判断し、ステップST2704へ移行する。HeNBは、MTCDの識別子を含むMTCDの設置通知を3GPP以外で受信しなかったと判断した場合は、MTCDからのデータではないと判断し、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了する。また、MTCDの識別子が含まれているか否かを確認せずに、3GPP以外で受信した場合は、MTCDからのデータであると判断し、ステップST2704へ移行するようにしてもよい。3GPP内で受信した場合は、ノーマルUEからのデータであると判断し、本実施の形態の本質的な部分ではないので、説明を省略することとして、処理を終了するようにしてもよい。ステップST2704において、HeNBは、集線処理を行うMTCDの識別子を記憶する。本動作例においては、MTCD_1の識別子とMTCD_nの識別子とを記憶する。ステップST2705において、HeNBは、集線処理を行う。本動作例においては、HeNBは、MTCD_1およびMTCD_nからのコアネットワークへのデータをまとめてMMEへ通知する。また、3GPP以外によるアクセスであるステップST2701とステップST2702との内容を解釈し、設置に関するアクセスであると理解する。次に、設置に関するアクセスに即した3GPP内のプロトコルとしてAttachprocedureを選定する。またAttachprocedureにパラメータとして、ステップST2701で受信したMTCD_1の識別子と、ステップST2702で受信したMTCD_nの識別子と、自HeNBの識別子と、HeNBのトラッキングエリアとをマッピングする。本動作例では、ステップST2701の処理の後に、ステップST2703、ステップST2704およびステップST2705に相当する処理が行われるが、理解を容易にするために、説明を省略している。ステップST2706において、HeNBは、ステップST2705で集線処理を行うことによって集線されたアタッチメッセージをMMEへ通知する。アタッチメッセージには、集線処理の対象となったMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、HeNBの識別子と、TAIとが含まれる。該通知には、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3を用いることができる。ステップST2706の処理の後は、MMEがステップST2605の処理を行い、HSSがステップST2606の処理を行う。次にMMEが、ステップST2607においてMTCD_1宛の着信を受信し、MMEがステップST2608およびステップST2609の処理を行う。次に、ステップST2707において、HeNBは、ステップST2609で受信したページングに含まれるMTCD_1についての集線処理を行ったか否かを判断する。ステップST2707の処理の判断には、ステップST2704で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップST2708へ移行する。集線処理を行っていないと判断した場合は、ステップST2709へ移行する。本動作例においては、HeNBは、MTCD_1についての集線処理を行っているので、ステップST2708へ移行する。ステップST2708において、HeNBは、MTCD_1宛の着信をMTCD_1へ通知する。ステップST2708の着信の通知は、ステップST2701で用いられた3GPP以外の通信システムを用いて行う。ステップST2709において、HeNBは、ステップST2609で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST2710へ移行する。自HeNBが含まれないと判断した場合は、ステップST2710の処理を行わない。ステップST2710において、HeNBは、3GPP内の通信システムを用いて着信の通知を行う。本実施の形態では、実施の形態1、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3と組み合わせた例について主に記載したが、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態2の変形例4とも組み合わせて用いることができる。また本実施の形態では、HeNBとMTCDとの間の通信方法が3GPP以外である場合について説明したが、HeNBとMTCDとの間の通信方法が3GPP内である場合でも本実施の形態を用いることができる。以上に述べた実施の形態4では、実施の形態1を実行し、HeNBとMTCDとの間の通信方法として、3GPPによって標準規格化された移動体通信システム以外の通信システムを用いた場合のページングPaging方法について開示している。実施の形態4を実行することによって、3GPPによって標準規格化された移動体通信システム以外の通信システムを用いた場合に、ページングPagingを実行することができる。実施の形態4変形例1.前述の実施の形態4を用いた場合、以下の課題が発生する。MTCDが移動し、HeNB経由でのMTCサーバとの通信が不可能となった場合であっても、HeNB内で集線処理を行ったMTCDとして、MTCDの識別子が記憶され続ける。これによって、HeNBの記憶領域が不要なデータに用いられるという課題が発生する。実施の形態4の変形例1での解決策として、以下の1,2の2つを開示する。1MTCDは、移動して、HeNB経由でのMTCサーバとの通信が不可能となった場合、その旨をHeNBへ通知する。MTCDは、移動する場合、その旨をソースHeNBへ通知する。該通知を受信したHeNBは、集線処理を行ったMTCDの記憶から、該MTCDを削除する。2MTCDは、移動して、HeNB経由でのMTCサーバとの通信が不可能となった場合、その旨をHeNB経由でコアネットワークへ通知する。MTCDは、移動する場合、その旨をソースHeNB経由でコアネットワークへ通知する。該通知を受信したコアネットワークは、MTCDのソースセルを変更するか否かを判断する。コアネットワークは、ソースセルを変更する旨の決定をした場合は、ソースセルを変更する旨をHeNBへ通知する。該通知を受信したHeNBは、集線処理を行ったMTCDの記憶から、MTCDを削除する。コアネットワークからHeNBへのソースセルを変更する旨の通知には、MTCDの識別子が含まれる。MTCDからHeNBへ通知する内容の具体例として、以下の1~3の3つを開示する。1移動する旨。2サービングセルを変更する旨。3ハンドオーバする旨。実施の形態4の変形例1により、実施の形態4の効果に加えて、以下の効果を得ることができる。MTCDが移動し、HeNB経由でのMTCサーバとの通信が不可能となった場合、つまりHeNBがMTCDの集線処理を行うことができなくなった場合、HeNBの記憶領域から、MTCDのデータを削除することが可能となる。これによって、無駄なデータでHeNBの記憶領域を使用することを防ぐことができる。実施の形態5.本実施の形態5では、実施の形態1を実行した際のページングPaging方法について開示する。本実施の形態5では、MTCD毎へのページングではなく、HeNB毎でのページング方法について開示する。集線処理を行ったHeNB毎であってもよい。実施の形態5での解決策を以下に示す。実施の形態1での解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1と同様とする。オペレータ、あるいはMTCユーザへの登録などは、MTCD個別で行わず、集線処理を行うHeNB単位で行う。サービス形態の一例を挙げる。家屋に設置されるHeNB毎に1つのMTCDとしての契約を行う。HeNBの傘下に複数のMTCDが存在した場合であっても、HeNBとして1つの契約となる。集線処理を行ったHeNB単位でコアネットワークへ登録し、ページングはHeNB宛へ行う。ページングを受信したHeNBは、傘下の全てのMTCDへ着信通知を行う。集線処理の具体例について、以下に開示する。実施の形態1で開示した具体例1~4と合わせて、以下の具体例5の動作を行う。5傘下のMTCDからコアネットワークへのデータ中に含まれるMTCDの識別子を削除し、代わりに自HeNBの識別子をマッピングする。既にHeNBの識別子を付加してコアネットワークへ通知するようなメッセージの場合は、MTCDの識別子を削除するのみでよい。コアネットワークへの登録方法の具体例について、以下に開示する。MMEは、HSSにMTCDの識別子ではなく、MTCDのコアネットワークへのデータを集線処理したHeNBの識別子を通知する。HSSは、MTCDの識別子ではなく、集線処理したHeNBの識別子を登録する。HeNBが傘下の全てのMTCDへ着信を通知する具体例として、以下の1,2の2つを開示する。1報知情報を用いる。2グループ呼出しを用いる。実施の形態5を用いた具体的な動作例を、図28を用いて説明する。図28は、実施の形態5における移動体通信システムのシーケンスを示す図である。図28において、図17および図26に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBで集線処理を行うMTCDからコアネットワークへのデータの具体例として、NASシグナリングの場合について開示する。また、HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestにMTCDインジケータをマッピングする場合について開示する。またHeNBが、傘下の全てのMTCDへ着信を通知する具体例については、報知情報を用いる場合について開示する。まず、MTCD_1がステップST1703の処理を行い、MTCD_nがステップST1704の処理を行う。次に、MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、ステップST1705およびステップST1707の処理を行う。次に、MTCD_1がステップST2601の処理を行い、MTCD_nがステップST2602の処理を行う。次に、ステップST2801において、HeNBは、ステップST2601で受信したMTCD_1からのアタッチメッセージと、ステップST2602で受信したMTCD_nからのアタッチメッセージとを集線処理する。本動作例では、集線処理として、複数のMTCDからコアネットワークへのデータであるアタッチメッセージを、まとめてMMEへ通知することとする。その際、傘下のMTCDからコアネットワークへのデータ中に含まれるMTCDの識別子であるMTCD_1の識別子と、MTCD_nの識別子とを、MMEへ通知しない。MTCDの識別子を通知しない代わりに、自HeNBの識別子を通知する。但し、自HeNBの識別子は、現行の規格のeNBからMMEへのAttachprocedureで通知されるパラメータである非特許文献13参照。本動作例のステップST2801では、傘下のMTCDから受信したアタッチメッセージから、MTCDの識別子を削除するのみでもよい。ステップST2802において、HeNBは、ステップST2801で集線処理を行うことによって集線されたアタッチメッセージをMMEへ通知する。アタッチメッセージには、集線処理の対象となったMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子は含まれず、HeNBの識別子と、TAIとが含まれる。またTAIの通知は任意である。ステップST2802の通知には、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3を用いることができる。ステップST2803において、MMEは、HSSへアタッチメッセージで受信したHeNBの識別子を通知する。ステップST2804において、HSSは、アタッチ処理されたHeNBを登録し、管理する。ステップST2805において、MMEは、HeNB宛の着信を受信したとする。着信の詳細な方法については、非特許文献13および非特許文献14に開示されている。着信には、HeNBの識別子が含まれる。これによって、HeNB単位の着信をすることができる。ステップST2806において、MMEは、自MMEの傘下にHeNBが存在するか否かを判断する。存在すると判断した場合は、ステップST2807へ移行し、存在しないと判断した場合は、処理を終了する。本動作例では、自MMEの傘下にHeNBが存在するので、ステップST2807へ移行する。ステップST2806の処理を行わずに、MMEは、ステップST2807において、傘下の基地局であるeNB、HeNBなどへ、ページングを通知してもよい。ステップST2807において、MMEは、HeNBへHeNB宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリスト、MTCD_1の識別子およびUEIdentityIndexvalueは含まれない。UEIdentityIndexvalueの説明は、後述の実施の形態6に示す。MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれない代わりに、HeNBの識別子が含まれる。HeNBの識別子が含まれることによって、HeNB単位に着信させることができる。ステップST2808において、HeNBは、ステップST2807で受信したページングに含まれる識別子が、HeNBの識別子であるか否かを判断する。HeNBは、HeNBの識別子であると判断した場合は、ステップST2809へ移行する。HeNBは、HeNBの識別子でないと判断した場合は、移動端末の識別子であると判断して、ステップST2610へ移行する。本動作例では、ステップST2807において受信したページングに含まれる識別子は、HeNBの識別子であるので、ステップST2809へ移行する。ステップST2809において、HeNBは、ステップST2807で受信したページングに含まれるHeNBの識別子が、自HeNBの識別子であるか否かを判断する。自HeNBであると判断した場合は、ステップST2810へ移行する。自HeNBでないと判断した場合は、処理を終了する。本動作例では、ステップST2807で受信したページングに含まれるHeNBの識別子は、自HeNBの識別子であるので、ステップST2810へ移行する。ステップST2810において、HeNBは、傘下の全てのMTCDへ報知情報を用いて着信を通知する。ステップST2811において、HeNBは、通常通りに移動端末識別子を含むページングを通知する。該ページングは、3GPPによって標準規格化された移動体通信システムで通知する。具体的には、ページングメッセージは、論理チャネルであるPCCHにマッピングされ、PCCHは、トランスポートチャネルであるPCHへマッピングされ、PCHは、物理チャネルであるPDSCHへマッピングされる。PDCCHで全移動端末共通のページングインジケータを送信する。ページングインジケータが送信されたPDCCHによって、前記ページングメッセージがマッピングされたPDSCHのリソースが割り当てられる。ページングの通知の詳細な方法については、非特許文献1、非特許文献2および非特許文献16に開示されている。本実施の形態では、実施の形態1、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3と組み合わせた例について主に記載したが、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態2の変形例4とも組み合わせて用いることができる。また実施の形態では、HeNBとMTCDとの間の通信方法が3GPP内である場合について説明したが、HeNBとMTCDとの間の通信方法が3GPP以外である場合でも本実施の形態を用いることができる。以上に述べた実施の形態5では、実施の形態1を実行し、MTCD毎へのページングではなく、HeNB毎でのページング方法について開示している。実施の形態5を実行することによって、HeNB毎でのページングを実現することができる。実施の形態5変形例1.本実施の形態5の変形例1では、実施の形態5を実行して、オペレータ、あるいはMTCユーザへの登録などは、MTCD個別で行わず、集線処理を行うHeNB単位で行った場合であっても、MTCD毎へのページングを行う方法について開示する。実施の形態5の変形例1での解決策を以下に示す。実施の形態1および実施の形態5の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1および実施の形態5と同様とする。HeNBは、集線処理を行ったMTCDの識別子を記憶し、MMEから該HeNBの識別子とは別にMTCDの識別子を含むページングメッセージを受信したときには、傘下のMTCDへ着信を通知する。実施の形態5の変形例1を用いた具体的な動作例を、図29を用いて説明する。図29は、実施の形態5の変形例1における移動体通信システムのシーケンスを示す図である。図29において、図17、図26および図28に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、HeNBで集線処理を行うMTCDからコアネットワークへのデータの具体例として、NASシグナリングの場合について開示する。また、HeNBが、傘下の移動端末UEがMTCDであるか、MTCD以外であるかを区別する方法の具体例として、RRCメッセージRRCConnectionRequestにMTCDインジケータをマッピングする場合について開示する。まず、MTCD_1がステップST1703の処理を行い、MTCD_nがステップST1704の処理を行う。次に、MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNBは、ステップST1705およびステップST1707の処理を行う。次に、MTCD_1がステップST2601の処理を行い、MTCD_nがステップST2602の処理を行う。次に、MTCD_1およびMTCD_nから送信されたアタッチメッセージを受信したHeNBは、ステップST2704、ステップST2801およびステップST2802の処理を行う。次に、MMEがステップST2803の処理を行い、HSSがステップST2804の処理を行う。ステップST2901において、MMEは、HeNB宛の着信を受信したとする。着信の詳細な方法については、非特許文献13および非特許文献14に開示されている。着信には、HeNBの識別子とは別に、個別に呼び出したいMTCD_1の識別子が含まれる。これによって、オペレータなどへの登録をMTCD個別で行わず、集線処理を行うHeNB単位で行った場合であっても、MTCD毎へのページングを行うことができる。MMEは、ステップST2901の処理の後に、ステップST2806の処理を行う。ステップST2806において、MMEが、自MMEの傘下にHeNBが存在すると判断した場合は、ステップST2902へ移行する。ステップST2902において、MMEは、HeNBへHeNB宛のページングを通知する。該ページングには、MTCD_1の識別子は含まれるが、MTCD_1のトラッキングエリアリストは含まれない。HeNBは、ステップST2808およびステップST2809の処理を行う。ステップST2809において、HeNBが、ステップST2902で受信したページングに含まれるHeNBの識別子が、自HeNBの識別子であると判断した場合は、ステップST2903へ移行する。ステップST2903において、HeNBは、ステップST2902で受信したページングに含まれるMTCD_1識別子のMTCD_1についての集線処理を行ったか否かを判断する。ステップST2903の判断には、ステップST2704で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップST2611へ移行する。集線処理を行っていないと判断した場合は、処理を終了する。本変形例では、実施の形態1、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3と組み合わせた例について主に記載したが、実施の形態1の変形例1、実施の形態1の変形例2、実施の形態1の変形例3および実施の形態2の変形例4とも組み合わせて用いることができる。また本変形例では、HeNBとMTCDとの間の通信方法が3GPP内である場合について説明したが、HeNBとMTCDとの間の通信方法が3GPP以外である場合でも、本変形例を用いることができる。以上に述べた実施の形態5の変形例1では、実施の形態1に加えて、実施の形態5を実行し、オペレータ、あるいはMTCユーザへの登録などは、MTCD個別で行わず、集線処理を行うHeNB単位で行った場合であっても、MTCD毎のページングを行う方法について開示している。実施の形態5の変形例1を実行することによって、オペレータ、あるいはMTCユーザへの登録などを、集線処理を行うHeNB単位で行った場合に、MTCD毎のページングを実現することができる。実施の形態6.実施の形態6で解決する課題について、以下に説明する。実施の形態5において、HeNBが、傘下の全てのMTCDへ着信を通知する場合に報知情報を用いる場合、無線区間、つまりHeNBとMTCDとの間が通常のページング送信とは異なる。MMEからHeNBへのページング中には、無線区間の設定に用いるパラメータが存在する。したがって、無駄なパラメータが存在することとなり、リソースの無駄が発生する。実施の形態6での解決策を以下に示す。実施の形態1、あるいは実施の形態5の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態1、あるいは実施の形態5と同様とする。MTCD毎へのページングではなく、HeNB毎でのページングを実行する場合、MMEからHeNBへのページングメッセージは、現行の規格非特許文献14参照と異ならせる。MMEは、受信した着呼に、MTCD識別子ではなく、HeNB識別子が含まれていた場合、MMEからHeNBへのページングメッセージは、現行の規格と異ならせる。現行の規格とは異ならせるページングメッセージの具体例として、以下の1,2のに2つ開示する。1新たなHeNB単位のページングメッセージを設ける。または新たな集線処理を行った場合のページングメッセージを設ける。新たなメッセージに含まれるパラメータの具体例としては、HeNBの識別子がある。2既存のS1シグナリングであるPagingを、HeNB単位のページングに用いる。既存のS1シグナリングであるPagingを、集線処理を行った場合のページングに用いる。次にPagingに追加および変更が必要なパラメータについて説明する。追加が必要なパラメータの具体例としては、HeNBの識別子がある。変更が必要なパラメータの具体例として、以下のa~cの3つを開示する。aUEIdentityIndexvalue。現行の規格では、UEIdentityIndexvalueは、eNBがページングを送信する無線フレームであるPagingFrame:PFを計算するために用いられる。HeNBが、傘下のMTCDへ報知情報を用いて着信を通知する場合、HeNBにおいてページングを送信する無線フレームの計算は不要である。したがって、UEIdentityIndexvalueの指定が移動体通信システム上不可能な状況が発生する。また、現行の規格では、PagingにはUEIdentityIndexvalueを必ずマッピングする必要がある。つまり、MTCD毎へのページングではなく、HeNB毎でのページングを現行のPagingで送信するような場合、UEIdentityIndexvalueの取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばPagingにHeNBの識別子がマッピングされていれば、HeNB毎でのページングであると判断し、UEIdentityIndexvalueはマッピングされていても、受信側で無効なパラメータとするか、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、MMEおよびHeNBの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。bUEPagingIdentity。現行の規格では、UEPagingIdentityは呼び出される移動端末の識別子である。HeNBが、傘下の全てのMTCDへ報知情報を用いて着信を通知する場合、HeNBにおいて、移動端末の一種であるMTCDの個別の識別子は不要である。また、発呼側からもMTCDの個別の識別子は通知されないことが想定される。したがって、UEPagingIdentityの指定が移動体通信システム上不可能な状況が発生する。また、現行の規格では、PagingにはUEPagingIdentityを必ずマッピングする必要がある。つまり、MTCD毎へのページングではなく、HeNB毎でのページングを現行のPagingで送信するような場合、UEPagingIdentityの取扱いにおいて、移動体通信システムとして統一がなくなるという問題が発生する。移動体通信システムとして統一が図られなければ、安定した通信網が供給できないなどの問題が発生する。そこで、例えばPagingにHeNBの識別子がマッピングされていれば、HeNB毎でのページングであると判断し、UEPagingIdentityはマッピングされていても、受信側で無効なパラメータとするか、あるいは送信側でのマッピングを必須とせずにオプションとする。これによって、MMEおよびHeNBの処理が明確となり、統一した移動体通信網の構築が可能となり、安定した通信網の供給が可能となる。cTA情報。現行の規格では、TA情報は、TA情報に属するeNBがページングを送信する。HeNBが、傘下のMTCDへ報知情報を用いて着信を通知する場合、ページング中にHeNBの識別子が含まれる。これによって、ページングに含まれるHeNBの識別子と一致するHeNBが、傘下のMTCDへ着信を通知するようにしてもよい。したがってTA情報は、特に必要ではないパラメータとなる。一方、現行の規格では、PagingにはTA情報を必ずマッピングする必要がある。つまり、MTCD毎へのページングではなく、HeNB毎でのページングを現行のPagingで送信するような場合、不要なパラメータであるTA情報が通知される。そこで、例えばPagingにHeNBの識別子がマッピングされていれば、HeNB毎でのページングであると判断し、送信側でのTA情報のマッピングを必須とせずにオプションとする。これによって、無駄なパラメータの送信を防止することが可能となる。実施の形態6により、実施の形態5の効果に加えて、以下の効果を得ることができる。MMEからHeNBへのページング中の無駄なパラメータを削減することができ、リソースを有効に活用することができる。実施の形態7.実施の形態7で解決する課題について、以下に説明する。まず、現行のページング方法について説明する。非特許文献14には、以下のことが開示されている。MMEからeNBへ通知されるページングメッセージ中に含まれるTAIListで示されたトラッキングエリアに属する各セルでは、無線インタフェース上でページングを発生させる。図30を用いて、現行のページング方法について再度説明する。図30は、現行のページング方法を説明するためのロケーションを示す図である。まず、図30のロケーションについて説明する。eNB3001、HeNB3003、HeNB3005、HeNB3007が設置されている。eNB3001は、カバレッジ3002を持つ。HeNB3003は、カバレッジ3004を持つ。HeNB3005は、カバレッジ3006を持つ。HeNB3007は、カバレッジ3008を持つ。HeNB3007のカバレッジ3008内に、移動端末3009が存在する。eNB3001のカバレッジ3002内に、eNB3001、HeNB3003、HeNB3005およびHeNB3007が存在する。トラッキングエリア1TA13016に、eNB3001、HeNB3003、HeNB3005およびHeNB3007が含まれる。また、eNB3010、HeNB3012およびHeNB3014が設置されている。eNB3010は、カバレッジ3011を持つ。HeNB3012は、カバレッジ3013を持つ。HeNB3014は、カバレッジ3015を持つ。eNB3010のカバレッジ3011内に、eNB3010、HeNB3012およびHeNB3014が存在する。トラッキングエリア2TA23017に、eNB3010、HeNB3012およびHeNB3014が含まれる。移動端末3009のトラッキングエリアリストとして、トラッキングエリア1TA13016と、トラッキングエリア2TA23017とが登録されている場合を考える。前記ロケーションにおいて、移動端末3009に着信が発生した場合の、現行のページング方法について説明する。現行の規格では、MMEからeNBへ通知されるページングメッセージ中に含まれるTAIListで示されたトラッキングエリアに属する各セルでは、無線インタフェース上でページングを発生させる。したがって、トラッキングエリア1TA13016に属するeNB3001、HeNB3003、HeNB3005およびHeNB3007と、トラッキングエリア2TA23017に属するeNB3010、HeNB3012およびHeNB3014とから、無線インタフェースを用いてページングが発生する。無意味なページング送信は、無線リソースを有効に活用することができず、また干渉が発生するという従来からの課題がある。次に、実施の形態7で解決する課題について、以下に説明する。集線処理を行う能力を有するHeNBと、集線処理を行う能力を有していないHeNBとが存在する場合を考える。前述の実施の形態3および実施の形態4を実行した場合、集線処理能力を有していないHeNBからMTCDへのページング通知、あるいは着信通知が無駄となる。これによって、無線リソースを有効に活用することができないという課題が生じる。前述の実施の形態3を実行した場合の無線リソースの無駄を、図31および図32を用いて説明する。図31および図32は、実施の形態3を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。図31と図32とは、境界線L1の位置で、つながっている。図31および図32において、図17および図26に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。まず、MTCD_1がステップST1703の処理を行い、MTCD_nがステップST1704の処理を行う。次に、MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNB3007は、ステップST1705およびステップST1707の処理を行う。次に、MTCD_1がステップST2601の処理を行い、MTCD_nがステップST2602の処理を行う。次に、MTCD_1およびMTCD_nから送信されたアタッチメッセージを受信したHeNB3007は、ステップST2603およびステップST2604の処理を行う。次に、MMEがステップST2605の処理を行う。次に、HSSがステップST2606の処理を行う。ステップST2607において、MMEが、MTCD_1宛の着信を受信した後、ステップST2608において、MMEは、MTCD_1のトラッキングエリアリストTAIListとも称されるを検索する。本動作例では、MMEは、MTCD_1のトラッキングエリアリストが、トラッキングエリア1TA13016とトラッキングエリア2TA23017とを含むことが判明する。ステップST3101において、MMEは、HeNB3007へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3102において、MMEは、HeNB3005へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3103において、MMEは、HeNB3003へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3104において、HeNB3007は、ステップST3101で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST3105へ移行する。自HeNBが含まれないと判断した場合は、ステップST3105の処理を行わない。本動作例では、図30に示すように、トラッキングエリアリストに含まれるトラッキングエリア1TA13016に、自HeNB3007が含まれている。したがってステップST3104の処理の後は、ステップST3105へ移行する。ステップST3105において、HeNB3007は、MTCD_1宛のページングをMTCD_1へ通知する。該ページングは、3GPPによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献1、非特許文献2および非特許文献16に開示されている。ステップST3106において、HeNB3005は、ステップST3102で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST3107へ移行する。自HeNBが含まれないと判断した場合は、ステップST3107の処理を行わない。本動作例では、図30に示すように、トラッキングエリアリストに含まれるトラッキングエリア1TA13016に、自HeNB3005が含まれている。したがってステップST3106の処理の後は、ステップST3107へ移行する。ステップST3107において、HeNB3005は、MTCD_1宛のページングを通知する。該ページングは、3GPPによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献1、非特許文献2および非特許文献16に開示されている。ステップST3108において、HeNB3003は、ステップST3103で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST3109へ移行する。自HeNBが含まれないと判断した場合は、ステップST3109の処理を行わない。本動作例では、図30に示すように、トラッキングエリアリストに含まれるトラッキングエリア1TA13016に、自HeNB3003が含まれている。したがってステップST3108の処理の後は、ステップST3109へ移行する。ステップST3109において、HeNB3003は、MTCD_1宛のページングを通知する。該ページングは、3GPPによって標準規格化された移動体通信システムで通知する。該ページングの通知の詳細な方法については、非特許文献1、非特許文献2および非特許文献16に開示されている。前述のように、MTCDの識別子がMTCD_1である移動端末3009は、HeNB3007のカバレッジ3008内に位置するので、ステップST3105におけるHeNB3007からのページングを受信することになる。したがって、ステップST3107におけるHeNB3005からのページング、およびステップST3109におけるHeNB3003からのページングは無駄となる。次に、実施の形態4を実行した場合の無線リソースの無駄を、図33および図34を用いて説明する。図33および図34は、実施の形態4を実行した場合の無線リソースの無駄を説明するための移動体通信システムのシーケンスを示す図である。図33と図34とは、境界線L2の位置で、つながっている。図33および図34において、図26、図27、図31および図32に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。移動端末3009からのデータを、HeNB3007が集線処理したとする。まず、MTCD_1がステップST2701の処理を行い、MTCD_nがステップST2702の処理を行う。次に、HeNB3007が、ステップST2703~ステップST2706の処理を行う。次に、MMEがステップST2605の処理を行い、HSSがステップST2606の処理を行う。ステップST2607において、MMEが、MTCD_1宛の着信を受信した後、ステップST2608において、MMEは、MTCD_1のトラッキングエリアリストTAIListとも称されるを検索する。本動作例では、MMEは、MTCD_1のトラッキングエリアリストが、トラッキングエリア1TA13016とトラッキングエリア2TA23017とを含むことが判明する。ステップST3101において、MMEは、HeNB3007へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3102において、MMEは、HeNB3005へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3103において、MMEは、HeNB3003へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。HeNB3007は、集線処理を行う能力を有する。したがって、ステップST2707において、HeNBは、ステップST3101で受信したページングに含まれるMTCD_1についての集線処理を行ったか否かを判断する。ステップST2707の処理の判断には、ステップST2704で記憶した情報を用いるとよい。集線処理を行ったと判断した場合は、ステップST2708へ移行する。集線処理を行っていないと判断した場合は、ステップST2709へ移行する。本動作例においては、HeNB3007は、MTCD_1についての集線処理を行っているので、集線処理を行ったと判断され、ステップST2708へ移行する。また、HeNB3005は、集線処理を行う能力を有していない。したがって、現行のページング方法の通り、ステップST3106において、HeNB3005は、ステップST3102で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST3107へ移行する。自HeNBが含まれないと判断した場合は、ステップST3107の処理を行わない。本動作例では、図30に示すように、トラッキングエリアリストに含まれるトラッキングエリア1TA13016に、自HeNB3005が含まれている。したがってステップST3106の処理の後は、ステップST3107へ移行する。また、HeNB3003は、集線処理を行う能力を有する。したがってステップST3201において、HeNBは、ステップST3103で受信したページングに含まれるMTCD_1についての集線処理を行ったか否かを判断する。集線処理を行ったと判断した場合は、ステップST3109へ移行する。集線処理を行っていないと判断した場合は、ステップST3202へ移行する。本動作例においては、HeNB3003は、MTCD_1についての集線処理を行ってないので、集線処理を行っていないと判断され、ステップST3202へ移行する。ステップST3202において、HeNBは、ステップST3103で受信したページングに含まれるMTCD_1のトラッキングエリアリストに含まれるトラッキングエリアに、自HeNBが含まれるか否かを判断する。自HeNBが含まれると判断した場合は、ステップST3203へ移行する。自HeNBが含まれないと判断した場合は、ステップST3203の処理を行わない。ステップST3203において、HeNBは、3GPP内の通信システムを用いて着信の通知を行う。本動作例においては、HeNB3003は、MTCD_1のトラッキングエリアに含まれるので、ステップST3203の処理を実行する。前述のように、MTCDの識別子がMTCD_1である移動端末3009は、HeNB3007のカバレッジ3008内に位置するので、ステップST3105におけるHeNB3007からのページングを受信することになる。したがって、ステップST3107におけるHeNB3005からのページング、およびステップST3203におけるHeNB3003からのページングは無駄となる。実施の形態7での解決策を以下に示す。HeNBで集線処理を行う旨を、MTCDの識別子とともにコアネットワーク側であるMME、HSSなどへ登録する。集線処理を行うか否かの情報を、以下集線処理状況とも称する。MTCD宛のページングが発生した場合は、ページングメッセージ中に集線処理状況を含ませる。HeNBが、集線処理を行う旨を示す情報が含まれるページングメッセージを受信した場合、自HeNBが集線処理を行う能力を有する場合にページングメッセージを送信する。HeNBで集線処理を行う旨を、コアネットワークへ登録するタイミングの具体例として、以下の1~4の4つを開示する。1HeNBが、傘下のMTCDからコアネットワークへのデータを集線する毎。2MTCDのアタッチメッセージを集線処理する際、あるいは集線処理の際にAttachprocedureを選定する際。本具体例2は、具体例1と比較して、HeNBが集線処理を行う旨をコアネットワークへ登録する回数が少なくなる。したがって、通信リソースを有効に活用することができ、HeNBの処理の負荷を軽減することができる。3MTCDのTAUメッセージを集線処理する際、あるいは集線処理の際にTrackingAreaUpdateprocedureを選定する際。本具体例3は、具体例1と比較して、HeNBが集線処理を行う旨をコアネットワークへ登録する回数が少なくなる。したがって、通信リソースを有効に活用することができ、HeNBの処理の負荷を軽減することができる。4前記2と前記3との組み合わせ。コアネットワークが、集線処理を行う旨の登録を削除するタイミングの具体例としては、MTCDからのDetachprocedureを受信した際である。登録方法の具体例を以下に開示する。MTCDの識別子と関連付けて集線処理状況を記憶する。登録するエンティティの具体例として、以下の1,2の2つを開示する。1MME。着信処理の際に、他のエンティティに問い合わせを行う必要がなくなる。したがって制御遅延を防止することができ、通信システムの処理の負荷を軽減することができるという点で有効である。2HSS。他の登録情報とともに記憶することができるので、データの一元管理が可能となるという点において有効である。具体例1と比較して、移動端末の移動によってMMEが変更になった場合であっても、登録情報を有効に活用することができるという点で有効である。つまり、HeNBからHSSへの集線処理を行う旨の登録回数を削減することができる。これによって、通信リソースを有効に活用することができ、HeNBの処理の負荷を軽減することができる。ページングが発生した場合に、ページングメッセージ中に集線処理を行った旨を示す情報を含ませる方法の具体例として、以下の1,2の2つを開示する。1登録場所がHSSであった場合、発信元、あるいは着信元のMMEが、HSSに集線処理状況を問い合わせる。MMEは、その問い合わせ結果をページングメッセージ中にマッピングする。2登録場所がMEEであった場合、着信元のMMEが着信のあったMTCDの集線処理状況を検索する。MMEは、その検索結果をページングメッセージ中にマッピングする。実施の形態7を用いた具体的な動作例を、図35および図36を用いて説明する。図35および図36は、実施の形態7における移動体通信システムのシーケンスを示す図である。図35と図36とは、境界線L3の位置で、つながっている。図35および図36において、図17、図26、図31および図32に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。また、HeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、MTCDのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がHSSである場合について開示する。また、実施の形態3を実行した場合について開示する。まず、MTCD_1がステップST1703の処理を行い、MTCD_nがステップST1704の処理を行う。次に、MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNB3007は、ステップST1705およびステップST1707の処理を行う。次に、MTCD_1がステップST2601の処理を行い、MTCD_nがステップST2602の処理を行う。次に、MTCD_1およびMTCD_nから送信されたアタッチメッセージを受信したHeNB3007は、ステップST2603において、ステップST2601で受信したMTCD_1からのアタッチメッセージと、ステップST2602で受信したMTCD_nからのアタッチメッセージとを集線処理する。つまり、アタッチメッセージの集線処理を行っている。これによって、本動作例では、集線処理を行う旨をコアネットワークへ登録する。次に、ステップST3301において、HeNB3007は、ステップST2603で集線処理を行うことによって集線されたアタッチメッセージと、集線処理を行う旨とをMMEへ通知する。アタッチメッセージには、集線処理の対象となったMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、HeNBの識別子と、TAIとが含まれる。アタッチメッセージ中に集線処理を行う旨を含ませてもよい。該通知には、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3を用いることができる。ステップST3302において、MMEは、HSSHomeSubscriberServerへアタッチメッセージとして受信したMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、集線処理を行う旨とを通知する。ステップST3303において、HSSは、アタッチ処理されたMTCD_1の識別子およびMTCD_nの識別子と、集線処理を行う旨とを登録し、管理する。登録および管理の際は、集線処理状況をMTCDの識別子と関連付けて行う。ステップST2607において、MMEが、MTCD_1宛の着信を受信した後、MMEは、ステップST2608の処理を行う。次に、ステップST3304において、MMEは、MTCD_1の集線状況をHSSへ問い合わせる。ステップST3305において、HSSは、MTCD_1の集線状況をMMEへ報告する。本動作例では、MTCD_1は、集線処理されているので、集線処理を行う旨が報告される。ステップST3306において、MMEは、ステップST3305で受信した集線状況報告に基づいて、MTCD_1が集線処理されたか否かを判断する。MTCD_1が集線処理されたと判断した場合は、ステップST3307へ移行する。MTCD_1が集線処理されていないと判断した場合は、ステップST3101へ移行する。本動作例では、MTCD_1は集線処理されており、ステップST3305において集線処理を行う旨が報告されている。したがって、MTCD_1が集線処理されたと判断され、ステップST3307へ移行する。ステップST3307において、MMEは、MTCD_1宛のページングメッセージに集線処理した旨を追加する。したがって、ステップST3307の処理を実行する本動作例においては、ステップST3101において、MMEからHeNB3007へ通知されるMTCD_1宛のページングメッセージ中には、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子の他に、集線処理した旨が含まれる。同様に、ステップST3102において、MMEからHeNB3005へ通知されるMTCD_1宛のページングメッセージ中には、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子の他に、集線処理した旨が含まれる。同様に、ステップST3103において、MMEからHeNB3003へ通知されるMTCD_1宛のページングメッセージ中には、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子の他に、集線処理した旨が含まれる。ステップST3308において、HeNB3007は、ステップST3101で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップST3309へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップST3104へ移行する。本動作例では、ステップST3101で受信したページングに、集線処理した旨が含まれている。したがってステップST3308の処理の後は、ステップST3309へ移行する。ステップST3309において、HeNB3007は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3104へ移行する。自HeNBが集線処理能力を有していないと判断した場合は、ステップST3104およびステップST3105の処理を行わない。本動作例では、HeNB3007は集線処理能力を有するので、ステップST3104へ移行する。次にHeNB3007は、ステップST3104およびステップST3105の処理を行う。ステップST3310において、HeNB3005は、ステップST3102で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップST3311へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップST3106へ移行する。本動作例では、ステップST3102で受信したページングに集線処理した旨が含まれている。したがってステップST3310の処理の後は、ステップST3311へ移行する。ステップST3311において、HeNB3005は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3106へ移行する。自HeNBが集線処理能力を有していないと判断した場合は、ステップST3106およびステップST3107の処理を行わない。本動作例では、HeNB3005は集線処理能力を有していないので、ステップST3106およびステップST3107の処理を行わない。実施の形態3を実行した場合の無線リソースの無駄を説明する図31および図32では、図32のステップST3107に示すように、HeNB3005は、MTCD_1を受信することがない、無駄なMTCD_1宛のページングを通知する。本実施の形態では、図32のステップST3107に示すような無駄なページングを削減することができる。ステップST3312において、HeNB3003は、ステップST3103で受信したページングに、集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップST3313へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップST3108へ移行する。本動作例では、ステップST3103で受信したページングに集線処理した旨が含まれている。したがってステップST3312の処理の後は、ステップST3313へ移行する。ステップST3313において、HeNB3003は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3108へ移行する。集線処理能力を有していないと判断した場合は、ステップST3108およびステップST3109の処理を行わない。本動作例では、HeNB3003は集線処理能力を有するので、ステップST3108へ移行する。次にHeNB3003は、ステップST3108およびステップST3109の処理を行う。実施の形態7を用いた具体的な動作例を、図37および図38を用いて説明する。図37および図38は、実施の形態7における移動体通信システムの他のシーケンスを示す図である。図37と図38とは、境界線L4の位置で、つながっている。図37および図38において、図17、図26、図31~図36に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。また、HeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、MTCDのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がMMEである場合について開示する。また、実施の形態3を実行した場合について開示する。まず、MTCD_1がステップST1703の処理を行い、MTCD_nがステップST1704の処理を行う。次に、MTCD_1およびMTCD_nから送信されたRRCConnectionRequestを受信したHeNB3007は、ステップST1705およびステップST1707の処理を行う。次に、MTCD_1がステップST2601の処理を行い、MTCD_nがステップST2602の処理を行う。次に、MTCD_1およびMTCD_nから送信されたアタッチメッセージを受信したHeNB3007は、ステップST2603およびステップST3301の処理を行う。次に、ステップST3401において、MMEは、ステップST3301のアタッチメッセージで受信したMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、集線処理を行う旨とを登録し、管理する。登録および管理の際は、集線処理状況をMTCDの識別子と関連付けて行う。次に、MMEがステップST2605の処理を行い、HSSがステップST2606の処理を行う。ステップST2607において、MMEが、MTCD_1宛の着信を受信した後、MMEは、ステップST2608の処理を行う。次に、ステップST3402において、MMEは、MTCD_1の集線状況を検索する。ステップST3402の処理の後は、図36と同様に、MMEは、ステップST3306、ステップST3307、ステップST3101~ステップST3103の処理を行う。また、HeNB3007は、ステップST3308、ステップST3309、ステップST3104およびステップST3105の処理を行う。またHeNB3005は、ステップST3310、ステップST3311、ステップST3106およびステップST3107の処理を行う。またHeNB3003は、ステップST3312、ステップST3313、ステップST3108およびステップST3109の処理を行う。本動作例では、図36に示すシーケンスと同様に、ステップST3311において、HeNB3005は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3106へ移行する。自HeNBが集線処理能力を有していないと判断した場合は、ステップST3106およびステップST3107の処理を行わない。本動作例では、HeNB3005は集線処理能力を有していないので、ステップST3106およびステップST3107の処理を行わない。実施の形態3を実行した場合の無線リソースの無駄を説明する図31および図32では、図32のステップST3107に示すように、HeNB3005は、MTCD_1を受信することがない、無駄なMTCD_1宛のページングを通知する。本実施の形態では、図32のステップST3107に示すような無駄なページングを削減することができる。実施の形態7を用いた具体的な動作例を、図39および図40を用いて説明する。図39および図40は、実施の形態7における移動体通信システムの他のシーケンスを示す図である。図39と図40とは、境界線L5の位置で、つながっている。図39および図40において、図26、図27および図31~図36に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。また、HeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、集線処理の際にAttachprocedureを選定した場合について開示する。また、登録するエンティティの具体例がHSSである場合について開示する。また、実施の形態4を実行した場合について開示する。まず、MTCD_1がステップST2701の処理を行い、MTCD_nがステップST2702の処理を行う。次に、HeNB3007が、ステップST2703およびステップST2704の処理を行う。次に、ステップST2705において、HeNB3007は、集線処理を行う。本動作例においては、MTCD_1およびMTCD_nからのコアネットワークへのデータをまとめてMMEへ通知する。また3GPP以外によるアクセスであるステップST2701およびステップST2702の内容を解釈し、設置に関するアクセスであると理解する。次に設置に関するアクセスに即した3GPP内のプロトコルとしてAttachprocedureを選定する。集線処理の際にAttachprocedureを選定している。したがって、本動作例では集線処理を行う旨をコアネットワークへ登録する。ステップST3501において、HeNB3007は、ステップST2705で集線処理を行うことによって集線されたアタッチメッセージと、集線処理を行う旨とをMMEへ通知する。アタッチメッセージには、集線処理の対象となったMTCDの識別子であるMTCD_1の識別子およびMTCD_nの識別子と、HeNBの識別子と、TAIとが含まれる。アタッチメッセージ中に集線処理を行う旨を含ませてもよい。該通知には、実施の形態2、実施の形態2の変形例1、実施の形態2の変形例2および実施の形態2の変形例3を用いることができる。ステップST3501の処理の後は、MMEは、ステップST3302、ステップST2608、ステップST3304、ステップST3306、ステップST3307およびステップST3101~ステップST3103の処理を行う。またHSSは、ステップST3303、ステップST2607およびステップST3305の処理を行う。また、HeNB3007は、ステップST3308、ステップST3309、ステップST2707、ステップST2708、ステップST2709およびステップST2710の処理を行う。またHeNB3005は、ステップST3310、ステップST3311、ステップST3106およびステップST3107の処理を行う。またHeNB3003は、ステップST3312、ステップST3313、ステップST3201、ステップST3109、ステップST3202およびステップST3203の処理を行う。ステップST3310において、HeNB3005は、ステップST3102で受信したページングに集線処理した旨が含まれているか否かを判断する。集線処理した旨が含まれていると判断した場合は、ステップST3311へ移行する。集線処理した旨が含まれていないと判断した場合は、ステップST3106へ移行する。本動作例では、ステップST3102で受信したページングに集線処理した旨が含まれている。したがってステップST3310の処理の後は、ステップST3311へ移行する。ステップST3311において、HeNB3005は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3106へ移行する。自HeNBが集線処理能力を有していないと判断した場合は、ステップST3106およびステップST3107の処理を行わない。本動作例では、HeNB3005は集線処理能力を有していないので、ステップST3106およびステップST3107の処理を行わない。実施の形態4を実行した場合の無線リソースの無駄を説明する図33および図34では、図34のステップST3107に示すように、HeNB3005は、MTCD_1を受信することがない、無駄なMTCD_1宛のページングを通知する。本実施の形態では、図34のステップST3107に示すような無駄なページングを削減することができる。実施の形態7を用いた具体的な動作例を、図41および図42を用いて説明する。図41および図42は、実施の形態7における移動体通信システムの他のシーケンスを示す図である。図41と図42とは、境界線L6の位置で、つながっている。図41および図42において、図26、図27、図31~図36、図39および図40に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、前述の図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。また、HeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、MTCDのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がMMEである場合について開示する。また、実施の形態4を実行した場合について開示する。本動作例では、図39および図40に示すシーケンスと同様に、ステップST3311において、HeNB3005は、自HeNBが集線処理能力を有するか否かを判断する。自HeNBが集線処理能力を有すると判断した場合は、ステップST3106へ移行する。自HeNBが集線処理能力を有していないと判断した場合は、ステップST3106およびステップST3107の処理を行わない。本動作例では、HeNB3005は集線処理能力を有していないので、ステップST3106およびステップST3107の処理を行わない。実施の形態4を実行した場合の無線リソースの無駄を説明する図33および図34では、図34のステップST3107に示すように、HeNB3005は、MTCD_1を受信することがない、無駄なMTCD_1宛のページングを通知する。本実施の形態では、図34のステップST3107に示すような無駄なページングを削減することができる。実施の形態7により、実施の形態3および実施の形態4の効果に加えて、以下の効果を得ることができる。HeNBが、集線処理を行う旨を示す情報が含まれるページングメッセージを受信した場合、自HeNBが集線処理を行う能力を有する場合にページングメッセージを送信する。これによって、集線処理を行うMTCD宛のページングは、集線処理を行う能力を有していないHeNBからの通知を削減することができる。集線処理を行うMTCDが集線処理能力を有していないHeNBの傘下に存在することはない。したがって、無駄なHeNBからのページング送信のみを削減し、着信漏れを防ぎつつ、無線リソースを有効に活用することができ、干渉を削減することができる。実施の形態7変形例1.実施の形態7の変形例1で解決する課題について、以下に説明する。実施の形態7を用いた場合、以下の課題が発生する。図36を用いて課題を説明する。実施の形態7を用いることによって、集線処理を行うMTCD宛のページングは、集線処理を行う能力を有していないHeNBからの通知を削減することができる。一方で、図36のステップST3102などにおいて、集線処理を行う能力を有していないHeNBへ通知されないページングメッセージが通知される。したがって、通信リソースの無駄が発生し、図36のステップST3310およびステップST3311などにおいて、MME、あるいは集線処理を行う能力を有していないHeNBの無駄な処理の負荷が発生するという課題がある。実施の形態7の変形例1での解決策を以下に示す。実施の形態7の解決策と異なる部分を中心に説明する。説明していない部分については、実施の形態7と同様とする。HeNBにおいて集線処理を行う旨をMTCDの識別子とともに、コアネットワーク側であるMME、HSSなどへ登録する。集線処理を行うか否かの情報を、以下集線処理状況とも称する。集線処理を行うMTCD宛のページングが発生した場合、MMEは、集線処理を行う能力を有するHeNBに、ページングメッセージを送信する。集線処理を行うMTCD宛のページングが発生した場合、MMEは、集線処理を行う能力を有していないHeNBに、ページングメッセージを送信しない。MMEが、傘下のHeNBの集線処理を行う能力を把握する具体例を、以下に開示する。前述の実施の形態1の変形例3を用いて、HeNBがMTCDからのデータの集線処理に関する能力情報をコアネットワークであるMME、SGSNなどへ通知する。実施の形態7の変形例1を用いた具体的な動作例を、図43および図44を用いて説明する。図43および図44は、実施の形態7の変形例1における移動体通信システムのシーケンスを示す図である。図43と図44とは、境界線L7の位置で、つながっている。図43および図44において、図17、図26、図31、図32、図35および図36に示すステップに対応するステップについては、同一の参照符を付して、共通する説明を省略する。本動作例では、前述の図30に示すロケーション図を用いて説明する。HeNB3003とHeNB3007とが、集線処理を行う能力を有するHeNBとし、HeNB3005が、集線処理を行う能力を有していないHeNBとする。移動端末3009は、MTCDとし、MTCDの識別子をMTCD_1とする。また、HeNBが集線処理に関する能力情報をコアネットワークへ通知するタイミングの具体例として、HeNB設置時について開示する。また、HeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例として、MTCDのアタッチメッセージを集線する際について開示する。また、登録するエンティティの具体例がHSSである場合について開示する。また、実施の形態3を実行した場合について開示する。ステップST3701において、HeNB3007が設置される。ステップST3702において、HeNB3007は、MMEへHeNB3007の集線処理に関する能力情報を通知する。ステップST3703において、HeNB3005が設置される。ステップST3704において、HeNB3005は、MMEへHeNB3005の集線処理に関する能力情報を通知する。ステップST3705において、HeNB3003が設置される。ステップST3706において、HeNB3003は、MMEへHeNB3003の集線処理に関する能力情報を通知する。ステップST3707において、MMEは、傘下のHeNBの能力情報を登録し、管理する。登録および管理の際は、能力情報をHeNBの識別子と関連付けて行う。ステップST3306において、MMEは、ステップST3305で受信した集線状況報告に基づいて、MTCD_1が集線処理されたか否かを判断する。MTCD_1が集線処理されたと判断した場合は、ステップST3708へ移行する。MTCD_1が集線処理されていないと判断した場合は、ステップST3101へ移行する。本動作例では、MTCD_1は集線処理されており、ステップST3305で集線処理を行う旨が報告されている。したがって、MTCD_1が集線処理されたと判断され、ステップST3708へ移行する。ステップST3708において、MMEは、傘下のHeNBのうち集線処理を行う能力を有するHeNBを選定する。選定には、ステップST3707で登録した情報を用いるとよい。本動作例では、HeNB3003とHeNB3007とが集線処理を行う能力を有するHeNBであると選定される。一方、HeNB3005は、集線処理を行う能力を有するHeNBであると選定されない。MMEは、集線処理を行う能力を有するHeNBにページングメッセージを送信し、集線処理を行う能力を有していないHeNBにページングメッセージを送信しない。したがって、ステップST3101において、MMEは、HeNB3007へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3103において、MMEは、HeNB3003へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。MMEは、HeNB3005へMTCD_1宛のページングを通知しない。図36では、ステップST3102に示すように、通知されないページングメッセージが、MMEからHeNB3005へ通知される。本実施の形態では、図36のステップST3102に示すような無駄な通信を削減することができる。一方、ステップST3306において、MMEが着信のあった移動端末を集線処理されていないと判断した場合、ステップST3101において、MMEは、HeNB3007へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3102において、MMEは、HeNB3005へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。ステップST3103において、MMEは、HeNB3003へMTCD_1宛のページングを通知する。該ページングには、MTCD_1のトラッキングエリアリストおよびMTCD_1の識別子が含まれる。本変形例では、実施の形態3と組み合わせた例について主に記載したが、実施の形態4とも組み合わせて用いることができる。実施の形態7の変形例1により、実施の形態7の効果に加えて、以下の効果を得ることができる。MMEが、集線処理を行うMTCD宛のページングメッセージを受信した場合、集線処理を行う能力を有するHeNBにページングメッセージを送信する。これによって、集線処理を行うMTCD宛のページングの、集線処理を行う能力を有していないHeNBへの通知を削減することができる。集線処理を行うMTCDが集線処理能力を有していないHeNBの傘下に存在することはない。したがって、無駄なHeNBへのページング通知のみを削減し、着信漏れを防ぎつつ、通信リソースを有効に活用することができ、MMEあるいは集線処理を行う能力を有していないHeNBの処理の負荷を軽減することができる。実施の形態7変形例2.実施の形態7の変形例2で解決する課題について、以下に説明する。実施の形態7を用いた場合、以下の課題が発生する。図35および図36を用いて課題を説明する。実施の形態7を用いることによって、集線処理を行うMTCD宛のページングは、集線処理を行う能力を有していないHeNBからの通知を削減することができる。一方で、MTCDの集線処理を行っていないHeNBからMTCD宛のページングは、図36のステップST3103およびステップST3109に示すように、以前通知される。無意味なページング送信は、無線リソースを有効に活用することができず、干渉が発生するという課題がある。実施の形態7の変形例2での解決策を以下に示す。HeNBは、HeNBで集線処理を行ったHeNBの識別子をMTCDの識別子とともに、コアネットワーク側であるMME、HSSなどへ登録する。実施の形態7と同様に、MTCD宛のページングが発生した場合は、ページングメッセージ中に集線処理を行ったHeNBの識別子を含ませる。HeNBが、集線処理を行ったHeNBの識別子が含まれるページングメッセージを受信した場合、HeNBの識別子が自HeNBのものであった場合に、ページングメッセージを送信する。HeNBが集線処理を行ったHeNBの識別子をコアネットワークへ登録するタイミングの具体例については、実施の形態7のHeNBで集線処理を行う旨をコアネットワークへ登録するタイミングの具体例と同様であるので、説明を省略する。コアネットワークが、集線処理を行ったHeNBの識別子の登録を削除するタイミングの具体例としては、MTCDからのDetachprocedureを受信したときが挙げられる。登録方法の具体例を以下に開示する。MTCDの識別子と関連付けて集線処理を行ったHeNBの識別子を記憶する。登録するエンティティの具体例は、実施の形態7と同様であるので、説明を省略する。ページングが発生した場合に、ページングメッセージ中に集線処理を行ったHeNBの識別子を含ませる方法の具体例は、実施の形態7のページングが発生した場合にページングメッセージ中に集線処理を行った旨を示す情報を含ませる方法の具体例と同様であるので、説明を省略する。あるいは、実施の形態7の変形例1と同様に、集線処理を行うMTCD宛のページングが発生した場合、MMEは、集線処理を行ったHeNBにページングメッセージを送信する。集線処理を行うMTCD宛のページングが発生した場合、MMEは、集線処理を行ったHeNB以外のHeNBに、ページングメッセージを送信しない。実施の形態7の変形例2により、実施の形態7および実施の形態7の変形例1の効果に加えて、以下の効果を得ることができる。集線処理を行ったHeNB以外のHeNBからのMTCD宛のページングを削減することができる。あるいは、集線処理を行ったHeNB以外へのページング通知を削減することができる。集線処理を行うMTCDが、集線処理を行ったHeNB以外のHeNBの傘下に存在することはない。したがって、無駄なHeNBからのページング、あるいは無駄なHeNBへのページング通知のみを削減し、着信漏れを防ぎつつ、無線リソースを有効に活用することができ、通信リソースを有効に活用することができる。また、MMEあるいは集線処理を行う能力を有していないHeNBの処理の負荷を軽減することができる。本発明で開示した方法は、eNB/NBに限らず、HeNB、HNB、ピコeNBLTEピコセルEUTRANpicocell、ピコNBWCDMAピコセルUTRANpicocell、ホットゾーンセル用のノードなどの、いわゆるローカルノードにも適用できる。MTCサービスをサポートするローカルノードに、本発明で開示した方法を行うことで、コアネットワークにおける混雑を回避することが可能となる。以上の各実施の形態では、LTEシステムE-UTRANを中心に説明したが、本発明の通信システムは、W-CDMAシステムUTRAN、UMTSおよびLTEアドヴァンスドLTEAdvancedにも適用することが可能である。この発明は詳細に説明されたが、上記した説明は、すべての局面において、例示であって、この発明がそれに限定されるものではない。例示されていない無数の変形例が、この発明の範囲から外れることなく想定され得るものと解される。"