説明

端末キープアライブ方式、及びキープアライブ間隔決定方法

【課題】 サーバと無線端末間のキープアライブ処理において、端末消費電力削減、ネットワーク負荷低減と障害検出時間短縮を両立する(第一の課題)。また、端末移動に伴う通信環境の変化に応じて、最適なキープアライブ間隔を決定する(第二の課題)。
【解決手段】 無線アクセス網と端末間のキープアライブにより検出した端末状態を、無線アクセス網からサーバに通知することにより、サーバと端末間のキープアライブを省略する。また、上記第二の課題を解決するために、本発明は、端末とサーバの連携により通信環境を動的に検出する手段を備え、前記検出結果に基づいてキープアライブ間隔を変更することを特徴とする。

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、端末とサーバ間のキープアライブ技術に関し、特に端末、サーバとアクセス網の連携により効率的にキープアライブを行う技術、および端末の移動に伴う通信環境の変化に応じてキープアライブ間隔を調整する技術に関する。
【背景技術】
【0002】
近年、FTTH(Fiber to the Home)をはじめとする固定アクセス網に急速に普及したIP電話システムにおいては、端末とサーバ間の接続性維持、確認のために、比較的高い頻度で端末とサーバ間のキープアライブ処理を実施する。例えば、IP電話の呼制御にSIP (Session Initiation Protocol)(非特許文献1)を使用する場合、端末とサーバ間のキープアライブ処理はデフォルトで3600秒毎に行われる。また、NAT (Network Address Translation)やファイアウォールが存在するシステムでは、NATやファイアウォールのセッション情報を維持するため数十秒〜数分毎に端末とサーバ間のキープアライブ処理を実施する場合もある。これは、一般的なNAT/ファイアウォール装置において、一定時間通信が行われない場合は該当するセッション情報を削除し、サーバから端末への通信を禁止するためである。端末とサーバ間のキープアライブ間隔は基本的に実装依存とされているが、固定網においては端末とサーバの設置環境に応じて、接続性を維持するために十分に小さい値に設定されている。
【0003】
一方、携帯電話をはじめとするセルラ系の無線アクセス網においては、これまで音声データの通信品質保証が困難であったためIP電話の導入は見送られてきた。しかし、2010年以降に開始される3.9G移動通信方式LTE (Long Term Evolution)では、通信速度向上、QoS(Quality of Service)機能の導入により、IP電話を実用化できる見通しである。また将来的には、端末が固定網、異種無線網間をシームレスに移動するようになり、複数のアクセス網を共通のIP電話コア網を用いて収容するFMC (Fixed Mobile Convergence)(非特許文献2)の構想もある。
【先行技術文献】
【非特許文献】
【0004】
【非特許文献1】IETF RFC 3261 “SIP: Session Initiation Protocol”, Jun. 2002.
【非特許文献2】Jeong-Je Cho, Jin-Ho Hwang, Nak-Po Kim, ”Novel FMC network composition methods in 3W(WiBro, WiFi and WCDMA) environments”, IEEE Advanced Communication Technology (ICACT) 12th Internationa Conference, Feb. 2010, Volume 1. pp.855 - 858.
【発明の概要】
【発明が解決しようとする課題】
【0005】
無線環境では、多くの場合、端末バッテリー容量や通信リソースに制限がある。そのため無線網にIP電話システムを導入する際に、端末とサーバ間のキープアライブ間隔を、固定網と同じく数分〜数時間単位に設定すると、端末やネットワークに過度な負荷をかける可能性がある。特に、携帯電話のようにエリアが広く、端末バッテリー容量の小さいシステムではこの影響が顕著に出ると想定される。しかしながら、この問題を解決するために、キープアライブ間隔を延長すると、障害検出に時間がかかってしまい、サービス品質が低下する。そこで、障害を検出するまでの時間を長くすることなく、端末の消費電力低減、ネットワークの負荷低減を実現するキープアライブ方法の実現が課題となる(第一の課題)。
【0006】
また、現在の技術によれば、端末やサーバの設置環境に応じてキープアライブ間隔を固定的に設定している。しかし、今後FMCが実現すると端末の移動の度に通信環境が変化するようになる。そこで、各通信環境に適したキープアライブ間隔を、動的に検出、設定することが課題となる(第二の課題)。
【課題を解決するための手段】
【0007】
上記第一の課題を解決するために、無線アクセス網と端末間のキープアライブにより検出した端末状態を、無線アクセス網からサーバに通知することにより、サーバと端末間のキープアライブを省略する。
【0008】
また、上記第二の課題を解決するために、本発明は、端末とサーバの連携により通信環境を動的に検出する手段を備え、前記検出結果に基づいてキープアライブ間隔を変更することを特徴とする。
【発明の効果】
【0009】
本発明によれば、端末消費電力低減と障害検出時間短縮を両立する効率的な端末とサーバ間のキープアライブが可能となる。
また端末が異種アクセス網間を移動する場合にも、各環境に応じた最適な端末とサーバ間のキープアライブ間隔の設定が可能となる。
【図面の簡単な説明】
【0010】
【図1】実施例1のシステム構成例。
【図2a】アプリサーバ61が備えるアプリ接続管理DB62の構成例。
【図2b】無線GW21が備える無線接続DB22の構成例。
【図3】マッピングサーバ63が備えるマッピングDB64の構成例。
【図4】アプリサーバ61の装置構成例。
【図5】アプリサーバ61が備えるアプリキープアライブ間隔決定ルーチン103の構成例。
【図6】端末1の装置構成例。
【図7】端末1が備える情報取得方式決定ルーチン152の構成例。
【図8】端末1における無線電波強度の判定方法例を示す図。
【図9】端末1が無線GW21に接続するシステム動作フロー例。
【図10】無線GW21に接続中の端末1が圏外移動するシステム動作フロー例。
【図11】端末1が無線GW21から無線GW31に移動するシステム動作フロー例。
【図12】端末1が無線GW31から無線GW41に移動するシステム動作フロー例。
【図13】端末1が無線GW41から無線GW51に移動するシステム動作フロー例。
【図14】端末1がUDPをTCPに変更するシステム動作フロー例。
【図15】端末1が無線アクセス網を再選択するシステム動作フロー例。
【図16】端末1がPush型通信からPull型通信に変更するシステム動作フロー例。
【図17】LTEにおける図9のシステム動作フローの実装例。
【図18】アプリサーバ1が異常発生により再起動するシステム動作フロー例。
【図19】実施例2のシステム構成例。
【図20a】モバイルルータ1010における端末キープアライブDB1011の構成例。
【図20b】モバイルルータ1010におけるNAT DB1012の構成例。
【図21a】キープアライブ中継サーバ1041におけるキープアライブ中継DB1042の構成例。
【図21b】キープアライブ中継サーバ1041におけるサーバキープアライブDB1043の構成例。
【図22】モバイルルータ1010の装置構成例。
【図23a】モバイルルータ1010が備える端末キープアライブ状況報告ルーチン1101の構成例。
【図23b】モバイルルータ1010が備えるNAT DB管理ルーチン1100の構成例。
【図24】モバイルルータ1010が無線アクセス網1020に接続し、端末1001がモバイルルータ1010に接続するシステム動作フロー例1。
【図25】モバイルルータ1010が無線アクセス網1020に接続し、端末1001がモバイルルータ1010に接続するシステム動作フロー例2。
【図26】端末1001が圏外移動するシステム動作フロー例。
【図27】アプリサーバ1044が再起動するシステム動作フロー例。
【図28】無線アクセス網の切替えによりモバイルルータ1010のグローバルアドレスが変更されるシステム動作フロー例。
【発明を実施するための形態】
【0011】
以下、図面を用いて本発明の実施例を説明する。
【0012】
<実施例1>
実施例1では、複数の無線システムと、前記複数の無線システムに接続可能な端末と、前記端末を収容するアプリサーバ(例えば、SIPサーバ)とから構成される通信システムにおいて、前記アプリサーバと前記端末間のアプリキープアライブ間隔を、端末の通信環境に応じて動的に変更する例を示す。また、アプリサーバが無線アクセス網から端末接続情報を取得できる場合には、その情報を利用してアプリケーション上のアプリキープアライブ間隔を長く設定する例を示す。 尚、実施例1では、端末1と無線GW21との接続を維持するための端末1と無線GW21とのキープアライブを「無線接続キープアライブ」と、端末1とアプリサーバ61との接続を維持するためのキープアライブを「アプリキープアライブ」と定義する。
【0013】
1.システム構成例
図1は、実施例1におけるシステム構成例を示す図である。図1において、1は複数の無線インタフェースを備えた端末を示し、(20、30a、30b、40、50)は端末1と通信可能な無線アクセス網を示し、(21、31、41、51)は無線アクセス網(20、30a、30b、40、50)に設置される無線GW (Gateway)を示し、(22、32、42、52)は無線GW(21、31、41、51)が保持する無線接続DB (Data Base)を示し、60は無線アクセス網(20、30a、30b、40、50)を収容するIPコア網を示し、61はIPコア網60に接続されるアプリサーバを示し、62はアプリサーバ61が保持するアプリ接続DBを示し、63はアプリサーバ61と無線GW(21、31、41、51)間の通信を中継するマッピングサーバを示し、64はマッピングサーバ63が保持するマッピングDBを示す。
【0014】
ここで図1のシステムにおける無線アクセス網(20、30a、30b、40、50)は、無線GW(21、31、41、51)の機能に応じて、”NAT有無”および”アプリ連携有無”の観点から計4種類に分類される。”NAT無”の無線アクセス網では、端末にグローバルアドレスを付与するが、”NAT有”の無線アクセス網では、端末にプライベートアドレスを付与し無線GWにおいてプライベートアドレスとグローバルアドレスの相互変換を行う。NAT機能を有する無線GW21はNATセッション毎にNATセッションタイマが設定できる。また”アプリ連携有”の無線アクセス網では、マッピングサーバを介して、無線アクセス網からサーバへの端末接続情報通知、サーバからの無線アクセス網のへのNAT制御を行うが、”アプリ連携無”の無線アクセス網では、無線GWがそのような通信インタフェースを備えないとする。
【0015】
無線GW(21、31、41、51)が保持する無線接続DB(22、32、42、52)は、無線アクセス網(20、30a、30b、40、50)における端末接続状況を管理する目的で使用される。例えば図2bに示すように、無線接続DB32は、無線アクセス網におけるユーザIDを示す無線ユーザID32-1、無線アクセス網(30a、30b)への接続状態を示す無線接続状態32-2、無線アクセス網(30a、30b)から端末に割当てたIPアドレスを示す割当てアドレス32-3等から構成される。
【0016】
マッピングサーバ63が保持するマッピングDB64は、アプリ接続DB62と、”アプリ連携機能”を有する無線接続DB(22、32)との対応関係を管理する目的で使用される。例えば図3に示すように、マッピングDB64は、アプリケーション上のユーザIDを示すアプリユーザID64-1、アプリユーザID64-1のユーザが無線アクセス網(20、30a、30b)との接続に使用する無線ユーザID64-2、無線ユーザID64-2における接続状態を示す無線接続状態64-3、無線アクセス網(20、30a、30b)から割り当てられたIPアドレスを示す割当てアドレス64-4等から構成される。
【0017】
以上で示した図1のシステムを、携帯電話網の標準化団体3GPP(3rd Generation Partnership Project)のシステム(詳細は3GPP TS 23.402を参照)に当てはめると、無線アクセス網(20、30a、30b、40、50)はLTE、CDMA2000、WiMAX、無線LAN等の各種無線アクセス網に相当し、無線GW(21、31、41、51)はLTEのPDN-GW(Packet Data Network - Gateway)や、CDMA2000のPDSN (Packet Data Serving Node)やHA (Home Agent)、WiMAXのCSN(Connectivity Service Network)-GW、無線LANのWAG (WLAN Access Gateway)等に相当し、マッピングサーバ63はPCRF (Policy and Charging Rules Function)に相当し、アプリサーバ61はAF (Application Function)に相当する。しかし、本発明はこれに限定されず、3GPPに準拠しないシステムに対しても適用可能である。
【0018】
2. 装置構成例と特徴機能
次に、図4〜7を用いて、本発明の特長となるアプリサーバ61と端末1の機能について説明する。
【0019】
図4は、アプリサーバ61の装置構成例を示す。本構成例において、アプリサーバ61のハードウェアは一般的なサーバ装置と同様であり、不揮発性の情報記憶デバイスであるハードディスク61-1と、揮発性の情報記憶デバイスであるメモリ61-2と、プログラムおよびデータを逐次読み込んで演算を行うCPU (Central Processing Unit)61-3と、外部装置との通信を中継するNIC (Network Interface Card)61-4と、各ユニットを接続するバス61-5から構成される。
【0020】
また、アプリサーバ61の機能を実現するプログラムおよびデータは、実行時にメモリ61-2に展開され、それらは少なくともアプリケーション特有の処理を行うアプリ処理ルーチン100と、端末との通信状況を管理するアプリ接続DB62と、経路上のNAT有無を判定するNAT有無判定ルーチン101と、無線アクセス網からの端末接続状態の取得可否、NAT制御可否を判定するアプリ連携有無判定ルーチン102と、NAT有無判定ルーチン101およびアプリ連携有無判定ルーチン102の判定結果に基づき端末のアプリキープアライブ間隔を決定するキープアライブ間隔決定ルーチン103と、アプリ連携有の場合に無線アクセス網から端末接続状態を取得する無線接続状態取得ルーチン104と、を含む。これらのうち、NAT有無判定ルーチン101、アプリ連携有無判定ルーチン102、アプリキープアライブ間隔決定ルーチン103を備える点が、本発明における特徴である。 アプリ接続DB62は、端末1との通信状況を管理する目的で用いられ、例えば図2aのようにアプリケーション上のユーザIDを示すアプリユーザID62-1、端末の通信モード(Push/Pull)を示すアプリ通信モード62-2、アプリ通信モード62-2がPushである場合にアプリサーバ61への接続状態を示すアプリ接続状態62-3、端末がアプリサーバ61からの制御信号を受け付けるIPアドレス、トランスポートプロトコル、ポート番号を示すアプリ通信アドレス62-4、アプリ接続状態62-3の取得方法を示すアプリ接続状態取得方法62-5等から構成される。アプリサーバ61は、アプリ接続DB62の通信モード62-2が”Push”である端末に対して定期的にアプリキープアライブを実施する。一方、図2aのユーザC(userC@appserver)のように通信モード62-2に”Pull”が設定されている場合には、電波状況の良いときに端末主導で情報をPullするため、アプリサーバ61側での端末1の状態管理や、端末1とアプリサーバ61間のアプリキープアライブは不要となる。。
【0021】
NAT有無判定ルーチン101は、前述した通り、STUN等のNAT検出プロトコルを用いてもよいし、アプリケーションプロトコルがSIPである場合には、端末1から受信したSIPパケットにおいて、IPヘッダの送信元IPアドレスと、SIPヘッダ上のContactアドレスを比較することにより判定してもよい。ここでIPヘッダとSIP Contactアドレスの比較によりNATの存在が検知できる理由は、NATが存在する場合、端末1はIPヘッダとSIP Contactアドレスの双方に無線GWから割り当てられたプライベートアドレスを設定するが、途中の無線GWにてIPヘッダのアドレスのみがグローバルアドレスに変換されるためである。そこで、IPヘッダとSIP Contactアドレスの値は一致する場合は”NAT無し”、異なる場合は”NAT有り”と判定できる。 アプリ連携有無判定ルーチン104は、該アプリサーバに接続している端末1のアプリユーザID等をキーとして、マッピングサーバに端末1が接続している無線アクセス網のアプリ連携有無を問い合わせる。また、マッピングサーバ63から、該問い合わせに対するアプリ連携有無の判定結果を受信する。これにより、端末1が接続している無線アクセス網のアプリ連携機能の有無を判定することができる。後で図9を用いて詳細を説明するが、本システムにおいては、無線GWがアプリ連携機能を備える場合、端末1が無線GWに接続した際に、無線GWからマッピングサーバ63に該無線GWと接続している端末1の端末接続状態の通知を行うため、マッピングサーバ63は該端末接続状態を検索することにより、端末1が接続している無線アクセス網のアプリ連携有無を判定し、端末1が接続している無線アクセス網のアプリ連携有無をアプリサーバ61に通知できる。
【0022】
アプリキープアライブ間隔決定ルーチン103のアルゴリズムは、例えば図5のフローチャートで表わされる。本ルーチンでは、NAT有無判定ルーチン101とアプリ連携有無判定ルーチン102の判定結果に基づき条件分岐を行う(ステップ121、122、127)。
【0023】
まずステップ121と122において、NAT有無判定ルーチン101で”NAT有”かつ” アプリ連携有無判定ルーチン104でアプリ連携有”と判定された場合には、アプリサーバ61は、図1のマッピングサーバ63経由で無線GW21に当該アプリキープアライブ通信用のNATセッションタイマを最大値(T_NAT_MAX)に設定するよう指示を出す(ステップ123)。具体的には、端末1がアプリキープアライブに使用するIPアドレスとポート番号(図2aのアプリ制御アドレス62-4にて管理する)に基づいてNATセッションを生成し、そのNATセッションタイマを最大値(T_NAT_MAX)に設定する旨の指示を行う。さらにアプリサーバ61は、その設定値(T_NAT_MAX)から予め定めたオフセット値(α)を差し引いた値を該端末のアプリキープアライブ間隔とする(ステップ124)。このように、NATセッションタイマの最大値(T_NAT_MAX)からオフセット値(α)を差し引いた値をアプリキープアライブ間隔とすることにより、各装置のタイマ精度の違いからNATセッションタイマとアプリキープアライブタイマにずれが生じるような環境においても、NATセッションタイマが満了する前にアプリキープアライブを実施することができ、NATセッションタイマを維持できる。
【0024】
ここで本システムにおいては、無線GW21がアプリサーバ61からの指示に基づいてNATセッション毎に異なる値のタイマを設定できると仮定している。通常のNAT装置は、装置自身の基準に基づきNATセッションタイマの値を決定するが、本願発明では、ここで述べたように無線GW21が外部装置であるアプリサーバ61からの指示に基づき特定のNATセッションのタイマを延長可能とする。これにより、アプリキープアライブ間隔を長く設定することができ、ひいては端末1およびアプリサーバ61の処理負荷を低減することが可能となる。なお、”NAT有”かつ”アプリ連携有”の場合のシステム動作フローは後で図9と図10を用いて説明する。
【0025】
次に図5のステップ121と122において、”NAT有”かつ”アプリ連携無”と判定された場合には、アプリサーバ61は、NATセッションタイマの値(T_NAT)を取得し(ステップ125)、その値(T_NAT)から予め定めたオフセット値(α)を差し引いた値を該端末のアプリキープアライブ間隔とする(ステップ126)。ステップ125において、アプリサーバ61は、NATセッションタイマの値(T_NAT)を取得するために、予め調査したNATセッションタイマの値を無線アクセス網や無線GW毎にテーブルとして管理してもよいし、もしくは前述のSTUNやUPnP (Universal Plug and Play)等のプロトコルを用いて端末1と連携しながら動的にNATセッションタイマの値を取得してもよい。いずれの手段を用いるにせよ、NATセッションタイマの値を取得し、該端末のアプリキープアライブ間隔を該NATセッションのNATセッションタイマよりも短く設定することにより、端末1とアプリサーバ61間の接続性を維持することが可能となる。なお、”NAT有”かつ”アプリ連携無”の場合のシステム動作フローは後で図13を用いて説明する。
【0026】
また図5のステップ121と127において、”NAT無”かつ”アプリ連携有”と判定された場合には、アプリサーバ61は、アプリキープアライブ間隔を該無線アクセス網毎に定められているアプリキープアライブ間隔の最大値(T_MAX)に設定するか、もしくはアプリキープアライブを実施しないことを決定する(ステップ128)。ここで、アプリキープアライブの最大値(T_MAX)とは、該端末内でアプリケーションが正常に稼働しているか否かを確認する時間間隔であり、アプリケーションの安定性や、ユーザのアプリケーション操作の頻度等を考慮して定めるものとする。本ケースにおいては、アプリサーバ61は、無線GWの備える図2bの無線接続DB32の情報を定期的に確認することにより、仮想的にアプリキープアライブを行っていると見なし、実際に端末1とアプリサーバ61間で行うアプリキープアライブの間隔を長く設定している。これにより、障害検出までの時間を長くせずとも、端末1が送受信するパケット数を減らすことができ、端末消費電力を低減することが可能となる。また一方で、無線アクセス網毎に定められているアプリキープアライブ間隔の最大値(T_MAX)でアプリキープアライブを実施することにより、該端末1内でアプリケーションが正常に稼働していることを定期的に確認できる効果がある。なお、”NAT無”かつ”アプリ連携有” の場合のシステム動作フローは後で図11を用いて説明する。
【0027】
また図5のステップ121と127において、”NAT無”かつ”アプリ連携無”と判定された場合には、アプリキープアライブ間隔を、無線アクセス網毎に定められているアプリキープアライブ間隔の標準値(T_STD)に設定する(ステップ129)。このように無線アクセス網毎にアプリキープアライブ間隔の標準値を定めることにより、基地局のエリアの広さ等を考慮して適切な頻度でIP接続性の確認を目的としたアプリキープアライブを行うことが可能となる。なお、”NAT無”かつ”アプリ連携無” の場合のシステム動作フローは後で図12を用いて説明する。
【0028】
次に、図6を用いて端末1の装置構成例を示す。本構成例において、端末1のハードウェアは一般的な無線端末と同様であり、不揮発性の情報記憶デバイスであるハードディスク1-1と、揮発性の情報記憶デバイスであるメモリ1-2と、プログラムおよびデータを逐次読み込んで演算を行うCPU 1-3と、無線電波の送受信を行うアンテナ1-4(a〜d)と、アンテナ1-4(a〜d)の無線信号に対してアナログ-デジタル変換や変復調等を行う無線信号処理部1-5(a〜d)と、各ユニットを接続するバス1-6から構成される。
【0029】
また、端末1の機能を実現するプログラムおよびデータの一部は、実行時にメモリ1-2に展開され、それらは少なくともアプリケーション特有の処理を行うアプリ処理ルーチン150と、アプリサーバ61と通信しアプリキープアライブ間隔を決定するアプリキープアライブ間隔交渉ルーチン151と、アンテナ1-4(a〜d)および無線信号処理部1-5(a〜d)を制御する無線制御ルーチン156と、アンテナ1-4(a〜d)および無線信号処理部1-5(a〜d)より無線電波状況を取得し、それらの統計情報を算出する無線電波状況監視ルーチン155と、アプリキープアライブ間隔交渉ルーチン151が決定したアプリキープアライブ間隔、および無線電波状況監視ルーチン155が算出した統計情報に基づき、アプリキープアライブ処理に伴う消費電力量の予測値を算出する消費電力量予測ルーチン153と、消費電力量予測ルーチン153の結果に基づきアプリサーバ61との通信方法を決定する通信方法決定ルーチン154を含む。これらのうち、通信方法決定ルーチン154を備える点が、本発明における特徴の一つである。
【0030】
図7は、端末1における通信方法決定ルーチン154の実装例を示す。本ルーチンでは、まず端末の移動速度や、各無線システムのエリアの広さ、無線電波状況監視ルーチン155によって算出した無線電波状況等を考慮し、最適と思われる無線アクセス網を1つ選択する(ステップ171)。そして、前記選択した無線アクセス網を用いてアプリサーバ61と通信を行い、システムのデフォルトの情報配信方式 (ここではUDP利用、Push型とする)におけるアプリキープアライブ間隔(T_KA)をアプリキープアライブ間隔交渉ルーチン151において決定する(ステップ172)。さらに、決定したアプリキープアライブ間隔(T_KA)と無線電波状況監視ルーチン155によって算出した無線電波状況(RSSI)とに基づき、消費電力量予測ルーチン153を用いてアプリキープアライブ処理に伴う単位時間当たりの消費電力量の予測値(W_EXP)を計算する(ステップ173)。単位時間当たりの消費電力量の予測式は、例えば以下の(1)式のように近似できる。
【0031】
T_EXP = C / T_KA * S(RSSI) ・・・(1)
ここで、Cは無線アクセス網毎に異なる定数、T_KAはアプリキープアライブ間隔、RSSIは無線電波状況、S(RSSI)は無線電波状況がRSSIである場合に単位データ量の送受信につき消費される電力量である。
【0032】
(1)式により算出した単位時間あたりの消費電力量の予測値(W_EXP)が予め無線アクセス網毎に定めた単位時間あたりの消費電力量の閾値(W_MAX)よりも小さい場合には、情報配信方式が適切であると判断し、そのまま処理を終了する(ステップ174)。一方、(1)式により算出した単位時間あたりの消費電力量の予測値(W_EXP)が、無線アクセス網毎に定めた単位時間あたりの消費電力量の閾値(W_MAX)よりも大きい場合には、以下の手順で情報配信方式の変更を行う。
【0033】
まず、ステップ171で選択した無線アクセス網の無線GWが”NAT有”かつ情報配信方式が”UDP利用”である場合には(ステップ175)、”UDP利用”を”TCP利用”に変更し(ステップ176)、再度キープアライブ間隔の交渉(ステップ172)のステップから実施する。一般的なNAT装置においては、コネクション管理を行わないUDPと比較して、コネクション管理を行うTCPのほうが、NATセッションタイマがより長く設定される。このため、ステップ172において情報配信方式のトランスポートプロトコルを”UDP利用”から”TCP利用”に変更することにより、アプリキープアライブ間隔を長くすることができ、結果として端末消費電力を削減できる効果が見込まれる。このように情報配信方式のトランスポートプロトコルを”UDP利用”から”TCP利用”に変更することによって、アプリキープアライブ間隔を長く設定するシステム動作フローは図14を用いて説明する。
【0034】
また、ステップ175において、”NAT無”または”UDP以外を利用”である場合には、無線信号処理部1-5(a〜d)より取得した無線電波状況等に基づいて他の無線アクセス網を利用可能であるかを確認し(ステップ177)、利用可能である場合には、接続する無線アクセス網をステップ171で選択した無線アクセス網からステップ177で選択した他の無線アクセス網に変更して(ステップ178)、再度アプリキープアライブ間隔の交渉(ステップ172)のステップから実施する。ステップ171の時点では、当該無線アクセス網におけるNATの有無や、アプリ連携機能の有無等の通信環境が必ずしも把握できていないため、ステップ178において、接続する無線アクセス網をステップ171で選択した無線アクセス網からステップ177で選択した他の無線アクセス網に変更することにより、より条件のよい、すなわち消費電力量がより少ない無線アクセス網を選択できる。なお、端末1は、一度接続した無線アクセス網のNAT有無やアプリ連携有無等のパラメータを記憶し、次回以降の無線アクセス網選択に利用してもよい。これにより、端末1が最適な無線アクセス網を選択するまでの時間を短縮できる効果が見込まれる。なお、無線アクセス網の再選択によりアプリキープアライブ間隔を延長するシステム動作フローは図15を用いて説明する。
【0035】
また、ステップ177において他の無線アクセス網を利用できない場合には、情報配信方式の通信モードをPush型通信からPull型通信に変更し(ステップ179)、処理を終了する。Push型通信は、情報の即時配信に向いている反面、無線電波状況と無関係にデータが送受信されるため、電波状況が悪い時には通信効率の低下、およびアプリサーバ61におけるパケット再送負荷が発生する。そこで電波状況が悪く消費電力量の増加が見込まれる場合には、一時的にPull型に切り替えることにより、これらの弊害を回避することができる。
【0036】
例えば、図6の無線電波状況監視ルーチン155において、無線電波状況を監視し、その瞬間の無線電波状況が比較的良いと判断した際に、アプリ処理ルーチン150に通知し、アプリ処理ルーチン150はその通知を契機としてアプリサーバ61から情報をPullする構成が考えられる。ここで無線電波状況監視ルーチン155において、無線電波状況が良いか否かを判定する方法としては、例えば図8(a)に示すような無線電波強度の推移に基づき、図8(b)の短期統計値(無線電波強度の0.7分位点であるS_07)と、図8(c)の短期統計値の変動予測ΔSを算出し、現時点での無線電波強度SがS_07とΔSの和よりも大きければ、無線電波状況が良好であると判断する方法等が考えられる(図8(d))。
【0037】
以上のように、無線電波状況が悪い時には情報配信方式の通信モードをPush型から一時的にPull型に切替え、さらに端末1の無線電波状況が良い時を見計らって通信を行うことにより、端末1の消費電力の低減、ならびにアプリサーバ61におけるパケット再送負荷を低減することが可能となる。このように情報配信方式の通信モードをPush型からPull型に切り替えるシステム動作フローは図16を用いて説明する。
【0038】
なお、本実施例においては、端末1が無線アクセス網と情報配信方式の選択機能を備え、またアプリサーバ61がアプリキープアライブ間隔の決定機能を備える構成としたが、このように端末1とアプリサーバ61の機能を明確に分離せず、端末1とアプリサーバ61が互いに連携しつつこれらの機能を実現する構成としてもよい。また、端末1とアプリサーバ61が外部のサーバ(例えば、無線アクセス網選択ポリシーを管理するサーバ等)と連携しつつ処理を行ってもよい。
【0039】
3. システム動作フロー例
次に、図9〜17を用いて本実施例におけるシステム動作フローの例を説明する。
【0040】
図9は、未接続状態の端末1が無線アクセス網20経由で無線GW21に接続し、その接続を利用してアプリサーバ61に位置登録を行う動作フローを示す。動作フローの中で、アプリサーバ61は端末1の通信環境を判定し、アプリキープアライブ間隔を決定する。
【0041】
はじめに、端末1は未接続状態にあるが(ステップ301)、端末1の電源が投入されたことにより無線アクセス網20の存在を検知し、無線GW21との接続を確立する(ステップ302)。このときに、無線GW21は、無線ユーザ端末に割り当てた割り当てアドレスIP#2(例えば、192.168.20.1)を無線端末のユーザID(user-A@m-operator20)と無線接続状態32-2と対応づけて無線接続DB22で保持する。無線接続DB22は、図2bに示した無線接続DB32とほぼ同様の構成をとるが、割当てアドレス32-3に設定されるアドレスがNAT変換前のプライベートIPアドレスである点が異なる。無線GW21のアプリ連携機能は、端末1と無線接続確立をマッピングサーバ63に対して通知する(ステップ303)。接続確立では、無線GW21からマッピングサーバ63に、無線接続DBで保持している、無線ユーザID(user-A@m-operator20)、無線接続状態、割当アドレスIP#2(192.168.20.1)などが通知される。マッピングサーバ63は無線GW21から通知される端末1の接続情報(割当アドレスIP#2(192.168.20.1)、無線接続状態「接続中」)を図3のマッピングDBに記憶し(64-3、64-4など)、応答を返信する(ステップ304)。ここで、本実施例においては、無線ユーザIDとアプリユーザIDのマッピング情報(64-1、64-2)を、管理者が予めマッピングDB64に設定していると想定する。すなわち、ステップ303において、マッピングサーバ63は接続通知メッセージに含まれる無線ユーザID(user-A@m-operator20)に基づいてマッピングDB64を検索し、該当するエントリに割当てアドレスIP#2(192.168.20.1)と無線接続状態「接続中」を設定することとなる。
【0042】
次に、端末1はアプリサーバ61からPush型情報配信を受けるために、無線GW21から割り当てられたIPアドレス(192.168.20.1)とアプリユーザID(userA@appserver)、トランスポートプロトコルudp、ポート番号(例えば5002)をアプリサーバ61に通知し位置登録を行う(ステップ305)。ここで無線GW21はNAT機能を有するため(305a)、ステップ305の位置登録メッセージにおいて、端末1がアプリケーション情報(例えばSIP Contactアドレス)として設定するIPアドレス(無線GW21が端末1に割当てるプライベートIPアドレスIP#2(192.168.20.1))と、アプリサーバ61が受信する位置登録メッセージのIPヘッダに設定されているIPアドレス(無線GW21に付与されたグローバルIPアドレス(例えば、10.10.10.2))は異なる。これにより、アプリサーバ61の NAT有無判定ルーチン101は、NATの存在を検知する(ステップ306)。
【0043】
また、アプリサーバ61は、位置登録メッセージを受信すると、アプリ接続DB62に、位置登録メッセージで通知されたIPアドレスIP#2、利用中のトランスポートプロトコル(UDP)とポート番号(192.168.20.12 udp 5002アプリ制御アドレス62-4)、アプリユーザID(userA@appserver)、通信モード(Push)62-2、アプリ接続状態(接続中)62-3を登録する。アプリ接続状態取得方法 (62-5)については、該端末が接続する無線アクセス網のアプリ連携有無が判明した後に設定される。さらに、アプリサーバ61のアプリ有無連携有無判定ルーチン104は、無線GW21のアプリ連携有無を調べるために、マッピングサーバ63に対して無線接続情報を問い合わせる(ステップ307)。マッピングサーバ63は、アプリサーバ61から通知された無線接続情報問い合わせ(ステップ307)に含まれる端末1のアプリケーション上のユーザIDを示すアプリユーザID(userA@appserver)と割当てアドレスIP#2(192.168.20.1)に該当する無線接続情報をマッピングDB64から検索し(ステップ308)、この場合は既にアプリユーザID(userA@appserver)とIPアドレス(192.168.20.1)に対応する無線GW21の接続情報が登録されているため成功応答を返信する(309)。アプリサーバ61のアプリ有無連携有無判定ルーチン104は成功応答を受信することにより、無線GW21が”アプリ連携有”であることを認識する。そして、アプリ接続DB62のアプリ接続状態取得方法62-5を“無線接続DBと同期”に設定する。 アプリサーバ61は、以上説明したNAT有無判定ルーチン101及びアプリ有無連携有無判定ルーチン104の処理により得た端末1の通信環境情報(“NAT有”、”アプリ連携有”)を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施する。アプリサーバ61は、図5のステップ123において説明したように、無線GW21の該NATセッションに対するNATセッションタイマを最大値(T_NAT_MAX)に設定するように無線GW21に指示する(ステップ310、311)。NATセッションタイマ設定310には、割当アドレスIP#2(192.168.20.1)、トランスポートプロトコル(udp)、ポート番号、タイマを最大値に設定する命令、等が含まれており、無線GW21はこれらの情報に基づきNATセッションのタイマを最大値に設定する。なお、ここでのNATセッションとは、NATセッションタイマ設定310に含まれる割当アドレスIP#2(192.168.20.1)、トランスポートプロトコル(udp)、ポート番号等の情報を用いて生成されるものとする。また、アプリサーバ61は、図5のステップ124において決定したアプリキープアライブ間隔(T_NAT_MAX-α)をNIC61-4を介して端末1に通知する(ステップ312)。ここでステップ312はステップ305に対する応答メッセージである。
【0044】
これ以降、端末1は待機状態になり、無線GW21との接続を維持するための無線接続キープアライブ(ステップ313〜315)と、決定したアプリキープアライブ間隔(T_NAT_MAX-α)を用いて行われるアプリサーバ61との接続を維持するためのアプリキープアライブ(ステップ316)を定期的に実行する。なお、アプリキープアライブ時には、無線GW21のNAT情報が更新されるため(ステップ316a)、NATセッションタイマ(T_NAT_MAX)よりも短い周期でアプリキープアライブを行うことにより、アプリサーバ61から端末1へ向かう通信経路を維持することが可能となる。また、本システムにおいては、無線接続キープアライブ間隔(T_M20)よりもアプリキープアライブ間隔(T_NAT_MAX)のほうを長く設定することにより、端末1の消費電力を低減する。このような設定が可能となる理由は、無線GW21のアプリ連携機能により、無線接続キープアライブの結果がアプリサーバ61に通知されるためである。
【0045】
図17は、3GPPの第3.9世代無線通信方式LTE(Long Term Evolution)における、図9のフローの実装例を示す。本フローにおいて、無線GW21はLTEのPDN-GW であり、マッピングサーバ63はPCRFであり、アプリサーバはSIPサーバである。
【0046】
はじめに、端末1は未接続状態にあるが(ステップ601)、端末1の電源が投入されたことにより無線アクセス網20の存在を検知し、無線GW21(PDN-GW)との接続を確立する(ステップ602)。このときに、無線GW21(PDN-GW)は、無線ユーザ端末に割当てた割当アドレス(192.168.20.1)を無線端末のユーザID (userA@m-operator20)と無線接続状態32-2と対応付けて無線接続DB32で保持する。また無線GW21(PDN-GW)はアプリ連携機能を有するため、Diameter CCRメッセージにより端末1の接続確立をマッピングサーバ63(PCRF)に対して通知する(ステップ603)。ステップ603では、無線GW21(PDN-GW)からマッピングサーバ63(PCRF)に、無線接続DB32で保持している、無線ユーザID(userA@m-operator20)、無線接続状態、割当アドレス(192.168.20.1)などが通知される。マッピングサーバ63(PCRF)は端末1の接続情報を図3のマッピングDBに記憶し、応答を返信する(ステップ604)。
【0047】
次に、端末1はアプリサーバ61(SIPサーバ)にSIP REGISTERを送信し位置登録を行う(ステップ605)。位置登録605では、アプリユーザID(userA@appserver)、割当アドレス(192.168.20.1)、トランスポートプロトコル(udp)、ポート番号などが通知される。ここで無線GW21(PDN-GW)はNAT機能を有するため(605a)、ステップ605の位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレス(割当アドレス192.168.20.1)と、実際にIPヘッダに設定されるIPアドレス(無線GW21に付与されたグローバルIPアドレス(例えば、10.10.10.2))は異なる。これにより、アプリサーバ61(SIPサーバ)はNATの存在を検知する(ステップ606)。
【0048】
また、アプリサーバ61(SIPサーバ)は、位置登録メッセージを受信すると、アプリ接続DB62に、位置登録メッセージで通知されたIPアドレスIP#2、利用中のトランスポートプロトコル(UDP)とポート番号(192.168.20.1 udp 5002アプリ制御アドレス62-4)、アプリユーザID(userA@appserver)、通信モード(Push)62-2、アプリ接続状態(接続中)62-3を登録する。アプリ接続状態取得方法 (62-5)については、該端末が接続する無線アクセス網のアプリ連携有無が判明した後に設定される。さらに、アプリサーバ61(SIPサーバ)のアプリ有無連携有無判定ルーチン104は、無線GW21(PDN-GW)のアプリ連携有無を調べるために、マッピングサーバ63(PCRF)に対してDiameter AARメッセージを送信し、無線接続情報を問い合わせる(ステップ607)。Diameter AAR607には、アプリユーザID(userA@appserver)と割当てアドレスIP#2(192.168.20.1)が含まれる。なお現在の標準規格においては、Diameter AARにより無線接続状況を問い合わせることはできないため、本処理を行うためにはメッセージの拡張が必要となる。マッピングサーバ63(PCRF)は、アプリサーバ61(SIPサーバ)から通知されたDiameter AAR607に含まれる端末1のアプリユーザID(userA@appserver)と割当てアドレスIP#2(192.168.20.1)に該当する無線接続情報をマッピングDB64から検索し(ステップ608)、この場合は既にアプリユーザID(userA@appserver)と割当てアドレスIP#2(192.168.20.1)に該当する無線GW21(PDN-GW)の接続情報が登録されているため成功応答を返信する(609)。アプリサーバ61(SIPサーバ)のアプリ連携有無判定ルーチン104は成功応答609を受信することにより無線GW21(PDN-GW)が”アプリ連携有”であることを認識する。そして、アプリ接続DB62のアプリ接続状態取得方法62-5を”無線接続DBと同期”に設定する。
【0049】
アプリサーバ61(SIPサーバ)は、以上の処理により得た端末1の通信環境情報(“NAT有”、”アプリ連携有”)を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施し、NATセッションタイマの延長(ステップ610、611)と、アプリキープアライブ間隔(T_NAT_MAX-α)の通知を行う(ステップ612)。なお、ステップ610、611のDiameter AAR/RARメッセージにおいて、NATタイマを設定する機能は本発明独自のものであり、標準規格の拡張が必要となる。
【0050】
これ以降、端末1は待機状態になり、無線GW21(PDN-GW)との接続を維持するための無線接続キープアライブ(ステップ613〜615)と、アプリサーバ61(SIPサーバ)との接続を維持するためのアプリキープアライブ(ステップ616)を定期的に実行する。
【0051】
次に図10を用いて、無線接続キープアライブの結果をアプリサーバ61に通知するシステム動作フローの例を示す。 はじめに、端末1は無線GW21とアプリサーバ61に接続しており(ステップ331)、無線接続キープアライブ(ステップ332、333)と、アプリキープアライブ(ステップ334)を定期的に実行している。ところが、端末1の移動により、無線アクセス網20の無線電波が届かなくなってしまったとする(ステップ335)。無線GW21は、端末1の無線接続キープアライブが一定時間行われないことにより、圏外移動を検知し(ステップ336)、無線接続DB32の端末1の無線接続情報とNAT情報(図示していない)を削除して(ステップ337)、マッピングサーバ63に端末1の無線ユーザID(userA@m-operator20)、割当アドレス(192.168.20.1)を含む切断通知を行う(ステップ338)。マッピングサーバ63は、マッピングDBを参照して無線ユーザID(userA@m-operator20)、割当アドレス(192.168.20.1)に対応するアプリユーザID(userA@appserver)を含む切断通知をアプリサーバ61に転送する(ステップ339)。アプリサーバ61は、切断通知を受信すると、アプリ接続DB62のアプリユーザID(userA@appserver)に対応するアプリ接続情報を削除(ステップ340)し、マッピングサーバに応答の返信(ステップ341、342)を行う。
【0052】
以上のように、無線アクセス網で行う無線接続キープアライブの結果をアプリサーバ61に通知することにより、アプリサーバ61と端末1間のキープアライブ間隔を長く設定しても、アプリサーバ61が適切なタイミングで端末接続情報を更新できるようになる。このため、端末1の消費電力を低減できるとともに、アプリサーバ61の処理負荷をも低減することが可能となる。
【0053】
次に図18を用いて、アプリサーバ61の異常発生を端末1に通知し、端末1から再度位置登録を実施するシステム動作フローの例を示す。
【0054】
はじめに、端末1は、無線GW21とアプリサーバ61に接続しており(ステップ701)、無線接続キープアライブ(ステップ702、703)と、アプリキープアライブ(ステップ706)を定期的に実行している。また、動作フローでは、アプリサーバ61の障害検出のために、アプリサーバ61とマッピングサーバ63の間でもキープアライブ(ステップ704、705)を定期的に実施しているとする。この状態において、アプリサーバ61に異常が発生し、アプリサーバ61が再起動を行ったとする(ステップ707)。マッピングサーバ63は、アプリサーバ61の再起動を検出すると(ステップ708)、再起動を行ったアプリサーバを示すアプリサーバIDを含むアプリサーバ再起動通知を無線GW21経由で端末1に通知する(ステップ709)。端末1は、アプリサーバ再起動通知を受けると、該アプリサーバIDで識別されるアプリサーバ61に対して再度位置登録を行い(ステップ710)、再びキープアライブ間隔の交渉、待ち受け状態への移行が行われる(ステップ711)。
【0055】
以上のように、アプリサーバ61の異常をマッピングサーバ63が検知し、無線GW21経由で端末1に通知することにより、端末1とアプリサーバ61間のキープアライブ間隔を長く設定しても、端末1がアプリサーバ61の異常発生を迅速に検知できるようになり、サービス品質を向上できる効果がある。
【0056】
次に、図11を用いて端末1が無線GW21から無線GW31に移動するシステム動作フローの例を示す。無線GW21はNAT機能を備えるが、無線GW31はNAT機能を備えていない。
【0057】
はじめに、端末1は無線GW21とアプリサーバ61に接続中の状態にある(ステップ361)。ところが、無線電波状況の変化により、端末1は無線アクセス網20から無線アクセス網30aへの移動を決定し、無線GW31との接続を確立する(ステップ362)。無線GW31はアプリ連携機能を有するため、このときに端末1の接続確立をマッピングサーバ63に対して通知する(ステップ363)。接続確立には、無線ユーザID(userA@m-operator30)及び端末1が無線GW31から割り当てられたIPアドレス(IP#3(10.10.10.1))が含まれる。マッピングサーバは接続確立に含まれる端末1の接続情報を図3のマッピングDBに記憶し、応答を返信する(ステップ364)。
【0058】
次に、端末1はアプリサーバ61との接続を維持するために、無線GW31から新たに割り当てられたIPアドレス(IP#3(10.10.10.1))を端末1のアプリユーザID(userA@appserver)と対応して、アプリサーバ61に対して通知する(ステップ365)。ここで無線GW31はNAT機能を有しないため、ステップ365の位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと(IP#3(10.10.10.1))、実際にIPヘッダに設定されるIPアドレス(10.10.10.1)は一致する。これにより、アプリサーバ61のNAT有無判定ルーチン101は、無線GW31にはNAT機能が存在しないと判断する。
【0059】
また、アプリサーバ61は、無線GW31のアプリ連携有無を調べるためにアプリ連携有無判定ルーチン104を実行して、マッピングサーバ63に対して端末1のアプリユーザID(userA@appserver)とIPアドレス(IP#3)を含む無線接続情報を問い合わせる(ステップ366)。マッピングサーバ63は、マッピングDBから、アプリサーバ61から通知された端末1のアプリユーザID(userA@appserver)とIPアドレス(IP#3(10.10.10.1))に該当する無線接続情報を検索する(ステップ367)。この場合は既にアプリユーザID(userA@appserver)とIPアドレス(IP#3(10.10.10.1))に対応する無線GW31の接続情報が登録されているため成功応答を返信する(368)。これにより、アプリサーバ61のアプリ有無連携有無判定ルーチン102は無線GW31が”アプリ連携有”であると判定する。
【0060】
アプリサーバ61は、以上のNAT有無判定ルーチン101及びアプリ有無連携有無判定ルーチン102の処理により得た端末1の通信環境情報(“NAT無”、”アプリ連携有”)を利用して図5のアプリキープアライブ間隔決定ルーチン103を実施し、端末1にキープアライブ間隔(T_MAX)の通知を行う(ステップ369)。具体的には、通信環境情報(“NAT無”、”アプリ連携有”)であるので、アプリキープアライブ間隔決定ルーチン103のステップ128によって、無線アクセス網30aのアプリキープアライブ間隔の最大値であるT_MAXがアプリキープアライブと決定されT_MAXが端末1に通知される。これ以降(あるいは372以降)、端末1とアプリサーバの間でT_MAXの間隔でアプリキープアライブが実行される。
【0061】
端末1は、無線GW31との接続確立(ステップ362)、アプリサーバ61の情報更新に成功する(ステップ369の応答を受信する)と、無線GW21との接続を切断する(ステップ370)。無線GW21は、端末1の無線ユーザID(userA@m-operator20)を含む切断通知をマッピングサーバ63に通知する(ステップ371、372)。マッピングサーバ63は無線GW21から端末1の切断通知を受信すると、マッピングDBの該無線ユーザID(userA@m-operator20)に対応する無線接続状態64-3を”切断中”とし、また割当てアドレス64-4を削除する。
【0062】
ステップ370で無線GW21との接続を切断すると、端末1は待機状態になり、無線GW31との接続を維持するための無線接続キープアライブ(ステップ373、374)と、アプリサーバ61との接続を維持するためのアプリキープアライブ(ステップ375)を定期的に実行する。なお、本システムにおいては、無線接続キープアライブ間隔(T_M30)よりもアプリキープアライブ間隔(T_MAX)のほうを長く設定することにより、端末1の消費電力を低減する。このような設定が可能となる理由は、無線GW31のアプリ連携機能により、無線接続キープアライブの結果がアプリサーバ61に通知されるためである。
【0063】
次に、図12を用いて端末1が無線GW31から無線GW41に移動するシステム動作フローの例を示す。
【0064】
はじめに、端末1は無線GW31とアプリサーバ61に接続中の状態にある(ステップ391)。ところが、無線電波状況の変化により、端末1は無線アクセス網30aから無線アクセス網40への移動を決定し、無線GW41との接続を確立する(ステップ392)。無線GW41はアプリ連携機能を有しないため、本動作フローにおいては無線GW41からマッピングサーバ63への通知は行われない。
【0065】
次に、端末1はアプリサーバ61との接続を維持するために、無線GW41から新たに割り当てられたIPアドレスと、アプリキープアライブに利用するトランスポートプロトコル(udp)、ポート番号を、アプリサーバ61に対して通知する(ステップ393)。ここで無線GW41はNAT機能を有しないため、ステップ393の再位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは一致する。これにより、アプリサーバ61のNAT有無判定ルーチンは、無線GW41にはNAT機能が存在しないと判断する。
【0066】
また、アプリサーバ61は無線GW41のアプリ連携有無を調べるためにアプリ連携有無判定ルーチンを実行して、マッピングサーバ63に対して無線接続情報を問い合わせる(ステップ394)。マッピングサーバ63は、アプリサーバ61から通知された端末1のアプリユーザID(userA@appserver)とIPアドレスIP#4に該当する無線接続情報をマッピングDBから検索する(ステップ395)。この場合は、無線GW31の接続情報である、ユーザID(userA@appserver)、無線ユーザIDUserA@m-operator30に対して割り当てアドレスIP#3はマッピングDBに保持されているが、無線GW41の接続情報である、ユーザID(userA@appserver)、無線ユーザIDUserA@m-operator30に対して割り当てアドレスIP#4が登録されていないため、マッピングサーバ63は、アプリサーバ61に失敗応答を返信する(396)。これにより、アプリサーバ61のアプリ有無連携判定ルーチンは、無線GW41が”アプリ連携無”であることを認識する。
【0067】
アプリサーバ61は、以上のNAT有無判定ルーチン及びアプリ有無連携判定ルーチンの処理により得た端末1の通信環境情報(“NAT無”、”アプリ連携無”)を利用して図5のキープアライブ間隔決定ルーチン103を実施し、端末1にアプリキープアライブ間隔(T_STD)の通知を行う(ステップ397)。具体的には、通信環境情報(“NAT無”、”アプリ連携無”)であるので、アプリキープアライブ間隔決定ルーチン103のステップ129によって、無線アクセス網40のアプリキープアライブ間隔の標準値であるT_STDがアプリキープアライブと決定されT_STDが端末1に通知される。これ以降、端末1とアプリサーバの間でT_STDの間隔でアプリキープアライブが実行される。
【0068】
端末1は、無線GW41との接続確立、アプリサーバ61の情報更新に成功すると、無線GW31との接続を切断し(ステップ398)、無線GW31は端末1の切断をマッピングサーバ63に通知する(ステップ399、400)。
【0069】
これ以降、端末1は待機状態になり、無線GW41との接続を維持するための無線接続キープアライブ(ステップ401、402)と、アプリサーバ61との接続を維持するためのアプリキープアライブ(ステップ403、404)を定期的に実行する。なお、本システムにおいては、無線GW41がアプリ連携機能を備えないため、アプリキープアライブ間隔(T_STD)を比較的小さい値に設定する。(アプリキープアライブ間隔を、アプリ連携がある場合のアプリキープアライブ間隔よりも小さい値とする。)このように、アプリ連携がある場合のアプリキープアライブ間隔よりもアプリキープアライブ間隔を短くすることにより、アプリ連携機能を有しない無線システムにおいてもアプリサーバが適切な精度で端末の接続状態を管理することが可能となる。
【0070】
次に、図13を用いて端末1が無線GW41から無線GW51に移動するシステム動作フローの例を示す。
【0071】
はじめに、端末1は無線GW41とアプリサーバ61に接続中の状態にある(ステップ421)。ところが、無線電波状況の変化により、端末1は無線アクセス網40から無線アクセス網50への移動を決定し、無線GW51との接続を確立する(ステップ422)。無線GW51はアプリ連携機能を有しないため、本動作フローにおいては無線GW51からマッピングサーバ63への通知は行わない。
【0072】
次に、端末1はアプリサーバ61との接続を維持するために、無線GW51から新たに割り当てられたIPアドレス(IP#5)と、アプリキープアライブに利用するトランスポートプロトコル(udp)、ポート番号をアプリユーザID(userA@@appserver)とともに、アプリサーバ61に対して通知する(ステップ423)。ここで無線GW51はNAT機能を有するため、ステップ423の再位置登録メッセージにおいて、端末1がアプリケーション情報として設定するIPアドレスと、実際にIPヘッダに設定されるIPアドレスは異なる。これにより、アプリサーバ61のNAT有無判定ルーチンは、無線GW51がNAT機能を備えていることを検知する(ステップ424)。
【0073】
また、アプリサーバ61は無線GW51のアプリ連携有無を調べるためにアプリ連携有無判定ルーチンを実行して、マッピングサーバ63に対して無線接続情報を問い合わせる(ステップ425)。マッピングサーバ63は、アプリサーバ61から通知された端末1のアプリユーザID(userA@appserver)とIPアドレス(IP#5)に該当する無線接続情報をマッピングDBから検索する(ステップ426)。この場合は無線GW51の接続情報、すなわちIPアドレス(IP#5)に対応する無線接続状態が登録されていないため、マッピングサーバはアプリサーバに失敗応答を返信する(427)。これにより、アプリサーバ61のアプリ連携有無判定ルーチンは無線GW41が”アプリ連携無”であることを認識する。
【0074】
アプリサーバ61は、以上のNAT有無判定ルーチン及びアプリ連携有無判定ルーチンの処理により得た端末1の通信環境情報(“NAT有”、”アプリ連携無”)を利用して図5のキープアライブ間隔決定ルーチン103を実施する。
NATセッションタイマ(T_NAT)の検出と(ステップ428)、端末1へのキープアライブ間隔(T_NAT-α)の通知を行う(ステップ429)。具体的には、通信環境情報(“NAT有”、”アプリ連携無”)であるので、アプリキープアライブ間隔決定ルーチン103のステップ125において無線GW51のIP#5に対して設定されている
NATセッションタイマ(T_NAT)を取得し、ステップ126において、NATセッションタイマ(T_NAT)を用いてアプリキープアライブ間隔を決定する。アプリサーバはNICを介して端末1に決定したアプリキープアライブ間隔を通知する。これ以降、端末1とアプリサーバの間でT_NAT-αの間隔でアプリキープアライブが実行される。
【0075】
端末1は、無線GW51との接続確立、アプリサーバ61の情報更新に成功すると、無線GW41との接続を切断する(ステップ430)。
【0076】
これ以降、端末1は、待機状態になり、無線GW51との接続を維持するための無線接続キープアライブ(ステップ431、432)と、アプリサーバ61との接続を維持するためのアプリキープアライブ(ステップ433、434)を定期的に実行する。なお、アプリキープアライブ実行時には、無線GW51のNAT情報が更新されるため(ステップ433a、434a)、NATセッションタイマ(T_NAT)よりも短い周期でアプリキープアライブを行うことにより、アプリサーバ61から端末1へ向かう通信経路を維持することが可能となる。
【0077】
以上の図9〜13では、アプリサーバ61が端末1の通信環境情報に応じてアプリキープアライブ間隔を決定するシステム動作フローの例を示したが、NATセッションタイマが短い場合や、無線電波状況の悪い環境においては、アプリキープアライブ処理による端末消費電力が許容値を超えてしまう状況も考えられる。そこで以下では、端末消費電力が許容値を超える場合に、端末1がアプリサーバ61との通信方法を動的に変更するシステム動作フローの例を示す。
【0078】
図14は、端末1がアプリケーションのトランスポートプロトコルをUDPからTCPに変更することにより、キープアライブ間隔を延ばし、消費電力を低減するシステム動作フローを示す。
【0079】
はじめに、端末1は未接続状態にある(ステップ451)。ところが、端末1の電源が投入された等の理由により、無線アクセス網50の存在を検知し、無線GW51との接続を確立する(ステップ452)。また、端末1はアプリサーバ61からPush型情報配信を受けるために、アプリサーバ61に対して位置登録を行う(ステップ453)。アプリサーバ61は図13のステップ424〜428と同様の手順を踏み、アプリキープアライブ間隔(T_NAT_UDP-α)を決定(ステップ454)、その値を端末1に通知する(ステップ455)。
【0080】
端末1は、通知されたアプリキープアライブ間隔T_NAT_UDP-αに基づいて図7の通信方法決定ルーチン154のステップ173からを実施し、消費電力量の許容値超過を判定する(ステップ456)。すなわち、アプリキープアライブ間隔T_NAT_UDP-αを用いて(1)式により算出した単位時間あたりの消費電力量の予測値(W_EXP)が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値(W_MAX)を超えているか否かを判定する。ここで、(1)式により算出した単位時間あたりの消費電力量の予測値(W_EXP)が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値(W_MAX)を超えている場合には現在の設定が”NAT有”かつ情報配信方式のトランスポートプトロコルが”UDP利用”であるため、“UDP利用”を“TCP利用”に変更して再度アプリサーバ61へ位置登録を行う(ステップ457)。アプリサーバ61は、再度アプリキープアライブ間隔決定ルーチン103を実行してキープアライブ間隔(T_NAT_TCP-α)を決定し(ステップ458)、その値を端末1へ通知する(ステップ459)。ここで一般的なNATでは、コネクション管理を行わないUDPのNATセッションタイマよりも、コネクション管理を行うTCPのNATセッションタイマを長く設定する。このため、TCPへの変更によりキープアライブ間隔が長くなり、消費電力量を閾値未満とすることができる(ステップ460)。以降、端末1は待機状態となり定期的にアプリキープアライブ(ステップ461、462)を実施するが、その消費電力は比較的低い値に抑えられる。
【0081】
なお、本動作フローのようにUDPからTCPへ変更するのではなく、最初からTCPを用いる方法も考えられるが、コネクション管理を行うTCPは、多数の端末を収容するアプリサーバの処理負荷を向上させる問題がある。そこで、本動作フローのようにUDPが不適切と判断された状況に限り、TCPに切り替えて接続することにより、アプリサーバの処理負荷を最低限に抑えることが可能となる。
【0082】
次に、図15を用いて、端末1が無線アクセス網を再選択する動作フローの例を示す。はじめに、端末1は未接続状態にあり(ステップ481)、図14のステップ451〜459と同様の処理を実施する(ステップ482)。ところが、本ケースでは何らかの理由により、図14で説明したように使用するトランスポートプロトコルをUDPからTCPへ変更してもなお消費電力量が閾値を超過してしまったとする(ステップ483)。すなわち、アプリキープアライブ間隔T_NAT_TCP-αを用いて(1)式により算出した単位時間あたりの消費電力量の予測値(W_EXP)が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値(W_MAX)を超えている場合である。ここで端末1は、図7の通信方法決定ルーチン152のステップ177に従い、他の無線アクセス網を使用であるかどうかを再検索する(ステップ484)。無線アクセス網30aの使用が可能であるため無線アクセス網30aへの接続を試みる(ステップ485)。無線アクセス網30aを収容する無線GW31は、”NAT無”かつ”アプリ連携有”のため、”NAT有”かつ”アプリ連携無”の無線GW51よりも、アプリキープアライブ間隔が長く設定される可能性が高い。そのため、最初に無線電波状況がよいと判断して接続した無線GW51よりも、無線GW31のほうが結果的に消費電力を低く抑えることができる。端末1は、実際に無線アクセス網に接続するまでNATの有無やアプリ連携機能の有無等の通信環境を把握できないため、本動作フロー例のように途中で無線アクセス網を再選択することは、より条件のよい無線アクセス網の選択可能性を高める効果がある。
【0083】
次に、図16を用いて、端末1が情報配信方式の通信モードをPush型通信からPull型通信に切り替える動作フローの例を示す。はじめに、端末1は未接続状態にあり(ステップ501)、図14のステップ451〜459と同様の処理を実施する(ステップ502)。ところが、本ケースでは何らかの理由により、使用するトランスポートプロトコルをUDPからTCPへ変更しても単位時間あたりの消費電力量の予測値(W_EXP)が予め無線アクセス網50で定めた単位時間あたりの消費電力量の閾値閾値(W_MAX)を超過し(ステップ503)、また図15で説明した無線アクセス網の再選択にも失敗したとする(ステップ504)。ここで端末1は、図7の通信方法決定ルーチン152のステップ179に従い、情報配信方式の通信モードをPush型からPull型へ変更することを端末1のアプリユーザIDとIPアドレスとともにアプリサーバ61に通知する (ステップ505)。この情報は、アプリサーバ61が備えるアプリ接続DB62(図2a)の通信モード(62-2)に格納され、アプリサーバ61は端末1へのPush型通知を停止する。そして、端末1は無線電波状況を監視し、比較的電波状況の良い時に限り(ステップ506)、アプリサーバ61への情報問合せを行う(ステップ507、508)。このように、端末1が無線電波状況のよいときを見計らって通信を行うことにより、通信効率を向上することができ、ひいては端末1の消費電力を低減することが可能となる。また、情報配信方式の通信モードをPush型をPull型に変更することにより、無線電波状況が悪い時にアプリサーバ61で発生する再送処理負荷を低減することが可能となる。
【0084】
以上、本実施例では、端末が複数の無線システム間を自由に移動する通信システムにおいて、アプリサーバから端末への情報配信方式、およびアプリサーバと端末間のアプリキープアライブ間隔を、端末の通信環境に応じて動的に変更するシステムの構成例を示した。
【0085】
本実施例では、端末とアプリサーバ間にNAT機能が存在する場合には、アプリキープアライブ間隔をNATセッションタイマよりも短い値に設定する。また端末とアプリサーバ間にNAT機能が存在せず、かつ無線接続キープアライブによって無線アクセス網が取得する無線アクセス網の端末接続情報をアプリサーバが取得できる場合には、アプリキープアライブ間隔を無線アクセス網毎に予め定めた最大値に設定する。また端末とアプリサーバ間にNAT機能が存在せず、かつ無線接続キープアライブによって無線アクセス網が取得する無線アクセス網の端末接続情報をアプリサーバが取得できない場合には、アプリキープアライブ間隔を無線アクセス網毎に予め定めた標準値に設定する。以上により、端末とアプリサーバ間の接続性を維持できる範囲内でアプリキープアライブ間隔を短縮し、端末の消費電力量を低減することが可能となる。さらに、このような手順で決定したアプリキープアライブ間隔での端末消費電力量が許容範囲を超える場合には、トランスポート層のプロトコルをUDPからTCPに変換、もしくは無線アクセス網の再選択、もしくは情報配信方式の通信モードををPush型からPull型に変更することにより、端末消費電力とアプリサーバの処理負荷を低減できる効果が得られる。
【0086】
<実施例2>
実施例1では、端末自身が直接無線アクセス網に接続するシステムを想定したが、実施例2では、端末がモバイルルータを介して無線アクセス網に接続するシステムを想定する。モバイルルータは、無線アクセス網(携帯電話網、WiMAX、公衆無線LAN等)に接続するWANインタフェースと、端末を収容するLANインタフェースとを備え、WANとLANのトラフィックを相互に中継する装置である。モバイルルータが用いられるシステムにおいては、無線アクセス網と接続するモバイルルータの消費電力低減、無線アクセス網のトラフィック削減が重要な課題となる。そこで、本実施例では、モバイルルータが配下の複数の端末のキープアライブ情報を集約してWANインタフェースに送信することにより、モバイルルータキープアライブメッセージ数を削減し、モバイルルータの消費電力低減、無線アクセス網のトラフィック削減を実現する例を示す。実施例2においては、端末とモバイルルータとの間のとの接続を維持するための端末とモバイルルータとのキープアライブを「端末キープアライブ」と定義する。モバイルルータ1010とキープアライブ中継サーバと接続を維持するための確認を「モバイルルータキープアライブ」と定義する。また、モバイルルータ1010とキープアライブ中継サーバ間のキープアライブ間隔を「モバイルルータキープアライブ間隔」と定義する。
端末1と無線GW21との接続を維持するための端末1と無線GW21とのキープアライブを「無線接続キープアライブ」と、端末1とアプリサーバ61との接続を維持するためのキープアライブを「アプリキープアライブ」と定義する。
【0087】
1. システム構成例
図19は、実施例2におけるシステム構成例を示す図である。図19において、(1001、1002)は端末を示し、(1020、1030)は無線アクセス網を示し、1010は端末(1001、1002)を収容するLANインタフェースと、無線アクセス網(1020、1030)に接続するWANインタフェースとを備えたモバイルルータを示し、1040は無線アクセス網(1020、1030)を収容するIPコア網を示し、1041はIPコア網1040に設置されるキープアライブ中継サーバを示し、 (1044、1045)はIPコア網1040に設置され端末(1001、1002)を収容するアプリサーバを示す。
【0088】
ここで、本発明の特徴は、モバイルルータ1010が複数の端末(1001、1002)のキープアライブ情報を集約してキープアライブ中継サーバ1041に通知し、キープアライブ中継サーバ1041がその情報を展開してアプリサーバ(1044、1045)に通知する点である。
【0089】
また、キープアライブ中継サーバ1041は、モバイルルータ1010から通知された端末キープアライブ情報の集約結果を展開するために、キープアライブ中継DB1042を備える。キープアライブ中継DB1042は、例えば、図21aに示すように、モバイルルータID(1042-1)、端末ID(1042-2)、アプリID(1042-3)、端末通信アドレス(1042-4)、状態(1042-5)、アプリサーバ通信アドレス(1042-6)等から構成される。
【0090】
さらに、キープアライブ中継サーバ1041は、アプリサーバ(1044、1045)に対してキープアライブ処理を実施し、その状態を端末(1001、1002)に通知することも可能である。この場合、アプリサーバ(1044、1045)のキープアライブ状況を管理するためにサーバキープアライブDB1043を保持する。サーバキープアライブDB1043は、例えば図21bに示すようにアプリサーバ通信アドレス(1043-1)、状態(1043-2)等から構成される。
【0091】
2. 装置構成例と特徴機能
次に、図22、図23a、図23bを用いて、モバイルルータ1010の装置構成と特徴機能を説明する。
【0092】
図22は、モバイルルータ1010の装置構成例を示す。本構成例において、モバイルルータ1010のハードウェアは一般的なモバイルルータ装置と同様であり、不揮発性の情報記憶デバイスであるハードディスク1010-1と、揮発性の情報記憶デバイスであるメモリ1010-2と、プログラムおよびデータを逐次読み込んで演算を行うCPU1010-3と、無線アクセス網(1020、1030)との通信を中継するアンテナ(1010-4a、1010-4b)およびWAN無線信号処理部(1010-5a、1010-5b)と、端末(1001、1002)との通信を中継するアンテナ1010-6およびLAN無線信号処理部1010-7と、各ユニットを接続するバス1010-8から構成される。
【0093】
また、モバイルルータ1010の機能を実現するプログラムおよびデータは、実行時にメモリ1010-2に展開され、それらは少なくともNATセッション情報を生成/更新/削除するNAT管理ルーチン1100と、NATセッション情報を保持するNAT DB1012と、端末(1001、1002)との間でキープアライブ処理を実施する端末キープアライブルーチン1102と、複数の端末(1001、1002)の端末キープアライブ状況を保持する端末キープアライブDB1012と、端末キープアライブ状況の集約結果をキープアライブ中継サーバ1041に通知する端末キープアライブ状況報告ルーチン1101と、キープアライブ中継サーバ1041に対してキープアライブ処理を実施する中継サーバキープアライブルーチン1103とを含む。これらのうち、端末キープアライブルーチン1102、端末キープアライブ状況報告ルーチン1101、端末キープアライブDB1011を備える点が、本発明における特徴である。
【0094】
端末キープアライブDB1011は、例えば図20aのように、端末ID(1011-1)、アプリID(1011-2)、NAT変換前の端末通信アドレスを示すLAN通信アドレス(1011-3)、キープアライブ状態(1011-4)等から構成される。
【0095】
NAT DB1012は、例えば図20bに示すように、NAT変換前のプライベートアドレスを示すLAN通信アドレス(1012-1)と、NAT変換後のグローバルアドレスを示すWAN通信アドレス(1012-2)等から構成される。モバイルルータでは、このNATDBに基づいて、NAT変換が行われる。
【0096】
図23aは、端末キープアライブ状況報告ルーチン1101の実装例を示す。本ルーチンは、モバイルルータ1010とキープアライブ中継サーバ1041間のキープアライブパケット交換時、端末キープアライブDB1011の情報更新時、およびNAT DB1012の情報更新時に実行される。処理内容は以下の通りである。はじめに、モバイルルータ101は、端末キープアライブDB1011、NAT DB1012で保持する情報のうち、前回送信したモバイルルータキープアライブの情報と、現在端末キープアライブ状況として保持している端末キープアライブDB1011、NAT DB1の情報との差分を抽出する(ステップ1121)。そして、モバイルルータ101は、前記抽出した差分の端末キープアライブ情報をキープアライブ中継サーバ1041に通知し(ステップ1122)、処理を終了する。このように、前回モバイルルータキープアライブを送信した時の端末キープアライブDB1011及びNAT DB1012と現時点で保持している端末キープアライブDB1011及びNAT DB1012の情報の差分の情報のみを通知することにより、情報量を圧縮し、無線アクセス網のトラフィック削減、モバイルルータ1010の消費電力低減を実現できる。なお、本ルーチンを実施するシステム動作フローの例を後で図24〜26を用いて説明する。
【0097】
また、モバイルルータ1010は、無線アクセス網の変更によりWAN側のグローバルアドレスが変化した際に、図23bに示すNAT管理ルーチン1100を実施することにより、端末(1001、1002)からアプリサーバ(1043、1044)への再位置登録にともなう処理負荷を低減する。すなわち、従来のシステムにおいては、モバイルルータ1010のWAN側グローバルアドレスが変更された際に、モバイルルータ1010のNAT DB1012がリセットされるため、モバイルルータ1010配下の端末(1001、1002)からアプリサーバ(1044、1045)に対して再度位置登録を行い、モバイルルータ1010のNATセッション情報を再度生成する必要があった。しかし、本発明のシステムによれば、図23bに示すようにモバイルルータ1010は、変更後のグローバルアドレスを用いてNAT DB1012のWAN通信アドレス1012-2(図20b参照)を更新することにより(図23bのステップ1123)、端末(1001、1002)からアプリサーバ(1044、1045)への再位置登録を不要としている。なお、本ルーチンを適用したシステム動作フローの例は、後で図28を用いて説明する。
【0098】
3. システム動作フロー例
次に、図24〜28を用いて、実施例2におけるシステム動作フローの例を示す。
【0099】
図24〜25は、モバイルルータ1010が無線アクセス網1020に接続した後、さらに端末1001がモバイルルータ1010に接続するシステム動作フローの例を示す。はじめに、端末1001、端末1002、モバイルルータ1010は未接続状態にある。次に、モバイルルータ1010の電源が投入されると、モバイルルータ1010は、最も電波状況の良い無線アクセス網1020に接続され、無線アクセス網1020からグローバルアドレス(IP#G1)を付与される(ステップ1202)。そして、モバイルルータ1010は、無線アクセス網1020の接続を利用してキープアライブ中継サーバ1041に接続し、モバイルルータ1010とキープアライブ中継サーバ間のモバイルルータキープアライブ間隔(T_MR1020)を決定する。この時点で、モバイルルータ1010の端末キープアライブDB1011にはまだ何も設定されていない。また、キープアライブ中継サーバ1041のキープアライブ中継DB1042にはモバイルルータID(1042-1)のみが設定されている。なお、モバイルルータキープアライブ間隔(T_MR1020)の決定方法の詳細はここでは述べないが、例えば、実施例1で示したアプリキープアライブ間隔の決定アルゴリズムが使用できる。その場合、モバイルルータ1010の通信環境に応じて、接続性を維持できる範囲でモバイルルータキープアライブ間隔をできるだけ長く設定するため、消費電力低減、ネットワーク負荷低減に貢献することが可能となる。以上により、モバイルルータ1010の接続処理が完了し、以降、定期的にモバイルルータキープアライブ(ステップ1204〜1206)が実施される。モバイルルータキープアライブには、モバイルルータ1010が保持する端末キープアライブDB1011に格納されている情報のうち、前回モバイルルータキープアライブを送信した時の情報と現時点で保持している情報との差分の情報が含まれる。モバイルルータキープアライブで通知された情報は、キープアライブ中継サーバ1041のキープアライブ中継DB1042に格納される。
【0100】
次に、端末1001の電源が投入され、端末1001は、モバイルルータ1010に対して接続し、プライベートアドレス(IP#P1)の割当てを受ける(ステップ1207)。そして、端末1001はモバイルルータ1010に対して端末キープアライブ要求を送信する(ステップ1208)。端末キープアライブ要求(1208)には、端末1001とモバイルルータ1010との間のキープアライブ間隔を示す端末キープアライブ間隔(T_TM1001)、端末キープアライブ対象となるアプリケーションのID、該アプリケーションが使用する通信アドレス(IPアドレス、ポート番号)等が含まれる。モバイルルータ1010は、端末キープアライブ要求(1208)を受信すると、該情報を端末キープアライブDB1011に格納し、さらに各アプリケーションの通信アドレスに対応するNATセッション情報を生成し、生成したNATセッション情報をNAT DB1012に設定する。モバイルルータでは、このNAT DNに基づいて、NAT変換が行われる。図24の説明においでは、プライベートアドレス(IP#P1)と、グローバルアドレス(IP#G1)とのNAT変換が行われる。また、これらのアドレスに対応するポート番号も変換される。また、モバイルルータ1010は、端末1001が新規に接続されたことをキープアライブ中継サーバ1041に通知し(ステップ1211)、キープアライブ中継サーバ1041は、ステップ1211で通知された情報をキープアライブ中継DB1042に格納する。さらに、モバイルルータ1010は、端末1001に応答を返信し、キープアライブ中継サーバ1041のアドレスを通知する(ステップ1212)。
【0101】
次に、端末1001は、アプリサーバ1044、1045に対して位置登録を行う(図24ステップ1213、図25ステップ1217)。位置登録要求にはキープアライブ中継サーバ1041とモバイルルータ1010のIDが含まれている。アプリサーバ(1044、1045)は、位置登録要求で通知された情報を使用して、キープアライブ中継サーバ1041にモバイルルータキープアライブ状況を問い合わせる(図24ステップ1214、図25ステップ1218)。この例では、モバイルルータキープアライブで通知された端末1001の情報が事前にキープアライブ中継サーバ1041に通知されているので、問い合わせに成功し、キープアライブ中継サーバ1041とアプリサーバ(1044、1045)間のサーバキープアライブ間隔(T_SV1044、T_SV1045)が通知される(図24ステップ1215、図25ステップ1219)。サーバキープアライブ間隔(T_SV1044、T_SV1045)は、アプリサーバ(1044、1045)とキープアライブ中継サーバ1041の負荷を上げない程度に長く、またサービスレベルを低下させない程度に短く設定される。
【0102】
次に、アプリサーバ(1044、1045)は、端末1001との間で実施するアプリキープアライブ間隔(T_AP1044、T_AP1045)を決定し、端末1001に応答を返信する(図24ステップ1216、図25ステップ1220)。なお、本実施例では、アプリキープアライブ(T_AP1044、T_AP1045)を非常に長く(例えば1日〜1週間)設定し、キープアライブメッセージを中継するモバイルルータ1010の負荷を低減する点に特徴がある。
【0103】
以上で端末1001の接続処理が終了し、以降、端末1001とモバイルルータ1010間の端末キープアライブ(ステップ1220〜1230)、モバイルルータ1010とキープアライブ中継サーバ1041間のモバイルルータキープアライブ(ステップ1230〜1233)、キープアライブ中継サーバ1041とアプリサーバ(1044、1045)間のサーバキープアライブ(ステップ1234〜1241)、端末1001とアプリサーバ(1044、1045)間のアプリキープアライブ(ステップ1242〜1245)が定期的に実施されるようになる。
【0104】
なお、図24〜25では端末1001の接続フローについて示したが、端末1002についても同様の手順が適用される。
【0105】
次に、図26を用いて端末1が圏外移動するシステム動作フローの例を示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバ(1044、1045)に接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している(ステップ1301)。ところが、端末1001の移動により、端末1001とモバイルルータ1010間の通信が切断される(ステップ1302)。モバイルルータ1010は、端末キープアライブに失敗することによって端末1001の圏外移動を検出し(1303)、端末キープアライブDB1011、NAT DB1012の中から端末1001に関する情報を削除する。そして、キープアライブ中継サーバ1041に対して端末キープアライブ状況更新を送信し(ステップ1305)、端末1001の離脱を通知する(図23aの端末キーピアライブ状況報告ルーチンによって計算された差分をモバイルキープアライブによって通知する)。キープアライブ中継サーバ1041は、端末1001の情報をキープアライブ中継DB1042から検索し、端末1001が接続している(端末ID1042-2に対応する)アプリサーバID1042-3を特定し、該アプリサーバIDに対応するアプリサーバ(1044、1045)に対して端末1001の離脱通知を送信する(ステップ1306、1308)。アプリサーバ(1044、1045)は、端末1001の位置登録情報を削除し、応答を返信する(ステップ1307、1309)。キープアライブ中継サーバ1041は、モバイルルータ1010に応答を返信する(1310)。以降、キープアライブ中継DB1042のアプリサーバ通信アドレス1042-6に基づいてキープアライブ中継サーバ1041主導で実施されるサーバキープアライブ、端末キープアライブDB1011に基づいてモバイルルータ1010主導で実施される端末キープアライブ端末とアプリサーバ(1044、1045)間の接続状態に基づいて端末主導で実施されるアプリキープアライブは実施されず、モバイルルータキープアライブのみが実施されるようになる(ステップ1311、1312)。 以上のように、モバイルルータ1010が端末1001の端末キープアライブ状況の変化をキープアライブ中継サーバ1041に通知することにより、端末1001とアプリサーバ(1044、1045)間のアプリキープアライブ間隔を長く設定しても、アプリサーバ(1044、1045)が端末1001の状態を正しく把握できるようになる。
【0106】
次に、図27を用いてアプリサーバ1044が再起動するシステム動作フローの例を示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバ(1044、1045)に接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している(ステップ1351)。ところが、アプリサーバ1044に異常が発生し、アプリサーバ1044 の再起動処理が行われる(ステップ1352)。キープアライブ中継サーバ1041は、サーバキープアライブによりアプリサーバ1044の再起動を検出(ステップ1353)し、モバイルルータ1010経由で端末1001にアプリサーバ1044が再起動したことを通知する(ステップ1354)。端末1001は、アプリサーバ1044の再起動通知を受けると、アプリサーバ1044に対して再位置登録を実施する(ステップ1355)。これにより、アプリサーバ1044に端末1001の位置情報が再登録される。続いてキープアライブ中継サーバ1041とアプリサーバ1044間の接続確立(ステップ1356〜1357)、端末1001へのアプリキープアライブ間隔通知(ステップ1358)が行われ、最初の定常状態に復帰する(ステップ1359)。
【0107】
以上のように、キープアライブ中継サーバ1041がアプリサーバ1044のサーバキープアライブ状況の変化をモバイルルータ1010と端末1001に通知することにより、端末1001とアプリサーバ1044間のアプリキープアライブ間隔を長く設定しても、端末1001がアプリサーバ1044の異常を早期検知し、迅速に定常状態に復帰することが可能となる。
【0108】
次に、モバイルルータ1010が無線アクセス網を切り替えたことにより、グローバルアドレスが変更されるシステム動作フローの例を、図28を用いて示す。はじめに、端末1001は、モバイルルータ1010とアプリサーバ(1044、1045)に接続しており、端末キープアライブ、モバイルルータキープアライブ、サーバキープアライブ、アプリキープアライブを定期的に実施している(ステップ1401)。ところが、無線電波状況が変化した等の理由により、モバイルルータ1010は、無線アクセス網1020との接続を切断し(ステップ1402)、無線アクセス網1030との接続を新規に確立する(ステップ1403)。この際に、無線アクセス網1030は、モバイルルータ1010に、無線アクセス網1020が割り当てたグローバルアドレス(IP#G1)とは異なるグローバルアドレス(IP#G2)を割り当てる。次に、モバイルルータ1010は、無線アクセス網1030との接続を利用して、キープアライブ中継サーバ1041との接続を再確立し(ステップ1404)、モバイルルータキープアライブ間隔(T_MR1030)を再決定する。そして、モバイルルータ1010は、図23bのNAT管理ルーチン1100に従い、新しく割り当てられたグローバルアドレス(IP#G2)を用いてLAN通信アドレスがプライベートアドレスIP#P1に対するNAT DB1012のWAN通信アドレスを、無線アクセス網1020が割り当てたグローバルアドレス(IP#G1)から新しく割り当てられたグローバルアドレス(IP#G2)に更新する(ステップ1405)。モバイルルータ1010は、ここで、LAN通信アドレスプライベートアドレスIP#P1及びこれに対応するポート番号に対して、新しく割り当てられたグローバルアドレス(IP#G2)及びこれに対応するポート番号の組み合わせを生成する。また、キープアライブ中継サーバ1041に端末キープアライブ状況更新を送信し(ステップ1406)、WAN通信アドレスの変化(変更後のIPアドレス、ポート番号など)を通知する。キープアライブ中継サーバ1041は、アプリサーバ(1044、1045)に対して通信アドレス変更を通知する(ステップ1407、1409)。アプリサーバ(1044、1045)は端末位置情報を更新、応答を返信する(ステップ1408、1410)。キープアライブ中継サーバ1041は、モバイルルータ1010に応答を返信し(1411)、以降、定常状態に復帰する(ステップ1412)。
【0109】
以上のように、モバイルルータ1010は、グローバルアドレスの変更時にNAT情報を更新し、その情報をキープアライブ中継サーバ1041経由でアプリサーバ(1044、1045)に通知することにより、端末とアプリサーバ間の再位置登録を実施することなく、サービスを継続することが可能となる。図28の動作フローでは端末1001の一台のみがモバイルルータに接続している状況を想定したが、モバイルルータ1010が収容する端末台数が多いほど、本処理の効果は大きくなる。なぜならば、従来技術に従い、グローバルアドレス変更時に端末(M台)からアプリサーバ(N台)への再位置登録を実施したとすると、無線アクセス網を通過するメッセージ数はM×N×2(リクエスト+レスポンス)となる。しかし、図28の動作フローのようにモバイルルータ1010が各端末の代理でアドレス変更を通知した場合、無線アクセス網を通過するメッセージ数は端末台数やアプリサーバ台数によらず2 (リクエスト+レスポンス)となるためである。特に、携帯電話網のように消費電力の大きい無線アクセス網の場合、メッセージ数の削減には大きな効果が見込まれる。
【符号の説明】
【0110】
1 端末、(20、30a、30b、40、50) 無線アクセス網、(21、31、41、51) 無線GW、(22、32、42、52) 無線接続DB、60 IPコア網、61 アプリサーバ、62 アプリ接続DB、63 マッピングサーバ、64 マッピングDB、100 アプリ処理ルーチン、101 NAT有無判定ルーチン、102 アプリ連携有無判定ルーチン、103 キープアライブ間隔決定ルーチン、104 無線接続状態取得ルーチン、151 アプリ処理ルーチン、152 キープアライブ間隔決定ルーチン、153 消費電力量予測ルーチン、154 通信方法決定ルーチン、155 無線電波状況監視ルーチン、156 無線制御ルーチン、(1001、1002) 端末、1010 モバイルルータ、1011 端末キープアライブDB、1012 NAT DB、(1020、1030) 無線アクセス網、1040 IPコア網、1041 キープアライブ中継サーバ、1042 キープアライブ中継DB、1043 サーバキープアライブDB、(1044、1045) アプリサーバ、1100 NAT管理ルーチン、 1101 端末キープアライブ状況報告ルーチン、1102 端末キープアライブルーチン、1103 中継サーバキープアライブルーチン。

【特許請求の範囲】
【請求項1】
複数の無線システムと、前記無線システムに接続可能な端末と、前記端末と定期的にキープアライブパケットを交換するアプリサーバと、前記無線システムから通知される無線システムへの端末の接続情報を保持するマッピングサーバを含む通信システムであって、
前記アプリサーバは、
端末が接続している無線システムが、前記無線システムへの端末の接続情報を前記マッピングサーバに通知するか否かに基づいて、前記端末とのキープアライブ間隔を変更することを特徴とする通信システム。
【請求項2】
請求項1に記載の通信システムであって、
前記マッピングサーバと前記アプリサーバ間のキープアライブ処理を実施し、
前記マッピングサーバは、前記アプリサーバの異常を検出した際に、該アプリサーバに接続している端末に該アプリサーバで異常が発生したことを前記端末に通知し、
前記端末は、前記異常が発生したアプリサーバに再度位置登録を行うことを特徴とする請求項1に記載の通信システム。
【請求項3】
前記アプリサーバは、
前記端末との間にNAT が存在するか否かを判定する手段と、
前記無線システムのうちの一つから前記端末の接続情報を取得できるか否かを判定する手段と、を備え、
前記端末との間にNATが存在する場合には前記キープアライブ間隔をNATセッションタイマよりも短い値に設定し、前記端末との間にNATが存在せずかつ前記アプリサーバが前記無線システムから前記端末の接続情報を取得できる場合には、前記キープアライブ間隔を予め定めた最大値に設定し、前記端末との間にNATが存在せずかつ前記アプリサーバが前記無線システムから前記端末の接続情報を取得できない場合には、前記キープアライブ間隔を前記最大値よりも短い予め定めた標準値に設定することを特徴とする請求項1に記載の通信システム。
【請求項4】
請求項3に記載の通信システムであって、
前記端末は、
前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合には、トランスポート層のプロトコルをUDPからTCPに変更することを特徴とする通信システム。
【請求項5】
請求項3に記載の通信システムであって、
前記端末は、
前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合に、接続する無線システムを前記複数の無線システムから再選択することを特徴とする通信システム。
【請求項6】
請求項3に記載の通信システムであって、
前記端末は、
前記アプリサーバとの交渉により決定したキープアライブ間隔および無線電波状況に基づいてキープアライブ処理に伴う単位時間当たりの消費電力量の予測値を計算し、前記単位時間あたりの消費電力量の予測値が事前に定めた閾値を超える場合に、Push型通信からPull型通信に切り替えることを前記アプリサーバに通知
することを特徴とする通信システム。
【請求項7】
少なくとも一つ以上の無線システムと、前記少なくとも一つ以上の無線システムに接続可能なモバイルルータと、前記モバイルルータに収容される複数の端末と、前記モバイルルータおよび前記無線システムを介して前記複数の端末とキープアライブを実施する少なくとも一つ以上のアプリサーバと、を含む通信システムであって、
前記モバイルルータは、
前記少なくとも一つ以上の無線システムに接続する第一の通信インタフェースと、前記複数の端末を収容する第二の通信インタフェースと、を備え、
前記第二の通信インタフェースを介して前記複数の端末と端末キープアライブを実施し、前記端末キープアライブによって収集した前記複数の端末のキープアライブ状況を集約して前記第一の通信インタフェースを介して前記端末が接続している前記無線アクセス網に送信することを特徴とする通信システム。
【請求項8】
請求項7に記載の通信システムであって、
前記一つ以上の無線システムを介して前記モバイルルータと通信を行うキープアライブ中継サーバを備え、
前記キープアライブ中継サーバは、
前記モバイルルータから前記集約されたキープアライブ状況を受信し、前記アプリサーバから受信したキープアライブ状況の問い合わせに対応して、前記キープアライブ状況の問い合わせに含まれるモバイルルータ識別子に対応したモバイルルータの前記キープアライブ状況を前記アプリサーバに対して送信することを特徴とする通信システム。
【請求項9】
請求項8に記載の通信システムにおいて、
前記モバイルルータは、
前記少なくとも一つ以上の無線システムから第一の通信アドレスの割当てを受けるとともに、前記端末には第二の通信アドレスを付与する機能と、
前記端末から前記アプリサーバへのパケットを中継する際に、前記端末に割当てた前記第二の通信アドレスおよび前記端末が該通信に割当てた第二のポート番号を、前記無線システムから割り当てられた前記第一の通信アドレスおよび前記モバイルルータが該通信に割当てた第一のポート番号に変換する変換機能と、
無線システムの切り替えにより切替後の無線システムから新たに第三の通信アドレスを割り当てられた際に、前記第二の通信アドレスおよび第二ポート番号に対応する、前記第三の通信アドレスおよび第三のポート番号の組合せを生成し、前記第三の通信アドレスおよび第三のポート番号の組合せを、前記キープアライブ中継サーバに送信することを特徴とする通信システム。

【図1】
image rotate

【図2a】
image rotate

【図2b】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate

【図11】
image rotate

【図12】
image rotate

【図13】
image rotate

【図14】
image rotate

【図15】
image rotate

【図16】
image rotate

【図17】
image rotate

【図18】
image rotate

【図19】
image rotate

【図20a】
image rotate

【図20b】
image rotate

【図21a】
image rotate

【図21b】
image rotate

【図22】
image rotate

【図23a】
image rotate

【図23b】
image rotate

【図24】
image rotate

【図25】
image rotate

【図26】
image rotate

【図27】
image rotate

【図28】
image rotate


【公開番号】特開2012−222378(P2012−222378A)
【公開日】平成24年11月12日(2012.11.12)
【国際特許分類】
【出願番号】特願2011−82401(P2011−82401)
【出願日】平成23年4月4日(2011.4.4)
【出願人】(000005108)株式会社日立製作所 (27,607)
【Fターム(参考)】