複数の無線システムと、前記無線システムに接続可能な端末と、前記端末と定期的にキープアライブパケットを交換するアプリサーバと、前記無線システムから通知される無線システムへの端末の接続情報を保持するマッピングサーバを含む通信システムであって、前記アプリサーバは、端末が接続している無線システムが、前記無線システムへの端末の接続情報を前記マッピングサーバに通知するか否かに基づいて、前記端末とのキープアライブ間隔を変更することを特徴とする通信システム。請求項1に記載の通信システムであって、前記マッピングサーバと前記アプリサーバ間のキープアライブ処理を実施し、前記マッピングサーバは、前記アプリサーバの異常を検出した際に、該アプリサーバに接続している端末に該アプリサーバで異常が発生したことを前記端末に通知し、前記端末は、前記異常が発生したアプリサーバに再度位置登録を行うことを特徴とする請求項1に記載の通信システム。前記アプリサーバは、前記端末との間にNATが存在するか否かを判定する手段と、前記無線システムのうちの一つから前記端末の接続情報を取得できるか否かを判定する手段と、を備え、前記端末との間にNATが存在する場合には前記キープアライブ間隔をNATセッションタイマよりも短い値に設定し、前記端末との間にNATが存在せずかつ前記アプリサーバが前記無線システムから前記端末の接続情報を取得できる場合には、前記キープアライブ間隔を予め定めた最大値に設定し、前記端末との間にNATが存在せずかつ前記アプリサーバが前記無線システムから前記端末の接続情報を取得できない場合には、前記キープアライブ間隔を前記最大値よりも短い予め定めた標準値に設定することを特徴とする請求項1に記載の通信システム。請求項3に記載の通信システムであって、前記端末は、前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合には、トランスポート層のプロトコルをUDPからTCPに変更することを特徴とする通信システム。請求項3に記載の通信システムであって、前記端末は、前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合に、接続する無線システムを前記複数の無線システムから再選択することを特徴とする通信システム。請求項3に記載の通信システムであって、前記端末は、前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合に、Push型通信からPull型通信に切り替えることを前記アプリサーバに通知することを特徴とする通信システム。少なくとも一つ以上の無線システムと、前記少なくとも一つ以上の無線システムに接続可能なモバイルルータと、前記モバイルルータに収容される複数の端末と、前記モバイルルータおよび前記無線システムを介して前記複数の端末とキープアライブを実施する少なくとも一つ以上のアプリサーバと、を含む通信システムであって、前記モバイルルータは、前記少なくとも一つ以上の無線システムに接続する第一の通信インタフェースと、前記複数の端末を収容する第二の通信インタフェースと、を備え、前記第二の通信インタフェースを介して前記複数の端末と端末キープアライブを実施し、前記端末キープアライブによって収集した前記複数の端末のキープアライブ状況を集約して前記第一の通信インタフェースを介して前記端末が接続している前記無線アクセス網に送信することを特徴とする通信システム。請求項7に記載の通信システムであって、前記一つ以上の無線システムを介して前記モバイルルータと通信を行うキープアライブ中継サーバを備え、前記キープアライブ中継サーバは、前記モバイルルータから前記集約されたキープアライブ状況を受信し、前記アプリサーバから受信したキープアライブ状況の問い合わせに対応して、前記キープアライブ状況の問い合わせに含まれるモバイルルータ識別子に対応したモバイルルータの前記キープアライブ状況を前記アプリサーバに対して送信することを特徴とする通信システム。請求項8に記載の通信システムにおいて、前記モバイルルータは、前記少なくとも一つ以上の無線システムから第一の通信アドレスの割当てを受けるとともに、前記端末には第二の通信アドレスを付与する機能と、前記端末から前記アプリサーバへのパケットを中継する際に、前記端末に割当てた前記第二の通信アドレスおよび前記端末が該通信に割当てた第二のポート番号を、前記無線システムから割り当てられた前記第一の通信アドレスおよび前記モバイルルータが該通信に割当てた第一のポート番号に変換する変換機能と、無線システムの切り替えにより切替後の無線システムから新たに第三の通信アドレスを割り当てられた際に、前記第二の通信アドレスおよび第二ポート番号に対応する、前記第三の通信アドレスおよび第三のポート番号の組合せを生成し、前記第三の通信アドレスおよび第三のポート番号の組合せを、前記キープアライブ中継サーバに送信することを特徴とする通信システム。無線環境では、多くの場合、端末バッテリー容量や通信リソースに制限がある。そのため無線網にIP電話システムを導入する際に、端末とサーバ間のキープアライブ間隔を、固定網と同じく数分~数時間単位に設定すると、端末やネットワークに過度な負荷をかける可能性がある。特に、携帯電話のようにエリアが広く、端末バッテリー容量の小さいシステムではこの影響が顕著に出ると想定される。しかしながら、この問題を解決するために、キープアライブ間隔を延長すると、障害検出に時間がかかってしまい、サービス品質が低下する。そこで、障害を検出するまでの時間を長くすることなく、端末の消費電力低減、ネットワークの負荷低減を実現するキープアライブ方法の実現が課題となる。また、現在の技術によれば、端末やサーバの設置環境に応じてキープアライブ間隔を固定的に設定している。しかし、今後FMCが実現すると端末の移動の度に通信環境が変化するようになる。そこで、各通信環境に適したキープアライブ間隔を、動的に検出、設定することが課題となる。上記第一の課題を解決するために、無線アクセス網と端末間のキープアライブにより検出した端末状態を、無線アクセス網からサーバに通知することにより、サーバと端末間のキープアライブを省略する。また、上記第二の課題を解決するために、本発明は、端末とサーバの連携により通信環境を動的に検出する手段を備え、前記検出結果に基づいてキープアライブ間隔を変更することを特徴とする。本発明によれば、端末消費電力低減と障害検出時間短縮を両立する効率的な端末とサーバ間のキープアライブが可能となる。また端末が異種アクセス網間を移動する場合にも、各環境に応じた最適な端末とサーバ間のキープアライブ間隔の設定が可能となる。以下、図面を用いて本発明の実施例を説明する。<実施例1>実施例1では、複数の無線システムと、前記複数の無線システムに接続可能な端末と、前記端末を収容するアプリサーバとから構成される通信システムにおいて、前記アプリサーバと前記端末間のアプリキープアライブ間隔を、端末の通信環境に応じて動的に変更する例を示す。また、アプリサーバが無線アクセス網から端末接続情報を取得できる場合には、その情報を利用してアプリケーション上のアプリキープアライブ間隔を長く設定する例を示す。尚、実施例1では、端末1と無線GW21との接続を維持するための端末1と無線GW21とのキープアライブを無線接続キープアライブと、端末1とアプリサーバ61との接続を維持するためのキープアライブをアプリキープアライブと定義する。1システム構成例図1は、実施例1におけるシステム構成例を示す図である。図1において、1は複数の無線インタフェースを備えた端末を示し、は端末1と通信可能な無線アクセス網を示し、は無線アクセス網に設置される無線GWを示し、は無線GWが保持する無線接続DBを示し、60は無線アクセス網を収容するIPコア網を示し、61はIPコア網60に接続されるアプリサーバを示し、62はアプリサーバ61が保持するアプリ接続DBを示し、63はアプリサーバ61と無線GW間の通信を中継するマッピングサーバを示し、64はマッピングサーバ63が保持するマッピングDBを示す。ここで図1のシステムにおける無線アクセス網は、無線GWの機能に応じて、NAT有無およびアプリ連携有無の観点から計4種類に分類される。NAT無の無線アクセス網では、端末にグローバルアドレスを付与するが、NAT有の無線アクセス網では、端末にプライベートアドレスを付与し無線GWにおいてプライベートアドレスとグローバルアドレスの相互変換を行う。NAT機能を有する無線GW21はNATセッション毎にNATセッションタイマが設定できる。またアプリ連携有の無線アクセス網では、マッピングサーバを介して、無線アクセス網からサーバへの端末接続情報通知、サーバからの無線アクセス網のへのNAT制御を行うが、アプリ連携無の無線アクセス網では、無線GWがそのような通信インタフェースを備えないとする。無線GWが保持する無線接続DBは、無線アクセス網における端末接続状況を管理する目的で使用される。例えば図2bに示すように、無線接続DB32は、無線アクセス網におけるユーザIDを示す無線ユーザID321、無線アクセス網への接続状態を示す無線接続状態322、無線アクセス網から端末に割当てたIPアドレスを示す割当てアドレス323等から構成される。マッピングサーバ63が保持するマッピングDB64は、アプリ接続DB62と、アプリ連携機能を有する無線接続DBとの対応関係を管理する目的で使用される。例えば図3に示すように、マッピングDB64は、アプリケーション上のユーザIDを示すアプリユーザID641、アプリユーザID641のユーザが無線アクセス網との接続に使用する無線ユーザID642、無線ユーザID642における接続状態を示す無線接続状態643、無線アクセス網から割り当てられたIPアドレスを示す割当てアドレス644等から構成される。以上で示した図1のシステムを、携帯電話網の標準化団体3GPPのシステムに当てはめると、無線アクセス網はLTE、CDMA2000、WiMAX、無線LAN等の各種無線アクセス網に相当し、無線GWはLTEのPDNGWや、CDMA2000のPDSNやHA、WiMAXのCSNGW、無線LANのWAG等に相当し、マッピングサーバ63はPCRFに相当し、アプリサーバ61はAFに相当する。しかし、本発明はこれに限定されず、3GPPに準拠しないシステムに対しても適用可能である。2装置構成例と特徴機能次に、図4~7を用いて、本発明の特長となるアプリサーバ61と端末1の機能について説明する。図4は、アプリサーバ61の装置構成例を示す。本構成例において、アプリサーバ61のハードウェアは一般的なサーバ装置と同様であり、不揮発性の情報記憶デバイスであるハードディスク611と、揮発性の情報記憶デバイスであるメモリ612と、プログラムおよびデータを逐次読み込んで演算を行うCPU613と、外部装置との通信を中継するNIC614と、各ユニットを接続するバス615から構成される。また、アプリサーバ61の機能を実現するプログラムおよびデータは、実行時にメモリ612に展開され、それらは少なくともアプリケーション特有の処理を行うアプリ処理ルーチン100と、端末との通信状況を管理するアプリ接続DB62と、経路上のNAT有無を判定するNAT有無判定ルーチン101と、無線アクセス網からの端末接続状態の取得可否、NAT制御可否を判定するアプリ連携有無判定ルーチン102と、NAT有無判定ルーチン101およびアプリ連携有無判定ルーチン102の判定結果に基づき端末のアプリキープアライブ間隔を決定するキープアライブ間隔決定ルーチン103と、アプリ連携有の場合に無線アクセス網から端末接続状態を取得する無線接続状態取得ルーチン104と、を含む。これらのうち、NAT有無判定ルーチン101、アプリ連携有無判定ルーチン102、アプリキープアライブ間隔決定ルーチン103を備える点が、本発明における特徴である。アプリ接続DB62は、端末1との通信状況を管理する目的で用いられ、例えば図2aのようにアプリケーション上のユーザIDを示すアプリユーザID621、端末の通信モードを示すアプリ通信モード622、アプリ通信モード622がPushである場合にアプリサーバ61への接続状態を示すアプリ接続状態623、端末がアプリサーバ61からの制御信号を受け付けるIPアドレス、トランスポートプロトコル、ポート番号を示すアプリ通信アドレス624、アプリ接続状態623の取得方法を示すアプリ接続状態取得方法625等から構成される。アプリサーバ61は、アプリ接続DB62の通信モード622がPushである端末に対して定期的にアプリキープアライブを実施する。一方、図2aのユーザCのように通信モード622にPullが設定されている場合には、電波状況の良いときに端末主導で情報をPullするため、アプリサーバ61側での端末1の状態管理や、端末1とアプリサーバ61間のアプリキープアライブは不要となる。。NAT有無判定ルーチン101は、前述した通り、STUN等のNAT検出プロトコルを用いてもよいし、アプリケーションプロトコルがSIPである場合には、端末1から受信したSIPパケットにおいて、IPヘッダの送信元IPアドレスと、SIPヘッダ上のContactアドレスを比較することにより判定してもよい。ここでIPヘッダとSIPContactアドレスの比較によりNATの存在が検知できる理由は、NATが存在する場合、端末1はIPヘッダとSIPContactアドレスの双方に無線GWから割り当てられたプライベートアドレスを設定するが、途中の無線GWにてIPヘッダのアドレスのみがグローバルアドレスに変換されるためである。そこで、IPヘッダとSIPContactアドレスの値は一致する場合はNAT無し、異なる場合はNAT有りと判定できる。アプリ連携有無判定ルーチン104は、該アプリサーバに接続している端末1のアプリユーザID等をキーとして、マッピングサーバに端末1が接続している無線アクセス網のアプリ連携有無を問い合わせる。また、マッピングサーバ63から、該問い合わせに対するアプリ連携有無の判定結果を受信する。これにより、端末1が接続している無線アクセス網のアプリ連携機能の有無を判定することができる。後で図9を用いて詳細を説明するが、本システムにおいては、無線GWがアプリ連携機能を備える場合、端末1が無線GWに接続した際に、無線GWからマッピングサーバ63に該無線GWと接続している端末1の端末接続状態の通知を行うため、マッピングサーバ63は該端末接続状態を検索することにより、端末1が接続している無線アクセス網のアプリ連携有無を判定し、端末1が接続している無線アクセス網のアプリ連携有無をアプリサーバ61に通知できる。アプリキープアライブ間隔決定ルーチン103のアルゴリズムは、例えば図5のフローチャートで表わされる。本ルーチンでは、NAT有無判定ルーチン101とアプリ連携有無判定ルーチン102の判定結果に基づき条件分岐を行う。まずステップ121と122において、NAT有無判定ルーチン101でNAT有かつアプリ連携有無判定ルーチン104でアプリ連携有と判定された場合には、アプリサーバ61は、図1のマッピングサーバ63経由で無線GW21に当該アプリキープアライブ通信用のNATセッションタイマを最大値に設定するよう指示を出す。具体的には、端末1がアプリキープアライブに使用するIPアドレスとポート番号図2aのアプリ制御アドレス624にて管理するに基づいてNATセッションを生成し、そのNATセッションタイマを最大値に設定する旨の指示を行う。さらにアプリサーバ61は、その設定値から予め定めたオフセット値を差し引いた値を該端末のアプリキープアライブ間隔とする。このように、NATセッションタイマの最大値からオフセット値を差し引いた値をアプリキープアライブ間隔とすることにより、各装置のタイマ精度の違いからNATセッションタイマとアプリキープアライブタイマにずれが生じるような環境においても、NATセッションタイマが満了する前にアプリキープアライブを実施することができ、NATセッションタイマを維持できる。ここで本システムにおいては、無線GW21がアプリサーバ61からの指示に基づいてNATセッション毎に異なる値のタイマを設定できると仮定している。通常のNAT装置は、装置自身の基準に基づきNATセッションタイマの値を決定するが、本願発明では、ここで述べたように無線GW21が外部装置であるアプリサーバ61からの指示に基づき特定のNATセッションのタイマを延長可能とする。これにより、アプリキープアライブ間隔を長く設定することができ、ひいては端末1およびアプリサーバ61の処理負荷を低減することが可能となる。なお、NAT有かつアプリ連携有の場合のシステム動作フローは後で図9と図10を用いて説明する。次に図5のステップ121と122において、NAT有かつアプリ連携無と判定された場合には、アプリサーバ61は、NATセッションタイマの値を取得し、その値から予め定めたオフセット値を差し引いた値を該端末のアプリキープアライブ間隔とする。ステップ125において、アプリサーバ61は、NATセッションタイマの値を取得するために、予め調査したNATセッションタイマの値を無線アクセス網や無線GW毎にテーブルとして管理してもよいし、もしくは前述のSTUNやUPnP等のプロトコルを用いて端末1と連携しながら動的にNATセッションタイマの値を取得してもよい。いずれの手段を用いるにせよ、NATセッションタイマの値を取得し、該端末のアプリキープアライブ間隔を該NATセッションのNATセッションタイマよりも短く設定することにより、端末1とアプリサーバ61間の接続性を維持することが可能となる。なお、NAT有かつアプリ連携無の場合のシステム動作フローは後で図13を用いて説明する。また図5のステップ121と127において、NAT無かつアプリ連携有と判定された場合には、アプリサーバ61は、アプリキープアライブ間隔を該無線アクセス網毎に定められているアプリキープアライブ間隔の最大値に設定するか、もしくはアプリキープアライブを実施しないことを決定する。ここで、アプリキープアライブの最大値とは、該端末内でアプリケーションが正常に稼働しているか否かを確認する時間間隔であり、アプリケーションの安定性や、ユーザのアプリケーション操作の頻度等を考慮して定めるものとする。本ケースにおいては、アプリサーバ61は、無線GWの備える図2bの無線接続DB32の情報を定期的に確認することにより、仮想的にアプリキープアライブを行っていると見なし、実際に端末1とアプリサーバ61間で行うアプリキープアライブの間隔を長く設定している。これにより、障害検出までの時間を長くせずとも、端末1が送受信するパケット数を減らすことができ、端末消費電力を低減することが可能となる。また一方で、無線アクセス網毎に定められているアプリキープアライブ間隔の最大値でアプリキープアライブを実施することにより、該端末1内でアプリケーションが正常に稼働していることを定期的に確認できる効果がある。なお、NAT無かつアプリ連携有の場合のシステム動作フローは後で図11を用いて説明する。また図5のステップ121と127において、NAT無かつアプリ連携無と判定された場合には、アプリキープアライブ間隔を、無線アクセス網毎に定められているアプリキープアライブ間隔の標準値に設定する。このように無線アクセス網毎にアプリキープアライブ間隔の標準値を定めることにより、基地局のエリアの広さ等を考慮して適切な頻度でIP接続性の確認を目的としたアプリキープアライブを行うことが可能となる。なお、NAT無かつアプリ連携無の場合のシステム動作フローは後で図12を用いて説明する。次に、図6を用いて端末1の装置構成例を示す。本構成例において、端末1のハードウェアは一般的な無線端末と同様であり、不揮発性の情報記憶デバイスであるハードディスク11と、揮発性の情報記憶デバイスであるメモリ12と、プログラムおよびデータを逐次読み込んで演算を行うCPU13と、無線電波の送受信を行うアンテナ14と、アンテナ14の無線信号に対してアナログデジタル変換や変復調等を行う無線信号処理部15と、各ユニットを接続するバス16から構成される。また、端末1の機能を実現するプログラムおよびデータの一部は、実行時にメモリ12に展開され、それらは少なくともアプリケーション特有の処理を行うアプリ処理ルーチン150と、アプリサーバ61と通信しアプリキープアライブ間隔を決定するアプリキープアライブ間隔交渉ルーチン151と、アンテナ14および無線信号処理部15を制御する無線制御ルーチン156と、アンテナ14および無線信号処理部15より無線電波状況を取得し、それらの統計情報を算出する無線電波状況監視ルーチン155と、アプリキープアライブ間隔交渉ルーチン151が決定したアプリキープアライブ間隔、および無線電波状況監視ルーチン155が算出した統計情報に基づき、アプリキープアライブ処理に伴う消費電力量の予測値を算出する消費電力量予測ルーチン153と、消費電力量予測ルーチン153の結果に基づきアプリサーバ61との通信方法を決定する通信方法決定ルーチン154を含む。これらのうち、通信方法決定ルーチン154を備える点が、本発明における特徴の一つである。図7は、端末1における通信方法決定ルーチン154の実装例を示す。本ルーチンでは、まず端末の移動速度や、各無線システムのエリアの広さ、無線電波状況監視ルーチン155によって算出した無線電波状況等を考慮し、最適と思われる無線アクセス網を1つ選択する。そして、前記選択した無線アクセス網を用いてアプリサーバ61と通信を行い、システムのデフォルトの情報配信方式におけるアプリキープアライブ間隔をアプリキープアライブ間隔交渉ルーチン151において決定する。さらに、決定したアプリキープアライブ間隔と無線電波状況監視ルーチン155によって算出した無線電波状況とに基づき、消費電力量予測ルーチン153を用いてアプリキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算する。単位時間当たりの消費電力量の予測式は、例えば以下の式のように近似できる。TEXPCTKASここで、Cは無線アクセス網毎に異なる定数、TKAはアプリキープアライブ間隔、RSSIは無線電波状況、Sは無線電波状況がRSSIである場合に単位データ量の送受信につき消費される電力量である。式により算出した単位時間あたりの消費電力量の予測値が予め無線アクセス網毎に定めた単位時間あたりの消費電力量の閾値よりも小さい場合には、情報配信方式が適切であると判断し、そのまま処理を終了する。一方、式により算出した単位時間あたりの消費電力量の予測値が、無線アクセス網毎に定めた単位時間あたりの消費電力量の閾値よりも大きい場合には、以下の手順で情報配信方式の変更を行う。まず、ステップ171で選択した無線アクセス網の無線GWがNAT有かつ情報配信方式がUDP利用である場合には、UDP利用をTCP利用に変更し、再度キープアライブ間隔の交渉のステップから実施する。一般的なNAT装置においては、コネクション管理を行わないUDPと比較して、コネクション管理を行うTCPのほうが、NATセッションタイマがより長く設定される。このため、ステップ172において情報配信方式のトランスポートプロトコルをUDP利用からTCP利用に変更することにより、アプリキープアライブ間隔を長くすることができ、結果として端末消費電力を削減できる効果が見込まれる。このように情報配信方式のトランスポートプロトコルをUDP利用からTCP利用に変更することによって、アプリキープアライブ間隔を長く設定するシステム動作フローは図14を用いて説明する。また、ステップ175において、NAT無またはUDP以外を利用である場合には、無線信号処理部15より取得した無線電波状況等に基づいて他の無線アクセス網を利用可能であるかを確認し、利用可能である場合には、接続する無線アクセス網をステップ171で選択した無線アクセス網からステップ177で選択した他の無線アクセス網に変更して、再度アプリキープアライブ間隔の交渉のステップから実施する。ステップ171の時点では、当該無線アクセス網におけるNATの有無や、アプリ連携機能の有無等の通信環境が必ずしも把握できていないため、ステップ178において、接続する無線アクセス網をステップ171で選択した無線アクセス網からステップ177で選択した他の無線アクセス網に変更することにより、より条件のよい、すなわち消費電力量がより少ない無線アクセス網を選択できる。なお、端末1は、一度接続した無線アクセス網のNAT有無やアプリ連携有無等のパラメータを記憶し、次回以降の無線アクセス網選択に利用してもよい。これにより、端末1が最適な無線アクセス網を選択するまでの時間を短縮できる効果が見込まれる。なお、無線アクセス網の再選択によりアプリキープアライブ間隔を延長するシステム動作フローは図15を用いて説明する。また、ステップ177において他の無線アクセス網を利用できない場合には、情報配信方式の通信モードをPush型通信からPull型通信に変更し、処理を終了する。Push型通信は、情報の即時配信に向いている反面、無線電波状況と無関係にデータが送受信されるため、電波状況が悪い時には通信効率の低下、およびアプリサーバ61におけるパケット再送負荷が発生する。そこで電波状況が悪く消費電力量の増加が見込まれる場合には、一時的にPull型に切り替えることにより、これらの弊害を回避することができる。例えば、図6の無線電波状況監視ルーチン155において、無線電波状況を監視し、その瞬間の無線電波状況が比較的良いと判断した際に、アプリ処理ルーチン150に通知し、アプリ処理ルーチン150はその通知を契機としてアプリサーバ61から情報をPullする構成が考えられる。ここで無線電波状況監視ルーチン155において、無線電波状況が良いか否かを判定する方法としては、例えば図8に示すような無線電波強度の推移に基づき、図8の短期統計値と、図8の短期統計値の変動予測ΔSを算出し、現時点での無線電波強度SがS07とΔSの和よりも大きければ、無線電波状況が良好であると判断する方法等が考えられる図8。以上のように、無線電波状況が悪い時には情報配信方式の通信モードをPush型から一時的にPull型に切替え、さらに端末1の無線電波状況が良い時を見計らって通信を行うことにより、端末1の消費電力の低減、ならびにアプリサーバ61におけるパケット再送負荷を低減することが可能となる。このように情報配信方式の通信モードをPush型からPull型に切り替えるシステム動作フローは図16を用いて説明する。なお、本実施例においては、端末1が無線アクセス網と情報配信方式の選択機能を備え、またアプリサーバ61がアプリキープアライブ間隔の決定機能を備える構成としたが、このように端末1とアプリサーバ61の機能を明確に分離せず、端末1とアプリサーバ61が互いに連携しつつこれらの機能を実現する構成としてもよい。また、端末1とアプリサーバ61が外部のサーバと連携しつつ処理を行ってもよい。3システム動作フロー例次に、図9~17を用いて本実施例におけるシステム動作フローの例を説明する。図9は、未接続状態の端末1が無線アクセス網20経由で無線GW21に接続し、その接続を利用してアプリサーバ61に位置登録を行う動作フローを示す。動作フローの中で、アプリサーバ61は端末1の通信環境を判定し、アプリキープアライブ間隔を決定する。はじめに、端末1は未接続状態にあるが、端末1の電源が投入されたことにより無線アクセス網20の存在を検知し、無線GW21との接続を確立する。このときに、無線GW21は、無線ユーザ端末に割り当てた割り当てアドレスIP2を無線端末のユーザIDと無線接続状態322と対応づけて無線接続DB22で保持する。無線接続DB22は、図2bに示した無線接続DB32とほぼ同様の構成をとるが、割当てアドレス323に設定されるアドレスがNAT変換前のプライベートIPアドレスである点が異なる。無線GW21のアプリ連携機能は、端末1と無線接続確立をマッピングサーバ63に対して通知する。接続確立では、無線GW21からマッピングサーバ63に、無線接続DBで保持している、無線ユーザID、無線接続状態、割当アドレスIP2などが通知される。マッピングサーバ63は無線GW21から通知される端末1の接続情報、無線接続状態接続中を図3のマッピングDBに記憶し643、644など、応答を返信する。ここで、本実施例においては、無線ユーザIDとアプリユーザIDのマッピング情報641、642を、管理者が予めマッピングDB64に設定していると想定する。すなわち、ステップ303において、マッピングサーバ63は接続通知メッセージに含まれる無線ユーザIDに基づいてマッピングDB64を検索し、該当するエントリに割当てアドレスIP2と無線接続状態接続中を設定することとなる。次に、端末1はアプリサーバ61からPush型情報配信を受けるために、無線GW21から割り当てられたIPアドレスとアプリユーザID、トランスポートプロトコルudp、ポート番号をアプリサーバ61に通知し位置登録を行う。ここで無線GW21はNAT機能を有するため305a、ステップ305の位置登録メッセージにおいて、端末1がアプリケーション情報例えばSIPContactアドレスとして設定するIPアドレスと、アプリサーバ61が受信する位置登録メッセージのIPヘッダに設定されているIPアドレス無線GW21に付与されたグローバルIPアドレスは異なる。これにより、アプリサーバ61のNAT有無判定ルーチン101は、NATの存在を検知する。また、アプリサーバ61は、位置登録メッセージを受信すると、アプリ接続DB62に、位置登録メッセージで通知されたIPアドレスIP2、利用中のトランスポートプロトコルとポート番号、アプリユーザID、通信モード622、アプリ接続状態623を登録する。アプリ接続状態取得方法については、該端末が接続する無線アクセス網のアプリ連携有無が判明した後に設定される。さらに、アプリサーバ61のアプリ有無連携有無判定ルーチン104は、無線GW21のアプリ連携有無を調べるために、マッピングサーバ63に対して無線接続情報を問い合わせる。マッピングサーバ63は、アプリサーバ61から通知された無線接続情報問い合わせステップ307に含まれる端末1のアプリケーション上のユーザIDを示すアプリユーザIDと割当てアドレスIP2に該当する無線接続情報をマッピングDB64から検索し、この場合は既にアプリユーザIDとIPアドレスに対応する無線GW21の接続情報が登録されているため成功応答を返信する。アプリサーバ61のアプリ有無連携有無判定ルーチン104は成功応答を受信することにより、無線GW21がアプリ連携有であることを認識する。そして、アプリ接続DB62のアプリ接続状態取得方法625を無線接続DBと同期に設定する。アプリサーバ61は、以上説明したNAT有無判定ルーチン101及びアプリ有無連携有無判定ルーチン104の処理により得た端末1の通信環境情報を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施する。アプリサーバ61は、図5のステップ123において説明したように、無線GW21の該NATセッションに対するNATセッションタイマを最大値に設定するように無線GW21に指示する。NATセッションタイマ設定310には、割当アドレスIP2、トランスポートプロトコル、ポート番号、タイマを最大値に設定する命令、等が含まれており、無線GW21はこれらの情報に基づきNATセッションのタイマを最大値に設定する。なお、ここでのNATセッションとは、NATセッションタイマ設定310に含まれる割当アドレスIP2、トランスポートプロトコル、ポート番号等の情報を用いて生成されるものとする。また、アプリサーバ61は、図5のステップ124において決定したアプリキープアライブ間隔をNIC614を介して端末1に通知する。ここでステップ312はステップ305に対する応答メッセージである。これ以降、端末1は待機状態になり、無線GW21との接続を維持するための無線接続キープアライブと、決定したアプリキープアライブ間隔を用いて行われるアプリサーバ61との接続を維持するためのアプリキープアライブを定期的に実行する。なお、アプリキープアライブ時には、無線GW21のNAT情報が更新されるため、NATセッションタイマよりも短い周期でアプリキープアライブを行うことにより、アプリサーバ61から端末1へ向かう通信経路を維持することが可能となる。また、本システムにおいては、無線接続キープアライブ間隔よりもアプリキープアライブ間隔のほうを長く設定することにより、端末1の消費電力を低減する。このような設定が可能となる理由は、無線GW21のアプリ連携機能により、無線接続キープアライブの結果がアプリサーバ61に通知されるためである。図17は、3GPPの第39世代無線通信方式LTEにおける、図9のフローの実装例を示す。本フローにおいて、無線GW21はLTEのPDNGWであり、マッピングサーバ63はPCRFであり、アプリサーバはSIPサーバである。はじめに、端末1は未接続状態にあるが、端末1の電源が投入されたことにより無線アクセス網20の存在を検知し、無線GW21との接続を確立する。このときに、無線GW21は、無線ユーザ端末に割当てた割当アドレスを無線端末のユーザIDと無線接続状態322と対応付けて無線接続DB32で保持する。また無線GW21はアプリ連携機能を有するため、DiameterCCRメッセージにより端末1の接続確立をマッピングサーバ63に対して通知する。ステップ603では、無線GW21PDNGWからマッピングサーバ63に、無線接続DB32で保持している、無線ユーザID、無線接続状態、割当アドレスなどが通知される。マッピングサーバ63は端末1の接続情報を図3のマッピングDBに記憶し、応答を返信する。次に、端末1はアプリサーバ61にSIPREGISTERを送信し位置登録を行う。位置登録605では、アプリユーザID、割当アドレス、トランスポートプロトコル、ポート番号などが通知される。ここで無線GW21はNAT機能を有するため、ステップ605の位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは異なる。これにより、アプリサーバ61はNATの存在を検知する。また、アプリサーバ61は、位置登録メッセージを受信すると、アプリ接続DB62に、位置登録メッセージで通知されたIPアドレスIP2、利用中のトランスポートプロトコルとポート番号、アプリユーザID、通信モード622、アプリ接続状態623を登録する。アプリ接続状態取得方法については、該端末が接続する無線アクセス網のアプリ連携有無が判明した後に設定される。さらに、アプリサーバ61SIPサーバのアプリ有無連携有無判定ルーチン104は、無線GW21のアプリ連携有無を調べるために、マッピングサーバ63に対してDiameterAARメッセージを送信し、無線接続情報を問い合わせる。DiameterAAR607には、アプリユーザIDと割当てアドレスIP2が含まれる。なお現在の標準規格においては、DiameterAARにより無線接続状況を問い合わせることはできないため、本処理を行うためにはメッセージの拡張が必要となる。マッピングサーバ63は、アプリサーバ61から通知されたDiameterAAR607に含まれる端末1のアプリユーザIDと割当てアドレスIP2に該当する無線接続情報をマッピングDB64から検索し、この場合は既にアプリユーザIDと割当てアドレスIP2に該当する無線GW21の接続情報が登録されているため成功応答を返信する。アプリサーバ61のアプリ連携有無判定ルーチン104は成功応答609を受信することにより無線GW21がアプリ連携有であることを認識する。そして、アプリ接続DB62のアプリ接続状態取得方法625を無線接続DBと同期に設定する。アプリサーバ61は、以上の処理により得た端末1の通信環境情報を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施し、NATセッションタイマの延長と、アプリキープアライブ間隔の通知を行う。なお、ステップ610、611のDiameterAARRARメッセージにおいて、NATタイマを設定する機能は本発明独自のものであり、標準規格の拡張が必要となる。これ以降、端末1は待機状態になり、無線GW21との接続を維持するための無線接続キープアライブと、アプリサーバ61との接続を維持するためのアプリキープアライブを定期的に実行する。次に図10を用いて、無線接続キープアライブの結果をアプリサーバ61に通知するシステム動作フローの例を示す。はじめに、端末1は無線GW21とアプリサーバ61に接続しており、無線接続キープアライブと、アプリキープアライブを定期的に実行している。ところが、端末1の移動により、無線アクセス網20の無線電波が届かなくなってしまったとする。無線GW21は、端末1の無線接続キープアライブが一定時間行われないことにより、圏外移動を検知し、無線接続DB32の端末1の無線接続情報とNAT情報図示していないを削除して、マッピングサーバ63に端末1の無線ユーザID、割当アドレスを含む切断通知を行う。マッピングサーバ63は、マッピングDBを参照して無線ユーザID、割当アドレスに対応するアプリユーザIDを含む切断通知をアプリサーバ61に転送する。アプリサーバ61は、切断通知を受信すると、アプリ接続DB62のアプリユーザIDに対応するアプリ接続情報を削除し、マッピングサーバに応答の返信を行う。以上のように、無線アクセス網で行う無線接続キープアライブの結果をアプリサーバ61に通知することにより、アプリサーバ61と端末1間のキープアライブ間隔を長く設定しても、アプリサーバ61が適切なタイミングで端末接続情報を更新できるようになる。このため、端末1の消費電力を低減できるとともに、アプリサーバ61の処理負荷をも低減することが可能となる。次に図18を用いて、アプリサーバ61の異常発生を端末1に通知し、端末1から再度位置登録を実施するシステム動作フローの例を示す。はじめに、端末1は、無線GW21とアプリサーバ61に接続しており、無線接続キープアライブと、アプリキープアライブを定期的に実行している。また、動作フローでは、アプリサーバ61の障害検出のために、アプリサーバ61とマッピングサーバ63の間でもキープアライブを定期的に実施しているとする。この状態において、アプリサーバ61に異常が発生し、アプリサーバ61が再起動を行ったとする。マッピングサーバ63は、アプリサーバ61の再起動を検出すると、再起動を行ったアプリサーバを示すアプリサーバIDを含むアプリサーバ再起動通知を無線GW21経由で端末1に通知する。端末1は、アプリサーバ再起動通知を受けると、該アプリサーバIDで識別されるアプリサーバ61に対して再度位置登録を行い、再びキープアライブ間隔の交渉、待ち受け状態への移行が行われる。以上のように、アプリサーバ61の異常をマッピングサーバ63が検知し、無線GW21経由で端末1に通知することにより、端末1とアプリサーバ61間のキープアライブ間隔を長く設定しても、端末1がアプリサーバ61の異常発生を迅速に検知できるようになり、サービス品質を向上できる効果がある。次に、図11を用いて端末1が無線GW21から無線GW31に移動するシステム動作フローの例を示す。無線GW21はNAT機能を備えるが、無線GW31はNAT機能を備えていない。はじめに、端末1は無線GW21とアプリサーバ61に接続中の状態にある。ところが、無線電波状況の変化により、端末1は無線アクセス網20から無線アクセス網30aへの移動を決定し、無線GW31との接続を確立する。無線GW31はアプリ連携機能を有するため、このときに端末1の接続確立をマッピングサーバ63に対して通知する。接続確立には、無線ユーザIDuserAmoperator30及び端末1が無線GW31から割り当てられたIPアドレスIP3が含まれる。マッピングサーバは接続確立に含まれる端末1の接続情報を図3のマッピングDBに記憶し、応答を返信する。次に、端末1はアプリサーバ61との接続を維持するために、無線GW31から新たに割り当てられたIPアドレスIP3を端末1のアプリユーザIDと対応して、アプリサーバ61に対して通知する。ここで無線GW31はNAT機能を有しないため、ステップ365の位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは一致する。これにより、アプリサーバ61のNAT有無判定ルーチン101は、無線GW31にはNAT機能が存在しないと判断する。また、アプリサーバ61は、無線GW31のアプリ連携有無を調べるためにアプリ連携有無判定ルーチン104を実行して、マッピングサーバ63に対して端末1のアプリユーザIDとIPアドレスIP3を含む無線接続情報を問い合わせる。マッピングサーバ63は、マッピングDBから、アプリサーバ61から通知された端末1のアプリユーザIDとIPアドレスIP3に該当する無線接続情報を検索する。この場合は既にアプリユーザIDとIPアドレスIP3に対応する無線GW31の接続情報が登録されているため成功応答を返信する。これにより、アプリサーバ61のアプリ有無連携有無判定ルーチン102は無線GW31がアプリ連携有であると判定する。アプリサーバ61は、以上のNAT有無判定ルーチン101及びアプリ有無連携有無判定ルーチン102の処理により得た端末1の通信環境情報を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施し、端末1にキープアライブ間隔の通知を行う。具体的には、通信環境情報であるので、アプリキープアライブ間隔決定ルーチン103のステップ128によって、無線アクセス網30aのアプリキープアライブ間隔の最大値であるTMAXがアプリキープアライブと決定されTMAXが端末1に通知される。これ以降あるいは372以降、端末1とアプリサーバの間でTMAXの間隔でアプリキープアライブが実行される。端末1は、無線GW31との接続確立ステップ362、アプリサーバ61の情報更新に成功するステップ369の応答を受信すると、無線GW21との接続を切断する。無線GW21は、端末1の無線ユーザIDuserAmoperator20を含む切断通知をマッピングサーバ63に通知する。マッピングサーバ63は無線GW21から端末1の切断通知を受信すると、マッピングDBの該無線ユーザIDuserAmoperator20に対応する無線接続状態643を切断中とし、また割当てアドレス644を削除する。ステップ370で無線GW21との接続を切断すると、端末1は待機状態になり、無線GW31との接続を維持するための無線接続キープアライブと、アプリサーバ61との接続を維持するためのアプリキープアライブを定期的に実行する。なお、本システムにおいては、無線接続キープアライブ間隔よりもアプリキープアライブ間隔のほうを長く設定することにより、端末1の消費電力を低減する。このような設定が可能となる理由は、無線GW31のアプリ連携機能により、無線接続キープアライブの結果がアプリサーバ61に通知されるためである。次に、図12を用いて端末1が無線GW31から無線GW41に移動するシステム動作フローの例を示す。はじめに、端末1は無線GW31とアプリサーバ61に接続中の状態にある。ところが、無線電波状況の変化により、端末1は無線アクセス網30aから無線アクセス網40への移動を決定し、無線GW41との接続を確立する。無線GW41はアプリ連携機能を有しないため、本動作フローにおいては無線GW41からマッピングサーバ63への通知は行われない。次に、端末1はアプリサーバ61との接続を維持するために、無線GW41から新たに割り当てられたIPアドレスと、アプリキープアライブに利用するトランスポートプロトコル、ポート番号を、アプリサーバ61に対して通知する。ここで無線GW41はNAT機能を有しないため、ステップ393の再位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは一致する。これにより、アプリサーバ61のNAT有無判定ルーチンは、無線GW41にはNAT機能が存在しないと判断する。また、アプリサーバ61は無線GW41のアプリ連携有無を調べるためにアプリ連携有無判定ルーチンを実行して、マッピングサーバ63に対して無線接続情報を問い合わせる。マッピングサーバ63は、アプリサーバ61から通知された端末1のアプリユーザIDとIPアドレスIP4に該当する無線接続情報をマッピングDBから検索する。この場合は、無線GW31の接続情報である、ユーザID、無線ユーザIDUserAmoperator30に対して割り当てアドレスIP3はマッピングDBに保持されているが、無線GW41の接続情報である、ユーザID、無線ユーザIDUserAmoperator30に対して割り当てアドレスIP4が登録されていないため、マッピングサーバ63は、アプリサーバ61に失敗応答を返信する。これにより、アプリサーバ61のアプリ有無連携判定ルーチンは、無線GW41がアプリ連携無であることを認識する。アプリサーバ61は、以上のNAT有無判定ルーチン及びアプリ有無連携判定ルーチンの処理により得た端末1の通信環境情報を利用して図5のキープアライブ間隔決定ルーチン103を実施し、端末1にアプリキープアライブ間隔の通知を行う。具体的には、通信環境情報であるので、アプリキープアライブ間隔決定ルーチン103のステップ129によって、無線アクセス網40のアプリキープアライブ間隔の標準値であるTSTDがアプリキープアライブと決定されTSTDが端末1に通知される。これ以降、端末1とアプリサーバの間でTSTDの間隔でアプリキープアライブが実行される。端末1は、無線GW41との接続確立、アプリサーバ61の情報更新に成功すると、無線GW31との接続を切断し、無線GW31は端末1の切断をマッピングサーバ63に通知する。これ以降、端末1は待機状態になり、無線GW41との接続を維持するための無線接続キープアライブと、アプリサーバ61との接続を維持するためのアプリキープアライブを定期的に実行する。なお、本システムにおいては、無線GW41がアプリ連携機能を備えないため、アプリキープアライブ間隔を比較的小さい値に設定する。アプリキープアライブ間隔を、アプリ連携がある場合のアプリキープアライブ間隔よりも小さい値とする。このように、アプリ連携がある場合のアプリキープアライブ間隔よりもアプリキープアライブ間隔を短くすることにより、アプリ連携機能を有しない無線システムにおいてもアプリサーバが適切な精度で端末の接続状態を管理することが可能となる。次に、図13を用いて端末1が無線GW41から無線GW51に移動するシステム動作フローの例を示す。はじめに、端末1は無線GW41とアプリサーバ61に接続中の状態にある。ところが、無線電波状況の変化により、端末1は無線アクセス網40から無線アクセス網50への移動を決定し、無線GW51との接続を確立する。無線GW51はアプリ連携機能を有しないため、本動作フローにおいては無線GW51からマッピングサーバ63への通知は行わない。次に、端末1はアプリサーバ61との接続を維持するために、無線GW51から新たに割り当てられたIPアドレスIP5と、アプリキープアライブに利用するトランスポートプロトコル、ポート番号をアプリユーザIDとともに、アプリサーバ61に対して通知する。ここで無線GW51はNAT機能を有するため、ステップ423の再位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは異なる。これにより、アプリサーバ61のNAT有無判定ルーチンは、無線GW51がNAT機能を備えていることを検知する。また、アプリサーバ61は無線GW51のアプリ連携有無を調べるためにアプリ連携有無判定ルーチンを実行して、マッピングサーバ63に対して無線接続情報を問い合わせる。マッピングサーバ63は、アプリサーバ61から通知された端末1のアプリユーザIDとIPアドレスに該当する無線接続情報をマッピングDBから検索する。この場合は無線GW51の接続情報、すなわちIPアドレスに対応する無線接続状態が登録されていないため、マッピングサーバはアプリサーバに失敗応答を返信する。これにより、アプリサーバ61のアプリ連携有無判定ルーチンは無線GW41がアプリ連携無であることを認識する。アプリサーバ61は、以上のNAT有無判定ルーチン及びアプリ連携有無判定ルーチンの処理により得た端末1の通信環境情報を利用して図5のキープアライブ間隔決定ルーチン103を実施する。NATセッションタイマの検出と、端末1へのキープアライブ間隔の通知を行う。具体的には、通信環境情報であるので、アプリキープアライブ間隔決定ルーチン103のステップ125において無線GW51のIP5に対して設定されているNATセッションタイマを取得し、ステップ126において、NATセッションタイマを用いてアプリキープアライブ間隔を決定する。アプリサーバはNICを介して端末1に決定したアプリキープアライブ間隔を通知する。これ以降、端末1とアプリサーバの間でTNATαの間隔でアプリキープアライブが実行される。端末1は、無線GW51との接続確立、アプリサーバ61の情報更新に成功すると、無線GW41との接続を切断する。これ以降、端末1は、待機状態になり、無線GW51との接続を維持するための無線接続キープアライブと、アプリサーバ61との接続を維持するためのアプリキープアライブを定期的に実行する。なお、アプリキープアライブ実行時には、無線GW51のNAT情報が更新されるため、NATセッションタイマよりも短い周期でアプリキープアライブを行うことにより、アプリサーバ61から端末1へ向かう通信経路を維持することが可能となる。以上の図9~13では、アプリサーバ61が端末1の通信環境情報に応じてアプリキープアライブ間隔を決定するシステム動作フローの例を示したが、NATセッションタイマが短い場合や、無線電波状況の悪い環境においては、アプリキープアライブ処理による端末消費電力が許容値を超えてしまう状況も考えられる。そこで以下では、端末消費電力が許容値を超える場合に、端末1がアプリサーバ61との通信方法を動的に変更するシステム動作フローの例を示す。図14は、端末1がアプリケーションのトランスポートプロトコルをUDPからTCPに変更することにより、キープアライブ間隔を延ばし、消費電力を低減するシステム動作フローを示す。はじめに、端末1は未接続状態にある。ところが、端末1の電源が投入された等の理由により、無線アクセス網50の存在を検知し、無線GW51との接続を確立する。また、端末1はアプリサーバ61からPush型情報配信を受けるために、アプリサーバ61に対して位置登録を行う。アプリサーバ61は図13のステップ424~428と同様の手順を踏み、アプリキープアライブ間隔を決定、その値を端末1に通知する。端末1は、通知されたアプリキープアライブ間隔TNATUDPαに基づいて図7の通信方法決定ルーチン154のステップ173からを実施し、消費電力量の許容値超過を判定する。すなわち、アプリキープアライブ間隔TNATUDPαを用いて式により算出した単位時間あたりの消費電力量の予測値が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値を超えているか否かを判定する。ここで、式により算出した単位時間あたりの消費電力量の予測値が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値を超えている場合には現在の設定がNAT有かつ情報配信方式のトランスポートプトロコルがUDP利用であるため、UDP利用をTCP利用に変更して再度アプリサーバ61へ位置登録を行う。アプリサーバ61は、再度アプリキープアライブ間隔決定ルーチン103を実行してキープアライブ間隔を決定し、その値を端末1へ通知する。ここで一般的なNATでは、コネクション管理を行わないUDPのNATセッションタイマよりも、コネクション管理を行うTCPのNATセッションタイマを長く設定する。このため、TCPへの変更によりキープアライブ間隔が長くなり、消費電力量を閾値未満とすることができる。以降、端末1は待機状態となり定期的にアプリキープアライブを実施するが、その消費電力は比較的低い値に抑えられる。なお、本動作フローのようにUDPからTCPへ変更するのではなく、最初からTCPを用いる方法も考えられるが、コネクション管理を行うTCPは、多数の端末を収容するアプリサーバの処理負荷を向上させる問題がある。そこで、本動作フローのようにUDPが不適切と判断された状況に限り、TCPに切り替えて接続することにより、アプリサーバの処理負荷を最低限に抑えることが可能となる。次に、図15を用いて、端末1が無線アクセス網を再選択する動作フローの例を示す。はじめに、端末1は未接続状態にあり、図14のステップ451~459と同様の処理を実施する。ところが、本ケースでは何らかの理由により、図14で説明したように使用するトランスポートプロトコルをUDPからTCPへ変更してもなお消費電力量が閾値を超過してしまったとする。すなわち、アプリキープアライブ間隔TNATTCPαを用いて式により算出した単位時間あたりの消費電力量の予測値が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値を超えている場合である。ここで端末1は、図7の通信方法決定ルーチン152のステップ177に従い、他の無線アクセス網を使用であるかどうかを再検索する。無線アクセス網30aの使用が可能であるため無線アクセス網30aへの接続を試みる。無線アクセス網30aを収容する無線GW31は、NAT無かつアプリ連携有のため、NAT有かつアプリ連携無の無線GW51よりも、アプリキープアライブ間隔が長く設定される可能性が高い。そのため、最初に無線電波状況がよいと判断して接続した無線GW51よりも、無線GW31のほうが結果的に消費電力を低く抑えることができる。端末1は、実際に無線アクセス網に接続するまでNATの有無やアプリ連携機能の有無等の通信環境を把握できないため、本動作フロー例のように途中で無線アクセス網を再選択することは、より条件のよい無線アクセス網の選択可能性を高める効果がある。次に、図16を用いて、端末1が情報配信方式の通信モードをPush型通信からPull型通信に切り替える動作フローの例を示す。はじめに、端末1は未接続状態にあり、図14のステップ451~459と同様の処理を実施する。ところが、本ケースでは何らかの理由により、使用するトランスポートプロトコルをUDPからTCPへ変更しても単位時間あたりの消費電力量の予測値が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値閾値を超過し、また図15で説明した無線アクセス網の再選択にも失敗したとする。ここで端末1は、図7の通信方法決定ルーチン152のステップ179に従い、情報配信方式の通信モードをPush型からPull型へ変更することを端末1のアプリユーザIDとIPアドレスとともにアプリサーバ61に通知する。この情報は、アプリサーバ61が備えるアプリ接続DB62の通信モードに格納され、アプリサーバ61は端末1へのPush型通知を停止する。そして、端末1は無線電波状況を監視し、比較的電波状況の良い時に限り、アプリサーバ61への情報問合せを行う。このように、端末1が無線電波状況のよいときを見計らって通信を行うことにより、通信効率を向上することができ、ひいては端末1の消費電力を低減することが可能となる。また、情報配信方式の通信モードをPush型をPull型に変更することにより、無線電波状況が悪い時にアプリサーバ61で発生する再送処理負荷を低減することが可能となる。以上、本実施例では、端末が複数の無線システム間を自由に移動する通信システムにおいて、アプリサーバから端末への情報配信方式、およびアプリサーバと端末間のアプリキープアライブ間隔を、端末の通信環境に応じて動的に変更するシステムの構成例を示した。本実施例では、端末とアプリサーバ間にNAT機能が存在する場合には、アプリキープアライブ間隔をNATセッションタイマよりも短い値に設定する。また端末とアプリサーバ間にNAT機能が存在せず、かつ無線接続キープアライブによって無線アクセス網が取得する無線アクセス網の端末接続情報をアプリサーバが取得できる場合には、アプリキープアライブ間隔を無線アクセス網毎に予め定めた最大値に設定する。また端末とアプリサーバ間にNAT機能が存在せず、かつ無線接続キープアライブによって無線アクセス網が取得する無線アクセス網の端末接続情報をアプリサーバが取得できない場合には、アプリキープアライブ間隔を無線アクセス網毎に予め定めた標準値に設定する。以上により、端末とアプリサーバ間の接続性を維持できる範囲内でアプリキープアライブ間隔を短縮し、端末の消費電力量を低減することが可能となる。さらに、このような手順で決定したアプリキープアライブ間隔での端末消費電力量が許容範囲を超える場合には、トランスポート層のプロトコルをUDPからTCPに変換、もしくは無線アクセス網の再選択、もしくは情報配信方式の通信モードををPush型からPull型に変更することにより、端末消費電力とアプリサーバの処理負荷を低減できる効果が得られる。<実施例2>実施例1では、端末自身が直接無線アクセス網に接続するシステムを想定したが、実施例2では、端末がモバイルルータを介して無線アクセス網に接続するシステムを想定する。モバイルルータは、無線アクセス網に接続するWANインタフェースと、端末を収容するLANインタフェースとを備え、WANとLANのトラフィックを相互に中継する装置である。モバイルルータが用いられるシステムにおいては、無線アクセス網と接続するモバイルルータの消費電力低減、無線アクセス網のトラフィック削減が重要な課題となる。そこで、本実施例では、モバイルルータが配下の複数の端末のキープアライブ情報を集約してWANインタフェースに送信することにより、モバイルルータキープアライブメッセージ数を削減し、モバイルルータの消費電力低減、無線アクセス網のトラフィック削減を実現する例を示す。実施例2においては、端末とモバイルルータとの間のとの接続を維持するための端末とモバイルルータとのキープアライブを端末キープアライブと定義する。モバイルルータ1010とキープアライブ中継サーバと接続を維持するための確認をモバイルルータキープアライブと定義する。また、モバイルルータ1010とキープアライブ中継サーバ間のキープアライブ間隔をモバイルルータキープアライブ間隔と定義する。端末1と無線GW21との接続を維持するための端末1と無線GW21とのキープアライブを無線接続キープアライブと、端末1とアプリサーバ61との接続を維持するためのキープアライブをアプリキープアライブと定義する。1システム構成例図19は、実施例2におけるシステム構成例を示す図である。図19において、は端末を示し、は無線アクセス網を示し、1010は端末を収容するLANインタフェースと、無線アクセス網に接続するWANインタフェースとを備えたモバイルルータを示し、1040は無線アクセス網を収容するIPコア網を示し、1041はIPコア網1040に設置されるキープアライブ中継サーバを示し、はIPコア網1040に設置され端末を収容するアプリサーバを示す。ここで、本発明の特徴は、モバイルルータ1010が複数の端末のキープアライブ情報を集約してキープアライブ中継サーバ1041に通知し、キープアライブ中継サーバ1041がその情報を展開してアプリサーバに通知する点である。また、キープアライブ中継サーバ1041は、モバイルルータ1010から通知された端末キープアライブ情報の集約結果を展開するために、キープアライブ中継DB1042を備える。キープアライブ中継DB1042は、例えば、図21aに示すように、モバイルルータID、端末ID、アプリID、端末通信アドレス、状態、アプリサーバ通信アドレス等から構成される。さらに、キープアライブ中継サーバ1041は、アプリサーバに対してキープアライブ処理を実施し、その状態を端末に通知することも可能である。この場合、アプリサーバのキープアライブ状況を管理するためにサーバキープアライブDB1043を保持する。サーバキープアライブDB1043は、例えば図21bに示すようにアプリサーバ通信アドレス、状態等から構成される。2装置構成例と特徴機能次に、図22、図23a、図23bを用いて、モバイルルータ1010の装置構成と特徴機能を説明する。図22は、モバイルルータ1010の装置構成例を示す。本構成例において、モバイルルータ1010のハードウェアは一般的なモバイルルータ装置と同様であり、不揮発性の情報記憶デバイスであるハードディスク10101と、揮発性の情報記憶デバイスであるメモリ10102と、プログラムおよびデータを逐次読み込んで演算を行うCPU10103と、無線アクセス網との通信を中継するアンテナおよびWAN無線信号処理部と、端末との通信を中継するアンテナ10106およびLAN無線信号処理部10107と、各ユニットを接続するバス10108から構成される。また、モバイルルータ1010の機能を実現するプログラムおよびデータは、実行時にメモリ10102に展開され、それらは少なくともNATセッション情報を生成更新削除するNAT管理ルーチン1100と、NATセッション情報を保持するNATDB1012と、端末との間でキープアライブ処理を実施する端末キープアライブルーチン1102と、複数の端末の端末キープアライブ状況を保持する端末キープアライブDB1012と、端末キープアライブ状況の集約結果をキープアライブ中継サーバ1041に通知する端末キープアライブ状況報告ルーチン1101と、キープアライブ中継サーバ1041に対してキープアライブ処理を実施する中継サーバキープアライブルーチン1103とを含む。これらのうち、端末キープアライブルーチン1102、端末キープアライブ状況報告ルーチン1101、端末キープアライブDB1011を備える点が、本発明における特徴である。端末キープアライブDB1011は、例えば図20aのように、端末ID、アプリID、NAT変換前の端末通信アドレスを示すLAN通信アドレス、キープアライブ状態等から構成される。NATDB1012は、例えば図20bに示すように、NAT変換前のプライベートアドレスを示すLAN通信アドレスと、NAT変換後のグローバルアドレスを示すWAN通信アドレス等から構成される。モバイルルータでは、このNATDBに基づいて、NAT変換が行われる。図23aは、端末キープアライブ状況報告ルーチン1101の実装例を示す。本ルーチンは、モバイルルータ1010とキープアライブ中継サーバ1041間のキープアライブパケット交換時、端末キープアライブDB1011の情報更新時、およびNATDB1012の情報更新時に実行される。処理内容は以下の通りである。はじめに、モバイルルータ101は、端末キープアライブDB1011、NATDB1012で保持する情報のうち、前回送信したモバイルルータキープアライブの情報と、現在端末キープアライブ状況として保持している端末キープアライブDB1011、NATDB1の情報との差分を抽出する。そして、モバイルルータ101は、前記抽出した差分の端末キープアライブ情報をキープアライブ中継サーバ1041に通知し、処理を終了する。このように、前回モバイルルータキープアライブを送信した時の端末キープアライブDB1011及びNATDB1012と現時点で保持している端末キープアライブDB1011及びNATDB1012の情報の差分の情報のみを通知することにより、情報量を圧縮し、無線アクセス網のトラフィック削減、モバイルルータ1010の消費電力低減を実現できる。なお、本ルーチンを実施するシステム動作フローの例を後で図24~26を用いて説明する。また、モバイルルータ1010は、無線アクセス網の変更によりWAN側のグローバルアドレスが変化した際に、図23bに示すNAT管理ルーチン1100を実施することにより、端末からアプリサーバへの再位置登録にともなう処理負荷を低減する。すなわち、従来のシステムにおいては、モバイルルータ1010のWAN側グローバルアドレスが変更された際に、モバイルルータ1010のNATDB1012がリセットされるため、モバイルルータ1010配下の端末からアプリサーバに対して再度位置登録を行い、モバイルルータ1010のNATセッション情報を再度生成する必要があった。しかし、本発明のシステムによれば、図23bに示すようにモバイルルータ1010は、変更後のグローバルアドレスを用いてNATDB1012のWAN通信アドレス10122を更新することにより、端末からアプリサーバへの再位置登録を不要としている。なお、本ルーチンを適用したシステム動作フローの例は、後で図28を用いて説明する。3システム動作フロー例次に、図24~28を用いて、実施例2におけるシステム動作フローの例を示す。図24~25は、モバイルルータ1010が無線アクセス網1020に接続した後、さらに端末1001がモバイルルータ1010に接続するシステム動作フローの例を示す。はじめに、端末1001、端末1002、モバイルルータ1010は未接続状態にある。次に、モバイルルータ1010の電源が投入されると、モバイルルータ1010は、最も電波状況の良い無線アクセス網1020に接続され、無線アクセス網1020からグローバルアドレスを付与される。そして、モバイルルータ1010は、無線アクセス網1020の接続を利用してキープアライブ中継サーバ1041に接続し、モバイルルータ1010とキープアライブ中継サーバ間のモバイルルータキープアライブ間隔を決定する。この時点で、モバイルルータ1010の端末キープアライブDB1011にはまだ何も設定されていない。また、キープアライブ中継サーバ1041のキープアライブ中継DB1042にはモバイルルータIDのみが設定されている。なお、モバイルルータキープアライブ間隔の決定方法の詳細はここでは述べないが、例えば、実施例1で示したアプリキープアライブ間隔の決定アルゴリズムが使用できる。その場合、モバイルルータ1010の通信環境に応じて、接続性を維持できる範囲でモバイルルータキープアライブ間隔をできるだけ長く設定するため、消費電力低減、ネットワーク負荷低減に貢献することが可能となる。以上により、モバイルルータ1010の接続処理が完了し、以降、定期的にモバイルルータキープアライブが実施される。モバイルルータキープアライブには、モバイルルータ1010が保持する端末キープアライブDB1011に格納されている情報のうち、前回モバイルルータキープアライブを送信した時の情報と現時点で保持している情報との差分の情報が含まれる。モバイルルータキープアライブで通知された情報は、キープアライブ中継サーバ1041のキープアライブ中継DB1042に格納される。次に、端末1001の電源が投入され、端末1001は、モバイルルータ1010に対して接続し、プライベートアドレスの割当てを受ける。そして、端末1001はモバイルルータ1010に対して端末キープアライブ要求を送信する。端末キープアライブ要求には、端末1001とモバイルルータ1010との間のキープアライブ間隔を示す端末キープアライブ間隔、端末キープアライブ対象となるアプリケーションのID、該アプリケーションが使用する通信アドレス等が含まれる。モバイルルータ1010は、端末キープアライブ要求を受信すると、該情報を端末キープアライブDB1011に格納し、さらに各アプリケーションの通信アドレスに対応するNATセッション情報を生成し、生成したNATセッション情報をNATDB1012に設定する。モバイルルータでは、このNATDNに基づいて、NAT変換が行われる。図24の説明においでは、プライベートアドレスと、グローバルアドレスとのNAT変換が行われる。また、これらのアドレスに対応するポート番号も変換される。また、モバイルルータ1010は、端末1001が新規に接続されたことをキープアライブ中継サーバ1041に通知し、キープアライブ中継サーバ1041は、ステップ1211で通知された情報をキープアライブ中継DB1042に格納する。さらに、モバイルルータ1010は、端末1001に応答を返信し、キープアライブ中継サーバ1041のアドレスを通知する。次に、端末1001は、アプリサーバ1044、1045に対して位置登録を行う。位置登録要求にはキープアライブ中継サーバ1041とモバイルルータ1010のIDが含まれている。アプリサーバは、位置登録要求で通知された情報を使用して、キープアライブ中継サーバ1041にモバイルルータキープアライブ状況を問い合わせる。この例では、モバイルルータキープアライブで通知された端末1001の情報が事前にキープアライブ中継サーバ1041に通知されているので、問い合わせに成功し、キープアライブ中継サーバ1041とアプリサーバ間のサーバキープアライブ間隔が通知される。サーバキープアライブ間隔は、アプリサーバとキープアライブ中継サーバ1041の負荷を上げない程度に長く、またサービスレベルを低下させない程度に短く設定される。次に、アプリサーバは、端末1001との間で実施するアプリキープアライブ間隔を決定し、端末1001に応答を返信する。なお、本実施例では、アプリキープアライブを非常に長く設定し、キープアライブメッセージを中継するモバイルルータ1010の負荷を低減する点に特徴がある。以上で端末1001の接続処理が終了し、以降、端末1001とモバイルルータ1010間の端末キープアライブ、モバイルルータ1010とキープアライブ中継サーバ1041間のモバイルルータキープアライブ、キープアライブ中継サーバ1041とアプリサーバ間のサーバキープアライブ、端末1001とアプリサーバ間のアプリキープアライブが定期的に実施されるようになる。なお、図24~25では端末1001の接続フローについて示したが、端末1002についても同様の手順が適用される。次に、図26を用いて端末1が圏外移動するシステム動作フローの例を示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバに接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している。ところが、端末1001の移動により、端末1001とモバイルルータ1010間の通信が切断される。モバイルルータ1010は、端末キープアライブに失敗することによって端末1001の圏外移動を検出し、端末キープアライブDB1011、NATDB1012の中から端末1001に関する情報を削除する。そして、キープアライブ中継サーバ1041に対して端末キープアライブ状況更新を送信し、端末1001の離脱を通知する図23aの端末キーピアライブ状況報告ルーチンによって計算された差分をモバイルキープアライブによって通知する。キープアライブ中継サーバ1041は、端末1001の情報をキープアライブ中継DB1042から検索し、端末1001が接続している端末ID10422に対応するアプリサーバID10423を特定し、該アプリサーバIDに対応するアプリサーバに対して端末1001の離脱通知を送信する。アプリサーバは、端末1001の位置登録情報を削除し、応答を返信する。キープアライブ中継サーバ1041は、モバイルルータ1010に応答を返信する。以降、キープアライブ中継DB1042のアプリサーバ通信アドレス10426に基づいてキープアライブ中継サーバ1041主導で実施されるサーバキープアライブ、端末キープアライブDB1011に基づいてモバイルルータ1010主導で実施される端末キープアライブ端末とアプリサーバ間の接続状態に基づいて端末主導で実施されるアプリキープアライブは実施されず、モバイルルータキープアライブのみが実施されるようになる。以上のように、モバイルルータ1010が端末1001の端末キープアライブ状況の変化をキープアライブ中継サーバ1041に通知することにより、端末1001とアプリサーバ間のアプリキープアライブ間隔を長く設定しても、アプリサーバが端末1001の状態を正しく把握できるようになる。次に、図27を用いてアプリサーバ1044が再起動するシステム動作フローの例を示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバに接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している。ところが、アプリサーバ1044に異常が発生し、アプリサーバ1044の再起動処理が行われる。キープアライブ中継サーバ1041は、サーバキープアライブによりアプリサーバ1044の再起動を検出し、モバイルルータ1010経由で端末1001にアプリサーバ1044が再起動したことを通知する。端末1001は、アプリサーバ1044の再起動通知を受けると、アプリサーバ1044に対して再位置登録を実施する。これにより、アプリサーバ1044に端末1001の位置情報が再登録される。続いてキープアライブ中継サーバ1041とアプリサーバ1044間の接続確立、端末1001へのアプリキープアライブ間隔通知が行われ、最初の定常状態に復帰する。以上のように、キープアライブ中継サーバ1041がアプリサーバ1044のサーバキープアライブ状況の変化をモバイルルータ1010と端末1001に通知することにより、端末1001とアプリサーバ1044間のアプリキープアライブ間隔を長く設定しても、端末1001がアプリサーバ1044の異常を早期検知し、迅速に定常状態に復帰することが可能となる。次に、モバイルルータ1010が無線アクセス網を切り替えたことにより、グローバルアドレスが変更されるシステム動作フローの例を、図28を用いて示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバに接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している。ところが、無線電波状況が変化した等の理由により、モバイルルータ1010は、無線アクセス網1020との接続を切断し、無線アクセス網1030との接続を新規に確立する。この際に、無線アクセス網1030は、モバイルルータ1010に、無線アクセス網1020が割り当てたグローバルアドレスとは異なるグローバルアドレスを割り当てる。次に、モバイルルータ1010は、無線アクセス網1030との接続を利用して、キープアライブ中継サーバ1041との接続を再確立し、モバイルルータキープアライブ間隔を再決定する。そして、モバイルルータ1010は、図23bのNAT管理ルーチン1100に従い、新しく割り当てられたグローバルアドレスを用いてLAN通信アドレスがプライベートアドレスIPP1に対するNATDB1012のWAN通信アドレスを、無線アクセス網1020が割り当てたグローバルアドレスから新しく割り当てられたグローバルアドレスに更新する。モバイルルータ1010は、ここで、LAN通信アドレスプライベートアドレスIPP1及びこれに対応するポート番号に対して、新しく割り当てられたグローバルアドレス及びこれに対応するポート番号の組み合わせを生成する。また、キープアライブ中継サーバ1041に端末キープアライブ状況更新を送信し、WAN通信アドレスの変化変更後のIPアドレス、ポート番号などを通知する。キープアライブ中継サーバ1041は、アプリサーバに対して通信アドレス変更を通知する。アプリサーバは端末位置情報を更新、応答を返信する。キープアライブ中継サーバ1041は、モバイルルータ1010に応答を返信し、以降、定常状態に復帰する。以上のように、モバイルルータ1010は、グローバルアドレスの変更時にNAT情報を更新し、その情報をキープアライブ中継サーバ1041経由でアプリサーバに通知することにより、端末とアプリサーバ間の再位置登録を実施することなく、サービスを継続することが可能となる。図28の動作フローでは端末1001の一台のみがモバイルルータに接続している状況を想定したが、モバイルルータ1010が収容する端末台数が多いほど、本処理の効果は大きくなる。なぜならば、従来技術に従い、グローバルアドレス変更時に端末からアプリサーバへの再位置登録を実施したとすると、無線アクセス網を通過するメッセージ数はM×N×2となる。しかし、図28の動作フローのようにモバイルルータ1010が各端末の代理でアドレス変更を通知した場合、無線アクセス網を通過するメッセージ数は端末台数やアプリサーバ台数によらず2となるためである。特に、携帯電話網のように消費電力の大きい無線アクセス網の場合、メッセージ数の削減には大きな効果が見込まれる。