(57)【特許請求の範囲】
【請求項１】
所定のプロトコルを終端する装置間でヘルスチェック用の信号を送受信して対向元の前記装置と対向先の前記装置との間のプロトコルパスを含む対向装置のヘルスチェックを行う移動体パケット通信システムのヘルスチェック方法であって、
対向元の前記装置が、自装置に予め登録されている「自装置に対する前記ヘルスチェックを実施するか否か」の要否情報を、前記プロトコルを構成する所定のプロトコルシーケンス中のプロトコルメッセージに設けられている所定の情報要素に設定して、対向先の前記装置へ通知することを特徴とする移動体パケット通信システムのヘルスチェック方法。
【請求項２】
前記プロトコルは、トネリングプロトコルであり、前記プロトコルパスはＩＰパスであることを特徴とする請求項１記載の移動体パケット通信システムのヘルスチェック方法。
【請求項３】
前記装置は、トネリングプロトコルを終端する装置であることを特徴とする請求項１又は２記載の移動体パケット通信システムのヘルスチェック方法。
【請求項４】
前記プロトコルメッセージへの要否情報の設定は、プロトコルの終端ＩＰアドレス単位で行うことを特徴とする請求項１、２又は３記載の移動体パケット通信システムのヘルスチェック方法。
【請求項５】
所定の前記プロトコルシーケンスは、前記プロトコルの確立シーケンスであることを特徴とする請求項１、２、３又は４記載の移動体パケット通信システムのヘルスチェック方法。
【請求項６】
所定のプロトコルを終端する装置間でヘルスチェック用の信号を送受信して対向元の前記装置と対向先の前記装置との間のプロトコルパスを含む対向装置のヘルスチェックを行う移動体パケット通信システムであって、
対向元の前記装置は、
自装置に予め登録されている「自装置に対する前記ヘルスチェックを実施するか否か」の要否情報を、前記プロトコルを構成する所定のプロトコルシーケンス中のプロトコルメッセージに設けられている所定の情報要素に設定する設定手段と、
前記要否情報が設定された前記プロトコルメッセージを対向先の前記装置へ通知する通知手段とを備えていることを特徴とする移動体パケット通信システム。
【請求項７】
前記プロトコルは、トネリングプロトコルであり、前記プロトコルパスはＩＰパスであることを特徴とする請求項６記載の移動体パケット通信システム。
【請求項８】
前記装置は、トネリングプロトコルを終端する装置であることを特徴とする請求項６又は７記載の移動体パケット通信システム。
【請求項９】
前記プロトコルメッセージへの要否情報の設定は、プロトコルの終端ＩＰアドレス単位で行うことを特徴とする請求項６、７又は８記載の移動体パケット通信システム。
【請求項１０】
所定の前記プロトコルシーケンスは、前記プロトコルの確立シーケンスであることを特徴とする請求項６、７、８又は９記載の移動体パケット通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、移動体パケット通信システム及びそのヘルスチェック方法に係り、詳しくは対向元のプロトコル終端装置から対向先のプロトコル終端装置への制御情報（ＧＴＰ
ｅｃｈｏによるヘルスチェックの要否情報等）を通知するのに有用な移動体パケット通信システム及びそのヘルスチェック方法に関する。
【背景技術】
【０００２】
現在採用されている３ＧＰＰ（３ｒｄ Generation  Partnership Project）で規定されているトネリングプロトコルＧＴＰにおいては、ＧＴＰ終端装置間のＧＴＰ ｅｃｈｏによるヘルスチェック、例えば、ＲＮＣ（Radio Network Controller equipment）−ＳＧＳＮ（Serving ＧＰＲＳ Support Ｎode）（ＧＰＲＳ(General Packet Radio Service)間、ＳＧＳＮ−ＧＧＳＮ（Gateway ＧＰＲＳ Support Ｎode））間、ＲＮＣ−ＧＧＳＮ間のＩＰパスを含む対向装置のヘルスチェックは、ＡｃｔｉｖｅなＰＤＰ ｃｏｎｔｅｘｔを持つ装置間で周期的に信号（ＧＴＰ ｅｃｈｏ ｒｅｑｕｅｓｔ）（ＧＴＰ（ＧＰＲＳ Tunneling Protocol））を送信し、その応答（ＧＴＰ ｅｃｈｏ ｒｅｓｐｏｎｓｅ）の受信の有無を確認することによって行われている。
そして、このようなヘルスチェックを行うのに用いられるＧＴＰ ｅｃｈｏは、各装置のＩＰアドレス単位で送受信される。ここで、各装置とは、ＲＮＣ、ＳＧＳＮ及びＧＧＳＮの各々をいう。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら、上述した公知技術では、ＧＴＰ終端装置間のＧＴＰ ｅｃｈｏによるヘルスチェックは、対向するすべてのＧＴＰ終端装置に対して「実施する」、或るいは、「実施しない」の選択しかできず、対向する一部のＧＴＰ終端装置に対して「実施する」、或るいは、「実施しない」を選択することはできなかった。
このため、従来、ヘルスチェックを実施する場合は、対向するすべてのＧＴＰ終端装置に対してＧＴＰ ｅｃｈｏによるヘルスチェックが実施されることになる上、ＧＴＰ終端装置間のＧＴＰ ｅｃｈｏによるヘルスチェックを行うのに用いられるＧＴＰ ｅｃｈｏは、各ＧＴＰ終端装置のＧＴＰ終端ＩＰアドレス単位で送受信されるため、ＧＴＰ終端装置数やＧＴＰ終端ＩＰアドレス数が増加すると、ヘルスチェック実施負荷、例えば、ＧＴＰ ｅｃｈｏの処理負荷やトラヒックが、ＧＴＰ終端装置やＧＴＰ終端装置間を接続するＩＰネットワーク装置の処理能力を圧迫するという問題があった。加えて、ヘルスチェック対象のＩＰアドレスの管理数や管理テーブルサイズも増加するという問題もあった。
【０００４】
この発明は、上述の事情に鑑みてなされたもので、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否情報等（対向元のプロトコル終端装置から対向先のプロトコル終端装置への制御情報）の伝達をプロトコル終端装置のプロトコル終端アドレス単位で行い得る移動体パケット通信システム及びそのヘルスチェック方法を提供することを目的としている。
【課題を解決するための手段】
【０００５】
上記課題を解決するために、この発明の第１の構成は、所定のプロトコルを終端する装置間でヘルスチェック用の信号を送受信して対向元の前記装置と対向先の前記装置との間のプロトコルパスを含む対向装置のヘルスチェックを行う移動体パケット通信システムのヘルスチェック方法に係り、対向元の前記装置が、自装置に予め登録されている「自装置に対する前記ヘルスチェックを実施するか否か」の要否情報を、前記プロトコルを構成する所定のプロトコルシーケンス中のプロトコルメッセージに設けられている所定の情報要素に設定して、対向先の前記装置へ通知することを特徴としている。
この発明の第２の構成は、所定のプロトコルを終端する装置間でヘルスチェック用の信号を送受信して対向元の前記装置と対向先の前記装置との間のプロトコルパスを含む対向装置のヘルスチェックを行う移動体パケット通信システムに係り、対向元の前記装置が、自装置に予め登録されている「自装置に対する前記ヘルスチェックを実施するか否か」の要否情報を、前記プロトコルを構成する所定のプロトコルシーケンス中のプロトコルメッセージに設けられている所定の情報要素に設定する設定手段と、前記要否情報が設定された前記プロトコルメッセージを対向先の前記装置へ通知する通知手段とを備えていることを特徴としている。
【発明の効果】
【０００６】
この発明の構成によれば、プロトコル終端アドレス毎に、移動体パケット通信システムのヘルスチェックの要否情報を通知することができる。
【発明を実施するための最良の形態】
【０００７】
この発明は、所定のプロトコルを終端する装置間で所定の制御を行うために用いる制御情報（移動体パケット通信システムのヘルスチェックの要否情報）を対向元の上記装置から対向先の上記装置へ通知するのに、上記制御情報を、上記プロトコルを構成する所定のプロトコルシーケンス中のプロトコルメッセージに設定することを含んで構成される。
【実施形態１】
【０００８】
図１は、この発明の実施形態１である移動体パケット通信システムのＧＴＰ終端装置間構成を示す図、図２は、同移動体パケット通信システムのＧＴＰ終端装置間で送受されるプロトコルメッセージのシーケンスを示す図、また、図３は、同移動体パケット通信システムのＧＴＰ終端装置で実施されるヘルスチェックの処理フローを示す図である。
この実施形態の移動体パケット通信システム１０は、ヘルスチェックを実施するか否かの要否情報をＧＴＰトネル確立シーケンス中のプロトコルメッセージに設定してヘルスチェック対象のＧＴＰ終端装置（ノード）に通知してそのレスポンスに基づいてヘルスチェックの実施の有無を判断するシステムに係り、移動体パケット通信システム１０のヘルスチェックの対象ノードには、図１に示すように、移動体パケット通信システム１０においてＧＴＰ終端装置であるＲＮＣ１１と、ＳＧＳＮ１２と、ＧＧＳＮ１３とがある。ＲＮＣ、ＳＧＳＮ及びＧＧＳＮは、単に装置ともいう。
【０００９】
ＲＮＣ１１は、無線リソースの管理、無線基地局装置の制御等を行う無線制御装置である。ＲＮＣ１１は、ＧＴＰＵ−ｐｌａｎｅを終端する。
ＳＧＳＮ１２は、自己との間で在圏関係にする移動局（ＵＥ（Ｕser Ｅquipment））の発着信を制御するノードである。ＳＧＳＮ１２は、ＧＴＰＣ−ｐｌａｎｅ及びＧＴＰＵ−ｐｌａｎｅを共に終端する。
ＧＧＳＮ１３は、他のデータ通信網から受信したパケットをＳＧＳＮ１３へ転送するノードである。ＧＧＳＮ１３は、ＧＴＰＣ−ｐｌａｎｅ及びＧＴＰＵ−ｐｌａｎｅを共に終端する。
【００１０】
ＲＮＣ１１、ＳＧＳＮ１２及びＧＧＳＮ１３は、いずれも、保守操作等でＧＴＰｅｃｈｏによるヘルスチェックの要否を自装置のＧＴＰ終端ＩＰアドレス単位に登録する機能を有している。
各装置は、プロトコルメッセージであるＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｑｕｅｓｔ及びＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｓｐｏｎｓｅ（ＲＡＢ（Radio Access Bearer））、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔ及びＣｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅ、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔ及びＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅの新規なパラメータ（ＧＴＰ ｅｃｈｏ要求(ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄ)）にヘルスチェックの要否を設定して対向装置に通知する機能を有する。
【００１１】
ＲＮＣ−ＳＧＳＮ間には、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｑｕｅｓｔ及びＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｓｐｏｎｓｅを使用し、また、ＳＧＳＮ−ＧＧＳＮ間には、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔ及びＣｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅを使用してＰＤＰ ｃｏｎｔｅｘｔを使用可能（Ａｃｔｉｖｅ）にする機能が構築されている。
また、ＳＧＳＮ−ＧＧＳＮ間では、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔ及びＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅを使用してＡｃｔｉｖｅなＰＤＰ Ｃｏｎｔｅｘｔを保持するＳＧＳＮのＩＰアドレスを切り替える機能が構築されている。
上述した各機能は、各装置及び各装置間においてプログラムで実施し得るように構成されている。そして、装置間毎に、一方の装置が対向元の装置となり、他方の装置が対向先の装置となる。
【００１２】
次に、図１及び図２を参照して、この実施形態の動作について説明する。
ＲＮＣ１１、ＳＧＳＮ１２及びＧＧＳＮ１３の各々は、保守操作等を用いてＧＴＰ ｅｃｈｏによるヘルスチェックの要否（ＧＴＰ ｅｃｈｏ ｒｅｑｕｅｓｔ送信を対向装置に要求するか否か）を自装置のＧＴＰ終端ＩＰアドレス単位に登録する（図２のＳ２１）。
ＳＧＳＮ１２は、ＵＥ（図２）からプロトコルメッセージであるＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを受信すると（図２のＳ２２）、ヘルスチェックの要否の登録情報を参照する。登録済みのとき登録済みの情報を、プロトコルメッセージであるＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＱＥＳＴｒｅｑｕｅｓｔに新規追加の情報要素（新規なパラメータ）ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＲＮＣ１１に送信する（図２のＳ２３）。
【００１３】
ＲＮＣ１１は、送信されて来たプロトコルメッセージを受信し（図３のステップＳ３１）、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｑｕｅｓｔの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されている値を元にして、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｑｕｅｓｔに設定されたＳＧＳＮ１２のＧＴＰ終端ＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する（図３のステップＳ３２）。
【００１４】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＲＮＣ１１）が対向する装置（このプロトコルシーケンスではＳＧＳＮ１２）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００１５】
この処理と並行して、ＲＮＣ１１は、登録済みのヘルスチェック要否を、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ｒｅｓｐｏｎｓｅ（図２のＳ２４）の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＳＧＳＮ１２へ送信する。
ＳＧＳＮ１２は、送信されて来たプロトコルメッセージを受信し（図３のステップＳ３１）、送信されて来たプロトコルメッセージを受信し（図３のステップＳ３１）、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴｒｅｓｐｏｎｓｅの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されている値を元にして、ＲＡＢ ＡＳＳＩＧＮＭＥＮＴ ＲＥＳＰＯＮＳＥに設定されたＲＮＣ１１のＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する。
【００１６】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＳＧＳＮ１２）が対向する装置（このプロトコルシーケンスではＲＮＣ１１）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００１７】
また、ＳＧＳＮ１２において、ＵＥからＡｃｔｉｖａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを受信すると（図２のＳ２２）、ＳＧＳＮ１２は、ＧＧＳＮ１３に対してＣｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを送信する。このプロトコルメッセージ、すなわち、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに、ヘルスチェックの要否の登録情報を設定してＧＧＳＮ１３に通知する（図２のＳ２５）。
【００１８】
その通知を受けたＧＧＳＮ１３は（図３のＳ３１）、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されている値を元に、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔに設定されたＳＧＳＮ１２のＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する（図３のステップＳ３２）。
【００１９】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＧＧＳＮ１３）が対向する装置（このプロトコルシーケンスではＳＧＳＮ１２）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００２０】
この処理と並行して、ＧＧＳＮ１３は、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを受信すると、ＧＧＳＮ１３は、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ＲｅｓｐｏｎｓｅをＳＧＳＮ１２に対して送信する。この送信において、登録済みのヘルスチェック要否を、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＳＧＳＮ１２に通知する（図２のＳ２６）。
【００２１】
この通知を受けたＳＧＳＮ１２は（図３のＳ３１）、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定された情報要素の値を元に、Ｃｒｅａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されたＧＧＳＮ１３のＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する。
【００２２】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＳＧＳＮ１２）が対向する装置（このプロトコルシーケンスではＧＧＳＮ１３）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
ＳＧＳＮ１２は、Ａｃｔｉｖａｔｅ ＰＤＰ Ｃｏｔｅｘｓｔ ｒｅｑｕｅｓｔに対する応答であるＡｃｔｉｖａｔｅ ＰＤＰ Ｃｏｔｅｘｓｔ ＡｃｃｅｐｔをＵＥに返す。
【００２３】
このように、この実施形態の構成によれば、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否をＧＴＰ終端装置のＧＴＰ終端ＩＰアドレス単位で対向装置に通知してヘルスチェックを行うようにしたので、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否をＧＴＰ終端装置のＧＴＰ終端ＩＰアドレス単位で選択可能になる。
これにより、装置数や装置で使用するＩＰアドレス数が増加しても、ヘルスチェック対象のＩＰアドレスの管理数の増加は増大しない。ＧＴＰ ｅｃｈｏの処理負荷も、ヘルスチェック対象の管理テーブルサイズも増加しない。
【実施形態２】
【００２４】
図４は、この発明の実施形態２である移動体パケット通信システムのＧＴＰ終端装置間で送受信されるプロトコルメッセージのシーケンスを示す図である。
この実施形態の構成が、実施形態１のそれと大きく異なる点は、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否のＳＧＳＮからＧＧＳＮへの送信にＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを用い、ＧＧＳＮからＳＧＳＮへの応答を受けるのにＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅを用いるようにした点である。
すなわち、この実施形態の移動体パケット通信システム１０Ａを、図４に示すプロトコルメッセージのシーケンスで構成したことにその特徴部分がある。
この構成以外のこの実施例の構成は、実施形態１と同じであるので、同一の構成部分には同一の参照符号を付して、その逐一の説明は省略する。
【００２５】
次に、図４を参照して、この実施形態の動作について説明する。
ＳＧＳＮ１２及びＧＧＳＮ１３が保守手順等を用いてＧＴＰｅｃｈｏによるヘルスチェックの要否（ＧＴＰ ｅｃｈｏ ｒｅｑｕｅｓｔ送信を対向装置に要求するか否か）を自装置のＧＴＰ終端ＩＰアドレス単位に登録した（図４のＳ４１）後、移動体パケット通信システムにおいて、ＧＴＰ ｅｃｈｏによるヘルスチェックが開始されるとする。
このシステム状態になると、ＳＧＳＮ１２は、ヘルスチェック要否の登録情報を参照し、その登録情報をＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＧＧＳＮ１３に通知する（図４のＳ４２）。
【００２６】
その通知を受けたＧＧＳＮ１３は、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されている値を元に、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されたＳＧＳＮ１２のＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する。
【００２７】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＧＧＳＮ１３）が対向する装置（このプロトコルシーケンスではＳＧＳＮ１２）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００２８】
この処理と並行して、ＧＧＳＮ１３は、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを受信すると、登録済みのヘルスチェック要否を、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＳＧＳＮ１２に通知する（図４のＳ４３）。
【００２９】
この通知を受けたＳＧＳＮ１２は、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定された情報要素の値を元に、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されたＧＧＳＮ１３のＧＴＰ終端ＩＰアドレスに対するＧＴＰ ｅｃｈｏヘルスチェックの起動要否を判定する。
【００３０】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＳＧＳＮ１２）が対向する装置（このプロトコルシーケンスではＧＧＳＮ１３）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００３１】
このように、この実施形態の構成によれば、実施形態１と同様に、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否をＧＴＰ終端装置のＧＴＰ終端ＩＰアドレス単位で選択可能になる。
これにより、装置数や装置で使用するＩＰアドレス数が増加しても、ヘルスチェック対象のＩＰアドレスの管理数の増加は増大しない。ＧＴＰ ｅｃｈｏの処理負荷も、ヘルスチェック対象の管理テーブルサイズも増加しない。
【実施形態３】
【００３２】
図５は、この発明の実施形態３である移動体パケット通信システムのＧＴＰ終端装置間で送受信されるプロトコルメッセージのシーケンスを示す図である。
この実施形態の構成が、実施形態１のそれと大きく異なる点は、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否のＧＧＳＮからＳＧＳＮへの送信にＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを用い、ＳＧＳＮからＧＧＳＮへの応答にＵｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｓｐｏｎｓｅを用いるようにした点である。
すなわち、この実施形態の移動体パケット通信システム１０Ｂを、図５に示すプロトコルメッセージのシーケンスで構成したことにその特徴部分がある。
この構成以外のこの実施例の構成は、実施形態１と同じであるので、同一の構成部分には同一の参照符号を付して、その逐一の説明は省略する。
【００３３】
次に、図５を参照して、この実施形態の動作について説明する。
ＳＧＳＮ１２及びＧＧＳＮ１３が保守手順等を用いてＧＴＰｅｃｈｏによるヘルスチェックの要否（ＧＴＰ ｅｃｈｏ ｒｅｑ送信を対向装置に要求するか否か）を自装置のＧＴＰ終端ＩＰアドレス単位に登録した（図５のＳ５１）後、移動体パケット通信システムにおいて、ＧＴＰ ｅｃｈｏによるヘルスチェックが開始されるとする。
このシステム状態になると、ＧＧＳＮ１３は、ヘルスチェック要否の登録情報を参照し、登録済みの情報を、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔ（図５のＳ５２）に新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＳＧＳＮ１２に通知する。
【００３４】
その通知を受けたＳＧＳＮ１２は（図３のＳ３１）、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されている値を元に、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔに設定されたＧＧＳＮ１３のＧＴＰ終端ＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する。
【００３５】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＳＧＳＮ１２）が対向する装置（このプロトコルシーケンスではＧＧＳＮ１３）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００３６】
この処理と並行して、ＳＧＳＮ１２は、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ ｒｅｑｕｅｓｔを受信すると、登録済みのヘルスチェック要否を、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅに新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定してＧＧＳＮ１３に通知する（図５のＳ５３）。
【００３７】
この通知を受けたＧＧＳＮ１３は、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅの情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定された情報要素の値を元に、Ｕｐｄａｔｅ ＰＤＰ ｃｏｎｔｅｘｔ Ｒｅｓｐｏｎｓｅ内の新規追加の情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄに設定されたＳＧＳＮ１２のＧＴＰ終端ＩＰアドレスに対するＧＴＰ ｅｃｈｏによるヘルスチェックの起動要否を判定する。
【００３８】
その判定で、情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック要」である場合は（図３のステップＳ３２のヘルスチェック要）、受信した装置（このプロトコルシーケンスではＧＧＳＮ１３）が対向する装置（このプロトコルシーケンスではＳＧＳＮ１２）のＧＴＰ終端ＩＰアドレスとの間でＧＴＰ ｅｃｈｏによるヘルスチェックを実施する（図３のステップＳ３３）。
情報要素ＧＴＰ ｅｃｈｏ ｒｅｑｕｉｒｅｄの設定値が「ヘルスチェック不要」である場合には（図３のステップＳ３２のヘルスチェック否）、ヘルスチェックを実施しないか、既に、ヘルスチェックを実施中の場合はそのヘルスチェックを停止する（図３のステップＳ３４）。
【００３９】
このように、この実施形態の構成によれば、実施形態１と同様に、ＧＴＰ ｅｃｈｏによるヘルスチェックの要否をＧＴＰ終端装置のＧＴＰ終端ＩＰアドレス単位で選択可能になる。
これにより、装置数や装置で使用するＩＰアドレス数が増加しても、ヘルスチェック対象のＩＰアドレスの管理数の増加は増大しない。ＧＴＰ ｅｃｈｏの処理負荷も、ヘルスチェック対象の管理テーブルサイズも増加しない。
【００４０】
以上、この発明の実施例を、図面を参照して詳述してきたが、この発明の具体的な構成は、これらの実施例に限られるものではなく、この発明の要旨を逸脱しない範囲の設計の変更等があってもそれらはこの発明に含まれる。
例えば、いずれの実施形態も、トネリングプロトコルＧＴＰについて説明したが、この発明は、このトネリングプロトコルに限らず、その他のプロトコルで実施可能である。それに伴って、ＧＴＰ終端ＩＰアドレスも、その他の終端アドレスとなる。ＩＰアドレスは、また、その他のプロトコルパスとなる。
【産業上の利用可能性】
【００４１】
ここに開示している制御情報通信方法及び情報通信システムは、同種の通信システムで利用し得る。
【図面の簡単な説明】
【００４２】
【図１】この発明の実施形態１である移動体パケット通信システムのＧＴＰ終端装置間構成を示す図である。
【図２】同移動体パケット通信システムのＧＴＰ終端装置間で送受されるプロトコルメッセージのシーケンスを示す図である。
【図３】同移動体パケット通信システムのＧＴＰ終端装置で実施されるヘルスチェックの処理フローを示す図である。
【図４】この発明の実施形態２である移動体パケット通信システムのＧＴＰ終端装置間で送受信されるプロトコルメッセージのシーケンスを示す図である。
【図５】この発明の実施形態３である移動体パケット通信システムのＧＴＰ終端装置間で送受信されるプロトコルメッセージのシーケンスを示す図である。
【符号の説明】
【００４３】
１０、１０Ａ、１０Ｂ      移動体パケット通信システム
１１      ＲＮＣ（設定手段の１つ、通知手段の１つ）
１２      ＳＧＳＮ（設定手段の１つ、通知手段の１つ）
１３      ＧＧＳＮ（設定手段の１つ、通知手段の１つ）
【図１】
0005292856.tif 000002
【図２】
0005292856.tif 000003
【図３】
0005292856.tif 000004
【図４】
0005292856.tif 000005
【図５】
0005292856.tif 000006