ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージであって、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する前記制御メッセージをネットワーク側から受信し、受信した前記制御メッセージに含まれている前記特定の条件を参照して、前記特定の条件に当てはまる場合には、前記通信モードを変更するよう制御する通信制御部を有する通信ノード。前記通信制御部が、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部と、ネットワークノードへ、前記高優先度モードによる前記イベント通知メッセージの送信又は前記ノーマルモードによる前記センシングデータの送信を行う送信部と、特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信した前記ネットワークノードから、前記任意の通信ノードからのイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示する前記メッセージを受信するメッセージ受信部と、前記メッセージを受信した場合に、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するかどうかを判断するモード遷移判断部とを、有し、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると前記モード遷移判断部が判断した場合には、前記動作モード制御部が、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう構成されている請求項1に記載の通信ノード。前記モード遷移判断部が、自通信ノードの種類を示す種別情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類を示す種別情報が前記メッセージに含まれている場合には、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると判断するよう構成されている請求項2に記載の通信ノード。前記モード遷移判断部が、自通信ノードの種類を示す種別情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類を示す種別情報が前記メッセージに含まれていない場合は、さらに、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認し、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれている場合には、前記送信モードを前記高優先度モードへ遷移するか又は前記高優先度モードのまま維持すると判断するよう構成されている請求項3に記載の通信ノード。前記通信制御部が、自通信ノードの種類と前記メッセージに含まれているラベル情報とが関連付けられているかどうかを示すイベントグループ情報を保持するイベントグループ情報保持部を有し、前記モード遷移判断部が、前記イベントグループ情報に基づいて、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認するよう構成されている請求項4に記載の通信ノード。前記送信モードを前記高優先度モードへ遷移するか又は前記高優先度モードのまま維持する対象の種別情報が前記イベントグループ情報に登録されており、前記モード遷移判断部が、前記メッセージに含まれているラベル情報に対応するイベントグループ情報に、前記メッセージに含まれている種別情報が登録されているかどうかを確認することで、自通信ノードの種類と関連付けられているラベル情報が前記メッセージに含まれているかどうかを確認するよう構成されている請求項5に記載の通信ノード。自通信ノードの種類を示す種別情報が前記メッセージに含まれており、前記送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持すると判断した後は、前記送信モードを前記高優先度モードへ遷移するよう指示する別のメッセージを受信した場合であっても、前記送信モードを前記ノーマルモードのまま維持するよう構成されている請求項2に記載の通信ノード。前記通信制御部が、ネットワークにおいて混雑状態が検知された場合にネットワークノードから送信されるメッセージであって、マシンタイプ通信において規定されている耐時間性機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を含む前記メッセージを受信するメッセージ受信部と、前記メッセージを受信した場合、自通信ノードが前記耐時間性機能を有しているか否かを判断する機能判断部と、前記耐時間性機能を有していると判断された場合、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御する接続制御部とを、有する請求項1に記載の通信ノード。前記通信制御部が、前記メッセージに特定の付加条件が設定されており、自通信ノードが前記付加条件に当てはまるかどうかを判断する付加条件判断部を更に有し、前記接続制御部が、前記付加条件判断部における判断結果に更に基づいて、前記ネットワークとの間で確立されている接続を切断する、若しくは、前記ネットワークとの間で確立されている接続は維持したままデータ送信を制御するか、又は、前記ネットワークとの間で接続が確立されていない場合には前記ネットワークへの接続要求を行わないように制御するよう構成されている請求項8に記載の通信ノード。ネットワーク側のエンティティが他の通信ノードからの通知に応じて送信する制御メッセージ、又は、前記他の通信ノードとの間の通信状況に応じて送信する制御メッセージに、特定の条件に当てはまる通信ノードの通信モードを変更するよう指示する情報を含ませ、前記特定の条件に当てはまる通信ノードの通信モードを変更させるよう制御する通信制御部を有するネットワークノード。特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、前記センサによって前記特定のイベントの発生を検知したことを通知するイベント通知メッセージを前記ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行う前記複数の通信ノードと接続されている前記ネットワークノードであって、前記通信制御部が、前記複数の通信ノードのいずれか1つから、特定のイベントの発生を検知したことを通知する前記イベント通知メッセージを受信する受信部と、前記イベント通知メッセージに対する応答として、送信モードを前記ノーマルモードへ遷移するか又は前記ノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部と、前記メッセージを前記複数の通信ノードへ送信するメッセージ送信部とを、有する請求項10に記載のネットワークノード。前記イベント通知メッセージを送信した通信ノードの種類と同じ種類の通信ノードの送信モードを前記ノーマルモードへ遷移させるか又は前記ノーマルモードのまま維持させるため、前記メッセージ作成部が、前記イベント通知メッセージを送信した通信ノードの種類を示す種別情報を前記メッセージに挿入するよう構成されている請求項11に記載のネットワークノード。前記複数の通信ノードのうちの特定の種類の通信ノードの送信モードを前記高優先度モードへ遷移させるか又は前記高優先度モードのまま維持させるため、前記メッセージ作成部が、前記複数の通信ノードのうちの特定の種類の通信ノードと関連付けられているラベル情報を前記メッセージに挿入するよう構成されている請求項12に記載のネットワークノード。通信ノードの種類とラベル情報との関連付けを示すイベントグループ情報を保持するイベントグループ情報保持部を有し、前記メッセージ作成部が、前記イベントグループ情報に基づいて、前記メッセージに挿入するラベル情報を選択するよう構成されている請求項13に記載のネットワークノード。前記通信制御部が、混雑状態が検知された場合に、マシンタイプ通信において規定されている時間制御機能を有している通信ノードは前記ネットワークへの接続を抑制するよう指示する情報を前記メッセージに含ませるメッセージ作成部を有する請求項10に記載のネットワークノード。ネットワーク内のエンティティとの間に第1の接続を確立している通信ノードが、第2の接続を確立するための接続確立方法であって、前記第2の接続を確立するための接続確立要求メッセージが拒絶された場合に、前記第1の接続の優先度と、前記第2の接続の優先度を比較するステップと、前記第2の接続の優先度が前記第1の接続の優先度より高い場合に、前記第1の接続に割り当てられている第1のQoS情報と、前記第2の接続に必要となる第2のQoS情報を比較し、前記第1のQoS情報を前記第2のQoS情報に再使用できるか判断するステップと、前記第1のQoS情報を前記第2のQoS情報に再使用できると判断する場合に、前記第2の接続を確立するために前記第1の接続を修正するステップと、を有する接続確立方法。前記第1の接続の接続先と、前記第2の接続の接続先が同じであるか確認するステップを更に有する請求項16に記載の接続確立方法。前記第2の接続を確立するために前記第1の接続を修正する前記ステップは、前記第1の接続をリリースした後、前記第2の接続を確立するための前記接続確立要求メッセージを送信する請求項16に記載の接続確立方法。前記優先度は、前記通信ノードが保持する情報から取得する請求項16に記載の接続確立方法。前記優先度は、前記通信ノードが利用するアプリケーションから取得する請求項16に記載の接続確立方法。前記第2のQoS情報は、前記通信ノードが保持する情報から取得する請求項16に記載の接続確立方法。前記第2のQoS情報は、前記通信ノードが利用するアプリケーションから取得する請求項16に記載の接続確立方法。前記第2のQoS情報は、前記通信ノード以外の通信ノードから取得する請求項16に記載の接続確立方法。ネットワーク内のエンティティとの間に接続を確立する通信ノードであって、前記エンティティとの間に前記接続を確立するための接続確立要求メッセージを送信する送信部と、前記通信ノードが、前記エンティティとの間に確立された第1の接続を保持している際、前記送信部が送信した前記第2の接続を確立するための前記接続確立要求メッセージが拒絶された場合に、前記第1の接続の優先度と、前記第2の接続の優先度を比較する比較部と、前記第2の接続の優先度が前記第1の接続の優先度より高い場合に、前記第1の接続に割り当てられている第1のQoS情報と、前記第2の接続に必要となる第2のQoS情報を比較し、前記第1のQoS情報を前記第2のQoS情報に再使用できるか判断する判断部と、前記第1のQoS情報を前記第2のQoS情報に再使用できると判断する場合に、前記第2の接続を確立するために前記第1の接続を修正する修正部とを、を有する通信ノード。以下、図面を参照しながら、本発明の第1~第3の実施の形態について説明する。<システム構成>まず、図1を参照しながら、本発明の第1~第3の実施の形態に共通するシステム構成について説明する。図1は、本発明の第1~第3の実施の形態に共通するシステム構成の一例を示す図である。上述のように、図1に図示されている通信システムは、少なくともMTCデバイス100、UE105、MTCデバイス100やUE105と無線接続する基地局eNB又はNB110、E-UTRAN115上のMTCデバイス100やUE105の移動管理を担当するMME120、MTCデバイス100やUE105のE-UTRAN115に対するユーザデータ配信制御を行うSGW130、MTCデバイス100やUE105に対するアドレス割り当てやPDN155とSGW130間のユーザデータ転送並びに経路制御を行うPGW140、MTCデバイス100やUE105のサブスクリプションデータ並びに通信コンテキストなどを管理保持しているHSS125、MTCデバイス100による通信の制御や状態管理、アプリケーションサービスの提供などを行うサーバであるMTCサーバ150、MTCデバイス100やMTCサーバ150に対してアプリケーションの管理制御やアプリケーションデータの管理を実施するMTCユーザ160を有している。なお、MTCユーザ160は、また、HSS125の代わりに、AAAAuthenticationauthorizationandAccountingサーバを用いてもよい。また、AAAサーバとHSS125は、物理的又は論理的に同一の装置に実装されるものであってもよい。なお、図1において、MTCサーバ150はPDN155内に位置しているが、通信システムのオペレータドメイン内に位置していてもよく、例えば、PGW140がMTCサーバ150の機能を担ってもよい。ここで、MTCデバイス100は少なくとも1つ以上の通信インタフェースを持ち、通信システム例えば、E-UTRAN115に接続することが可能である。なお、MTCデバイス100は、図示されている通信システム以外のネットワーク例えば、UTRAN、WLANWirelessLANネットワークやWiMAXネットワークに、同時に、あるいは排他的に接続するものであってもよい。MTCデバイス100は、接続した通信システムを通じて、MTCサーバ150と通信可能であり、MTCサーバ150はMTCユーザ160と通信可能である。また、MTCデバイス100は、通信システム内で従来のUE105と共存しながら通信を行う。なお、図1では、MTCデバイス100とUE105とがそれぞれ異なるeNB110に接続しているが、MTCデバイス用のeNB110が区別されているわけではなく、どのeNB110と接続してもよいものとする。しかし、今後、MTCデバイス100が、MTCデバイス100用にカスタマイズされたeNB110のみに接続が許されるという環境に変化した場合、MTCデバイス100はMTCデバイス100用のeNB110に接続されてもよい。また、各MTCデバイス100は、UE105と同様にMTCデバイス100を識別するためのID以降、デバイスIDと呼ぶが割り当てられていることとする。同様に、MTCデバイス100がMTCグループを形成する場合、MTCグループを識別するためのID以降、グループIDと呼ぶが割り当てられていることとする。同様に、MTCデバイス100は、デバイスの種類例えば、煙センサを識別するためのID以降、デバイス種IDと呼ぶが割り当てられていることとする。なお、MTCデバイス100の種類は、そのMTCデバイス100が搭載又は接続されている装置の種類によって決まる。また、MTCデバイス100の種類は、MTCサーバ、MTCユーザ、又は、通信システムのオペレータによって設定されてもよい。なお、MTCデバイス100、通信システムのエンティティ例えば、MME120、PGW140など、MTCサーバ150が、デバイス種IDを用いずに、MTCデバイス100の種類を識別することができるのであれば例えば、デバイスIDのうちデバイス種別を示す一部のビット列例えば、上位あるいは下位数ビットからMTCデバイス100の種類を導出、必ずしも本デバイス種IDを用いる必要はない。また、デバイスIDも同様に、例えばIMEIInternationalMobileEquipmentIdentityやIMSIInternationalMobileSubscriberIdentityを用いることで、MTCデバイス100を一意に識別できるのであれば、新たに割り当てる必要はない。また、グループIDも同様に、例えばデータを転送するPDNコネクション、EPSベアラを共有する場合例えば、MTCグループの中で代表するMTCデバイス100が、通信システムとPDNコネクション、EPSベアラを確立していて、代表するMTCデバイス100が同MTCグループに属する他のMTCデバイス100が取得したデータを転送する場合には、PDNコネクションIDやEPSベアラID、APNAccessPointNameを用いることでMTCグループを識別できるのであれば、新たに割り当てる必要はない。また、各MTCデバイス100には、例えばMTCユーザ160などによって事前にMTCの機能MTCFeaturesが組み込まれていてもよく例えば、SIMカードに書き込む、MTCデバイス100の記憶メモリに書き込む、ネットワーク装置例えば、MME120やMTCサーバ150などやMTCデバイス100自身が、所望のMTCの機能を有効化/無効化するものであってもよい。上記のようなMTCデバイス100のデバイスID、グループID、デバイス種ID、搭載しているMTCの機能、MTCの機能の有効化/無効化など、MTCに関連する様々な情報は、HSS125が保持するサブスクリプションデータや通信コンテキストなどに登録されているものとする。また、E-UTRAN115におけるMTCデバイス100のモビリティ制御は、UE105に対する制御と同様にMME120が実施する。また、MTCサーバ150は、通信システムを運用するオペレータが管理する場合と、オペレータ以外の運用者が管理する場合がある。いずれの場合も、オペレータが管理するPGW140とのインタフェースを有し、通信システムに接続するMTCデバイスから/へのユーザデータ転送、通信システムにおけるMTCデバイスの制御に関するサービスを享受する。なお、オペレータがMTCサーバを管理する場合、MTCサーバとPGW140を同一装置内に実施するものであってもよく、これによって外部インタフェースの実装を装置内に隠蔽して装置コストの削減を図ることができる。また、MTCユーザ160は、各MTCデバイス100が取得したデータを管理利用する主体であり、事業運営者や企業、またデータ管理を実施する制御主体PC、サーバなどに相当する。例えば、MTCデバイス100が自動販売機に組み込まれていることを想定すると、MTCユーザ160は自動販売機の売り上げ集計やメンテナンスを実施する会社などである。また、MTCデバイス100を煙センサに組み込まれていることを想定すると、MTCユーザ160は消防署や警備会社、保険会社、又は住宅の火災による被害の軽減を担当する会社などであると考えられる。なお、MTCユーザ160は、上記のようにMTCの管理を行うユーザが使用するMTCユーザ端末と考えてもよく、あるいは、MTCの管理を行うユーザが操作するMTCサーバ150と同一の装置であると考えてもよい。また、一般的に、MTCデバイス100とMTCサーバ150との間で交換されるデータは、アプリケーションレベルのデータであるため、MTCデバイス100とPGW140との間のデータ転送は、UプレーンUserplane:ユーザプレーンの利用が想定される。しかし、アプリケーションやサービスの内容や性質例えば、生存者確認など緊急性を伴うデータ転送向けサービス、通信システムのネットワークオペレータの要求例えば、ネットワーク装置例えば、MME120による制御が必要となる場合例えば、MTCデバイス100の位置情報の変更や、MTCグループ/同一デバイス種などの制御、MTCデバイス100/MTCサーバ150の要求例えば、迅速に、又は、高い信頼度でデータを送信/取得したい場合によっては、即時性や信頼性を有するCプレーンControlplane:制御プレーンを利用するシグナリングメッセージにアプリケーションデータを重畳、あるいはピギーバックすることによる効果が大きい場合がある。また、イベント検知時に優先度の高いイベント通知メッセージを送信するMTCデバイス100は、取得したデータセンシングデータとも呼ぶからイベントを検出すると、優先度の高いイベント通知メッセージをMTCサーバに送信し、同時に、あるいは続けて、取得したデータセンシングデータをMTCサーバに送信するものとする。また、上記の構成を有する通信システムにおいて、MTCデバイス100は、通信システムE-UTRAN115に接続されており、通信システムを通じてMTCサーバ150と通信可能であるとする。<第1の実施の形態>以下、本発明の第1の実施の形態におけるシステム動作の一例について、図3を用いて詳しく説明する。図3は、本発明の第1の実施の形態におけるシステム動作の一例複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法を説明するためのシーケンス図である。なお、図3には、図1に図示されているシステム構成における処理シーケンスの一例が図示されている。ここで、本実施の形態の説明を容易化するために、MTCデバイス100は以下のような特徴を持っていることを前提とする。MTCデバイス100は、非特許文献1で定義されているTimeControlledと、PAMと、Groupbasedと、Lowmobilityとを有しているとする。MTCデバイス100は、他の複数のMTCデバイス100と共に1つのMTCグループとして管理されていることとする。また、MTCグループ内のMTCデバイス100は、煙センサ、炎センサ、人感センサで構成されているものとする実際には、各センサにMTCデバイス100である通信モジュールが実装される。煙センサは、一定値以上あるいは所定時間連続して一定値以上の煙濃度を検出した場合、すなわちイベント煙を検知した際に、火災が発生している可能性が高いと判断し、高い優先度高優先度モードとも呼ぶでメッセージを送信する。炎センサはイベント炎を検知した際、火災が発生している可能性が高いと判断し、煙センサと同様に、高い優先度高優先度モードでメッセージを送信する。一方、人感センサはイベント人の有無を検知した際、一般的な優先度ノーマルモードとも呼ぶでセンシングデータを送信する。ここで、高優先度モードとは、イベントを検知した際に優先度の高いイベント通知メッセージを送信する状態である。またノーマルモードとは、イベントを検知した際に優先度の高いイベント通知メッセージは送信せずに、取得したデータを一般的な優先度で送信する状態、又は、一般的な優先度でイベント通知メッセージを送信し、取得したデータも同様に一般的な優先度で送信する状態である。なお、メッセージの優先度は、EPSベアラのQCIや、EPSベアラの帯域幅例えば、MBRMaximumBitRateやAMBRAggregateMaximumBitRate、MTCデバイス100が持つIMSIやIMEIの値、PCCPolicyandChargingControl、MTCFeature/MTCデバイス100の種類/MTCサービス毎に定義される優先度や値などで定義されてもよい。図3では、MTCグループ内のMTCデバイス100を識別するために、MTCデバイスA100AとMTCデバイスB100Bとが図示されている。なお、ここでは、MTCデバイスA100Aを、最初にイベントを検知するMTCデバイス煙センサと仮定し、MTCデバイス100Bを、MTCデバイスA100Aと同一のMTCグループに属する他のMTCデバイス煙センサ、炎センサ、人感センサと仮定する。なお、図3では2つのMTCデバイス100MTCデバイスA100A、MTCデバイスB100Bしか存在していないが、3つ以上のMTCデバイス100が同じMTCグループ内に存在する場合でも、同様に動作する。以下、図3に図示されているシーケンスについて説明する。MTCデバイスA100A煙センサは、MTCサーバ150と通信を行うためのPDNコネクションを、従来手法例えば、非特許文献3で示されるAttachprocedureに基づいてPGW140と確立する図3のステップS201:PDNコネクション確立済み。また、MTCデバイスB100Bも、従来手法例えば、非特許文献3で示されるAttachprocedureに基づいてPGW140とPDNコネクションを確立する図3のステップS206:PDNコネクション確立済み。ここで、MTCデバイスA100Aが、例えば、火災発生などにより、イベント煙を検知したとする図3のステップS202:イベント検知。イベントを検知したMTCデバイスA100Aは、イベントを検知したことをMTCサーバ150に通知するためのメッセージここでは、イベント通知メッセージデバイスAと表記を送信する。なお、MTCデバイスA100A煙センサが煙を検知した場合は、火災が発生している可能性が高いと予測され、MTCデバイスA100Aは優先度の高いメッセージ例えば、PAMを用いて、MTCサーバ150に通知する図3のステップS203:イベント通知メッセージデバイスA。また、これ以降、優先度の高いメッセージとは、PAMや、他のNASメッセージより優先度が高いNAS/ASメッセージなどを指す。また、この優先度の高いメッセージは、EventNotification、AlarmSignaling、EventAlert、Emergencysignaling、EventDetectionMessageなどと呼ばれてもよい。なお、このMTCデバイスA100Aから送信される優先度の高いメッセージであるイベント通知メッセージデバイスAは、例えば、非特許文献1が定義するPAMや、非特許文献3で記述されているTAUTrackingAreaUpdateRequestなどの位置登録メッセージにピギーバック重畳した場合、又は、PDNコネクションやEPSベアラが確立されていない状態でイベントを検知した場合は、PDNコネクションやEPSベアラを確立する際に用いられる、例えば、AttachRequestやServiceRequest、非特許文献4にて定義されるDSMIPv6bootstrappingbasedonIKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTHRequestメッセージを用いてもよい。また、BearerModificationRequestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でMTCデバイス100からのイベント通知を実施することができる。通信システムのエンティティ例えば、MME120は、MTCグループに属しているMTCデバイスA100Aから、イベントを検知したことを知らせる優先度の高いイベント通知メッセージを受信すると、SGW130/PGW140を通じて、MTCサーバ150にイベント通知メッセージデバイスAを転送する。また、通信システムのエンティティ例えば、MME120は、後続する優先度の高いイベント通知メッセージ同一イベント例えば、煙の発生、若しくは、そのイベント例えば、煙発生を引き起こした出来事例えば、火災発生によって引き起こされたイベント例えば、炎の発生によるイベント通知メッセージ例えば、PAMの送信を抑制するためのメッセージここでは、逆イベント通知メッセージと表記する。また、逆PAM、混雑回避メッセージ、TimeTolerantIndication、congestionindication、congestionpriorindication、PAMreductionindicationなどと呼ばれてもよいを、同グループの全てのMTCデバイス100にブロードキャストする図3のステップS204:逆イベント通知メッセージ。なお、通信システムのEntity例えば、MME120は、この逆通知メッセージに同種の優先度の高い通知メッセージの送信停止を示すパラメータを格納してもよい。また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元例えば、MME120の判断例えば、通信システムのオペレータによる事前設定によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。また、MME120は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ逆イベント通知メッセージを効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる。このとき、MME120は、MTCデバイスA100AがMTCグループに属しているか、また、MTCグループに属しているのであれば、どのMTCグループに属しているかを、MTCデバイスA100Aに対応するサブスクリプションデータをHSS125から取得してグループIDが登録されているかどうかで判断してもよい。若しくは、MTCデバイスA100Aがメッセージに格納したグループIDから、MTCデバイスA100Aがグループに属しているかどうかあるいは、どのグループに属しているかを判断してもよい。また、MME120が既にサブスクリプションデータを保持、又は、HSS125からサブスクリプションデータを取得する以外の方法例えば、外部サーバへの問合せなどにより、MTCデバイスA100AがMTCグループに属しているかどうかを確認してもよい。また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したMTCデバイスA100Aが属しているMTCグループ配下の全てのMTCデバイスMTCデバイスA100A及びMTCデバイスB100Bとしているが、GroupbasedFeatureが適用されないケースにおいては、例えば、MTCデバイスA100Aが接続しているeNB110やMME120あるいは特定のTrackingArea配下の全てのMTCデバイス100を逆イベント通知メッセージの送信対象としてもよい。この場合は、特定のエリアに位置するMTCデバイス100からの同じイベントによる優先度の高いイベント通知メッセージも回避することができる。また、MTCグループという概念を考慮せずに、優先度の高いイベント通知メッセージを回避できることにより、グループIDなどを用いなくてもよいという利点がある。ここでは、グループIDの代わりに、eNB110のID、若しくは、eNB110のアドレス並びにデバイスのベアラに対応するS1UTEIDを使用してもよい。また、MME120があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲通知範囲を限定することにより、システム全体へのインパクトを低減させることができる。なお、この逆イベント通知メッセージは、上記MME120以外の他の通信システムにおけるエンティティ例えば、eNB110、PGW140などや、MTCサーバ150が送信してもよい。逆イベント通知メッセージは、上述のように、後続する同種の優先度の高いイベント通知メッセージ同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージ例えば、PAMを抑制するためのメッセージである。具体的には、逆イベント通知メッセージは、MTCデバイス100に対してノーマルモードの動作を要請するメッセージであり、逆イベント通知メッセージを受信したMTCデバイス100は、高優先度モードで動作している場合はノーマルモードへモード遷移し、ノーマルモードで動作している場合は、そのままノーマルモードを維持する。また、優先度の高いイベント通知メッセージ例えば、PAMなどを回避する以外での逆イベント通知メッセージの使い方がある。例えば、通信システムのエンティティとMTCデバイス100が、複数の優先度レベルを認識することができ、MTCデバイス100が優先度の異なる複数のセンシングデータを送信したい場合、逆イベント通知メッセージを受信したMTCデバイス100は、例えば、逆イベント通知メッセージに格納されているネットワーク側が示す許容優先度レベルや、MTCデバイス100にあらかじめ組み込まれているコンテキスト例えば、混雑度レベル3のときは優先度レベル3以上のメッセージのみ送信許容やアプリケーションデータを用いて、送信可能なセンシングデータを選択/決定してもよい。このとき、例えば逆イベント通知メッセージを受信することで、MTCデバイス100は送信するセンシングデータの優先度の判別を行わないモード例えば、ノーマルモードから、優先度を考慮して送信するセンシングデータを選択/決定できるモード例えば、高優先度モードに切り替えてもよい。また、少なくともMTCデバイス100が複数の優先度レベルを認識することができる場合、ネットワーク側の装置例えば、MTCサーバ150やMME120によって送信された優先度レベルの変更を示しているメッセージなどによって、MTCデバイス100は例えば、送信するメッセージの優先度レベルを変更するなどの処理をしてもよい。これにより、ネットワークが混雑していてパケットロスが発生しているような状況において、MTCデバイス100自身が送信するメッセージの優先度レベルを考慮し、送信するメッセージを選択することで、更なる混雑状態を作ることを回避できる。逆イベント通知メッセージを受信したMTCデバイスA100Aは、逆イベント通知メッセージに従って、図7のように高優先度モードからノーマルモードにモード遷移を行うステップS205:モード切替。そして、その後は、MTCデバイスA100Aは、ノーマルモードでセンシングデータの送信を行う図3のステップS210:取得データ送信。なお、図3のステップS210の取得データ送信は、ステップS205のモード切替後の任意のタイミングに行われる。また、ここでは、最初にイベント通知メッセージを送信したMTCデバイスA100Aが、逆イベント通知メッセージの受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージの送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージを送信したMTCデバイスA100Aに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。また、逆イベント通知メッセージを受信したMTCデバイスB100Bは、自らイベントを検知した際に高い優先度のイベント通知メッセージ例えば、PAMなどを用いてMTCサーバ150にイベントを検知したことを通知するMTCデバイス例えば、他の煙センサや炎センサなどであっても、逆イベント通知メッセージの受信に応じて図7のように高優先度モードからノーマルモードにモード遷移する図3のステップS207:モード切替。そして、その後、イベントを検知したとしても図3のステップS208:イベント検知、高い優先度のイベント通知メッセージ例えば、PAMなどの送信を行わず図3のステップS207:モード切替、ノーマルモードでセンシングデータの送信を行う図3のステップS209:取得データ送信。なお、MTCデバイスB100Bが、通常時からノーマルモードでセンシングデータをMTCサーバ150に送信している人感センサのようなMTCデバイスの場合には、送信モードをノーマルモードのままに維持する。また、ステップS207の高優先度モードからノーマルモードにモード遷移後にイベントを検知した際、高優先度ではなく一般的な優先度でイベント通知メッセージを通知し、その後にセンシングデータを送信してもよい。なお、上述のように、イベントを検知した際に高い優先度のイベント通知メッセージを用いてイベントを検知したことをMTCサーバ150に通知していたMTCデバイス100例えば、煙センサや炎センサは、逆イベント通知メッセージの受信によってノーマルモードへモード遷移するが、例えば、一定時間後例えば、逆イベント通知メッセージでライフタイム値を通知など、又は、MME120やMTCサーバ150から送信されるメッセージ例えば、NASメッセージなどを受信することで、ノーマルモードから高優先度モードに戻すようにしてもよい。これにより、1つのイベントが終了した後は、従来と変わらない動作に戻すことができる図3には不図示。<第2の実施の形態>第1の実施の形態の解決手法によれば、本発明が目的としている冗長なイベント通知メッセージの送信を抑制することは実現できているが、優先度の高い必要なイベント通知メッセージの送信さえも抑制してしまう場合がある。例えば、煙センサが煙の発生を検出した場合、逆イベント通知メッセージによってすべてのMTCデバイス100例えば、炎センサなどがノーマルモードへ遷移してしまう。その結果、煙の発生後、さらに炎センサが炎を検知した場合であっても、炎センサは、高い優先度のイベント通知メッセージ例えば、PAMなどを送信することはできない。また、例えば、上記した複数のマンション群のセキュリティを監視している環境において、通常災害が発生していないとき人感センサは緊急性が要求されていないため、検知したイベント/取得したデータをノーマルモードでMTCサーバ150に定期的あるいは所定のタイミングで送信する。しかしながら、煙センサが煙を検知した環境においては、火災が発生している可能性が高いため、人の有無に関する情報は重要度が高くなる。そのため、人感センサが検知した人の有無に関する情報は、一般的な優先度ノーマルモードではなく、高い優先度でイベント通知メッセージ例えば、PAMなどを用いて通知しないといけない。このように、通常はノーマルモードで人の有無に関する情報を送信していたMTCデバイス100人感センサが、同じMTCグループに属しているMTCデバイス100、若しくは周辺のMTCデバイス100が検知したイベントにより、高い優先度のイベント通知メッセージ例えば、PAMなどでイベントの検知人の有無に関する情報を通知できるようにしたいという要望がある。また、煙センサが煙を検知し、火災が発生している可能性が高い環境では、人は一斉に走って逃げることが想定される。このとき、人感センサが、例えば一定の人の歩行速度と密度を超えたとき、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。また、通信システムのオペレータ、MTCサーバ150やMTCユーザ160などの要求によって、MTCデバイス100間で通信が可能である環境において、周辺のMTCデバイス100から一定の値以上のメッセージを受信した場合例えば、アドホックネットワークのような環境において、一定時間内に一定値以上のパケットを転送した場合など、優先度の高いイベント通知メッセージを通知するように設定されている場合も考えられる。なお、MTCデバイス100が、イベントを検知した際に、イベント通知メッセージのみを通知する、又は、取得したデータのみ送信する、若しくは、イベント通知メッセージと取得したデータを送信するメッセージの両方のメッセージを送信するかは、例えばMTCデバイス100自身、通信システムのオペレータ、MTCサーバ150やMTCユーザ160などによって決まるものとする。第1の実施の形態における解決法通信システムのエンティティ、若しくは、MTCサーバ150が、イベントを検知したMTCデバイス100から送信される優先度の高いイベント通知メッセージ受信後、対象となるMTCグループに属する複数のMTCデバイス100が送信する可能性のある優先度の高いイベント通知メッセージを抑制することを目的としたメッセージを送信する方法では、全てのデバイスに一律に送信停止を指示していたため、上述のようなケースにおいて、必要なイベント通知メッセージ例えば、煙センサがPAMを送信した後の、炎センサ又は人感センサからのPAMなどを受信することができなくなってしまう。したがって、第1の実施の形態の改良系を第2の実施の形態で示す。以下、本発明の第2の実施の形態におけるシステム動作の一例について、図4を用いて詳しく説明する。図4は、本発明の第2の実施の形態におけるシステム動作の一例複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法を説明するためのシーケンス図である。なお、図4には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、本実施の形態の説明を容易化するために、MTCデバイス100は以下のような特徴を持っていることを前提とする。MTCデバイス100は、非特許文献1で定義されているTimeControlledと、PAMと、Groupbasedと、Lowmobilityとを有しているとする。MTCデバイス100は、他の複数のMTCデバイス100と共に1つのMTCグループとして管理されていることとする。また、MTCグループ内のMTCデバイス100は、煙センサ、炎センサ、人感センサで構成されているものとする。煙センサはイベント煙を検知すると、火災が発生している可能性が高いと判断し、高い優先度高優先度モードでメッセージを送信する。炎センサはイベント炎を検知すると、火災が発生している可能性が高いと判断し、煙センサと同様に、高い優先度高優先度モードでメッセージを送信する。一方、人感センサがイベント人の有無を検知すると、ノーマルモードでセンシングデータを送信する。図4では、MTCグループ内のMTCデバイス100を識別するために、MTCデバイスA100AとMTCデバイスB100Bとが図示されている。なお、ここでは、MTCデバイスA100Aを、最初にイベントを検知するMTCデバイス煙センサと仮定し、MTCデバイスB100Bを、MTCデバイスA100Aと同一のMTCグループに属する他のMTCデバイス煙センサ、炎センサ、人感センサと仮定する。以下、図4に図示されているシーケンスについて説明する。MTCデバイスA100A煙センサは、MTCサーバ150と通信を行うためのPDNコネクションを、従来手法例えば、非特許文献3で示されるAttachprocedureに基づいてPGW140と確立する図4のステップS301:PDNコネクション確立済み。また、MTCデバイスB100Bも同様に、従来手法例えば、非特許文献3で示されるAttachprocedureに基づいて、PGW140とPDNコネクションを確立する図4のステップS308:PDNコネクション確立済み。ここで、MTCデバイスA100Aが、例えば、火災発生などにより、イベント煙を検知したとする図4のステップS302:イベント検知。イベントを検知したMTCデバイスA100Aは、イベントを検知したことをMTCサーバ150に通知するために、検知したイベント情報など例えば、煙発生フラグ、デバイス種IDなどを格納したイベント通知メッセージを作成し、MTCサーバ150にイベント通知メッセージここでは、イベント通知メッセージイベント情報デバイスAと表記を送信する図4のステップS303:イベント通知メッセージイベント情報デバイスA。なお、MTCデバイスA100A煙センサが煙を検知した場合は、火災が発生している可能性が高いと予測され、MTCデバイスA100Aは優先度の高いメッセージを用いて、MTCサーバ150に通知する。また、このとき、MTCデバイスA100Aは、イベント通知メッセージにセンシングデータ煙濃度を格納してもよい。図5Aは、図4のステップS303において、MTCデバイスA100Aが通信システムを通じて、MTCサーバ150に送信するメッセージの一例として、イベント通知メッセージイベント情報デバイスAのフォーマット例を示す図である。MTCデバイスA100Aは、例えば、従来のNASメッセージフィールドに、少なくともイベントフラグフィールドを追加する。イベントフラグフィールドは、MTCデバイスA100Aがイベントを検知したこと例えば、MTCデバイスA100Aが煙センサの場合は、煙発生フラグを示すためのフィールドである。なお、検出したイベントの種別を併記してもよい。さらには、センシングデータフィールド、デバイス種IDフィールドを追加してもよい。また、センシングデータフィールドは、例えばイベントを検知した際に、MTCサーバ150に早期にすなわちイベント通知とともに送信しておきたいデータ例えば、MTCデバイスA100Aが煙センサの場合、煙濃度などを格納するためのフィールドである。また、デバイス種IDフィールドは、イベントを検知したMTCデバイスA100Aの種類を識別するための情報を格納するためのフィールドである。例えば、MTCデバイスA100Aが煙センサの場合は、煙センサであることが識別可能な情報が格納される例えば、IMEIのデバイス種別を示すビット列から判断する、など。なお、これら従来のNASメッセージに加えたイベントフラグフィールド、センシングデータフィールド、デバイス種IDフィールドは、NASメッセージフィールドに埋め込まれるものであってもよい。また、従来のNASメッセージ以外のメッセージ例えば、MTC用のを用いてもよい。なお、本実施の形態は、Cプレーンでイベント通知メッセージイベント情報デバイスAが送信されると仮定しているが、Uプレーンで送信される場合には、従来のUプレーンで送信されるメッセージの任意のフィールドでもよい。また、MTCデバイスA100A、若しくはMTCサーバ150/MTCユーザ160が、イベントフラグフィールドの情報を用いなくても、MTCデバイス100がイベントを検知したことを確認できる、例えば、Timecontrolledが適用されたMTCデバイス100が、割り当てられた時間外にアクセスしてきた場合に、MTCデバイス100が高優先度モードで通知すべきイベントを検出したものとMME120が判断できる場合は、イベントフラグフィールドを省略してもよい。また、MTCデバイスA100AがMTCサーバ150に早期にすなわちイベント通知とともに送信しておきたいセンシングデータがない場合は、センシングデータフィールドを省略してもよい。また、デバイス種IDフィールドも同様に、従来のNASメッセージフィールドに格納されているデバイスIDから、そのデバイスの種類を導出することができるのであれば、省略してもよい。また、デバイス種IDフィールドに情報が格納されていることで、MTCデバイスA100Aがイベントを検知したということを確認できる例えば、煙センサを示すデバイス種IDが格納される場合、同時に煙検知イベントが通知されたものとするのであれば、イベントフラグフィールドも同様に省略してもよい。なお、このMTCデバイスA100Aから送信される優先度の高いメッセージであるイベント通知メッセージイベント情報デバイスAは、例えば、非特許文献1が定義するPAMや、非特許文献3で記述されているTAUTrackingAreaUpdateリクエストなどの位置登録メッセージにピギーバック重畳した場合、又は、PDNコネクションやEPSベアラが確立されていない状態でイベントを検知した場合は、PDNコネクションやEPSベアラを確立する際に用いられる、例えば、AttachRequestやServiceRequest、非特許文献4にて定義されるDSMIPv6bootstrappingbasedonIKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTHRequestメッセージを改良して用いてもよい。また、BearerModificationRequestメッセージを用いるものであってもよい。これによって、新規メッセージを導入することなく、少ない修正でMTCデバイス100からのイベント通知を実施することができる。通信システムのエンティティ例えば、MME120は、イベント通知メッセージイベント情報デバイスAを受信すると、受信したメッセージから、必要な情報例えば、イベントフラグ、センシングデータ、デバイス種IDを抽出し、例えば、従来のUpdateBearerRequestメッセージなどに格納し、SGW130/PGW140を通じて、MTCサーバ150にイベント通知メッセージイベント情報デバイスAを転送する。このとき、MME120は、イベント通知メッセージイベント情報デバイスAからイベント情報イベントフラグ/デバイス種IDを抽出して、逆イベント通知メッセージイベント情報逆PAM、混雑回避メッセージ、TimeTolerantIndication、congestionindication、congestionpriorindication、PAMreductionindicationなどと呼ばれてもよいに格納し、MTCデバイスA100Aが属しているMTCグループ内の全てのMTCデバイス100に送信する図4のステップS304:逆イベント通知メッセージイベント情報。また、この逆イベント通知メッセージは、逆イベント通知メッセージの送信元例えば、MME120の判断例えば、通信システムのオペレータによる事前設定によって、他のメッセージより高い優先度、若しくは一般的な優先度で送信してもよい。他のメッセージより高い優先度で逆イベント通知メッセージが送信される場合は、メッセージの送信元が過負荷状態であり、一般的な優先度のメッセージの処理が放棄される場合でも、優先度の高い逆イベント通知メッセージは送信することができる。また、優先度の高い逆イベント通知メッセージではなく、一般的な優先度で逆イベント通知メッセージを送るものであってもよい。この場合は、特にメッセージの優先度を設定する必要がなくなる。また、MME120は、一定期間内に所定数のイベント通知メッセージを受信した、あるいは単に一定数のイベント通知メッセージを受信した場合に、逆イベント通知メッセージを送信するものであってもよい。これにより、同一のイベント通知メッセージが今後も増加するであろうことを予見した上で、それらの発生を抑えるための逆イベント通知メッセージを送信することにより、単発のイベント通知メッセージから判断する場合に比べて、抑止メッセージ逆イベント通知メッセージを効果的に発行することができ、通信リソースや帯域の有効利用を図ることができる単発のイベント通知メッセージにより判断する場合、イベント通知メッセージを受信するたびに逆イベント通知メッセージを送信することになり、通信リソースや帯域を浪費することになる。このとき、MME120は、MTCデバイスA100AがMTCグループに属しているか、また、MTCグループに属しているのであれば、どのMTCグループに属しているかを確認するために、MTCデバイスA100Aに対応するサブスクリプションデータをHSS125から取得してグループIDが登録されているかどうかで判断してもよい。若しくは、ステップS303のイベント通知メッセージイベント情報デバイスAに格納されているグループIDなどから判断してもよい図5A不図示。また、MME120が既にサブスクリプションデータを保持、又は、HSS125からサブスクリプションデータを取得する以外の方法例えば、外部サーバなどを用いて、MTCデバイスA100AがMTCグループに属しているかどうかを確認できるのであれば、HSS125に問い合わせる必要はない。また、ここでは逆イベント通知メッセージを送信する対象を、イベントを検知したMTCデバイスA100Aが属しているMTCグループ配下の全てのMTCデバイスMTCデバイスA100A及びMTCデバイスB100Bとしているが、Groupbasedを搭載していないケースにおいては、MTCデバイスA100Aが接続しているeNB110配下の全てのMTCデバイス100を逆イベント通知メッセージの送信対象としてもよい。この場合、特定のエリアに位置するMTCデバイス100からの同じイベントによる優先度の高いイベント通知メッセージを抑制することができる。また、MTCグループという概念を考慮せずに、優先度の高いイベント通知メッセージを抑制できることにより、グループIDなどを用いなくてもよいという利点がある。ここでは、グループIDの代わりに、eNBIDやeNBアドレス並びにMTCデバイス100のEPSベアラに対応するS1UTEIDを使用してもよい。また、MME120があらかじめ送信相手を確認できているのであれば、ブロードキャストではなく、マルチキャストやユニキャストで逆イベント通知メッセージを送信してもよい。これにより、制御範囲通知範囲を限定することにより、システム全体へのインパクトを低減させることができる。また、MME120は、逆イベント通知メッセージイベント情報をMTCグループの全てのMTCデバイス100に送信する際、例えば、逆イベント通知メッセージイベント情報の送信先であるMTCグループのグループID、デバイス種IDと一緒に逆イベント通知メッセージイベント情報を送信したことを、逆イベント通知メッセージイベント情報送信済み情報として記憶する。この記憶した逆イベント通知メッセージイベント情報送信済み情報は、同じMTCグループ内の同じデバイス種のMTCデバイス100から同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによるイベント通知メッセージイベント情報を受信した際に、再度同じ逆イベント通知メッセージイベント情報を送信しないように、MTCデバイス100が判断するパラメータとして使用される。なお、イベント通知メッセージイベント情報を受信した際、同じMTCグループの同じMTCデバイス種からのイベント通知メッセージイベント情報であると判断できる場合は、再度、逆イベント通知メッセージイベント情報を送信することが望ましいが、この場合は、必ずしも逆イベント通知メッセージイベント情報送信済み情報を記憶する必要はない。また、MME120は、上記したようにMTCデバイス100の種類を確認できるものとする例えば、MTCデバイスのデバイスIDからMTCデバイス100の種類を確認することができる例えば、デバイスIDのうちデバイス種別を示す一部のビット列例えば、上位あるいは下位数ビット、又は、外部サーバにデバイスIDを通知するとデバイス種IDを取得できるなど、又は、図5Aに図示されているようにイベント通知メッセージイベント情報デバイスAにデバイス種IDも格納されていることとする。また、MTCデバイス100が複数のイベントグループ情報を保持している場合、MME120は、イベントグループ情報ラベル複数のイベントグループ情報のうちのどのイベントグループ情報を使用するかを示すためにイベントグループ情報と関連付けられている情報を逆イベント通知メッセージイベント情報に格納して送信を行う。MME120が、どのイベントグループ情報を使用するかを判断する方法は、例えば、サブスクリプションデータに登録されている情報例えば、イベント情報とイベントグループ情報が対になっている情報などを用いてもよいし、MTCサーバ150/MTCユーザ160が、あらかじめ設定しているMTCサービスの仕様や登録情報、また設定情報などに基づいて決定してもよい。また、MME120による上記の判断どのイベントグループ情報を使用するかは、MTCデバイス100が送信するイベント通知メッセージイベント情報で、複数のイベントグループ情報を保持していることを通知したうえで、実施されてもよい。ここで、図5Bを参照しながら、逆イベント通知メッセージイベント情報について説明する。図5Bは、図4のステップS304において、MME120が、MTCデバイスA100Aが属するMTCグループの全てのMTCデバイス100MTCデバイスB100Bを含むにブロードキャストするメッセージの一例として、逆イベント通知メッセージイベント情報のフォーマット例を示す図である。MME120は、従来のNAS返信メッセージフィールドに、イベントフラグフィールド、デバイス種IDフィールド、イベントグループ情報ラベルフィールドを追加したメッセージを送信する。イベントフラグフィールドは、MTCデバイス100がイベントを検知したことを示すためのフィールドである。なお、イベントフラグフィールドは、このメッセージが逆イベント通知メッセージであることを識別するためのフィールドとしても用いられる。また、デバイス種IDフィールドは、イベントを検知したMTCデバイス100の種類の情報例えば、煙センサを格納するためのフィールドである。デバイス種IDフィールドには、例えば、この逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージの送信元のMTCデバイス100の種類を識別するための情報が格納される。なお、このデバイス種IDフィールドに格納される情報は、後述するイベントグループ情報図6参照内に登録されている情報と対応付けられている必要があり、また、イベントグループ情報内に登録されている情報との対応が明確に判別できるのであれば、デバイス種ID以外の情報例えば、イベントのIDなどを用いてもよい。また、イベントグループ情報ラベルフィールドは、例えば、MTCデバイス100が複数のイベントグループ情報を保持している際に使用されるフィールドである。このイベントグループ情報ラベルフィールドには、MTCデバイス100がどのイベントグループ情報を使用するかを決定するために、MME120によってイベントグループ情報ラベル例えば、火災、地震、強盗、建物崩壊、土砂崩れなどが格納される。なお、本実施の形態は、Cプレーンで逆イベント通知メッセージイベント情報が送信されると仮定しているが、Uプレーンで送信される場合には、従来のUプレーンで送信されるメッセージの任意のフィールドでもよい。また、MTCデバイス100が、MME120からの逆イベント通知メッセージイベント情報に格納されるイベントフラグフィールドの情報を用いなくても、同じMTCグループ、若しくは、周辺のMTCデバイス100が、イベントを検知したことを確認できるのであれば例えば、Timecontrolledで割り当てられた時間外のメッセージ受信から確認可能、イベントフラグフィールドを省略してもよい。また、MME120が、MTCデバイス100が1つのイベントグループ情報しか保持していないことを確認済みの場合や、イベントグループ情報を用いたモード遷移の詳細な管理を行わないような場合には、イベントグループ情報を識別する必要がないので、イベントグループ情報ラベルフィールドを省略してもよい。例えば、ネットワーク装置例えば、MME120から送信される逆イベント通知メッセージに、イベントグループ情報ラベルを格納せずにデバイス種IDのみを格納することで、最初にイベント通知メッセージを送信したMTCデバイス100と同種のMTCデバイス100からのイベント通知メッセージのみを抑制することができる。なお、これら従来のNASメッセージに加えたイベントフラグフィールド、デバイス種IDフィールド、イベントグループ情報ラベルフィールドは、NAS返信メッセージフィールドに埋め込まれるものであってもよい。なお、このMME120から送信される逆イベント通知メッセージイベント情報は、例えば、非特許文献3や非特許文献5で記述されているPagingメッセージやBearerModificationRequestメッセージ、非特許文献1が定義するPAM、非特許文献3で記述されているTAUAcceptメッセージ、又は、非特許文献4が定義するDSMIPv6bootstrappingbasedonIKEv2で使用されるIKE_SA_INITメッセージやIKE_AUTHResponseメッセージを拡張して用いてもよい。なお、イベント通知メッセージイベント情報デバイスAに格納されているイベント情報を参照し、その参照したイベント情報を逆イベント通知メッセージイベント情報に格納してブロードキャストするエンティティは、MME120ではなく、PGW140やMTCサーバ150であってもよい。また、イベント通知メッセージイベント情報デバイスAに格納されているデバイス種IDと、逆イベント通知メッセージイベント情報に格納されているデバイス種IDは、関連性が保証されているのであれば、必ずしも一致しなくてもよい。しかし、この場合も、逆イベント通知メッセージイベント情報に格納されている情報と、イベントグループ情報に登録されている情報例えば、デバイス種IDとは、関連性が保証されている必要がある。なお、デバイス種IDではなく、イベント情報や従来のNASメッセージに含まれているMTCデバイス100を識別する、例えば、IPアドレスや、デバイスIDを基に、逆イベント通知メッセージイベント情報に格納するデバイス種IDを確認できるのであれば、イベント通知メッセージイベント情報デバイスAに格納されているデバイス種IDを使用する必要はない。逆イベント通知メッセージイベント情報を受信したMTCグループ内のMTCデバイス100図4中のMTCデバイスB100Bに相当は、逆イベント通知メッセージイベント情報に格納されているデバイス種IDを抽出し、MTCデバイスB100B自身のデバイスID/デバイス種IDと一致しているかどうかを確認する図4のステップS309:自種IDと一致しているかを確認。この確認によって、逆イベント通知メッセージイベント情報から抽出されたデバイス種IDと、自身のデバイスID/デバイス種IDとが一致している場合には、MTCデバイス100は、ノーマルモードに遷移する元々ノーマルモードだった場合はそのまま維持。なお、逆イベント通知メッセージイベント情報から抽出されたデバイス種IDは、その逆イベント通知メッセージを送信するきっかけとなったイベント通知メッセージイベントの送信元のMTCデバイス100ここでは、MTCデバイスA100Aの種類を表している。すなわち、MTCデバイスB100Bは、自デバイスと同種類のMTCデバイス100からイベント通知メッセージが送信されたかどうかを判断し、自デバイスと同種類のMTCデバイス100からイベント通知メッセージが既に送信されたことが確認できた場合には、高優先度モードによるイベント通知メッセージの送信を行わないよう、ノーマルモードで動作を行う。また、MTCデバイスB100Bは、受信した逆イベント通知メッセージイベント情報に含まれているデバイス種IDに基づいて、高優先度モードへのモード切替を行うべきかどうかを判断し、高優先度モードへのモード切替を行う必要が確認された場合には、高優先度モードへモード切替あるいは、元々高優先度モードで動作しているのであればそのまま高優先度モードを維持を行う図4のステップS310高優先度モードへの切替を行うかどうかを判断モード切り換え。ここで、高優先度モードへモード切替を行うべきかどうかの判断は、例えば、逆イベント通知メッセージイベント情報から抽出したデバイス種IDが、そのMTCデバイスB100Bが保持しているイベントグループ情報図6に記載されているかどうかで判断する。なお、MTCデバイスB100Bが複数のイベントグループ情報を保持している場合は、逆イベント通知メッセージイベント情報に格納されているイベントグループ情報ラベルを抽出し、抽出されたイベントグループラベル情報に対応するイベントグループ情報を使用して判断する。図6は、MTCデバイス100が、受信した逆イベント通知メッセージイベント情報に含まれているデバイス種ID/イベントグループ情報ラベルに基づいて、モード切替を行うべきかどうかを判断するために用いられるイベントグループ情報の一例を示す図である。このイベントグループ情報には、複数のデバイス種ID対応関係が分かるのであれば、デバイス種IDと一致する必要はないが登録されており、このデバイス種IDは静的/動的に設定される。逆イベント通知メッセージイベント情報を受信したMTCデバイスB100Bは、逆イベント通知メッセージイベント情報から抽出されたデバイス種IDが、イベントグループ情報に登録されているかどうかを確認する。図6には、MTCデバイスB100B人感センサが保持しているイベントグループ情報の一例が図示されている。図6では、イベントグループ情報に煙センサIDと炎センサIDとが記載されており、このイベントグループ情報を保持しているMTCデバイスB100B人感センサは、煙センサID又は炎センサIDが含まれている逆イベント通知メッセージイベント情報を受信すると、高優先度モードへモード切替を行ってあるいは、そのまま高優先度モードを維持して動作を行う。すなわち、イベントグループ情報には、特定の逆イベント通知メッセージイベント情報を受信した場合、高優先度モードに遷移あるいは維持するよう規定する情報が登録されている。イベントグループ情報にどの種類のデバイス種IDを登録するかは、例えば、イベント発生時の好適な動作に基づいて考慮されることが好ましい。一例として、例えば、火災が発生したときには、煙センサからネットワーク側へ優先度の高いイベント通知メッセージイベント情報が送信され、その逆イベント通知メッセージイベント情報がMTCグループ内にブロードキャストされた場合であっても、炎を検知するために炎センサは高優先度モードのまま動作させておき、また、人が残っていないかどうかを迅速に把握するために人感センサを高優先度モードにモード遷移させることが最適な動作であるとする。この場合には、例えば、炎センサが保持するイベントグループ情報に煙センサIDと人感センサID、煙センサが保持するイベントグループ情報に炎センサIDと人感センサID、人感センサが保持するイベントグループ情報に煙センサIDと炎センサIDをそれぞれ登録しておくことで、最適な動作を実現することが可能となる。なお、イベントグループ情報に登録するデバイス種ID及び各MTCデバイス100の動作については、後で詳細に説明する。なお、ステップS309及びステップS310の確認処理は、各MTCデバイス100にイベントグループ情報をどのように持たせるか各MTCデバイス100個別にイベントグループ情報を持たせるのか、あるいは、複数のMTCデバイス100に同じイベントグループ情報を持たせるのかや、イベントグループ情報内に含まれる情報をどのように構成しておくかイベントグループ情報を持つMTCデバイス100の自種IDをイベントグループ情報に含ませておくかどうかなどによって、様々な方法を採用することが可能である。しかしながら、本発明の基本的な考え方は、ステップS309及びステップS310の確認処理の方法を限定するものではない。本発明では、逆イベント通知メッセージを受信したMTCデバイス100が、自デバイスと同種類のデバイスから既にイベント通知メッセージの送信が行われたかどうかを確認でき、さらに、自デバイスと異なる種類のデバイスからイベント通知メッセージの送信が行われている場合には高優先度モードへ遷移あるいは、現在のモードをそのまま維持すべきかどうかを判断できるようにすることが重要である。また、図6には、上述のように、MTCデバイスB100B人感センサが保持するイベントグループ情報が図示されているが、このイベントグループ情報に、人感センサ自体のID人感センサIDが含まれていてもよい。ここで一例として挙げているステップS309及びステップS310の確認処理によれば、MTCデバイスB100B人感センサは、自身が保持しているイベントグループ情報に自デバイス種ID人感センサIDが含まれているかどうかを確認することはないが、逆イベント通知メッセージイベント情報を受信した場合でも例外的に高優先度モードで動作を行うMTCデバイス100のデバイス種IDの一覧を、イベントグループ情報として登録することで、共通のイベントグループ情報を作成することも可能である。具体的には、火災発生時に、煙センサ、炎センサ、人感センサを高優先度モードで動作させたいと考えた場合には、イベントグループラベルの情報火災が付けられており、煙センサ、炎センサ、人感センサが登録されたイベントグループ情報を、煙センサ、炎センサ、人感センサに共通して持たせておくことも可能である。さらに、ステップS309及びステップS310の確認処理を上述したものとは異なる動作とすることで、すべてのMTCデバイス100が共通のイベントグループ情報を持たせた場合であっても、本発明に係る詳細なモード遷移の管理を実現できる方法も存在する。また、MTCグループのMTCデバイス100は、逆イベント通知メッセージイベント情報を受信した際、逆イベント通知メッセージイベント情報に格納されているデバイス種ID例えば、煙センサを記憶する図4のステップS311:イベント情報の記憶。この記憶したイベント情報は、MTCデバイス100が再度MME120から別の逆イベント通知メッセージイベント情報例えば、人感センサIDを受信した際に、優先度の高いイベント通知メッセージを送信しない高優先度モードに切り替わらないと判断するパラメータとして使用される。例えば、MTCデバイスA100A煙センサが、イベントを検知して、優先度の高いイベント通知メッセージイベント情報を送信した後、MTCデバイスA100Aと同じMTCグループに属しているMTCデバイス100は、デバイス種IDが煙センサの逆イベント通知メッセージイベント情報を受信する。このとき、MTCデバイスA100Aと同じデバイス種のMTCデバイスB100B煙センサは、高優先度モードからノーマルモードにモード遷移するとともに、デバイス種IDが煙センサの逆イベント通知メッセージイベント情報を受信したことを記憶する。その後、同じMTCグループのMTCデバイスB100B人感センサがイベントを検知して、優先度の高いメッセージイベント情報を送信した場合には、MTCグループ内のMTCデバイス100は、デバイス種IDが人感センサの逆イベント通知メッセージイベント情報を、デバイス種IDが煙センサの逆イベント通知メッセージイベント情報に続いて受信する。このとき、MTCデバイスA100Aは、先に受信しているデバイス種IDが煙センサの逆イベント通知メッセージイベント情報を記憶しており、この記憶された情報受信履歴をパラメータとして、ノーマルモードから高優先度モードにモード遷移せずに、再度優先度の高いイベント通知メッセージイベント情報を送信しないよう動作する。これにより、同一イベント例えば、火災発生の際にいったん高優先度モードからノーマルモードに遷移したMTCデバイス100は、再度、高優先度モードに戻らないように制御することが可能となる。なお、このモード切替するための判断要素となるパラメータは、MTCデバイス100の種類を示すデバイス種ID以外の情報でもよい。なお、ステップS309の自デバイス種IDの確認ステップからステップS311のイベント情報の記憶ステップは、順不同で実施してもよい。その後、MTCデバイスB100B例えば、人感センサが、イベント例えば、人の存在を検知したとする図4のステップS313:イベント検知。イベント検知したMTCデバイスB100Bは、イベント検知時にデータ送信するモードを確認し、その送信モードに従って、MTCサーバ150に通知を行う。このとき、MTCデバイスB100Bが高優先度モードであり、優先度の高いメッセージを通知する場合は、MTCデバイスB100Bは、検知したイベント情報などを格納したイベント通知メッセージをMTCサーバ150に通知する図4のステップS314:イベント通知メッセージイベント情報デバイスB。一方、MTCデバイスB100Bが高優先度モードではなくノーマルモードで送信する場合は、ステップS314のイベント通知メッセージイベント送信点線部分はノーマルモードで通知するか、若しくは行わず、MTCサーバ150にセンシングデータを送信する図4のステップS315:取得データ送信。なお、ステップS314のイベント通知メッセージとステップS315の取得データ送信は、逐次的、若しくは、同時に行ってもよい。また、最初にイベント通知メッセージイベント情報を送信したMTCデバイスA100Aも、逆イベント通知メッセージイベント情報を受信し、逆イベント通知メッセージイベント情報に従って、図7のように高優先度モードからノーマルモードにモード遷移を行い図4のステップS306:モード切替、逆イベント通知メッセージイベント情報を受信したことを記憶する図4のステップS307:イベント情報の記憶。そして、その後は、MTCデバイスA100Aは、ノーマルモードでセンシングデータの送信を行う図4のステップS316:取得データ送信。なお、図4のステップS316の取得データ送信は、ステップS303のイベント通知メッセージイベント情報デバイスA送信後の任意のタイミングに行うことが可能である。また、ここでは、最初にイベント通知メッセージイベント情報を送信したMTCデバイスA100Aが、逆イベント通知メッセージイベント情報の受信によって、高優先度モードからノーマルモードへモード遷移を行っているが、高優先度モードによるイベント通知メッセージイベント情報の送信を行った直後に自らノーマルモードへモード遷移してもよく、あるいは、イベント通知メッセージイベント情報を送信したMTCデバイスA100Aに関しては、そのまま高優先度モードによる通知を継続して行えるようにしてもよい。また、通常、イベントを検知した際に高い優先度のイベント通知メッセージでMTCサーバ150に通知していたMTCデバイス100例えば、炎センサは、例えば、一定時間後例えば、逆イベント通知メッセージでライフタイム値を通知など、又は、MME120、MTCサーバ150から送信されるメッセージ例えば、NASメッセージなどをMTCデバイス100が受信することで、ノーマルモードから高優先度モードに戻すことができる。また、通常、いったん高優先度モードに遷移した後にノーマルモードに戻って動作を行っているMTCデバイス100例えば、人感センサに関しても、同様の方法で、元の状態逆イベント通知メッセージを受信した場合に、ノーマルモードから高優先度モードへ遷移できる状態に戻すことができる。これにより、1つのイベントが終了後も、通常と同様の動作に戻すことができる図3には不図示。次に、図8を参照しながら、本発明の第2の実施の形態におけるMTCデバイス100の構成について説明する。図8は、本発明の第2の実施の形態におけるMTCデバイス100の構成の一例を示す図である。図8において、MTCデバイス100は、通信システム例えば、E-UTRANやUTRANと接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部501、受信したメッセージが逆イベント通知メッセージであるか判断し、受信した逆イベント通知メッセージに格納されているイベント情報を記憶し、逆イベント通知メッセージに格納されているデバイス種IDが、MTCデバイス100自身のデバイス種IDと一致しているか確認し、さらに、保持しているイベントグループ情報に逆イベント通知メッセージに格納されているデバイス種IDが登録されているか確認する逆イベント通知メッセージ処理部502、逆イベント通知メッセージを受信した際にMTCデバイス100の現在の送信モードを確認し、その送信モードを確認するために使用する情報を保持し、MTCデバイス100の送信モードを切り替える送信モード制御部504、特定のイベントそのMTCデバイス100が監視しているイベントを検知するイベント検知部505、イベント検知時に高い優先度のメッセージで送るか判断するイベント通知メッセージ処理部503を少なくとも有する。なお、例えば、イベント通知メッセージ処理部503が、送信モード制御部504の機能を保持している場合は、送信モード制御部504を省略できる。他の機能部も同様に、1つの機能部で上記の機能部を含む場合は、省略してもよい。逆に、例えば、イベント通知メッセージ処理部503で実施している、受信した逆イベント通知メッセージに格納されているイベント情報を記憶する機能と、イベント検知時に高い優先度のメッセージで送るかどうかを判断する機能とを分けてもよい。なお、MTCデバイス100において上述の各構成要素が動作を行うことで、特定のイベントの発生を検知するためのセンサによって検知されたセンシングデータを通常の優先度で送信するノーマルモード、又は、センサによって特定のイベントの発生を検知したことを通知するイベント通知メッセージをノーマルモード、若しくは、ノーマルモードの優先度よりも高い優先度で送信する高優先度モードのいずれかの送信モードで動作を行うよう制御する動作モード制御部としての機能、ネットワークノードへ高優先度モードによるイベント通知メッセージの送信又はノーマルモードによるセンシングデータの送信を行う送信部としての機能、特定のイベントの発生を検知したことを通知するイベント通知メッセージを任意の通信ノードから受信したネットワークノードから、任意の通信ノードが通知するイベント通知メッセージに対する応答として送信されるメッセージであって、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを受信するメッセージ受信部としての機能、メッセージを受信した場合に、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するかどうかを判断するモード遷移判断部としての機能などが実現される。次に、図8に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図9Aと図9Bを用いて詳しく説明する。図9Aは、本発明の第2の実施の形態において、イベント検知時に、ノーマルモード又は高優先度モードでMTCサーバ150への送信処理を行うMTCデバイス100の処理フローの一例を示すフロー図であり、図9Bは、本発明の第2の実施の形態において、ネットワーク側例えば、MME120から逆イベント通知メッセージを受信したMTCデバイス100の処理フローの一例を示すフロー図である。最初に、図9Aを参照しながら、MTCデバイス100がイベントを検知した際に、ノーマルモード又は高優先度モードでMTCサーバ150への送信する場合の処理フローについて説明する。MTCデバイス100は、MTCサーバ150と通信を行うために、PGW140との間にPDNコネクション及びEPSベアラを確立する図9AのステップS601。ここで、MTCデバイス100は、イベント検知部505でイベントを検知したとする図9AのステップS602。なお、イベントの検知は、例えば、煙センサであれば煙の検知、炎センサであれば炎の検知、人感センサであれば人物の検知などである。イベント検知後、MTCデバイス100は、送信モードに関する情報を取得し図9AのステップS603、高い優先度のメッセージでMTCサーバ150に送信するかどうかを、イベント通知メッセージ判断部503で判断する図9AのステップS604。送信モードが高優先モードであり、高い優先度のイベント通知メッセージでMTCサーバ150に通知すると判断した場合、MTCデバイス100は通信処理部501で例えば、イベントフラグ例えば、煙発生、センシングデータ、デバイス種IDを生成し図9AのステップS605、このイベント情報を格納したイベント通知メッセージイベント情報デバイスAを、通信システムを通じてMTCサーバ150に送信する図9AのステップS606。なお、上述のように、例えば、TimeControlledが適用されたMTCデバイス100が、割り当てられた時間外にアクセスしてきた場合に、MTCデバイス100が高優先度モードで通知すべきイベントを検出したものとネットワーク側例えば、MME120が判断できる場合、MTCデバイス100は、イベントフラグをイベント通知メッセージイベント情報デバイスAに格納する必要はない。また、上記以外の手段を用いて、MTCデバイス100がイベントを検知したことをネットワーク側が確認できるのであれば、同様にイベントフラグを省略してもよい。また、デバイス種IDも同様に、例えば、デバイスIDのうちデバイス種別を示す一部のビット列例えば、上位あるいは下位数ビットからMTCデバイス100の種類を導出し、MTCデバイス100の種類をネットワーク側で識別できるのであれば、デバイス種IDを格納する必要はない。一方、送信モードがノーマルモードであり、一般的な優先度で検知したイベント例えば、煙発生とセンシングデータをMTCサーバ150に送信すると判断した場合、MTCデバイス100は、通常通り、イベント通知メッセージイベント情報デバイスAと取得したセンシングデータを、通信処理部501から送信する図9のステップS607。なお、上述のように、MTCデバイス100は、一定時間後例えば、逆イベント通知メッセージで通知されたライフタイム値など、又は、MME120、MTCサーバ150から送信されるメッセージ例えば、NASメッセージなどを受信したときに、高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モードに戻す処理を行ってもよい図9Aには不図示。次に、図9Bを参照しながら、MTCデバイス100がネットワーク側例えば、MME120から逆イベント通知メッセージを受信した場合の処理フローについて説明する。MTCデバイス100は、MTCサーバ150と通信を行うために、PGW140との間にPDNコネクション及びEPSベアラを確立する図9BのステップS701。ここで、MTCデバイス100は、通信システムから何らかのメッセージを受信すると、受信したメッセージが逆イベント通知メッセージイベント情報であるかどうかを逆イベント通知メッセージ処理部502にて判断する図9BのステップS702。逆イベント通知メッセージイベント情報ではないと判断した場合には、そのメッセージに適した別の処理が行われる図9Bには不図示。一方、逆イベント通知メッセージイベント情報だと判断した場合、MTCデバイス100は、逆イベント通知メッセージイベント情報からデバイス種IDを抽出し、同一のデバイス種IDが格納された逆イベント通知メッセージイベント情報を再度受信した場合を特定するために、抽出されたデバイス種IDを逆イベント通知メッセージ処理部502にて記憶する図9BのステップS703。続いて、逆イベント通知メッセージ処理部502において、MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージイベント情報に格納されているデバイス種IDとが一致しているかどうかを確認する図9BのステップS705。MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージイベント情報に格納されているデバイス種IDとが一致する場合は、自デバイスと同じ種類のMTCデバイス100からイベント通知メッセージが既に送信されていると判断でき、MTCデバイス100は、ノーマルモードで動作を行う図9BのステップS706。なお、ステップS706では、MTCデバイスが高優先度モードだった場合は、送信モード制御部504においてノーマルモードに遷移し、MTCデバイスがノーマルモードだった場合は、そのままノーマルモードを維持する。一方、MTCデバイス100自身のデバイスID/デバイス種IDと逆イベント通知メッセージイベント情報に格納されているデバイス種IDとが一致しない場合は、逆イベント通知メッセージ処理部502において、逆イベント通知メッセージイベント情報に含まれるイベントグループ情報ラベルに対応するイベントグループ情報を読み出し図9BのステップS707、逆イベント通知メッセージイベント情報から抽出したデバイス種IDが、イベントグループ情報に登録されているかどうかを確認する図9BのステップS708。逆イベント通知メッセージイベント情報から抽出したデバイス種IDがイベントグループ情報に登録されていない場合は、受信した逆イベント通知メッセージはMTCデバイス100が関与していないイベントに係る逆イベント通知メッセージイベント情報であると判断でき、MTCデバイス100は、処理を終了する。なお、デバイス種IDのリストが登録されたイベントグループ情報をMTCデバイス100に保持させるのではなく、自デバイス種とそのラベルとが関連付けられているかどうかを示す情報を保持させることも可能であり、この場合には、MTCデバイス100は、ステップS708において、自デバイス種とラベル名例えば火災とが関連付けられているかどうかを確認するだけでよい。一方、逆イベント通知メッセージイベント情報から抽出したデバイス種IDが、イベントグループ情報に登録いる場合は、受信した逆イベント通知メッセージイベント情報はMTCデバイス100が関与しているイベントに係る逆イベント通知メッセージイベント情報であると判断できる。この場合、MTCデバイス100は、逆イベント通知メッセージ処理部502に記憶されているデバイス種IDを確認し、同じ種類のMTCデバイス100から送信されたイベント通知メッセージイベント情報に対する逆イベント通知メッセージイベント情報を既に受信しているかどうかを判断する図9BのステップS709。そして、MTCデバイス100は、同じ種類のMTCデバイス100から送信されたイベント通知メッセージイベント情報に対する逆イベント通知メッセージイベント情報を既に受信している場合は処理を終了し、一方、同じ種類のMTCデバイス100から送信されたイベント通知メッセージイベント情報に対する逆イベント通知メッセージイベント情報を初めて受信した場合は、高優先度モードで動作を行う図9BのステップS710。なお、ステップS710では、MTCデバイス100が高優先度モードだった場合は、送信モード制御部504においてそのまま高優先度モードを維持し、MTCデバイスがノーマルモードだった場合は、高優先度モードに遷移する。このようにして決定された送信モードは、図9Aに図示されている送信モードの確認処理図9AのステップS603で参照される。なお、ステップS705の自デバイス種IDとの一致を確認するタイミング、ステップS708の逆イベント通知メッセージイベント情報から抽出されたデバイス種IDがイベントグループ情報に登録されているかどうかを確認するタイミング、ステップS709の逆イベント通知メッセージイベント情報の受信を既に行っているデバイス種かどうかを確認するタイミングは、順序が異なっていてもよい。次に、図10を参照しながら、本発明の第2の実施の形態におけるMMEの構成について説明する。図10は、本発明の第2の実施の形態におけるMME120の構成の一例を示す図である。図10において、MME120は、通信システム例えば、E-UTRANやUTRAN上で通信処理を行い、IPなどのパケット通信処理を実施する通信処理部801、受信メッセージが高い優先度で送られてきたイベント通知メッセージであるか判断した後、イベント情報を取得し、取得したイベント情報を記憶するイベント通知メッセージ処理部803、同一イベント、又は、そのイベントによって引き起こされたイベントによる冗長なイベント通知メッセージの受信を抑制するためにイベント通知メッセージから取得したイベント情報を格納した逆イベント通知メッセージをブロードキャスト送信するか判断する逆イベント通知メッセージ処理部802を少なくとも有する。なお、例えば、逆イベント通知メッセージ処理部802が、イベント通知メッセージ処理部803の機能を保持している場合、イベント通知メッセージ処理部803を省略できる。他の機能部も同様に、1つの機能部で上記の機能部を含む場合は、省略してもよい。なお、MME120において上述の各構成要素が動作を行うことで、MTCデバイス100から、特定のイベントの発生を検知したことを通知するイベント通知メッセージを受信する受信部としての機能、イベント通知メッセージに対する応答として、送信モードをノーマルモードへ遷移するか又はノーマルモードのまま維持するよう指示するメッセージを作成するメッセージ作成部としての機能、メッセージをMTCデバイス100へ送信するメッセージ送信部としての機能を有している。次に、図10に図示されている構成を有するMME120について、本発明における特徴的な処理を中心に、図11を用いて詳しく説明する。図11は、本発明の第2の実施の形態におけるMME120の処理フローの一例を示すフロー図である。MME120は、MTCデバイスA100Aから送信されたメッセージを受信し、イベント通知メッセージ処理部803にて、このメッセージが優先度の高いイベント通知メッセージイベント情報デバイスAであると判断したとする図11のステップS901。なお、MME120は、イベント通知メッセージイベント情報デバイスAだと判断する際に、イベント通知メッセージイベント情報デバイスAのイベントフラグフィールドを参照してもよい。続いて、MME120は、イベント通知メッセージ処理部803にて、受信したイベント通知メッセージイベント情報デバイスAからイベント情報を取得する図11のステップS902。そして、MME120は、同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる冗長なイベント通知メッセージの送信を抑制するために逆イベント通知メッセージイベント情報をMTCグループのMTCデバイス100に送信するかどうかを逆イベント通知メッセージ処理部802にて判断する図11のステップS903。なお、逆イベント通知メッセージイベント情報を送信するかどうかあるいは、高優先度モードによる動作を要求するために、どのラベルを逆イベント通知メッセージに付加するかを判断する際、逆イベント通知メッセージ処理部802に保持されているイベントグループ情報を用いて判断してもよい。また、HLR/HSS125にMTCデバイス100の情報例えば、サブスクリプションデータを問い合わせて判断してもよい。逆イベント通知メッセージイベント情報を送信すると判断した場合、MME120は、例えば、イベント通知メッセージイベント情報デバイスAから取得されたデバイス種IDを格納した逆イベント通知メッセージイベント情報をMTCデバイスA100Aが属するMTCグループの全てのMTCデバイスMTCデバイスB100Bを含むにブロードキャストで送信する図11のステップS904。なお、MME120は、MTCデバイスA100AがMTCグループに属しているかどうかを判断する手段として、イベント通知メッセージイベント情報デバイスAに格納されているグループID図5Aには不図示や、HSS125が保持するサブスクリプションデータを用いてもよい。また、MME120が逆イベント通知メッセージイベント情報を送信する際、MME120はイベント通知メッセージイベント情報デバイスAから抽出したデバイス種IDを、再度イベント通知メッセージイベント情報デバイスAを受信した際に逆イベント通知メッセージイベント情報を送信するかどうかを判断する際に用いるパラメータとして使用するため、例えば、逆イベント通知メッセージ処理部802にて記憶することが望ましい。なお、イベント通知メッセージイベント情報デバイスAから抽出するデバイス種IDは、MTCデバイス100の種類を識別するためのID以外を使用してもよいが、上述のように、各MTCデバイス100が保持するイベントグループ情報に登録されている情報と関連している必要がある。また、MME120は、逆イベント通知メッセージイベント情報にイベントグループ情報ラベルを付加する場合、特定のデバイスからのイベント通知メッセージ例えば、煙センサや炎センサに対して、事前に定められた特定のラベル名例えば火災を付加するように構成されていてもよく、また、イベント通知メッセージに含まれているイベント情報やセンシングデータ、その他の情報などから、付加すべきイベントグループ情報ラベル名を決定してもよい。また、あるMTCデバイス100例えば、煙センサから受信したイベント通知メッセージイベント情報に応じてあるイベントグループ情報ラベル例えば火災を付加して逆イベント通知メッセージを送信した場合、イベントグループ情報などによって関連付けられている別のデバイス種のMTCデバイス100例えば、炎センサからイベント通知メッセージを所定時間内に受信したときには、その逆イベント通知メッセージイベント情報に同一のラベル名例えば火災を付加するようにしてもよい。また、MME120は、一定時間後、又は、MTCサーバ150/MTCユーザ160があらかじめ設定した仕様や登録情報、また設定情報などに基づいて、MTCデバイス100又はMME120が保持している情報を解放するためのメッセージ例えば、NASメッセージで、MTCデバイス100が持つ送信モードの定常化高優先度モードからノーマルモード、若しくは、ノーマルモードから高優先度モードを送信してもよい図11には不図示。また、上述の説明では、MME120が逆イベント通知メッセージイベント情報を送信しているが、MTCサーバ150が逆イベント通知メッセージイベント情報を送信することも可能である。なお、本発明の第2の実施の形態において、MTCサーバ150が逆イベント通知メッセージイベント情報を送信する場合のMTCサーバ150の構成は、図10に図示されているMME120の構成と同様であり、ここでは説明を省略する。同様に、本発明の第2の実施の形態において、MTCサーバ150の処理フローは、図10に図示されているMME120の処理フローずなわち、図11に図示されている処理フローと同様であり、ここでは説明を省略する。次に、図12~図14を参照しながら、上述した本発明の第1及び第2の実施の形態における各MTCデバイス100の動作とイベントグループ情報について、具体的な例を挙げながら説明する。図12は、本発明の第1及び第2の実施の形態に係る具体的な例を説明するために、各MTCデバイス100の配置の一例を示す図である。図12には、MTCグループ内に様々なMTCデバイス100煙センサ、炎センサ、人感センサ、ガスセンサ、水道センサ、水道メータセンサ、地震センサ、ドアロックセンサなどが多数配置されている状態が模式的に図示されている。図12に図示されているように、例えば、多数のMTCデバイス100が1つの施設内に配置されることで、例えば、施設内で発生し得るイベント事故や災害などを監視している。以下では、同一MTCグループ内の多数のMTCデバイス100のうち、2つの煙センサ、2つの炎センサ、2つの人感センサ、1つのドアロックセンサ、1つの水道センサに焦点を当てて、本発明に係る動作について具体的に説明する。なお、煙センサは、通常は高優先度モードで動作し、煙の発生を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、炎センサは、通常は高優先度モードで動作し、炎の発生を検知熱の検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、人感センサは、通常はノーマルモードで動作し、人の存在の有無の情報をセンシングデータとしてノーマルモードで送信するよう構成されているとする。また、ドアロックセンサは、通常は高優先度モードで動作し、施錠されたドアの開錠を検知すると高優先度のイベント通知メッセージを送信するよう構成されているとする。また、水道メータセンサは、通常はノーマルモードで動作し、水道メータの値検針値をセンシングデータとしてノーマルモードで送信するよう構成されているとする。<図13の1>本発明の第1の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージが送信される。この場合、逆イベント通知メッセージを受信するMTCデバイス100すなわち、MTCグループ内のすべてのMTCデバイス100は、ノーマルモードへ遷移する元々ノーマルモードの場合はそのまま維持。具体的には、図13の1に図示されているように、煙センサ、炎センサ、ドアロックセンサは高優先度モードからノーマルモードへ遷移し、人感センサはノーマルモードを維持し続ける。また、その他のMTCデバイス100例えば、地震センサや水道センサなども、すべてノーマルモードによる動作を行うよう制御される。<図13の2、図14のA、B>また、本発明の第2の実施の形態によれば、例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージイベント情報を送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージイベント情報が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID煙センサ及びイベントグループ情報ラベル名火災を含む逆イベント通知メッセージ[煙|火災]を受信する。逆イベント通知メッセージ[煙|火災]の受信によって、煙センサは、同じデバイス種からイベント通知メッセージイベント情報が送信されたことを把握し、ノーマルモードに遷移する。一方、炎センサは、異なるデバイス種からイベント通知メッセージイベント情報が送信されたことを把握し、そのまま高優先度モードを維持する。また、人感センサは、ラベル名火災を含む逆イベント通知メッセージイベント情報を受信することで、ノーマルモードから高優先度モードへ遷移する。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージイベント情報であることを把握し、そのまま高優先度モードを維持する。さらに、ある炎センサが炎の発生を検知し、MTCサーバ150へイベント通知メッセージイベント情報を送信したとすると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージイベント情報が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID炎センサ及びラベル名火災を含む逆イベント通知メッセージ[炎|火災]を受信する。逆イベント通知メッセージ[炎|火災]の受信によって、炎センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサは、同一の出来事火災の発生によって引き起こされたイベントの逆イベント通知メッセージすなわち、逆イベント通知メッセージ[煙|火災]の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、人感センサは、同一の出来事火災の発生によって引き起こされたイベントの逆イベント通知メッセージすなわち、逆イベント通知メッセージ[煙|火災]の受信によって高優先度モードへの遷移を既に行っているので、そのまま高優先度モードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。さらに、ある人感センサが人物の存在を検知し、MTCサーバ150へイベント通知メッセージを送信したとすると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージイベント情報が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種ID人感センサ及びラベル名火災を含む逆イベント通知メッセージ[人感|火災]を受信する。逆イベント通知メッセージ[人感|火災]の受信によって、人感センサは、同じデバイス種からイベント通知メッセージが送信されたことを把握し、ノーマルモードに遷移する。一方、煙センサ及び炎センサは、同一の出来事火災の発生によって引き起こされたイベントの逆イベント通知メッセージすなわち、逆イベント通知メッセージ[煙|火災]及び逆イベント通知メッセージ[炎|火災]の受信によってノーマルモードへの遷移を行っているので、そのままノーマルモードを維持し続ける。また、ドアロックセンサは、自デバイスとは関連性のない逆イベント通知メッセージであることを把握し、そのまま高優先度モードを維持する。図13の2のような動作を実現するためには、例えば、図14のAに図示されているように、例えば、煙センサにラベル名火災のイベントグループ情報炎センサ及び人感センサのデバイス種IDが登録されているを持たせ、炎センサにラベル名火災のイベントグループ情報煙センサ及び人感センサのデバイス種IDが登録されているを持たせ、人感センサにラベル名火災のイベントグループ情報炎センサ及び煙センサのデバイス種IDが登録されているを持たせればよい。なお、ドアロックセンサなどのような関連性のないMTCデバイス100においては、ラベル名火災のイベントグループ情報を持たせないようにしておくか、あるいは、デバイス種IDが登録されていないラベル名火災のイベントグループ情報を持たせるようにしておく。上述の図14のAのようなイベントグループ情報の持たせ方によれば、個々のデバイス種によって異なるイベントグループ情報を持たせることになるが、別の方法として、全MTCデバイス100に共通同一のイベントグループ情報を持たせるようにすることも可能である。この場合、例えば図9BのステップS708の処理において、逆イベント通知メッセージイベント情報に含まれているデバイス種IDがイベントグループ情報に含まれているかどうかを確認することに加えて、さらに、自デバイス種IDがイベントグループ情報に含まれているかどうかを確認することで、本発明に係る動作が実現可能となる。なお、この場合も、ドアロックセンサなどのような関連性のないMTCデバイス100においては、ラベル名火災のイベントグループ情報を持たせないようにしておいてもよい。図14のAのように、個々のMTCデバイス100が異なるイベントグループ情報を持つようにする場合には、モード遷移に関してより詳細な管理を行うことができる。例えば、人感センサが持つラベル名火災のイベントグループ情報に、煙センサのみが登録された状態に変更することによって、人感センサは、煙センサのデバイス種IDを含む逆イベント通知メッセージイベント情報を受信した場合には高優先度モードへ遷移するが、炎センサのデバイス種IDを含む逆イベント通知メッセージイベント情報を受信した場合にはノーマルモードをそのまま維持するように設定することが可能となる。なお、このような状態を想定しない場合特定のイベントに対して、どのデバイス種のMTCデバイス100からイベント通知メッセージが送信された場合であっても、関連するラベルを持っているMTCデバイス100は高優先度モードに遷移する場合は、自デバイス種がそのラベル名に関連付けられているかどうかを確認するだけでよい。すなわち、各MTCデバイス100のデバイス種IDが登録されているイベントグループ情報を持つ必要はなく、単に、自デバイス種とラベル名例えば火災とが関連付けられているかどうかを示す情報を持っているだけでよい。一方、図14のBのように、MTCデバイス100が共通のイベントグループ情報を持つようにする場合には、どのMTCデバイス100にどのイベントグループ情報を持たせる必要があるかを考慮せずに、全MTCデバイスに対してイベントグループ情報を一括配信して保持させることが可能となる。<図13の3、図14のC、D>また、本発明の第2の実施の形態では、複数のイベントグループ情報を設定することで、イベントごとラベル名ごとに、MTCデバイス100のモード遷移を変えることが可能である。例えば、あるドアロックセンサがドアの開錠不審者侵入の可能性を検知し、MTCサーバ150へイベント通知メッセージイベント情報を送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ逆イベント通知メッセージイベント情報が送信される。この場合、MTCグループ内のすべてのMTCデバイス100は、デバイス種IDドアロックセンサここでは、開錠と表記及びラベル名侵入を含む逆イベント通知メッセージ[開錠|侵入]を受信する。このとき、図13の3のように、例えば、逆イベント通知メッセージ[開錠|侵入]の受信によって、人感センサのみモード遷移ノーマルモードから高優先度モードさせ、その後、人感センサが人物の存在を検知し、MTCサーバ150へイベント通知メッセージイベント情報を送信した場合に、他の人感センサのモードを高優先度モードからノーマルモードに戻す動作を行わせるとする。このような場合には、MTCデバイス個別にイベントグループ情報を設定する方法において、図14のCのように、人感センサにラベル名侵入のイベントグループ情報ドアロックセンサのデバイス種IDが登録されているを持たせるか、あるいは、MTCデバイス100に共通のイベントグループ情報を設定する方法において、図14のDのように、全MTCデバイス100に人感センサにラベル名侵入のイベントグループ情報人感センサ及びドアロックセンサのデバイス種IDが登録されているを持たせればよい。この場合、少なくとも人感センサは、ラベル名の異なる複数のイベントグループ情報を保持することになる。<図13の4>また、上述の本発明の第2の実施の形態では、例えば、デバイス種ID及びイベントグループ情報ラベルラベル名の両方がイベント情報として含まれた逆イベント通知メッセージイベント情報の送信が行われている。しかしながら、イベントグループ情報ラベルラベル名を用いず、イベントグループ情報による詳細な設定が行われないような構成として、デバイス種IDのみを含む逆イベント通知メッセージの送信が行われるようにしてもよい。この方法は、第1の実施の形態における逆イベント通知メッセージによって行われるノーマルモードへのモード遷移の指示を、イベント通知メッセージを送信したMTCデバイス100と同じ種類のMTCデバイスに対してのみ行うものであると言える。また、図9Bの動作本発明の第2の実施の形態における動作において、ステップS707~S709の処理を行わないものであるとも言える。例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ、デバイス種ID煙センサを含む逆イベント通知メッセージイベント情報が送信される。この場合、MTCグループ内のすべてのMTCデバイス100が、デバイス種ID煙センサを含む逆イベント通知メッセージを受信するが、図13の4に図示されているように、この逆イベント通知メッセージに含まれているデバイス種IDと同じ種類のMTCデバイスすなわち、すべての煙センサのみ、モード遷移ノーマルモードへの遷移を行う。<図13の5、図14のE>また、上述の本発明の第2の実施の形態では、例えば、デバイス種ID及びイベントグループ情報ラベルラベル名の両方がイベント情報として含まれた逆イベント通知メッセージイベント情報の送信が行われているが、逆イベント通知メッセージイベント情報に、デバイス種IDを挿入せず、イベントグループ情報ラベルラベル名のみを付加することも可能である。この方法は、図9Bの動作本発明の第2の実施の形態における動作において、ステップS705の処理を行わないものであると言える。例えば、ある煙センサが煙の発生を検知し、MTCサーバ150へイベント通知メッセージを送信すると、MME120からMTCグループ内のすべてのMTCデバイス100へ、ラベル名火災を含む逆イベント通知メッセージが送信される。ここで、図14のEに図示されているように、人感センサのみが、自デバイス種とラベル名火災とが関連付けられていることを示す情報を持っているとする。なお、図14のEでは、人感センサは、ラベル名火災のイベントグループ情報を保持しているのが図示されているように、ラベル名火災を含む逆イベント通知メッセージの受信時にモード遷移を行うことが特定できるような情報であれば、情報の持ち方は限定されるものではない。MTCグループ内のすべてのMTCデバイス100が逆イベント通知メッセージ[火災]を受信するが、例えば、煙センサ、炎センサ、ドアロックセンサなどのMTCデバイス100は、ラベル名火災に関連付けられておらず、モード遷移を行わない。一方、人感センサは、ラベル名火災に関連付けられており、逆イベント通知メッセージ[火災]の受信によってモード遷移高優先度モードへの遷移を行う。なお、図13の5及び図14のEの例によれば、人感センサ以外のMTCデバイス100のモードはそのまま維持される一方、人感センサのモードが高優先度モードへ遷移するため、MTCデバイス100からのイベント通知メッセージの送信を抑制できているわけではない。しかしながら、あるMTCデバイス100からイベント通知メッセージが送信されたことを契機として、通常はノーマルモードで動作しているMTCデバイス100例えば、人感センサの送信モードを高優先度モードに変更できるという点において有用である。すなわち、通常はノーマルモードで動作しているMTCデバイス100人感センサを、必要に応じて迅速に高優先度モードに遷移させることが可能となる。<第3の実施の形態>上記の実施の形態の解決手法によれば、MTCデバイス100が通知するイベント通知メッセージとMME120が送信する逆イベント通知メッセージは、共にCプレーン上で交換されていたが、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、逆イベント通知メッセージはネットワーク装置例えば、MME120、MTCサーバ150やPGW140によってCプレーンが用いられる場合がある。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおけるメッセージは基本的にUプレーン上で交換すると設定されている場合、イベント例えば、煙発生を検知したMTCデバイス100は、Uプレーンを用いてイベント通知メッセージをPGW140/MTCサーバ150に通知する。ここで、ネットワーク装置例えば、PGW140/MTCサーバ150はMTCサービスの仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージの応答である逆イベント通知メッセージをUプレーンを用いて送信したいが、MME120経由で逆イベント通知メッセージを送信しなければならない場合例えば、MME120がイベント通知メッセージに格納されているイベント情報例えば、デバイスID/デバイス種IDを用いて、MTCデバイス100の管理情報を更新しなければならない場合がある。このようなケースが、本発明の第4の実施の形態に相当する。以下、本発明の第3の実施の形態におけるシステム動作の一例について、図15を用いて詳しく説明する。図15は、本発明の第3の実施の形態におけるシステム動作の一例複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法を説明するためのシーケンス図である。なお、図15には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。以下、図15に図示されているシーケンスについて説明する。ステップS321~ステップS322は、本発明の第2の実施の形態におけるステップS301~ステップS302図4を参照と同様なので、ここでは説明を省略する。続いて、MTCデバイスA100Aは、検知したイベント情報例えば、煙センサIDを格納したイベント通知メッセージイベント情報をUプレーン上で、MTCサーバ150に通知するステップS323:イベント通知メッセージイベント情報デバイスA。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージイベント情報デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順に転送される。なお、ここでは、MTCサーバ150が、イベント通知メッセージイベント情報の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージイベント情報の送信先を他のネットワーク装置例えば、PGW140にしてもよい。続いて、MTCサーバ150は、受信したイベント通知メッセージイベント情報からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、MTCサーバ150は、同一イベント例えば、煙の発生、若しくは、そのイベント例えば、煙発生を引き起こした出来事例えば、火災発生によって引き起こされたイベント例えば、炎の発生によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージをMME120に送信する。続いて、MME120がCプレーンを用いてMTCグループに属するMTCデバイス100に逆イベント通知メッセージをブロードキャストステップS324:逆イベント通知メッセージイベント情報。なお、ここでは、MME120が逆イベント通知メッセージを生成しているが、他のネットワーク装置例えば、MTCサーバ150やPGW140が生成してもよい。その場合、MME120でないネットワーク装置MTCサーバ150やPGW140がブロードキャストしてもよい。逆イベント通知メッセージを送信したMME120は、逆イベント通知メッセージに格納されていたイベント情報例えば、デバイスIDを抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶するステップS325:イベント情報の記憶。なお、ステップS326以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。本発明の第3の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、ネットワーク装置例えば、MME120、MTCサーバ150やPGW140から送信される逆イベント通知メッセージはCプレーンを用いることで、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、ネットワーク装置例えば、PGW140、MTCサーバ150が、MME120経由Cプレーンで逆イベント通知メッセージを送信しなければいけない場合例えば、MME120がイベント通知メッセージに格納されているイベント情報例えば、デバイスID/デバイス種IDを用いて、MTCデバイス100の管理情報を更新しなければならない場合に対応することができる。<第4の実施の形態>本発明の第4の実施の形態では、MTCデバイス100が通知するイベント通知メッセージはCプレーンで、ネットワーク装置例えば、MTCサーバ150やPGW140から送信される逆イベント通知メッセージはUプレーンが用いられる場合について説明する。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、MTCデバイス100がイベント例えば、煙発生を検知したとする。本来であれば、MTCデバイス100はUプレーンを用いて、イベント通知メッセージをPGW140/MTCサーバ150に通知するが、MME120がMTCデバイス100の管理に必要とする情報が伴う場合例えば、MTCデバイス100が移動可能な煙センサ例えば、煙発生を検知可能な移動ロボットであり、イベント情報に加えてMTCデバイス100の位置情報を通知する場合や、MTCサービスがMTCデバイス100の位置情報も付加してイベント情報を通知するMTCサービス例えば、MTCデバイス100が車などに搭載されていて、イベント検知時、位置情報も付加して送信するサービスである場合、あらかじめ通信システムのオペレータ、MTCサーバ150、MTCユーザ160によって設定されている仕様、登録情報や設定情報に基づいて、MTCデバイス100の判断でCプレーンを用いてイベント通知メッセージを通知する場合がある。以下、本発明の第4の実施の形態におけるシステム動作の一例について、図16を用いて詳しく説明する。図16は、本発明の第4の実施の形態におけるシステム動作の一例複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法を説明するためのシーケンス図である。なお、図16には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。以下、図16に図示されているシーケンスについて説明する。ステップS341~ステップS342は、本発明の第2の実施の形態におけるステップS301~ステップS302図4を参照と同様なので、ここでは説明を省略する。続いて、MTCデバイスA100Aは、検知したイベント情報例えば、煙センサIDを格納したイベント通知メッセージイベント情報をCプレーン上で、MME120に通知するステップS343:イベント通知メッセージイベント情報デバイスA。MME120は、MTCデバイスA100Aからイベント通知メッセージイベント情報デバイスAを受信し、必要な情報例えば、MTCデバイスA100Aの位置情報やデバイスIDなどを抽出し、例えば、MTCデバイスA100Aの管理処理例えば、MTCデバイスA100Aのコンテキスト情報の更新や、位置情報の更新などを行うステップS344:デバイスA管理処理。そして、MME120は、イベント通知メッセージイベント情報デバイスAに格納されていたイベント情報例えば、デバイスIDやデバイス種IDを抽出し、再度逆イベント通知メッセージをブロードキャストするか判断する際に使用するために記憶するステップS345:イベント情報の記憶。続いて、MME120は、受信したイベント通知メッセージイベント情報をMTCサーバ150に転送するステップS346。このとき、MME120は、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定された仕様、登録情報や設定情報に基づいて、受信したイベント通知メッセージイベント情報デバイスAをそのまま転送、若しくは、必要な情報例えば、イベント情報のみをMTCサーバ150に送信する。なお、ここでは、MTCサーバ150が、イベント通知メッセージイベント情報の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージイベント情報の送信先を他のネットワーク装置例えば、PGW140にしてもよい。なお、ステップS344のデバイスA管理処理からステップS346のイベント通知メッセージイベント情報デバイスAの転送処理は、順不同で実施してもよい。続いて、MTCサーバ150は、受信したイベント通知メッセージイベント情報からイベント情報を抽出し、逆イベント通知メッセージに格納する。そして、MTCサーバ150は、同一イベント例えば、煙の発生、若しくは、そのイベント例えば、煙発生を引き起こした出来事例えば、火災発生によって引き起こされたイベント例えば、炎の発生によるイベント通知メッセージの送信を抑制するために、逆イベント通知メッセージイベント情報をUプレーンを用いてMTCグループに属するMTCデバイス100にブロードキャストするステップS347:逆イベント通知メッセージイベント情報。ステップS348以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。本発明の第4の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージはCプレーンで、ネットワーク装置例えば、MTCサーバ150やPGW140から送信される逆イベント通知メッセージはUプレーンを用いることで、MTCサービスにおけるメッセージが基本的にUプレーンを用いて送信されると設定されている環境において、MTCデバイス100が、MME120経由Cプレーンでイベント通知メッセージを送信しなければいけない場合例えば、MME120がイベント通知メッセージに格納されているイベント情報例えば、デバイスID/デバイス種IDやMTCデバイス100の位置情報を用いて、MTCデバイス100の管理情報を更新しなければならない場合に対応することができる。<第5の実施の形態>本発明の第5の実施の形態では、MTCデバイス100が通知するイベント通知メッセージはUプレーンで、ネットワーク装置例えば、MTCサーバ150やPGW140から送信される逆イベント通知メッセージも同様にUプレーンが用いられる場合について説明する。すなわち、MTCデバイス100から通知されるイベント通知メッセージイベント情報とネットワーク装置例えば、MTCサーバ150やPGW140から送信される逆イベント通知メッセージイベント情報が、共にUプレーン上で交換される場合について説明する。例えば、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって、静的、若しくは、動的に設定されるMTCサービスの仕様や登録情報、また設定情報などに基づいて、MTCサービスにおける全てのメッセージがUプレーンを用いて送信されると設定されている環境である。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージイベント情報デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順で転送され、MTCサーバ150から送信される逆イベント通知メッセージイベント情報は、PGW140、SGW130、eNB110、MTCデバイス100という順で転送される。つまり、MME120は介さず、MTCサービスのメッセージが交換される。例えば、MTCサービスにおけるメッセージ例えば、イベントを検知した情報や、センシングデータなどは、MTCデバイス100の位置情報などを更新するメッセージ例えば、TAU、RAU、ページングなどを除いて、全てアプリケーション情報と解釈し、MTCデバイス100やUE105のモビリティ制御やPDNコネクションEPSベアラを管理、QoSなどを管理するためのCプレーンではなく、ユーザデータアプリケーション情報を転送するUプレーンでのみ交換しなくてはならないという環境が、本発明の第5の実施の形態に相当する。以下、本発明の第5の実施の形態におけるシステム動作の一例について、図17を用いて詳しく説明する。図17は、本発明の第6の実施の形態におけるシステム動作の一例複数のMTCデバイス100から送信される同一イベント、又は、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージの送信抑制方法を説明するためのシーケンス図である。なお、図17には、図1に図示したシステム構成における処理シーケンスの一例を図示する。ここで、MTCデバイス100の特徴は、本発明の第2の実施の形態における特徴と同様であり、ここでは説明を省略する。以下、図17に図示されているシーケンスについて説明する。ステップS361~ステップS362は、本発明の第2の実施の形態におけるステップS301~ステップS302と同様なので、ここでは説明を省略する。続いて、MTCデバイスA100Aは、検知したイベント情報例えば、煙センサIDを格納したイベント通知メッセージイベント情報をUプレーン上で、MTCサーバ150に通知するステップS363:イベント通知メッセージイベント情報デバイスA。すなわち、MTCデバイスA100Aから通知されるイベント通知メッセージイベント情報デバイスAは、eNB110、SGW130、PGW140、MTCサーバ150という順で転送される。なお、ここでは、MTCサーバ150が、イベント通知メッセージイベント情報の通知先になっているが、通信システムのオペレータ、MTCサーバ150やMTCユーザ160によって設定される仕様や登録情報、また設定情報などに基づいて、イベント通知メッセージイベント情報の送信先を他のネットワーク装置例えば、PGW140にしてもよい。続いて、MTCサーバ150は、受信したイベント通知メッセージイベント情報のイベント情報例えば、デバイスIDやデバイス種IDを逆イベント通知メッセージに格納し、Uプレーンを用いてMTCグループに属するMTCデバイス100にブロードキャストするステップS364:逆イベント通知メッセージイベント情報。続いて、MTCサーバ150は、同一イベント例えば、煙の発生、若しくは、そのイベント例えば、煙発生を引き起こした出来事例えば、火災発生によって引き起こされたイベント例えば、炎の発生によるイベント通知メッセージの送信を抑制するために、イベント通知メッセージイベント情報デバイスAに格納されているイベント情報例えば、デバイスIDやデバイス種IDを記憶するステップS365:イベント情報の記憶。ステップS366以降は、本発明の第2の実施の形態のステップS306以降と同様なので、ここでは説明を省略する。本発明の第5の実施の形態のように、MTCデバイス100が通知するイベント通知メッセージとネットワーク装置例えば、MTCサーバ150やPGW140が送信する逆イベント通知メッセージが共にUプレーンを用いることで、例えばMTCサービスにおけるメッセージ例えば、イベントを検知した情報や、センシングデータなどは、MTCデバイス100の位置情報などを更新するメッセージ例えば、TAU、RAU、ページングなどを除いて、全てアプリケーション情報と解釈し、MTCデバイス100やUE105のモビリティ制御やPDNコネクションEPSベアラを管理、QoSなどを管理するためのCプレーンではなく、ユーザデータアプリケーション情報を転送するUプレーン上で交換しなくてはならないという環境に対応することができる。<第6の実施の形態>また、上記の各実施の形態では、PGW140をデータゲートウェイとするEPSEvolvedPacketSystemアーキテクチャを用いた例について説明したが、それ以外にも、例えばGPRSGeneralPacketRadioServiceアーキテクチャや、UMTSUniversalMobileTelecommunicationsSystemアーキテクチャ、またそれらアーキテクチャが混在するような構成においても、同様に実施可能であることは当業者にとって明らかである。例えば、GPRSアーキテクチャやUMTSアーキテクチャに基づく構成の場合、上述したようなMME120とSGW130の役割をSGSNServingGPRSSupportNodeが担い、相当する処理を実施する。また、同様にPGW140の役割をGGSNGatewayGPRSSupportNodeが担い、相当する処理を実施する。さらには、PDNコネクションと同等の論理通信路として、PDPコンテキストが用いられる。いくつかのメッセージについては、その表記やシグナリングの手順、またメッセージの順序などが若干異なる場合があるが、本発明による実施においては問題ではない。なお、その他の通信システム例えば、WLANなどのローカル通信システムやWiMAXなどの広域通信システム、3GPP2などのセルラシステム、その他自営通信システムなどにおいても同様に実施可能である。<第7の実施の形態>上記の実施の形態では、図1のMTC通信ネットワークの構成において、複数のMTCデバイス100が1つのMTCグループとしてまとめられ、各MTCデバイスが3Gアクセス例えば、E-UTRAN115への通信インタフェースを保持し、3Gアクセスを介して、MTCデバイス100が検知したイベントや、センシングデータをMTCサーバ150に送信するアーキテクチャを用いた例について説明した。しかし、それ以外にも、例えば、MTCデバイス100と3Gアクセスとの間にMTCデバイスゲートウェイを設け、MTCデバイスゲートウェイがMTCデバイスから送信されたメッセージを転送するアーキテクチャにおいても実施可能であることが明らかである。本発明の第7の実施の形態におけるMTC通信ネットワークの構成の一例を図18に示す。図18において、図1と異なる点は、MTCデバイス100とeNB1103Gアクセスとの間にMTCデバイスゲートウェイ102が存在することである。図18において、MTCデバイスゲートウェイ102は、3Gアクセス115と通信するための通信インタフェースを1つ以上持つ。さらに、MTCデバイスゲートウェイ102は、複数のMTCデバイス100と通信するための通信インタフェース例えば、通信バスを設け、そのバスへの通信インタフェースや、有線LANのような通信インタフェースや、Zigbeeジグビー登録商標や無線LANなどの無線通信プロトコルを持つ。一方、MTCデバイス100は、上記の各実施の形態のMTCデバイス100とは異なり、3Gアクセスへの通信インタフェースを持っていなくてもよい。すなわち、MTCデバイス100は、検知したイベント情報やセンシングデータを直接3Gアクセス経由でMTCサーバ150に送信することができなくてもよい。その代わり、MTCデバイス100が検知したイベント情報やセンシングデータは、MTCデバイスゲートウェイ102に送信することで、MTCデバイスゲートウェイ102が3Gアクセスを経由して、ネットワーク装置例えば、MME120、PGW140やMTCサーバ150に転送する。このように、MTCデバイスゲートウェイ102が、MTCデバイス100が取得したデータをまとめて送信することで、通信システムのオペレータ、MTCサーバ150やMTCユーザ160は、個別にMTCデバイス100を管理する必要がなくなり、処理負荷とリソースが軽減される。また、3Gアクセスに通信する装置をMTCデバイスゲートウェイ102にまとめることで、例えば、全MTCデバイス100に高価な3Gアクセスへの通信インタフェースを搭載する必要がなくなり、コスト削減を図ることもできる。なお、本発明の第6の実施の形態は、マンションやビル、集合住宅などを監視するシステムを管理する業者において、現実的な実施の形態と言える。また、第1の実施の形態で説明したように、少なくともMTCデバイスゲートウェイ102が複数のMTCデバイス100から送信されたデータの優先度レベルを確認することができ、ネットワーク側で混雑状態が起こっているとき例えば、eNB110、MME120やPGW140がオーバーフローや、MTCユーザ160が通信システムオペレータと特別な契約例えば、高額な利用料金の課金ルールを結ぶことで、優先的なデータ転送がされる契約を保持するとき、又は、オペレータ方針によって一定の優先度レベルを用いたデータ転送の指示が配布されたとき例えば、優先度レベル3以上はデータ転送可のときには、MTCデバイスゲートウェイ102が優先度レベルを確認しながら例えば、ネットワーク側が示す許容優先度レベルとMTCデバイス100から転送されるデータに格納された優先度レベルを比較する。または、MTCデバイス100やMTCデバイスゲートウェイ102にあらかじめ組み込まれているコンテキスト例えば、混雑度レベル3のときは優先度レベル3以上のメッセージのみ送信許容などのルールが登録されているコンテキストやアプリケーションデータに含まれている優先度レベルを確認する、転送データの選択をすることで、優先度レベルが高いデータのみネットワーク側へ転送することができる優先度の低いデータの転送は後回し例えば、混雑状態の解消後にすることができる。これにより、ネットワーク側の混雑状態が起こっている場合でも、MTCユーザ160やMTCサーバ150は、優先的に収集しているデータを受信することができる。また、MTCデバイス100がMTCデバイスゲートウェイ102の役割を担うことも可能である。この場合、MTCデバイスゲートウェイ102となるMTCデバイス100の負荷が増えることが予想され、負荷を分散する手段が必要となり得る。例えば、MTCデバイスゲートウェイ102の役割を、MTCグループの各MTCデバイス100で順番に例えば、時間で区切って担当していくなどして負荷分散することが可能である。<第8の実施の形態>上記の実施の形態では、ネットワーク側で混雑状態になる前にネットワーク側の装置例えば、eNB110、MME120や、SGW130、PGW140、MTCサーバ150から逆イベント通知メッセージが通知され、MTCデバイス100から送信される冗長なイベント通知メッセージの送信を抑制し、ネットワーク側の混雑状態を回避していた。しかし、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ例えば、PDNコネクション確立リクエストや、転送データを受信した時点で混雑状態が起こり始めたときに、UE105などから優先度の高い緊急メッセージEmergencyrequestや、Emergencymessageとも呼ばれるやデータアプリケーションメッセージ、PDNコネクション確立リクエストが送られてきた場合、更なるリソースU-planeUプレーン、C-planeCプレーン共が必要となる。例えば、通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140における処理能力のリソース例えば、データ転送における処理や、MTCデバイス100やUE105に割り当てる通信リソースや帯域リソースなどがある。このような課題も解決するために、既に確立済みであるPDNコネクションをUE105やMTCデバイス100、ネットワーク側のエンティティ例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150が保持する優先度レベル例えば、UE105やMTCデバイス100に割り当てられる優先度レベルや、送信するデータの優先度レベルや、QCIやARPを用いて選択的に切断すること、あるいは、新規PDNコネクションの確立を制御することで優先度レベルの高いリクエストやメッセージ、アプリケーションのためのリソースを確保する。なお、この本発明の第8の実施の形態は、MTCデバイス100やUE105が多く存在するエリアで起こり得る現実的な実施の形態である。以下、本発明の第8の実施の形態について、図19~24を用いて説明する。ここで、本発明の第8の実施の形態の説明を容易化するために、図19と図20におけるMTCデバイスBとMTCデバイスDとMTCデバイスEとMTCデバイスFは、非特許文献1で定義されているTimetolerantタイムトレラント耐時間性を有していることを前提とする。このTimetolerantの機能を保持しているMTCデバイス100は、ネットワークが混雑状態の場合やオペレータ方針などによって、メッセージ例えば、PDNコネクション確立リクエストやデータ転送の送信タイミングを遅らせることができる。このTimetolerantの動作について、図19を用いて説明する。図19は、MTCデバイスAとMTCデバイスBとMTCデバイスCが既にPDNコネクションを確立済みで各MTCデバイス100から3Gアクセス側にデータ転送をしており図19のAデータ転送、MTCデバイスDとMTCデバイスEとMTCデバイスFが順次的に、これからPDNコネクションを確立し、3Gアクセス側にデータ転送を行おうとしている状態であるMTCデバイスA~CはConnectedmodeであり、MTCデバイスD~Fは順次的にIDLEmodeからConnectedmodeになろうとしている状態。このとき、MTCデバイスDがPDNコネクションを確立しようとした際に、3Gアクセス側で混雑状態が発生してしまうとする例えば、3Gアクセス側で許容できるトラフィック量を超えてしまう図19のF混雑発生。この場合、3Gアクセス側は、MTCデバイスDのPDNコネクションの確立を拒絶することを示すPDNコネクション確立拒絶メッセージをMTCデバイスDに返信した後に、3Gアクセス側で混雑状態になっていることを通知するメッセージ図19のB送信制御メッセージを対象となるMTCデバイス100本発明の第8の実施の形態では、MTCデバイスA~Fである。実環境では、例えば、特定のAPNに接続しているMTCデバイス100、特定のMTCグループに属しているMTCデバイス100、特定のオペレータに属しているMTCデバイス100、特定のエリア例えば、特定のeNB110やMME120に接続しているMTCデバイスなどにブロードキャスト送信する。なお、ネットワークが混雑状態を認識するタイミングは、上記のようにMTCデバイスDのPDNコネクション確立要求を受けた際に限定されず、既にPDNコネクションを確立しているMTCデバイスによって送信されたデータによって輻輳が発生した、あるいは発生しそうである場合に、送信制御メッセージを対象となるMTCデバイスが属するエリアへブロードキャスト送信する。なお、B送信制御メッセージには、例えば、MTCデバイス100から送信されるメッセージ例えば、PDNコネクション確立リクエストをどのくらい遅らせるかを示す値例えば、待機時間が格納されていることとする図19のC待機時間。待機時間が格納されたB送信制御メッセージを受信したMTCデバイス100は、Timetolerantの機能を保持しているか確認する。Timetolerantの機能を保持しているMTCデバイス100は、B送信制御メッセージを受信した後、3Gアクセスから示された値例えば、待機時間に基づいて、送信メッセージのタイミングを遅らせることができる例えば、図19のDからE。なお、ここでは3Gアクセスから示された値待機時間に基づいて送信メッセージのタイミングを遅らせているが、例えばMTCデバイスが値待機時間を計算してもよく、また、MTCサーバ150などの外部サーバに値待機時間を問い合わせてもよい。Timetolerantの機能を保持していないMTCデバイス100やUE105がB送信制御メッセージを受信した場合は、送信メッセージのタイミングを遅らせることができないため、C待機時間の間にメッセージ例えば、PDNコネクション確立リクエストやアプリケーションデータ、Emergencyrequestや、Emergencymessageを送信する。Timetolerantを保持していないMTCデバイス100やUE105が送信するメッセージは、C待機時間の後に再送信することができない送信メッセージのタイミングを遅らせることができないため、優先度レベルが高いMTCデバイス100やUE105から送信されるメッセージとして送信できるようにする。この優先度レベルが高いMTCデバイス100やUE105から送信されるメッセージをネットワーク側が受け入れられるようにするために、送信メッセージのタイミングを遅らせることができる優先度レベルが低いMTCデバイス100Timetolerantの機能を保持するMTCデバイス100によって確立されたPDNコネクションを切断するC待機時間の後にメッセージを送信させることで、リソースC-plane、U-plane共を確保する。Timetolerantの機能を保持していないMTCデバイス100とUE105がB送信制御メッセージを受信した際、一定の期間例えば、B送信制御メッセージに格納されている値待機時間ではなく、MTCデバイス100やUE105にあらかじめ組み込まれている待機時間固定値を待機することができる場合、Timetolerantの機能を保持しているMTCデバイス100は、Timetolerantの機能を保持していないMTCデバイス100より長い時間、メッセージの送信を遅らせることができるものとする。以下、本発明の第8の実施の形態におけるシステム動作の一例について、図20を用いて詳しく説明する。図20は、本発明の第8の実施の形態におけるシステム動作の一例既に確立済みであるPDNコネクションをUE105やMTCデバイス100、ネットワーク側のエンティティ例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150が保持する優先度レベル例えば、UE105やMTCデバイス100に割り当てられる優先度レベルや、送信するデータの優先度レベルや、QCIやARPを用いて切断することで優先度レベルの高いリクエストやアプリケーションのためのリソース確保方法を説明するためのシーケンスチャートである。なお、図20には、図1に図示したシステム構成における処理シーケンスの一例を図示する。MTCデバイスA100AとMTCデバイスB100BとMTCデバイスC100Cは、既にPDNコネクションを確立済みであり、データ転送を行っていることとする図20のステップS1001A、S1001B、S1001C:PDNコネクション確立済み。続いて、MTCデバイスD100Dがデータ転送をするためにPDNコネクション確立リクエストをMME120に送信する図20のステップS1002:PDNコネクション確立リクエスト。PDNコネクション確立リクエストを受け、ネットワーク側のエンティティ例えば、eNB110やMME120などが、例えば処理能力の許容レベル閾値を上回ったかどうか確認することによって、混雑状態を検出するリソースの確保が必要であることを検出する図20のステップS1003:混雑検出。ここでは、MTCデバイスD100Dから送信されたPDNコネクション確立リクエストを受信することでネットワーク側のエンティティ例えば、eNB110やMME120などが混雑状態を検出しているが、データ転送をしているMTCデバイス100本発明の第8の実施の形態では、MTCデバイスA~Cによって送信されるデータサイズ送信されているデータの総量の増加などによって、ネットワーク側のエンティティが混雑状態を検出してもよい。また、本実施の形態の説明を容易化するために、MME120が混雑状態を検出しているが、他のエンティティ例えば、eNB110やSGW130、PGW140、MTCサーバ150が混雑状態を検出してもよい。その場合、各エンティティがMTCデバイスD100Dに混雑状態が起こっていることを直接通知してもよいし、MME120やeNB110などに通知することで、間接的に通知してもよい例えば、PGW140が混雑状態を検出し次第、MME120に混雑状態を通知し、MME120はMTCデバイスD100DからPDNコネクション確立リクエストが送信されてきた際に、混雑状態をMTCデバイス100に通知してもよい。混雑状態を検出したMME120は、PDNコネクションを確立できないことを通知するためにPDNコネクション確立リクエスト拒絶メッセージをMTCデバイスD100Dに送信する図20のステップS1004:PDNコネクション確立リクエスト拒絶。続いて、eNB110は、対象となるMTCデバイス100例えば、特定のAPNに接続しているMTCデバイス、特定のMTCグループに属しているMTCデバイス、特定のオペレータに属しているMTCデバイス、特定のエリア例えば、特定のeNB110やMME120に接続しているMTCデバイスなどに送信制御メッセージをブロードキャストする図20のステップS1005、S1006:送信制御メッセージ。対象となるMTCデバイス100の決定は、例えば、ステップS1005のブロードキャストメッセージ指示でMME120がeNB110に指示してもよい。このとき、MME120はeNB110やSGW130、PGW140、MTCサーバ150に指示を問い合わせてもよい。なお、eNB110が対象となるMTCデバイス100にブロードキャスト送信する際、従来技術であるページングメッセージPagingやMBMSMultimediaBroadcastAndMulticastServiceを用いてよい。また、ここでは、本実施の形態の説明を容易化するために、MME120がeNB110にブロードキャストメッセージを指示し、eNB110が対象デバイスにブロードキャストしているが、他のエンティティがブロードキャストメッセージを指示し、ブロードキャスト送信してもよい例えば、PGW140がeNB110にブロードキャストメッセージ指示し、eNB110がブロードキャスト送信。また、MME120によるメッセージの送信処理ステップS1004とステップS1005の順序は、入れ替わってもよい。さらに、ステップS1005において送信制御メッセージをブロードキャストすることで、MTCデバイスD100DのPDNコネクション確立リクエストの拒絶を通知することができるのであれば、ステップS1004を省略してもよい。送信制御メッセージを受信したMTCデバイス100は、Timetolerantの機能を保持しているか確認する。MTCデバイス100が、Timetolerantの機能を保持している場合、PDNコネクション確立リクエストを送信するタイミングを送信制御メッセージに格納されている待機時間に基づいて遅らせる。Timetolerantの機能を保持していないMTCデバイス100は、送信メッセージのタイミングを遅らせることができないので、ネットワーク側で混雑状態が起こっている場合でもPDNコネクション確立リクエストを送信する。このように、MTCデバイス100からのPDNコネクション確立リクエストの送信を回避することで、通信システムの処理負荷が軽減され、C-planeのリソースは確保できる。しかしながら、既にPDNコネクションを確立しているMTCデバイスMTCデバイスA100A~MTCデバイスC100Cのデータ転送が完了するまで、U-planeのリソースに空きは生じない。さらに、上記したようにUE105などから優先度の高い緊急メッセージEmergencyrequestや、Emergencymessageとも呼ばれるやアプリケーションメッセージが送られてくることで、優先度レベルの高いUE105やMTCデバイス100用の更なるリソースU-plane、C-plane共が必要となることがある。そこで、MTCデバイス100の優先度レベルを用いて、既に確立済みであるPDNコネクションを選択的に切断することで優先度レベルの高いPDNコネクション確立リクエストやアプリケーションデータの転送のためのU-planeのリソースを確保する。この優先度レベルを判別するためにも、例えば、Timetolerantの機能を保持しているMTCデバイス100であるかどうかをMTCデバイス100に確認させる。そこで、eNB110がブロードキャスト送信する送信制御メッセージにTimetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断するよう指示するパラメータを格納する。Timetolerantの機能を保持するMTCデバイス100は、例えば、eNB110からブロードキャスト送信される送信制御メッセージの受信後、確立済みのPDNコネクションを切断する。また、MTCデバイス100は、送信制御メッセージから一定時間例えば、3Gアクセスから示された値例えば、待機時間経過後、再度PDNコネクションを確立し、データ転送を行ってもよい。図21は、図20のステップS1006において、eNB110が対象となるMTCデバイス100にブロードキャスト送信する送信制御メッセージであり、Timetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断するよう指示するパラメータと、更に付加される詳細な条件を示したパラメータが格納されるメッセージ構成の一例として、送信制御メッセージのフォーマット例を示す図である。図21は、ブロードキャスト送信するために必要となるヘッダフィールドとTimetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断することを示したTimetolerantフィールドとさらに詳細な情報を用いてPDNコネクションの維持/切断を判断する際に用いる詳細な条件詳細データが格納される詳細データフィールドで構成される。詳細データフィールドには、従来技術のAPNや位置情報例えば、eNBIDやeNBアドレス、MTCグループを識別するグループID、接続しているネットワークオペレータを識別するPLMNIDに加えて、確立済みのPDNコネクションを用いて転送するデータのデータ残量データ残量値や予想完了時間予想完了時刻、残時間、PDNコネクションEPSベアラのQCIQoSClassIndicatorやARPAllocationandRetentionPriority、データ転送を開始した時刻以降、Beforetimeとも呼ぶ、MTCfeature例えば、非特許文献1で定義されている着信しかできないMobileoriginatedonlyの機能を保持しているMTCデバイス100などを格納することができる。MTCデバイス100は、確立済みのPDNコネクションを維持/切断する判断条件として、MTCデバイス100がTimetolerantの機能を保持しているかに加えて、詳細データフィールドに格納されている詳細な判断条件を用いることができる。つまり、この詳細データフィールドを用いることで、論理演算を用いて説明するとTimetolerantの機能を保持しているMTCデバイス100AND詳細データや、Timetolerantの機能を保持しているMTCデバイス100OR詳細データや、Timetolerantの機能を保持しているMTCデバイス100EXOR詳細データの結果で、確立済みのPDNコネクションの維持/切断を決定することができる。なお、MTCデバイス100やUE105、通信システムのエンティティが、優先度レベルの低いMTCデバイス100、又は、アプリケーションであることを示すパラメータ例えば、Lowpriorityindicatorを認識できる場合は、Lowpriorityの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断することを示したパラメータと置き換えてもよい代わりに使用してもよい。例えば、Timetolerantの機能を保持しているMTCデバイス100であり、Mobileoriginatedonlyの機能を保持しているMTCデバイス100によって確立されたPDNコネクションのみ切断する。または、Timetolerantの機能を保持しているMTCデバイス100、もしくは、Mobileoriginatedonlyの機能を保持しているMTCデバイス100によって確立されたPDNコネクションは切断する。または、Timetolerantの機能を保持しているMTCデバイス100であり、Mobileoriginatedonlyの機能を保持しているMTCデバイス100によって確立されたPDNコネクションと、Timetolerantの機能を保持しているMTCデバイス100とMobileoriginatedonlyの機能を保持しているMTCデバイス100でもないMTCデバイス100によって確立されたPDNコネクションは切断するというように定義してもよい。また、例えば詳細データフィールドにBeforetimeを格納することで、Timetolerantの機能を保持しているMTCデバイス100であり、Beforetimeで示された値時刻以降にPDNコネクションを確立、若しくは、データ送信を開始したMTCデバイス100である場合、確立済みのPDNコネクションを切断すると定義してもよい。このとき、Beforetimeは、例えばAM11:00のように値時刻を示してもよい。また、Beforetimeは、Beforetimeで示された値時刻以内にPDNコネクションを確立したMTCデバイス、若しくは、データ転送を開始してから経過した時間のように指示することもでき、その場合は、例えば1分のように値時刻を示してもよい。また、例えば詳細データフィールドに転送するデータのデータ残量データ残量値を格納することで、Timetolerantの機能を保持しているMTCデバイス100であり、MTCデバイス100によって送信されるデータの残量がネットワーク側から指示されたデータ残量値を超えてしまっている場合は、確立済みのPDNコネクションを切断すると定義してもよい。このとき、データ残量値は、例えば1MBytesのように値を示してもよい。また、例えば詳細データフィールドに予想完了時間残時間を格納することで、Timetolerantの機能を保持しているMTCデバイス100であり、MTCデバイス100が予想するデータ送信の予想完了時間残時間がeNB110からブロードキャスト送信された送信制御メッセージに格納されている予想完了時間残時間を超えてしまっている場合は、確立済みのPDNコネクションを切断すると定義してもよい。このとき、予想完了時間は、例えばAM11:15、残時間は1分のように値を示してもよい。また、この予想完了時間や残時間は、例えば、データダウンロード完了までの時間を表わすアプリケーションなどから取得できる情報を利用してもよい。また、例えば詳細データフィールドにQCIやARPを格納することで、Timetolerantの機能を保持しているMTCデバイス100であり、現在送信しているデータで用いているPDNコネクションやEPSベアラのQCIやARPが、詳細データフィールドで示された値以下である場合、該当するPDNコネクションを切断するというように定義してもよい。通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140やMTCサーバ150が詳細データフィールドに格納するQCIやARPは、例えばSubscriptiondataやMTCデバイス100の情報が登録されているコンテキスト、課金ルールなどを管理しているPCRFPolicyandChargingRulesFunction、図1には不図示から取得したデータなどを用いて決定してもよい。例えば、MME120がHSS125から送信制御メッセージの送信対象先であるMTCデバイス100のSubscriptiondataを取得し、確立されているPDNコネクションの平均QCIやARPを導き出し、現在の混雑状態と照らし合わせて、詳細データフィールドに格納するQCIやARPを決定してもよい。MTCデバイス100は、上記したような詳細データフィールドに格納されているPDNコネクションを切断するための詳細な判断条件を用いるために、例えば、Beforetimeが格納される場合は、Beforetimeを用いるためにMTCデバイス100はデータ転送を開始した時刻や、PDNコネクションを確立した時刻を記憶、若しくは、その時点からタイマーを起動し、eNB110からブロードキャスト送信された送信制御メッセージを受信するまでの時間を計測してもよい。また、詳細データフィールドにデータ残量データ残量値が格納される場合は、MTCデバイス100は、現在送信しているデータの残りを把握しておく必要がある。例えば、MTCデバイス100は送信予定のデータ総量例えば、50MBytesと送信済みデータ量を記憶しておくことで、データ残量を計算してもよい。また、詳細データフィールドに予想完了時間あるいは、予想完了時刻や残時間が格納される場合は、MTCデバイス100は、現在送信しているデータの予想完了時間や、送信完了するまでに要する時間を把握しておく必要がある。例えば、MTCデバイス100は送信予定のデータ量例えば、50MBytesと送信レート例えば、1Mbpsと送信済みデータ量例えば、40MBytesを把握しておき、データ転送の予想完了時間現時刻がAM11:00とすると、データ転送の予想完了時刻50MBytes―40MBytes×8bits÷1Mbps=80秒なので、AM11:0120秒や残時間80秒を見積もってもよい。上記式は、単純に計算した式の例であり、実環境におけるパケットロス率などを考慮した式を用いてもよい。また、このような予想完了時間や残時間は、起動しているアプリケーションから取得してもよい。また、詳細データフィールドにQCIやARPが格納される場合は、MTCデバイス100は、現在使用しているPDNコネクションのQCIやARPを把握しておく必要がある。例えば、MTCデバイス100は、PDNコネクションEPSベアラを確立した際例えば、Attachprocedure中や、Bearermodificationprocedure中にネットワーク側のエンティティ例えば、eNB110、MME120、SGW130、PGW140、HSS125からQCIやARPを取得し、ネットワーク側からブロードキャスト送信される送信制御メッセージに格納されるQCIやARPと比較してもよい。また、詳細データフィールドにMTCfeatureが格納される場合は、MTCデバイス100は、搭載しているMTCfeatureを把握しておく必要がある。例えば、MTCデバイス100は、MTCデバイス100コンテキストを持ち、そのコンテキストの中に各MTCデバイス100が搭載する全てのMTCfeatureを登録してもよい。または、MTCデバイス100が3GアクセスとPDNコネクションを確立する際例えば、Attachprocedure中、ネットワーク側からMTCデバイス100が保持できるMTCfeature、もしくは、MTCサーバ/ユーザから指示されているMTCfeatureをMTCデバイス100に通知することで、MTCデバイス100が搭載しているMTCfeatureを把握してもよい。なお、詳細データフィールドを用いずに、TimetolerantフィールドのみでPDNコネクションの維持/切断を判断する場合は、例えば図21に図示されているフォーマットから詳細データフィールドを省略してもよい。また、Timetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断することを通知するために、従来技術のページングとSIBSystemInformationBlockを用いてもよい。例えば、MTC用のSIBを新たに設ける、若しくは、既存のSIBを改良して、MTCデバイス100にそのSIBを読み出すように指示することで、Timetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断することを通知してもよい。また、従来技術のMBMSMultimediaBroadcastAndMulticastServiceを用いて、各MTCデバイス100に通知してもよい。Timetolerantの機能を保持するMTCデバイス100は確立済みPDNコネクションを切断することを通知されたMTCデバイス100は、自分自身がTimetolerantの機能を保持しているかどうかを確認する。MTCデバイス100が、Timetolerantの機能を保持しており、かつ、既にPDNコネクションを確立済みである場合には、PDNコネクションを切断する図20のステップS1007:PDNコネクションリリース。なお、ここではMTCデバイス100が、Timetolerantの機能を保持していて、既にPDNコネクションを確立済みである場合、即座にPDNコネクションを切断しているが、例えばMTCデバイスと通信システムのポリシや、アプリケーションの仕様などに基づいて、切断のタイミングを見計らってもよい。また、MTCデバイス100と通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140は、PDNコネクションを切断する際、完全に切断するのではなく、再度PDNコネクションを確立する際の時間短縮や処理負荷軽減のために以前の状態例えば、MTCデバイス100のIPアドレス、IMSI、IMEI、鍵情報を一定期間、各装置で保持して再利用してもよい。また、図20の例では、MTCデバイスB100Bが、Timetolerantの機能を保持しており、かつ、既にPDNコネクションを確立済みのMTCデバイス100に該当する。すなわち、MTCデバイスB100Bは、ステップS1006の送信制御メッセージを受信すると、確立済みのPDNコネクションを切断する。なお、このとき、MTCデバイスB100Bは、確立したPDNコネクションを切断するために、非特許文献3で定義されているUE-initiatedDetachProcedureやUErequestedbearerresourcemodificationprocedureなどの従来技術に係る処理を用いてもよい。また、Timetolerantを保持しておらず、PDNコネクションが確立済みのMTCデバイス100図20の例では、MTCデバイスA100AとMTCデバイスC100Cに相当は、PDNコネクションをそのまま維持する。また、Timetolerantを保持していて、PDNコネクションを保持しておらず、これからメッセージ例えば、PDNコネクション確立リクエストを送信しようとしていたMTCデバイス100MTCデバイスE100EやMTCデバイスF100Fに相当は、上記で説明したように例えば、図19のDからE、メッセージの送信タイミングを遅らせる。また、その後、UE105などから優先度の高い緊急メッセージEmergencyrequestや、Emergencymessageとも呼ばれるやアプリケーションメッセージが送られてくる場合、若しくは、メッセージを送るためのPDNコネクション確立リクエストが送られてくる場合図20のステップS1008:データ送信/PDNコネクション確立リクエストがある。この場合、UE105は、メッセージを送信することが可能である。ステップS1007で、MTCデバイスBが確立済みのPDNコネクションを切断したことによってリソースC-plane、U-plane共が確保されたため、ネットワーク側はステップS1008のUEによるデータ送信、若しくは、PDNコネクション確立リクエストを受け入れることができる。なお、本発明の第8の実施の形態では、Timetolerantの機能を保持するMTCデバイス100のみを対象とするのではなく、APNやMTCグループのグループID、ネットワークオペレータを識別するPLMNIDPublicLandMobileNetworkID、デバイス種ID、デバイスIDなどと組み合わせて使用してもよい。また、本発明の第8の実施の形態は、MTCデバイス100が送信制御メッセージ受信後に確立したPDNコネクションを切断しているが、通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140やMTCサーバ150が、SubscriptiondataやMTCデバイス100特有のコンテキスト、メッセージ交換例えば、Attachprocedure時などの情報から、切断すべきPDNコネクション特定のPDNコネクションを確認することができるのであれば、通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140やMTCサーバ150主導でPDNコネクションを切断してもよい。このとき、非特許文献3で定義されているPDNGWinitiatedbearerdeactivationやMME-initiatedDetachprocedureなどの従来技術に係る処理を用いてもよい。例えば、通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140やMTCサーバ150が、優先度の高いUE105やMTCデバイス100のためのリソースを確保するために算出、若しくは、取得したPDNコネクションを切断するための条件例えば、Timetolerantの機能を保持するMTCデバイス100で、Beforetimeで示される値に該当するMTCデバイス100と、記憶していたMTCデバイス100によってPDNコネクションが確立された時刻を比較し、切断すべきPDNコネクションを確認することができる場合がある。次に、図22を参照しながら、本発明の第8の実施の形態におけるMTCデバイス100の構成について説明する。図22は、本発明の第8の実施の形態におけるMTCデバイス100の構成の一例を示す図である。図22において、MTCデバイス100は、通信システム例えば、E-UTRANやUTRANと接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部1110、ネットワーク側からブロードキャスト送信された送信制御メッセージのTimetolerantフィールドと詳細データフィールドを処理するブロードキャストメッセージ処理部1120、ブロードキャストメッセージ処理部1120の結果に基づいて、既に確立済みのPDNコネクションを維持/切断するPDNコネクション処理部1130を少なくとも有する。また、送信制御メッセージの詳細データフィールドに情報が格納される場合は、詳細データ処理部1140を設けてもよい。詳細データ処理部1140は、例えば、Beforetimeを用いてデータ送信開始時間でPDNコネクションの切断をする場合、MTCデバイス100内でデータ送信を開始した時間を記憶する機能やタイマー機能を有する。詳細データ処理部1140は、既存の処理部例えば、ブロードキャストメッセージ処理部1120に組み込んでもよい。次に、図22に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図23を用いて詳しく説明する。図23において、MTCデバイス100は、eNB110からブロードキャスト送信されたメッセージ送信制御メッセージを受信する図23のステップS1210。MTCデバイス100は、MTCデバイス100自身がPDNコネクションを切断するMTCデバイス100であるかを確認するために、ブロードキャストメッセージ送信制御メッセージのTimetolerantフィールドと詳細データフィールドに格納されている情報をブロードキャストメッセージ処理部1120で取得する図23のステップS1220。MTCデバイス100は、受信したブロードキャストメッセージの送信対象に自分が含まれていないと判断した場合には、特別な処理は行わずに終了する。一方、MTCデバイス100が、受信したブロードキャストメッセージの送信対象に自分が含まれていると判断した場合には、MTCデバイス100と通信システムの間にPDNコネクションを確立済みであるかどうかを更に確認する図23のステップS1230。なお、MTCデバイス100が、ブロードキャストメッセージの送信対象に自分が含まれているかどうかを判断する処理フロー図23のステップS1220の処理の詳細については後述する図24を参照。MTCデバイス100と通信システム間にPDNコネクションが確立されていない場合、MTCデバイス100はPDNコネクション未確立時の動作例えば、Timetolerantの機能を保持しているMTCデバイス100は、PDNコネクション確立リクエストの送信タイミングを遅らせるを実施して図23のステップS1240、終了する。一方、MTCデバイス100と通信システム間に、既にPDNコネクションを確立されている場合、MTCデバイス100は、PDNコネクション処理部1130で、例えば非特許文献3で定義されているUE-initiatedDetachProcedureやUErequestedbearerresourcemodificationprocedureなどを用いて、確立済みのPDNコネクションを切断する図23のステップS1250。次に、詳細データフィールドに格納された値を用いてPDNコネクションを維持/切断する際の詳細な流れについて説明する。例えば、詳細データフィールドにデータ転送を開始してから経過した時間を示すBeforetimeが格納されている場合について、図24を用いて詳しく説明する。なお、図24は、図23のステップS1220の処理の詳細について説明するためのものである。図24において、MTCデバイス100は、eNB110からブロードキャスト送信されたメッセージ送信制御メッセージを受信する図24のステップS1210。続いて、MTCデバイス100は、MTCデバイス100自身がPDNコネクションを切断するMTCデバイス100であるかを確認するために、ブロードキャストメッセージ送信制御メッセージのTimetolerantフィールドを確認する図24のステップS1221。このとき、MTCデバイス100は、例えば、製造時に設定された情報例えば、MTCfeatureの一覧が登録されているMTCデバイス100コンテキストやAttachprocedure中にネットワーク側から通知される情報例えば、通信システムのオペレータから設定されるMTCfeatureや、MTCUserから設定されるMTCfeatureなどから、自分自身がTimetolerantの機能を保持しているか確認してもよい。MTCデバイス100は、自分自身がTimetolerantの機能を保持していないと判断した場合には、特別な処理は行わずに終了する。一方、MTCデバイス100が、自分自身がTimetolerantの機能を保持していると判断した場合には、続いて、送信制御メッセージの詳細データフィールドで示されたBeforetimeの値時刻を取得する。ここでは、MTCデバイス100が既にPDNコネクションを確立済みであると仮定し、MTCデバイス100はPDNコネクションを確立した時刻や、確立したPDNコネクションで行うデータ転送の開始時刻を記憶、若しくは、タイマーを起動し、送信制御メッセージを受信するまでの時間を計測しているとする。MTCデバイス100は、送信制御メッセージの詳細データフィールドで示されたBeforetimeの値時刻と記憶若しくは、計測した値時刻の比較を行い、PDNコネクションの切断を判断する図24のステップS1222。例えば、送信制御メッセージの詳細データフィールドで示されたBeforetimeの値時刻がAM11:00であり、MTCデバイス100が記憶若しくは、計測した値時刻がAM10:55であった場合送信制御メッセージで示された時刻>MTCデバイス100内で記憶計測した時刻という条件に当てはまらない場合、ネットワーク側が判断した値時刻より前から通信を開始し始めていたということで、送信制御メッセージの送信対象に自分が含まれていないと判断し、その結果、特別な処理は行わずにPDNコネクションを維持する。なお、このAM11:00のような形式ではなく、1分前のような形式でもよい。一方、送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻の条件に当てはまる場合には、ネットワーク側が判断した値時刻より後に通信を開始し始めたということで、送信制御メッセージの送信対象に自分が含まれていると判断し、その結果、確立済みのPDNコネクションを切断する図24のステップS1230、ステップS1240。また、この詳細データフィールドを用いたPDNコネクションの切断について、Beforetimeを例に挙げて説明したが、他のデータ残量や残時間などについても同様な処理例えば、図24のステップS1222はBeforetimeを用いて説明しているが、送信制御メッセージで示されたデータ残量値>MTCデバイス内で計算したデータ残量値などが行われる。また、Beforetimeとデータ残量を組み合わせることによって、さらにPDNコネクションの維持/切断に用いる詳細な判断条件にできる。例えば、Beforetimeを用いて、PDNコネクションを切断するか絞り込みをした後に、その中でデータ残量がどれくらいかによってPDNコネクションを切断するかを判断してもよい。また、本発明の第8の実施の形態を非特許文献6で定義されているLowpriorityindicatorと組み合わせることで、ネットワーク側で混雑状態が起こっている際、最初にLowpirorityindicatorを持つMTCデバイス100によって確立されたPDNコネクションを切断し、続いてTimetolerantの機能を持つMTCデバイス100によって確立されたPDNコネクションを切断するというように、段階的にPDNコネクションを切断することができる。これにより、リソースを段階的に確保することができ、過剰なPDNコネクションの切断を回避することができる。例えば、通信システムのエンティティ例えば、eNB110やMME120、SGW130、PGW140、HSSが、Lowpriorityindicatorが格納されたPDNコネクション確立リクエストを送信してきたMTCデバイス100を、例えば、MTCデバイスコンテキストに登録、または、Subscriptiondataに登録するなどによって把握しておき、上記処理を実現させてもよい。また、通信システムのエンティティが、Lowpriorityindicatorを持つMTCデバイス100を把握することによって、ブロードキャスト送信する送信制御メッセージの送信先をLowpriorityindicatorを持つMTCデバイス100のみと指定してもよい。また、Lowpriorityindicatorとの組み合わせではなく、Timetolerantフィールドの代わりにLowpriorityindicatorフィールドを用いて、切断すべきPDNコネクションを決定してもよい。このとき、Lowpriorityindicatorフィールドは、詳細データフィールドと組み合わせて使用してもよい。例えば、MME120が混雑状態を検知した場合、最初にLowpriorityindicatorを持つMTCデバイス100によって確立されたPDNコネクションを切断する指示をeNB110に送信し、eNB110が対象となるMTCデバイス100に送信制御メッセージをブロードキャストする。送信制御メッセージを受信し、かつ、Lowpriorityindicatorを持つMTCデバイス100は、確立済みのPDNコネクションを切断する。ここで、リソースの確保が十分でないと判断された場合例えば、混雑状態を示す閾値を超えている場合など、MME120がTimetolerantフィールド例えば、Timetolerantの機能を保持していると詳細データフィールド例えば、MobileOriginatedonlyを用いて、確立済みのPDNコネクションを切断するとeNB110に通知し、eNB110が対象となるMTCデバイス100にブロードキャスト送信する。送信制御メッセージを受信し、かつ、TimetolerantとMobileOriginatedonlyの機能を持つMTCデバイス100は、確立済みのPDNコネクションを切断する。これにより、リソースを段階的に確保することができ、過剰なPDNコネクションの切断を回避することができる。本発明の第8の実施の形態では、一部のMTCデバイス100MTCデバイスB100B、MTCデバイスD100D、MTCデバイスE100E、MTCデバイスF100FがTimetolerantの機能を保持していることを前提としているが、全てのMTCデバイス100がTimetolerantの機能を保持している場合にも適用できる。全てのMTCデバイス100が、Timetolerantの機能を保持している場合、Timetolerantの機能を保持しているか否かでPDNコネクションの切断を判断することができなくなるので、図21の詳細データフィールドに格納される判断条件を用いて、PDNコネクションの切断を判断する。例えば、全てのMTCデバイス100がTimetolerantの機能を保持している環境において、Timetolerantの機能を保持し、MobileOriginatedonlyの機能も保持しているMTCデバイス100によって確立されたPDNコネクションを切断するというブロードキャストメッセージは、MobileOriginatedonlyの機能を保持しているMTCデバイス100によって確立されたPDNコネクションは切断するという送信制御メッセージになる。同様に、全てのMTCデバイス100が、Timetolerantの機能を保持している環境において、Timetolerantの機能を保持し、送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻の条件に当てはまる場合には、確立済みのPDNコネクションを切断するという送信制御メッセージは、送信制御メッセージで示された時刻>MTCデバイス100内で記憶した時刻の条件に当てはまるMTCデバイス100によって確立されたPDNコネクションは切断するという送信制御メッセージになる。そのため、eNB110がブロードキャスト送信する送信制御メッセージにおいて、Timetolerantの機能を保持するMTCデバイス100であるか否かを識別するための図21のTimetolerantフィールドは省略できる。以上、本発明の第8の実施の形態によれば、既にネットワーク側で混雑状態が起こっているとき、若しくは、あるメッセージ例えば、PDNコネクション確立リクエストや、転送データを受信した時点で混雑状態が起こり始めたときに、UE105などから優先度の高い緊急メッセージEmergencyrequestや、Emergencymessageとも呼ばれるやアプリケーションメッセージが送られてくることで更なるリソースU-plane、C-plane共が必要となる課題に対して、ネットワーク側からブロードキャスト送信されるメッセージで、MTCデバイス100がTimetolerantの機能を保持しており、そして、詳細データフィールドで示される値例えば、Beforetimeで示されるデータ転送を開始してから経過した時間を用いて、既に確立済みであるPDNコネクションの維持/切断をする。これにより、優先度レベルの高いリクエストやアプリケーションのためのリソースを確保することができる。また、ネットワーク側例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150から対象となるMTCデバイス100例えば、特定のAPNに接続しているMTCデバイス100、特定のMTCグループに属しているMTCデバイス100、特定のオペレータに属しているMTCデバイス100、特定のエリア例えば、特定のeNB110やMME120に接続しているMTCデバイス100などにメッセージがブロードキャストされることによって、メッセージ例えば、PDNコネクション確立リクエストを送信しようとしていたMTCデバイス100からのメッセージを回避することができる。それにより、ネットワーク側のエンティティ例えば、eNB110やMME120、SGW130、PGW140、MTCサーバ150の処理負荷やトラフィックが軽減される。また、上記の実施の形態でネットワーク側のエンティティ例えば、eNB110やMME120、SGW、PGW、MTCサーバ150からメッセージ例えば、本発明の第1~第7の実施の形態では逆イベント通知メッセージ、本発明の第8の実施の形態では送信制御メッセージがブロードキャストされる。ネットワーク側のエンティティ例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150は、非特許文献6で定義されるように、このブロードキャストされるメッセージにMTCデバイス100が送信するメッセージを遅らすための待機時間Stoptime、Barringtime、Backofftime、Waittimeなどとも呼ばれるを格納する場合もある。MTCデバイス100は、この待機時間の間はデータ送信やPDNコネクション確立リクエストなどのメッセージ送信を行えないものとする例えば、MTCデバイス100が通常モードからデータ送信抑制モードや、規制モード、制限モードなどにモード遷移する。しかし、優先度レベルの高いイベントを検知した場合や、緊急事態が生じた場合には、ネットワーク側からメッセージ送信の抑制をされているが、MTCデバイス100はデータ送信やPDNコネクション確立リクエストの送信が可能なモード例えば、通常モードにモード遷移できるものとする。また、この待機時間は、詳細データフィールドに格納されるPDNコネクションを維持/切断するための条件例えば、Beforetimeと共用してもよい。例えば、待機時間を3分と設定し、優先度レベルの低いMTCデバイスからのメッセージ例えば、PDNコネクション確立リクエストを3分間抑制すると同時に、3分以内に確立されたPDNコネクションを切断するように指示してもよい。なお、このとき、詳細データフィールドは省略でき、通信システムのエンティティやMTCデバイス100の処理負荷、ネットワークのトラフィックが軽減される。また、上記の実施の形態特に第8の実施の形態で、MTCデバイス100とネットワーク側のエンティティが、異なる優先度レベルを認識できる場合例えば、アプリケーションAのデータは優先度レベルAであり、UE105からのメッセージは優先度レベルBなど、ネットワーク側のエンティティ例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150は優先度レベル毎にメッセージ送信を抑制してもよい。例えば、eNB110がブロードキャスト送信する送信制御メッセージに優先度レベルBのみ抑制ということを示すパラメータを格納する。この送信制御メッセージを受信したMTCデバイス100は、優先度レベルBのメッセージのみ送信を遅らせる/停止させる、若しくは、優先度レベルを変化させてメッセージを送信する。例えば、優先度レベルBのみ抑制であるが、MTCグループAに属しているMTCデバイス100は免除ということを示すパラメータと組み合わせて使用してもよい。また、優先度レベルだけではなく、従来技術の、例えば、Accessclassを用いてMTCデバイス100から送信されるメッセージを抑制してもよい。また、上記の実施の形態特に第1~第8の実施の形態におけるMTCデバイス100は、1つのMTCグループや1つのAPN、1つのPLMNオペレータに属していたが、複数のMTCグループや複数のAPN、複数のPLMNオペレータに属してもよい。例えば、MTCデバイス100が2つのAPNAPN-1とAPN-2に接続している場合、通信システムは段階的にMTCデバイス100から送信されるメッセージを抑制することができる。例えば、ネットワーク側のエンティティ例えば、eNB110、MME120、SGW130、PGW140、MTCサーバ150がブロードキャスト送信する送信制御メッセージ、若しくは、逆イベント通知メッセージにAPN-1を用いた送信メッセージを抑制ということを示すパラメータを格納する。これにより、MTCデバイス100はAPN-1を用いたメッセージ送信は抑制されるが、APN-2を用いたメッセージ送信は可能となる。また、本発明の第8の実施の形態では、説明の容易化のために、Timetolerantフィールドと詳細データフィールドを用いた結果、確立済みのPDNコネクションを切断すると多く記述したが、通信システムのオペレータのポリシやMTCサーバ、MTCユーザのポリシ、アプリケーションのポリシ、MTCデバイスのポリシによっては、確立済みのPDNコネクションを切断ではなく、維持すると決定してもよい。なお、本発明の第8の実施の形態では、Timetolerantの機能を保持し、詳細データフィールドで指定された条件に該当するMTCデバイス100が、既にPDNコネクションを確立済みである場合、MTCデバイス100はPDNコネクションを切断していたが図24のステップS1221、S1222、S1230、S1250、PDNコネクションは切断せずに維持したまま、データ送信のみ制御例えば、停止、データレートの変更、データサイズの変更を行ってもよい。これにより、U-planeのリソースを段階的に確保することができる。また、PDNコネクションを切断しないため、再度PDNコネクションを確立する必要がなくなり、通信システムのエンティティ例えば、eNB110、MME120、SGW130、PGW140の処理負荷が軽減される例えば、アドレスの割り当て、バインディングアップデート。なお、本発明の第8の実施の形態は、通信システムのエンティティが対象となるMTCデバイス100にブロードキャストして、優先度レベルの高いUE105やMTCデバイス100のためのリソースを確保するためにPDNコネクションを切断しているが、ブロードキャストではなく、ユニキャストやマルチキャストで送信してもよい。なお、本発明の第8の実施の形態は、図19、20を用いて説明したように、MTCデバイスD100DがPDNコネクション確立リクエストをネットワーク側に送信した結果図20のステップS1002、ネットワーク側が混雑状態になり図20のステップS1003、送信制御メッセージがMTCデバイスに送信されていた図20のステップS1006。つまり、送信制御メッセージは、ネットワーク側が混在状態にある場合に、優先度レベルが低いMTCデバイス100からのメッセージ例えば、PDNコネクション確立リクエストの回避と、既に確立済みのPDNコネクションを切断することを要求するために使用された。さらに、送信制御メッセージは、既にPDNコネクションを確立済みであるMTCデバイス100が、新たに送信する可能性がある別のPDNコネクション確立リクエストを拒絶する、あるいは遅延させるためにも用いることができる。送信制御メッセージを新たなPDNコネクション確立リクエストの遅延のために用いる場合、混雑状態を検出した際に通信システムのエンティティは、待機時間を含む送信制御メッセージを対象となるMTCデバイスへブロードキャストする。このとき、ネットワーク側がブロードキャスト送信する送信制御メッセージにパラメータ情報として格納される待機時間は、既にPDNコネクションを確立済みであるMTCデバイス100MTCデバイスA100A、MTCデバイスB100B、MTCデバイスC100C、MTCデバイスD100Dが送信する追加のPDNコネクション確立メッセージの送信タイミングを遅らせることを指示する情報として用いられる。この送信制御メッセージを受信したMTCデバイス100は、MTCデバイス100自身が既に確立済みのPDNコネクションを保持済みであり、新たに別のPDNコネクションを確立したい場合は、待機時間が経過するまでそのPDNコネクション確立リクエストの送信を遅らせると判断する。例えば、既に1つのPDNコネクションを確立しているMTCデバイス100が、さらに1つのPDNコネクションを新たに追加で確立しようとしていた場合、送信制御メッセージを受けることで、2つ目のPDNコネクションの確立要求の送信を、待機時間後へと遅らせる。また、既にPDNコネクションを確立済みであるMTCデバイス100が、待機時間が格納されていない送信制御メッセージを受信した場合、追加のPDNコネクション確立リクエストを送信しないようにすることもできる。例えば、送信制御メッセージに追加確立禁止を示すパラメータを格納することで、MTCデバイス100による追加のPDNコネクション確立リクエスト送信を回避する。また、既にPDNコネクションを確立済みであるMTCデバイス100が、待機時間が格納されていない送信制御メッセージであり、さらにMTCデバイス100による追加予定のPDNコネクションに対するパラメータ例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなどが格納された送信制御メッセージを受信した場合、追加のPDNコネクションを確立する際にこの情報に従って、PDNコネクション確立リクエストを送信する。例えば、パラメータ情報に、同時に確立可能なPDNコネクションの最大数が含まれている場合、MTCデバイス100自身が確立したいPDNコネクション数と送信制御メッセージに格納されている、同時に確立可能なPDNコネクションの最大数を比較し、確立したいPDNコネクションの数が、同時に確立可能なPDNコネクションの数を上回る場合は、確立済みのPDNコネクションが終了した後に、新たなPDNコネクションの確立を行う。つまり、2つ目のPDNコネクションを確立したいMTCデバイス100が、同時確立可能なPDNコネクションの数が1つであるパラメータ情報を受信した場合は、確立した1つ目のPDNコネクションを用いた通信が終了し、そのPDNコネクションを切断した後に、2つ目の新たな別のPDNコネクションを確立する。さらに、3つ目のPDNコネクションを確立する場合には、2つ目のPDNコネクションを用いた通信が終了した後に、そのPDNコネクションを切断し、3つ目の新たなPDNコネクションを確立する。なお、新たなPDNコネクションを確立する必要が生じた際に、既に確立されているPDNコネクションを直ぐに切断すると判断してもよい。また、パラメータ情報として、同時に確立可能なPDNコネクションの数を通知する代わりに、追加のPDNコネクションの確立が制限されていることを示す情報を送信制御メッセージに含めてもよい。この情報を受けたMTCデバイス100は、新たなPDNコネクションを確立する場合は、既に確立しているPDNコネクションを切断した後に、新たなPDNコネクションの確立要求を送信する。これにより、MTCデバイス100が複数のPDNコネクションを確立しなければならない場合例えば、MTCデバイス100が複数のMTCサーバ150または複数のAPN、若しくは、複数のMTCユーザ160と接続されていて、MTCユーザの情報セキュリティや契約関係上、PDNコネクションを分けて使用しなければならない場合に、同時に確立できるPDNコネクションの数を制限することで、同時に複数のPDNコネクションを確立することによって帯域が占有されてしまうことを防ぐ効果がある。また、上記したMTCデバイス100による追加予定のPDNコネクションに対するパラメータ例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなどに加えて、待機時間が格納される場合、MTCデバイス100による追加予定のPDNコネクションに対するパラメータ例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなどの適用時間有効期間として使用することで、リアルタイムに変化するネットワーク側の混雑状態に沿ったリソース管理になる。例えば、ネットワーク側からブロードキャスト送信される送信制御メッセージに、待機時間例えば、1分が格納されており、かつ、各MTCデバイス100が確立可能なPDNコネクションは1つと示されている場合、送信制御メッセージを受信したMTCデバイス100は、送信制御メッセージを受信した後から1分以内に新たなPDNコネクション確立リクエストを送信する場合は、既に確立済みのPDNコネクションを切断した後、追加のPDNコネクションを確立する。待機時間の経過後は、各MTCデバイス100が確立可能なPDNコネクションは1つと示されている情報は、適用時間を過ぎているので、追加のPDNコネクションを確立する際には用いなくてよい。なお、追加予定のPDNコネクションに対するパラメータが格納された送信制御メッセージを受信したMTCデバイス100は、追加のPDNコネクションを確立する際、追加のPDNコネクションの確立を諦めて既に確立済みのPDNコネクションを維持するか、若しくは、既に確立済みのPDNコネクションを切断して追加のPDNコネクションを確立するかを、例えば、MTCデバイス100が保持するコンテキスト例えば、MTCサーバ150やMTCユーザ160からの要求やスタティックな情報や、アプリケーションに仕様に基づいて判断してもよい。この各MTCデバイス100が確立可能なPDNコネクションは1つと示されている情報は、送信制御メッセージの詳細データフィールドに格納してもよい。なお、既にPDNコネクションを確立しているMTCデバイス100に対して、追加のPDNコネクションに対するパラメータを通知するメッセージは、ブロードキャストではなくユニキャストで送信されてもよい。この場合、MTCデバイス100は、最初のPDNコネクションを確立する際に例えば、Attachprocedure中、通信システムのエンティティから追加のPDNコネクションに対するパラメータ例えば、各MTCデバイス100が確立可能なPDNコネクションの最大数、又は、追加PDNコネクションに割り当て可能なQoSなどを含む送信制御メッセージを受信する。パラメータ情報を取得したMTCデバイス100は、上記のように、取得したパラメータ情報に従って追加のPDNコネクションを確立するためのPDNコネクション確立リクエストを送信する。なお、追加のPDNコネクションに対するパラメータ情報がMTCデバイス100に通知されるタイミングは、MTCデバイス100から最初のPDNコネクション確立リクエストを受けた際に限定されず、既にPDNコネクションの確立が終了した後の任意のタイミングでもよい。つまり、ネットワーク側が混雑状態を検出した際に、既にPDNコネクションを確立しているMTCデバイス100に対してパラメータ情報が通知される。また、MTCデバイス100が送信する追加のPDNコネクションの確立リクエストを受信した際に、その確立リクエストが拒絶されたことを通知する送信制御メッセージ、さらには追加のPDNコネクションに対するパラメータ情報を含む送信制御メッセージをMTCデバイス100に通知してもよい。<第9の実施の形態>本発明の第9の実施の形態では、既にPDNコネクションを確立済みの状態で、さらに追加のPDNコネクション確立を望むMTCデバイス100が、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。MTCデバイス100は、ネットワークが混雑している場合でも、新たにPDNコネクションを確立し、データを送信したい場合がある。例えば、MTCデバイス100が人感センサであり、センサが不良動作を起こしていないかなどを確認するためのメンテナンスデータと、実際にセンサが取得したセンシングデータの送信先のMTCサーバ150が異なり、メンテナンス用のPDNコネクションは確立済みで、センシングしたデータを送信するためのPDNコネクションを任意の期間のみ確立するケースや、又は、MTCデバイス100が自動販売機であり、MTCサーバ150に接続するためのPDNコネクションと、IMSIPMultimediaSubsystemに接続するためのPDNコネクションがあり、MTCサーバ150に接続するためのPDNコネクションは確立済みで、IMSに接続するためのPDNコネクションを任意のタイミングで確立するケースなどがある。しかし、最初のPDNコネクションを確立してから、追加のPDNコネクションを確立するまでの間に、ネットワークは混雑状態を検出する場合があり、このとき、MTCデバイス100が送信する追加のPDNコネクション確立リクエストは拒絶されてしまう。また、MTCデバイス100において、既に確立済みのPDNコネクションで送信しているデータより、追加で確立するPDNコネクションで送信するデータのほうが優先度レベルの高い場合がある。このとき、MTCデバイス100が追加のPDNコネクションを確立できない場合、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送受信できないなどの不利益が生じる。このような課題を解決するために、既にPDNコネクションを確立済みであるMTCデバイス100は、ネットワークから通知される混雑状態に関する情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。以下、本発明の第9の実施の形態について、図25、図26、図27A~図27E、図28~図30、図35、図36を用いて説明する。ここで、本発明の第9の実施の形態の説明を容易化するために、本発明の第9の実施の形態におけるMTCデバイス100は、ネットワークと既にPDNコネクションを1つ確立済みであり、確立済みのPDNコネクション内のEPSベアラに対して、ネットワークが保証するビットレートGBR:GuaranteedBitRateは5Mbpsとする。また、MTCデバイス100は、追加のPDNコネクションを確立するために、PDNコネクション確立リクエストを送信する。このGBR=5Mbpsとは、ネットワークがMTCデバイス100に対して、5Mbpsのビットレートを保証することを示している。例えば、MTCデバイス100に5MbpsのGBRが割り当てられている間、ネットワークは5Mbpsを下回るビットレート例えば、4MbpsをMTCデバイス100に提供しないことを示している。GBR=5Mbpsが割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100の動作について、図25を用いて説明する。図25において、GBR=5Mbpsが割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立しようとする状態を前提とするステップS2500。MTCデバイス100は、追加のPDNコネクションを確立するためにPDNコネクション確立リクエストを送信するステップS2501:PDNコネクション確立リクエスト。なお、MTCデバイス100がPDNコネクションを確立する際、非特許文献3で定義されているPDNconnectivityrequestメッセージや、Servicerequestや、CreateBearerrequestメッセージなどを使用してもよい。このとき、PDNコネクション確立リクエストを受信したネットワークでは、ネットワーク側で混雑状態が発生してしまうとする図25のA混雑発生。そのため、ネットワークは、ステップS2501でMTCデバイス100から送信されたPDNコネクション確立リクエストを拒絶するPDNコネクション確立拒絶レスポンスを送信するステップS2502:PDNコネクション確立拒絶レスポンス。追加のPDNコネクション確立を拒絶されたMTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較するステップS2503:優先度レベルの比較。なお、PDNコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、MTCデバイス100が保持するポリシ、MTCデバイス100がMTCのためにスタティック静的に格納されている情報例えば、最初に起動したアプリケーションを優先的に処理するなどなどを用いて取得してもよい。追加のPDNコネクションの優先度レベルのほうが高いと判断したMTCデバイス100は、確立済みのPDNコネクションの代わりとして追加のPDNコネクションを確立できるか確認するために、既に確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報GBR情報などと、追加のPDNコネクションのEPSベアラに必要なQoS情報GBR情報などを比較するステップS2504:QoS比較。例えば、GBRで比較する場合には、図27Aで示すように、確立済みのPDNコネクションのEPSベアラに割り当てられているGBRが1Mbpsの場合、MTCデバイス100は、追加のPDNコネクションのEPSベアラに必要なGBRが1Mbps以下であれば、確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できる。なお、このとき、MTCデバイス100は従来であれば、追加のPDNコネクションを確立することができないが、確立済みのPDNコネクションより追加のPDNコネクションの優先度レベルのほうが高いことを知得した場合、MTCデバイス100は確立済みのPDNコネクションをリリースした後、MTCデバイス100は追加のPDNコネクションを確立する。また、QCIで比較する場合には、図27Bで示すように、MTCデバイス100が、追加で確立するPDNコネクションのQCIが、既に確立済みのPDNコネクションに割り当てられているQCIと一致している場合、MTCデバイス100は確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できる。また、QCIが一致しており、かつ確立済みのPDNコネクションのGBRが、追加で確立するPDNコネクションのGBRよりも大きい場合に、MTCデバイス100は確立済みのPDNコネクションを切断することで、追加のPDNコネクションを確立できると判断してもよい。このように、上記のGBRを用いた説明と同様に、MTCデバイス100は従来であれば、追加のPDNコネクションを確立することができないが、確立済みのPDNコネクションより追加のPDNコネクションの優先度レベルのほうが高いため、MTCデバイス100は確立済みのPDNコネクションをリリースした後、MTCデバイス100は追加のPDNコネクションを確立する。また、QoS情報を複数用いて、MTCデバイス100が確立済みのPDNコネクションをリリースして、追加のPDNコネクションを確立するか判断してもよい。例えば、MTCデバイス100が、QoS情報として、GBRとMBRを用いてもよい。この場合、MTCデバイス100は、最初のステップとして、追加で確立するPDNコネクションのベアラで用いられるGBRが、既に確立済みのPDNコネクションのベアラで用いられるGBR以下であるか確認する。既に確立済みのPDNコネクションのベアラで用いられるGBR以下の場合、MTCデバイス100は、GBRに続いてMBRも同様に確認する。MBRも同様に既に確立済みのPDNコネクションのベアラで用いられるMBR以下の場合、MTCデバイス100は、既に確立済みのPDNコネクションをリリーすることによって確保されるリソースを用いて追加のPDNコネクションを確立することができると判断し、既に確立済みのPDNコネクションをリリースする。そして、MTCデバイス100は、新しいPDNコネクションを確立する。なお、上記の説明例では、QoS情報の比較処理を実施する際、GBR、QCI、MBRを挙げているが、他のQoS情報に関する例も含めて、図26にアクション、図27A~図27Eにアクション結果が図示されている。また、上記のQoS比較処理の説明では、MTCデバイス100が1つのPDNコネクションを確立済みの状態を前提としていたが、MTCデバイス100が複数のPDNコネクションを確立済みの状態では、各PDNコネクション、若しくは、各PDNコネクションのEPSベアラに割り当てられているQoS情報の合計GBRの合計などや、もしくは、両方QCIが一致するベアラケースなどが、追加で確立するPDNコネクションで必要なQoS情報を満たすことができる場合、MTCデバイス100は追加のPDNコネクションを確立することができる。このとき、MTCデバイス100は、確立済みのPDNコネクションを全てリリースしてもよいし、追加のPDNコネクションに必要なQoS情報を確保するためにリリースする必要があるPDNコネクションを複数選択した後、それらをリリースしてもよい。なお、追加のPDNコネクションや、EPSベアラに必要なQoS情報は、例えば、MTCサービスのアプリケーションや、MTCデバイス100が保持するポリシ、MTCデバイス100にMTCのためにスタティックに格納されている情報、MTCサーバ150やMTCユーザ160から直接通知される情報などから取得してもよい。ステップS2503において比較した結果、追加で確立するPDNコネクションのEPSベアラのQoS情報GBR情報が、既に確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報GBR情報以下であれば例えば、既に確立済みのPDNコネクションのEPSベアラに割り当てられているGBR情報が5Mbpsで、追加で確立するPDNコネクションのEPSベアラで必要なGBR情報が4Mbpsの場合など、確立済みのPDNコネクションをリリースするステップS2505:PDNコネクションReleaseprocedure。なお、確立済みのPDNコネクションをリリースする際に、非特許文献3で定義されるUErequestedPDNdisconnectionprocedureや、UE-initiatedDetachprocedure、UErequestedbearerresourcemodificationprocedureなどを使用してもよい。また、MTCデバイス100が、PDNコネクションをリリースすることによって確保されたリソースが、MTCデバイス100ではなく、他のMTCデバイスやUEに割り当てられてしまう場合が考えられる。この場合、MTCデバイス100は、確立済みのPDNコネクションをリリースする際、リリースしたPDNコネクションのEPSベアラに割り当てられているQoS情報GBR情報を新たに確立するPDNコネクションで再使用することをネットワークへ通知する。図28は、MTCデバイス100がUErequestedPDNdisconnectionprocedureを用いて、ネットワーク側にリリースしたPDNコネクションのEPSベアラに割り当てられていたリソースQoS情報を新たに確立するPDNコネクションで再使用することをネットワークへ通知するメッセージのフォーマット例である。図28に図示されているメッセージは、従来のPDNDisconnectionRequestメッセージフィールドに加えて、他のMTCデバイス100やUE105にQoS情報GBR情報を割り当てないように通知するためのQoS保持フィールド、MTCデバイス100が要求するネットワーク側でQoS情報を保持する期間を示す保持期間フィールドで構成される。続いて、図25において、確立済みのPDNコネクションをリリース後、MTCデバイス100は、PDNコネクション確立リクエストを送信するステップS2506:PDNコネクション確立リクエスト。このとき、ネットワーク側が、PDNコネクションをリリースすることによって確保されたリソースを使用して新たにPDNコネクションを確立しようとしているMTCデバイス100であることを識別できることとする。例えば、PDNコネクション確立リクエストに格納されているMTCデバイス100のIMSIやIMEI、又は、PDNコネクションReleaseprocedure中に交換した新規の識別子などを用いてMTCデバイス100を識別してもよい。ステップS2506のPDNコネクション確立リクエストを受信したネットワークは、PDNコネクションをリリースすることによって確保されたリソースを使用して新たにPDNコネクションを確立しようとしているMTCデバイス100であることを確認し、PDNコネクション確立許可レスポンスを送信するステップS2507:PDNコネクション確立許可レスポンス。PDNコネクション確立後、MTCデバイス100はステップS2507で確立したPDNコネクションのEPSベアラで使用するQoS情報GBR情報に変更するため、PDNコネクションModificationprocedureを実施するステップS2508。このときも、ステップS2506のときと同様に、ネットワークは、確保しているリソースの対象MTCデバイス100であることを識別できることとする。なお、ステップS2504のQoS情報の比較後、MTCデバイス100が確立済みのPDNコネクションをリリースし、PDNコネクションの確立処理をするのではなく、PDNコネクションModificationprocedureをするだけで、新たに確立しようとしているPDNコネクションと同等のPDNコネクションが確保できる場合は、ステップS2505からステップS2507を省略してもよい。確立したPDNコネクションのQoS情報を更新後、MTCデバイス100はPDNコネクションの確立を完了するステップS2509:PDNコネクション確立完了。なお、第9の実施の形態では、MTCデバイス100が追加のPDNコネクションを送信した際にネットワークが混雑状態を検出して、PDNコネクションの確立を拒絶しているが、例えば、他のMTCデバイス100やUE105によるデータ送信などによる混雑発生を機に、例えば、同じMTCグループや同じeNB110に接続しているMTCデバイス100など、複数のMTCデバイス100やUE105に対して、ブロードキャストメッセージで、追加のPDNコネクションの確立拒絶を通知してもよい。次に、図29を参照しながら、本発明の第9の実施の形態におけるMTCデバイス100の構成について説明する。図29は、本発明の第9の実施の形態におけるMTCデバイス100の構成の一例を示す図である。図29において、MTCデバイス100は、通信システム例えば、E-UTRANやUTRANと接続して下位レイヤにおける通信処理と上位レイヤでIPなどのパケット通信処理を実施する通信処理部2701、PDNコネクション確立リクエストの送信や確立したPDNコネクションのEPSベアラに割り当てられるQoS情報の更新、PDNコネクションのリリースなどを処理するPDNコネクション処理部2702、確立済みPDNコネクションのQoS情報と追加で確立するPDNコネクションのQoS情報を比較するQoS情報比較部2703を少なくとも有する。なお、図29には不図示だが、MTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較する優先度レベル比較部を有していてもよい。次に、図29に図示されている構成を有するMTCデバイス100について、本発明における特徴的な処理を中心に、図30を用いて詳しく説明する。図30において、MTCデバイス100は、既にPDNコネクションを1つ確立済みの状態であり、追加のPDNコネクションの確立リクエストをPDNコネクション処理部2702から通信処理部2701を介して、ネットワークに送信するステップS2801:PDNコネクション確立リクエスト送信。PDNコネクション確立リクエストを受信したネットワークでは、混雑状態を検出しているため、MTCデバイス100は、3Gアクセスから送信されるPDNコネクション確立拒絶レスポンスを受信するステップS2802:PDNコネクション確立拒絶レスポンス受信。追加PDNコネクションの確立を拒絶されたMTCデバイス100は、QoS情報比較部2703にて、確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報と、追加で確立するPDNコネクションのEPSベアラに必要なQoS情報を比較するステップS2803:QoS情報の比較。なお、MTCデバイス100は、優先度レベル比較部において、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較し、追加のPDNコネクションの優先度レベルのほうが高いと判断した場合に、確立済みのPDNコネクションの代わりとして追加のPDNコネクションを確立できるか確認するために、QoS情報の比較を行うようにしてもよい。ステップS2803において比較した結果、追加で確立するPDNコネクションのQoS情報が、確立済みのPDNコネクションのQoS情報以下であれば例えば、追加で確立するPDNコネクションのEPSベアラで必要なGBRが4Mbpsで、既に確立済みのPDNコネクションのEPSベアラのGBRが5Mbpsである場合など、QoS情報比較部2703からPDNコネクション処理部2702に確立済みのPDNコネクションをリリースするように指示し、通信処理部2701を介して、PDNコネクションをリリースするためのメッセージを送信するステップS2804:確立済みPDNコネクションリリース。このとき、MTCデバイス100は、リリースするPDNコネクションに割り当てられているリソース例えば、通信リソースや帯域リソースなどを他のMTCデバイス100やUE105に割り当てないように指示するための識別子を送信するメッセージに格納する。一方、ステップS2803において比較した結果、追加で確立するPDNコネクションのQoS情報が、確立済みのPDNコネクションのQoS情報より大きければ例えば、追加で確立するPDNコネクションのEPSベアラで必要なGBRが6Mbpsで、既に確立済みのPDNコネクションのEPSベアラのGBRが5Mbpsである場合など、確立済みのPDNコネクションはリリースされることなく、維持される。確立済みのPDNコネクションをリリースしたMTCデバイス100は、PDNコネクション処理部2702から通信処理部2701を介して、追加のPDNコネクションを確立するステップS2805:追加のPDNコネクション確立。この場合もステップS2804と同様に、MTCデバイス100は、ネットワークが、PDNコネクションをリリースしたMTCデバイス100であることを識別できるような識別子を、追加のPDNコネクション確立リクエストに格納する。PDNコネクションを確立後、MTCデバイス100は、デフォルトのPDNコネクションのQoS情報から追加のPDNコネクションが必要とするQoS情報に更新するため、非特許文献3で定義されるUErequestedbearerresourcemodificationprocedureなどを用いて、更新するステップS2806:追加PDNコネクションのQoS情報を更新。この場合もステップS2804と同様に、MTCデバイス100は、ネットワークが、PDNコネクションをリリースしたMTCデバイス100であることを識別できるような識別子を、確立したPDNコネクションのQoS情報の更新メッセージに格納する。なお、ステップS2803のQoS情報の比較後、MTCデバイス100が確立済みのPDNコネクションをリリースし、PDNコネクションの確立処理をするのではなく、PDNコネクションModificationprocedureを実施し、MTCデバイス100が要求するPDNコネクションを実現できる場合は、ステップS2804及びステップS2805を省略してもよい。なお、上記の第9の実施の形態では、ネットワークからMTCデバイス100に混雑状態に関する情報が通知され、MTCデバイス100は確立済みのPDNコネクション、若しくは、PDNコネクションのEPSベアラに割り当てられているQoS情報と、追加のPDNコネクションで必要なQoS情報を比較して、確立済みのPDNコネクションをリリースすることで確保されるリソースを、新たなPDNコネクションの確立に用いることができるか否かを判断している。このQoS情報に加えて、MTCデバイス100は、MTCデバイス100の確立可能なPDNコネクション数を確立済みのPDNコネクションをリリースする際の判断材料として用いてもよい。この確立可能なPDNコネクション数の情報を、例えば、MTCデバイス100が、MTCのためにスタティックに格納している情報から取得してもよい、又は、ネットワークが任意のタイミング例えば、混雑状態を検出したときでMTCデバイス100に確立可能なPDNコネクション数をあらかじめ通知してもよい、又は、MTCデバイス100は、確立済みのPDNコネクションを確立した際にネットワークからMTCデバイス100が確立可能なPDNコネクション数は1つという情報を取得してもよい、又は、ネットワークは、PDNコネクション確立拒絶レスポンスで、QoS情報は通知することはできないが、MTCデバイス100が確立可能なPDNコネクション数の情報のみを通知できる場合は、MTCデバイス100が追加のPDNコネクションを確立する際に送信するPDNコネクション確立リクエストの返信PDNコネクション確立拒絶レスポンスで、MTCデバイス100が確立可能なPDNコネクション数は1つという情報を通知してもよい。このように、QoS情報と確立可能なPDNコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、PDNコネクションを1つ確立済みのMTCデバイス100から、追加のPDNコネクションの確立リクエストを受信した場合、ネットワークがMTCデバイス100に対して、PDNコネクション確立拒絶レスポンスを送信する。このとき、MTCデバイス100は保持している確立可能なPDNコネクション数の情報を用いて、現在確立しているPDNコネクション数を確認し、さらに確立済みのPDNコネクションが存在する場合、その確立済みのPDNコネクション、若しくは、確立済みのPDNコネクションのEPSベアラに割り当てられているQoS情報例えば、GBR=1Mbpsと追加で確立するPDNコネクションで必要なQoS情報500kbpsを比較し、追加のPDNコネクションで必要とされるQoS情報を満たすことができる場合、MTCデバイス100は確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。なお、MTCデバイス100の保持する確立可能なPDNコネクション数の情報とPDNコネクション数を管理するPDNコネクション処理部で情報共有同期がとれていない場合や、PDNコネクション確立拒絶レスポンスで取得できる情報例えば、混雑レベルや現在の確立可能なPDNコネクション数を得る場合や、確立済みのPDNコネクションより優先度レベルの高いPDNコネクションの確立リクエストの場合があるため、MTCデバイス100が保持する確立可能なPDNコネクション数に既に確立済みのPDNコネクションの数が達している状態にもかかわらず、MTCデバイス100は追加のPDNコネクション確立するためのPDNコネクション確立リクエストを送信する可能性がある。以上、本発明の第9の実施の形態によれば、既にPDNコネクションを確立済みのMTCデバイス100が追加のPDNコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、確立済みのPDNコネクションに割り当てられているQoS情報と追加で確立するPDNコネクションに必要なQoS情報を比較し、追加で確立するPDNコネクションに必要なQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報を満たすことができる場合、MTCデバイス100は確立済みPDNコネクションをリリース又は変更し、追加のPDNコネクションを確立することができる。これにより、MTCデバイス100は優先度レベルが高いデータを送信することができ、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送信できないなどの問題は解決される。<第10の実施の形態>本発明の第10の実施の形態では、既にPDNコネクションを確立済みの状態で、さらに追加のPDNコネクション確立を望むMTCデバイス100が、ネットワークから通知されるMTCデバイス100やUE105に割り当て可能な通信リソースや帯域リソースの情報に基づいて、既に確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立する。第10の実施の形態で想定しているシナリオは、第9の実施の形態と同じである。第9の実施の形態との違いは、MTCデバイス100が追加のPDNコネクションを確立する際、確立済みのPDNコネクション、又は、そのPDNコネクションのEPSベアラに割り当てられているQoS情報と、ネットワークから通知されるMTCデバイス100に割り当て可能なQoS情報例えば、通信リソースや帯域リソースを足し合わせたリソースが、新たに確立するPDNコネクションに必要なリソースよりも大きい場合に、確立済みのPDNコネクションをリリースすると判断する点である。以下、第9の実施の形態との違いを中心に詳しく説明する。以下、本発明の第10の実施の形態について、図31、図32、図33A~図33E、図34~図36を用いて説明する。ここで、本発明の第10の実施の形態の説明を容易化するために、本発明の第10の実施の形態におけるMTCデバイス100は、第9の実施の形態における前提と同様に、ネットワークと既にPDNコネクションを1つ確立済みであり、確立済みのPDNコネクション内のEPSベアラに対して、ネットワークが保証するビットレートGBR:GuaranteedBitRateは5Mbpsとする。また、MTCデバイス100は、追加のPDNコネクションを確立するために、PDNコネクション確立リクエストを送信する。このとき、MTCデバイス100は、既に確立済みのPDNコネクションで送信されるデータの優先度より、追加で確立するPDNコネクションで送信するデータの優先度レベルのほうが高いことを認識していることを前提としている。GBR=5Mbpsが割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立する際、ネットワークから通知されるQoS情報に基づいて、確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立するMTCデバイス100の動作について、図31を用いて説明する。図31において、GBR=5Mbpsが割り当てられたEPSベアラを含むPDNコネクションを確立済みであるMTCデバイス100が、追加のPDNコネクションを確立しようとする状態を前提とするステップS2900。MTCデバイス100は、追加のPDNコネクションを確立するためにPDNコネクション確立リクエストを送信するステップS2901:PDNコネクション確立リクエスト。なお、図31におけるステップS2900及びS2901は、図25におけるステップS2500及びS2501と同じなので、ここでは詳細な説明を省略する。続いて、混雑状態を検出したネットワークは、PDNコネクションの確立リクエストの送信元であるMTCデバイス100に割り当て可能なQoS情報例えば、GBR<=2Mbpsなら許可などを格納したPDNコネクション確立拒絶レスポンスを送信するステップS2902:PDNコネクション確立拒絶レスポンス。なお、GBR以外のQoS情報として、図32及び図33A~図33Eで示すように、QCIQoSClassIndicator、ARPAllocationandRetentionPriority、MBRMaximumBitRate、Group-AMBRGroup-AggregatedMaximumBitRate、APN-AMBRAccessPointName-AMBR、TransferDelay、PacketDelayBudget、PacketErrorLossRate、Applicationpriorityなどがある。図34は、3Gアクセスが、追加のPDNコネクションに割り当て可能なQoS情報をMTCデバイス100に通知する際のメッセージのフォーマット例である。図34に図示されているメッセージは、従来のPDNコネクション確立拒絶メッセージフィールドに加えて、MTCデバイス100に割り当て可能なQoS情報を格納するQoS情報フィールド、QoS情報フィールドに格納されている情報の有効時間割り当て可能な時間を示す有効期間フィールドで構成される。なお、有効期間フィールドは、本発明の第8の実施の形態で説明した待機時間と併用してもよい。ネットワークからMTCデバイス100に割り当て可能なQoS情報を通知されたMTCデバイス100は、図31で示すように、追加で確立するPDNコネクションに必要なQoS情報が、既に確立済みのPDNコネクションに割り当てられているQoS情報と、ステップS2902で通知されたMTCデバイス100に割り当て可能なQoS情報の合計以下であるか比較するステップS2903:QoS比較。例えば、GBRで比較する場合には、図33Aで示すように、確立済みのPDNコネクションのEPSベアラに割り当てられているGBRが1Mbpsで、ネットワークからPDNコネクション確立拒絶レスポンスで通知される追加PDNコネクションに割り当て可能なGBRが0.5Mbpsである場合は、MTCデバイス100はGBRが1.5Mbps以下であれば、PDNコネクションを確立できる。すなわち、追加で確立するPDNコネクションのEPSベアラで必要とするGBRが1.5Mbps以下であれば、確立可能である。なお、このとき、確立済みのPDNコネクションをリリースする必要があるときは、MTCデバイスが追加で確立するPDNコネクションのGBRが、ネットワークから通知されるGBR<追加で確立するPDNコネクションのGBR<ネットワークから通知されるGBRと確立済みのPDNコネクションのEPSベアラに割り当てられているGBRの合計のときである。また、この具体例では、ネットワークからMTCデバイス100に通知される追加のPDNコネクションに割り当て可能なQoS情報は、現在のMTCデバイス100に対して割り当て可能なQoS情報であるが、MTCデバイス100が確立可能な絶対値を示すQoS情報を使用してもよい。例えば、GBRの場合、3Gアクセスから通知されるMTCデバイス100に割り当てられるQoS情報は、1.5Mbps確立済みPDNコネクションのEPSベアラに割り当てられているGBR1Mbps追加のPDNコネクションに割り当て可能なGBR0.5Mbpsとして通知してもよい。また、QCIで比較する場合には、図33Bで示すように、MTCデバイス100が追加で確立するPDNコネクションのQCIが、3Gアクセスから通知されるMTCデバイス100に割り当て可能なQCIと一致している場合、MTCデバイス100は追加のPDNコネクションを確立できる。また、詳しい説明は後述するが、QoS情報に加えて、MTCデバイス100が確立可能なPDNコネクション数もMTCデバイス100に通知される場合例えば、MTCデバイス100は、一定時間例えば、混雑時に通知される待機時間Backofftime、合計1つのPDNコネクションを確立可能、MTCデバイス100は確立済みのPDNコネクションのQCIを確認し、追加で確立するPDNコネクションのQCIと比較する。QCIが同じで、かつ、確立可能なPDNコネクション数が1つである場合、MTCデバイス100は、確立済みのPDNコネクションをリリースすることで、追加のPDNコネクションを確立できる。なお、上記の説明例では、QoS情報の比較処理を実施する際、GBR、QCIを挙げているが、他のQoS情報に関する例も含めて、図32にアクション、図33A~図33Eにアクション結果が図示されている。また、ステップS2903のQoS比較を行う前に、本発明の第9の実施の形態で説明したように、追加のPDNコネクション確立を拒絶されたMTCデバイス100は、追加のPDNコネクションの優先度レベルと確立済みのPDNコネクションの優先度レベルを比較した後に、QoS比較を起こってもよい。なお、PDNコネクションの優先度レベルは、アプリケーションレイヤから取得できるアプリケーション毎に割り当てられる優先度レベルや、MTCデバイス100が保持するポリシ、MTCデバイス100がMTCのためにスタティック静的に格納されている情報例えば、最初に起動したアプリケーションを優先的に処理するなどなどを用いて取得してもよい。続く、ステップS2903のQoS比較後、図31のステップS2904からステップS2908は、図25のステップS2505からステップS2509と同じなので、ここでは詳細な説明を省略する。なお、上記の第10の実施の形態では、MTCデバイス100が追加のPDNコネクションの確立リクエストに対するPDNコネクション確立拒絶レスポンスで、MTCデバイス100に割り当て可能なQoS情報を通知していたが、ネットワークはMTCデバイス100に割り当て可能なリソースが存在することから、PDNコネクション確立許可レスポンスで通知してもよい。その場合、ステップS2902のPDNコネクション確立拒絶レスポンスは、PDNコネクション確立許可レスポンスに変わる。加えて、ステップS2903からステップS2906は省略でき、ステップS2907のPDNコネクションModificationprocedureから実施可能となる。なお、上記の第10の実施の形態では、ネットワークからMTCデバイス100にQoS情報が通知されているが、QoS情報に加えて、MTCデバイス100の確立可能なPDNコネクション数を通知してもよい。QoS情報と確立可能なPDNコネクション数を組み合わせることにより、ネットワークは割り当て可能なリソースを精度高く制御することができる。例えば、ネットワークが、PDNコネクションを1つ確立済みのMTCデバイス100から、追加のPDNコネクションの確立リクエストを受信した場合、ネットワークがMTCデバイス100に対して、MTCデバイス100の確立可能なPDNコネクション数は1つ、かつ、追加のPDNコネクションに割り当て可能なQoS情報GBRは、1MbpsのQoS情報をPDNコネクション確立拒絶レスポンスに格納して送信する。このとき、MTCデバイス100はMTCデバイス100の確立可能なPDNコネクション数は1つという情報から、追加のPDNコネクションを確立するためには、確立済みのPDNコネクションをリリースする必要があることを確認できる。さらに、追加のPDNコネクションに割り当て可能なQoS情報GBRは、1MbpsというQoS情報から、追加のPDNコネクションで必要とされるQoS情報を満たせるか確認することができ、追加のPDNコネクションで必要とされるQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報以下である場合は、MTCデバイス100は、確立済みのPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。以上、本発明の第10の実施の形態によれば、既にPDNコネクションを確立済みのMTCデバイス100が追加のPDNコネクションを確立する際、ネットワークで混雑状態を検出している場合でも、ネットワークから通知されるMTCデバイスに割り当て可能なQoS情報と、確立済みのPDNコネクションに割り当てられているQoS情報と、追加で確立するPDNコネクションに必要なQoS情報を比較し、追加で確立するPDNコネクションに必要なQoS情報が、確立済みのPDNコネクションに割り当てられているQoS情報を満たすことができる場合、MTCデバイス100は確立済みPDNコネクションをリリースし、追加のPDNコネクションを確立することができる。これにより、MTCデバイスは優先度レベルが高いデータを送信することができ、MTCデバイス100やMTCサーバ150、MTCユーザ160などに優先度レベルが高いデータを送信できないなどの問題は解決される。上記の本発明の第9の実施の形態と第10の実施の形態では、MTCデバイス100による確立済みのPDNコネクションの接続先と、追加で確立するPDNコネクションの接続先が同じであることを前提としている。ここで、図35ではMTCデバイス100が複数の接続先とPDNコネクションを確立できる状態を示している。図35におけるMTCデバイスA100Aは、例えば、複数のMTCサーバ150に接続することができ、1つ目のPDNコネクション確立済みのPDNコネクションの接続先はMTCサーバA150Aで、2つ目のPDNコネクション追加で確立するPDNコネクションの接続先はMTCサーバB150Bになる場合がある。MTCデバイスA100Aの接続先が異なる場合、本発明の第9の実施の形態と第10の実施の形態におけるPDNコネクションの確立拒絶レスポンスを受信した後の処理ステップとして、接続先を確認する処理が必要となる。図36は、図25のステップS2502とステップS2503の間に接続先を確認する処理ステップを追加したものである。また、図35におけるMTCデバイスA100Aと図36におけるMTCデバイスA100Aは同一であるとする。MTCサーバA150Aにデータを送信するためのPDNコネクションを確立済みのMTCデバイスA100Aが、MTCサーバB150Bにデータを送信するためのPDNコネクションを確立するためのPDNコネクション確立リクエストをネットワーク送信するステップS2501。MTCサーバBにデータを送信するためのPDNコネクション確立リクエストを受信したネットワークは、A混雑発生によって、PDNコネクション確立拒絶レスポンスを送信するステップS2502。ここで、MTCデバイスA100Aは、確立済みのPDNコネクションをリリースして、追加のPDNコネクションを確立することができるかを判断するための処理として、確立済みのPDNコネクションの接続先と、追加のPDNコネクションの接続先が同じであるか否かを確認するステップS2520。接続先を表す情報としては、APNを用いることができる。つまり、APNが同じであれば接続先が同じであると判断し、APNが異なれば接続先が異なると判断する。確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が同じである場合は、引き続き、第9の実施の形態と同様の処理図25のステップS2503以降の処理や第10の実施の形態と同様の処理図31のステップS2903以降の処理を行う。しかしながら、確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が異なる場合、例えば、追加のPDNコネクション確立リクエストを受信したMTCサーバB150Bでは混雑検出されているが、MTCデバイスA100Aによって既に確立済みのPDNコネクションを通してデータを転送されているMTCサーバA150Aでは混雑検出されていない混雑が起こっていない場合には、確立済みのPDNコネクションをリリースすることで確保されるリソースを、追加のPDNコネクションの確立に再使用することができないと判断する。なお、追加のPDNコネクション確立リクエストが拒絶されている理由は、MTCサーバB150Bにおける混雑検出以外に、ネットワーク通信システムのエンティティであるSGW-B130BやPGW-B140Bなどで起きている輻輳であってもよい。ここで、MTCサーバA150Aにおいて混雑状態が起きていない状態で、MTCデバイスA100Aによって送信された追加のPDNコネクション確立リクエストが、MTCサーバB150Bの混雑状態により拒絶された場合、MTCデバイスA100Aは、MTCサーバA150Aにデータを送信するためのPDNコネクションをリリースしても、MTCサーバB150Bに送信するためのPDNコネクションを確立できない。そのため、MTCデバイスA100Aは、確立済みのPDNコネクションを維持し、追加のPDNコネクションの確立をキャンセルする。また、確立済みのPDNコネクションの接続先と追加のPDNコネクションの接続先が異なる状態でも、MTCデバイスA100Aが拒絶された追加のPDNコネクションの接続先を変更できる場合例えば、MTCサーバA150AとMTCサーバ150Bが同じオペレータによる管轄、若しくは、MTCユーザ160に接続されている場合や、MTCサーバ150AとMTCサーバB150B間でPDNコネクション移行の契約が交わされており、交渉を自動的に実施するなど、MTCデバイスA100Aは、追加で確立するPDNコネクションの接続先を変更する。続いて、MTCデバイスA100Aは、確立済みのPDNコネクションの接続先であるMTCサーバA150AとのPDNコネクションをリリースし、MTCサーバA150Aにデータを転送するための追加のPDNコネクションを確立する。なお、追加のPDNコネクションの接続先を変更する処理と確立済みのPDNコネクションの接続先であるMTCサーバA150AとのPDNコネクションをリリースする処理は順不同である。なお、この接続先はMTCサーバ150やMTCユーザ160のアドレスやIdentity例えば、MTCサーバTEID、ネットワーク通信システムの装置であるPGWのアドレスやIdentity例えば、PGWTEID、APNなど接続先を識別できるものでもよい。また、上記の実施の形態特に第2~第8の実施の形態における逆イベント通知メッセージイベント情報や送信制御メッセージには、イベント情報例えば、デバイスIDやデバイス種IDが格納されていたが、eNBIDやeNBアドレス並びに、MTCデバイス100のEPSベアラに対応するS1UTEID、イベント通知メッセージイベント情報デバイスAの送信元であるMTCデバイスA100Aのアドレスや、MTCサービスで管理されている情報例えば、MTCデバイスA100Aが位置する情報例えば、3階、301号室、3丁目などを追加することで、逆イベント通知メッセージイベント情報を受信したMTCデバイス100がモード遷移する必要があるかどうかを判断させてもよい。なお、本発明を説明する一例として、煙センサに通信モジュールを実装したMTCデバイスA100Aが、煙を検知した後に起こりうる冗長のイベント通知メッセージに対する抑制方法について説明したが、以下のケースにも適用可能である。例えば、ガス管の状態例えば、破損していないかを確認するガス管センサに通信モジュールを実装した複数のMTCデバイスA100Aと主に居住スペースに配置されるガス漏れを検知するガスセンサに通信モジュールを実装した複数のMTCデバイスB100Bが、同じMTCグループで構成されている環境において、ガス管が破損することにより、MTCデバイスA100Aによって通知されるイベント通知メッセージイベント情報デバイスAを利用して、MTCデバイスB100Bのイベント通知メッセージを抑制してもよい。すなわち、MTCデバイスA100Aからイベント情報例えば、ガス管センサIDが格納されたイベント通知メッセージイベント情報デバイスAを受け、ネットワーク装置例えば、MME120やMTCサーバ150が、イベント情報例えば、ガス管センサIDを格納した逆イベント通知メッセージをMTCグループに属するMTCデバイス100に送信し、MTCデバイス100がモード遷移する必要があるか優先度の高いイベント通知メッセージを送信するか判断させてもよい。このようなMTCサービスに本発明を適用した場合、ガス管が破損することによって生じると予想されるガス管破損の誘発やガス漏れに対して、イベント例えば、ガス管破損やガス漏れを検知した複数のMTCデバイス100による冗長な優先度の高いイベント通知メッセージを抑制することができ、MTCデバイス100とネットワーク装置例えば、MME120やMTCサーバ150の処理負荷を軽減、トラフィックを低減することができる。また、例えば、エアバックと連動している衝撃センサを搭載済の乗用車に通信モジュールを実装したMTCデバイス100が、複数台の衝突事故例えば、複数台による玉突き事故を起こした場合、最初にネットワーク装置例えば、MME120やMTCサーバ150に通知された優先度の高いイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、ネットワーク装置例えば、MME120やMTCサーバ150が、最初に受信したイベント通知メッセージのイベント情報例えば、衝撃センサIDを格納した逆イベント通知メッセージを衝突事故が起きたエリア例えば、イベント通知メッセージが送信されたeNB110配下のMTCデバイス100にブロードキャストすることで、同一イベント、若しくは、そのイベントを引き起こした出来事によって引き起こされたイベントによる優先度の高いイベント通知メッセージを抑制することができる。このようなMTCサービスに本発明を適用した場合、衝撃センサを搭載した複数台の乗用車の衝突事故が発生した際に高い確率で生じる冗長な優先度の高いイベント通知メッセージを抑制することができ、MTCデバイス100とネットワーク装置例えば、MME120やMTCサーバ150の処理負荷を軽減、トラフィックを低減することができる。また、例えば、土砂崩れを監視する加速度センサや傾斜センサに通信モジュールを実装したMTCデバイス100が、土砂崩れが起こりそうなエリア例えば、山や崖に複数設置されている環境において、土砂崩れが起こることにより、MTCデバイス100によって通知されるイベント通知メッセージを利用して、後続する優先度の高いイベント通知メッセージを抑制してもよい。すなわち、MTCデバイス100からイベント情報例えば、加速度センサIDが格納されたイベント通知メッセージイベント情報を受け、ネットワーク装置例えば、MME120やMTCサーバ150が、イベント情報例えば、加速度センサIDを格納した逆イベント通知メッセージをMTCグループに属するMTCデバイス100に送信し、MTCデバイス100がモード遷移する必要があるか優先度の高いイベント通知メッセージを送信するか判断させてもよい。また、このような、あらかじめ単一の事象のみ監視するMTCサービスであることが定義されている環境においては、イベント情報例えば、加速度センサIDを含めなくても、何のイベントが発生したか明らかであるため、省略してもよい。また、例えば、振動センサに通信モジュールを実装したMTCデバイスによる陸橋の揺れ具合の監視から陸橋に異常がないか確認するMTCサービスなども同様に、本発明は適用可能である。なお、上記の本発明の各実施の形態では、MTCデバイス100から通知されるイベント通知メッセージをトリガとして、ネットワーク装置例えば、MME120やSGW130、PGW140、MTCサーバ150が冗長なイベント通知メッセージを抑制するための逆イベント通知メッセージをブロードキャストしていたが、イベント通知メッセージではなく、例えば、MTCデバイス100とMTCデバイス100に組み込まれているUICCUniversalIntegratedCircuitCardの関連性の不一致を検知した場合や、MTCデバイス100上で機能しているMTCfeatureとHSSが保持するMTCデバイス100のサブスクリプションデータに登録されているMTCfeatureの整合が取れない場合や、設置場所が限定、若しくは、固定されているMTCデバイス100例えば、自動販売機、煙センサ、炎センサ、つまり、MTCデバイス100の位置情報の変化が起こりにくい環境通信環境の変化や、基地局の負荷バランスによってMTCデバイス100の接続する基地局切り替えは除くで、MTCデバイス100の位置情報の変化を検知した場合や、MTCデバイス100とネットワークの間のPDNコネクション、又は、EPSベアラが切断された場合などをトリガとして、逆イベント通知メッセージをブロードキャストしてもよい。また、上記の本発明の各実施の形態では、MTCデバイス100から送信されたイベント通知メッセージを受信したネットワーク装置例えば、MME120、SGW130、PGW140、MTCサーバ150は、イベント通知メッセージの内容を他のネットワーク装置に転送していたが例えば、本発明の第2の実施の形態では、イベント通知メッセージを受信したMME120が、SGW130、PGW140を経由してMTCサーバ150にイベント通知メッセージを転送、若しくは、必要な情報のみを転送している、オペレータの方針やMTCアプリケーションの仕様などに基づいて、転送しなくてもよい。また、上記の本発明の各実施の形態では、MTCデバイス100がネットワークとの間にPDNコネクションとEPSベアラを確立した後にイベントを検知していたが、イベントを検知した後にPDNコネクションとEPSベアラを確立し、イベント情報やセンシング情報を送信してもよい。また、上記の本発明の各実施の形態では、逆イベント通知メッセージを送信するネットワーク装置は、MME120やPGW140、MTCサーバ150を例として挙げて説明していたが、これらに限定されるわけではなく、SGW130や外部のネットワークに位置する装置例えば、ローミング先のネットワーク装置やAAAサーバ、SIPサーバが送信してもよい。また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置例えば、MME120、SGW130、PGW140、MTCサーバ150が逆イベント通知メッセージをブロードキャストしていたが、例えば、ネットワーク装置例えば、MME120、SGW130、PGW140、MTCサーバ150がMTCデバイス100の接続先である基地局eNB110に逆イベント通知メッセージをブロードキャストするように指示し、eNB110が逆イベント通知メッセージをブロードキャストしてもよい。例えば、現在規定されているようにeNBがページングをブロードキャストし、UE105にETWSの情報を取得させる手段を利用、拡張することで、既存システムに大きな影響を与えることなく、本発明を実施することができる。また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置例えば、MME120、SGW130、PGW140、MTCサーバ150は、逆イベント通知メッセージをブロードキャストして、冗長なイベント通知メッセージを抑制していたが、他の役割を持たせたメッセージをブロードキャストしてもよい。例えば、特定のエリアに複数の自動販売機MTCデバイス100が設置されている環境で、例えば、窃盗によって1つの自動販売機の位置情報が変化したことをネットワーク側が検知した場合、ネットワーク装置は自動販売機の位置情報変化をトリガとして、上記特定のエリアの複数の自動販売機に対して、各自動販売機の位置情報を送信することTrackingAreaUpdateを指示したメッセージをブロードキャストしてもよい。これにより、他の自動販売機の状況を定期的に実施される位置情報の更新時より迅速、かつ、確実に確認することができる。また、上記の本発明の各実施の形態では、イベント通知メッセージを受信したネットワーク装置例えば、MME120、SGW130、PGW140、MTCサーバ150は、逆イベント通知メッセージをブロードキャストしていたが、逆イベント通知メッセージを送信するMTCデバイス100を把握している場合には、マルチキャストやユニキャストで実施してもよい。なお、上記の本発明の各実施の形態の説明で用いた各機能ブロックは、典型的には集積回路であるLSILargeScaleIntegrationとして実現される。これらは個別に1チップ化されてもよいし、一部又はすべてを含むように1チップ化されてもよい。なお、ここでは、LSIとしたが、集積度の違いにより、ICIntegratedCircuit、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。また、集積回路化の手法はLSIに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。LSI製造後に、プログラムすることが可能なFPGAFieldProgrammableGateArrayや、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブルプロセッサを利用してもよい。さらには、半導体技術の進歩又は派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。例えば、バイオ技術の適応などが可能性としてあり得る。