JP2005260972A - Ｇｐｒｓトンネリング・プロトコル・パス保全プロトコル - Google Patents

Abstract

【課題】呼またはパスをセットアップするときにパスまたは経路を選択するノードでのネットワーク状況認識を高めるシステムおよび方法を提供する。
【解決手段】ネットワークの各ノードにパス保全表を構築し、維持することにより、ネットワーク効率が改善される。表は、各ノードに関連付けられたパスのパス保全情報を含む。パスは、発信元アドレス、宛先アドレスおよびポートまたはバージョン番号によって定義される。ノードが、パスに関連付けられたネットワーク・メッセージ・トラフィックを処理することにより、または手動入力によりパスを認識すると、そのノードは、通常のネットワーク・メッセージ・トラフィックによって提供される情報を用いて、あるいは提供されない場合は、エコー要求メッセージを送信し、エコー応答メッセージまたはそれがないことに関連する情報を処理することによってパス状況情報を維持する。
【選択図】図７

Description

本開示は、通信ネットワーク中のノードの状態に関する情報を蓄積し、維持するシステムおよび方法を対象とする。蓄積された情報は、ネットワークの呼処理、その他のネットワーク部分のため利用され得る。蓄積された情報を提供することにより、呼処理などのネットワーク活動に際して効率を高めることが可能になる。以下では、各実施形態を、第３世代パートナーシップ・プロジェクト（３ＧＰＰ）ユニバーサル移動通信システム／汎用パケット無線サービス（ＵＭＴＳ／ＧＰＲＳ）ネットワークを参照して説明する。しかしながら、各実施形態は、他のネットワーク環境で使用するためにも適合され得る。

第３世代パートナーシップ・プロジェクトは、いくつかの遠隔通信標準機関の間の協力協定である。３ＧＰＰは、通信ネットワークの開発および実施に際して機器製造者および通信サービス提供者を指導する技術仕様および技術報告書を策定し、公表する。３ＧＰＰに関する詳細は、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇに記載されている。３ＧＰＰの郵便宛先は、650 Route des Lucioles, Sophia Antipolis, Valbonne, Franceである。

図１を参照すると、３ＧＰＰが配布した標準によりアドレス指定された例示的ネットワーク部分１１０は、モバイル機器１１４、ノードＢまたはセル・サイト１１８、無線ノード制御装置（ＲＮＣ）１２２、第１のサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）１２４、第１のゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）１２８、課金ゲートウェイ機能（ＣＧＦ）１３２、第２のＳＧＳＮ１３６および第２のＧＧＳＮ１４２を含む。

例えば、モバイル機器は、移動通信ネットワークとインターフェイスするようになされた携帯電話、ラップトップ・コンピュータ、携帯情報端末他の機器である。ノードＢ１１８は、基地局またはネットワーク無線受信機である。ノードＢ１１８は、セル・サイトの主要構成要素であり、モバイル機器１１４とネットワークのその他の部分（１２２、１２４、１２８、１３６、１４２）の間のリンクとして働く。

ＲＮＣ１２２は、ノードＢ１１８および複数の他のノードＢ（図示せず）の動作を制御し、調整する。例えば、ＲＮＣ１２２は、モバイル機器１１４が他のノードＢの範囲から出てネットワーク部分１１０のノードＢ１１８の範囲内に入るときに、複数の他のノードＢとネットワーク部分１１０のノードＢ１１８の間のハンドオフを調整する。また、ＲＮＣ１２２は、ノードＢ１１８（およびその他のノードＢ）とネットワークの残りの部分（１２４、１２８、１３６、１４２など）の間のリンクとしても働く。

第１のＳＧＳＮ１２４は、ＲＮＣ１２２とネットワークのその他の部分（１２８、１３６など）の間のゲートウェイとして働く。例えば、第１のＳＧＳＮ１２４は、スイッチング要素として働き、ＲＮＣとの間のメッセージ・トラフィックを、ネットワーク中の他のポイント（１２８、１３６、１４２など）との間で宛先指定する。第１のＧＧＳＮ１２８は、例示的ネットワーク部分１１０と別のネットワークの間のゲートウェイとして働く。例えば、第１のＧＧＳＮ１２８は、例示的ネットワーク１１０と公衆データ網１４６の間のゲートウェイとして働く。

第１のＳＧＳＮ１２４は、ＲＮＣ１２２との間のメッセージ・トラフィックを、第２のＳＧＳＮ１３６との間でも宛先指定し得る。例えば、第２のＳＧＳＮは、他の無線ノード制御装置（図示せず）への、したがって、他のノードＢへのインターフェイスとして働く。着呼側が別のモバイル・ネットワークに関連付けられている場合、第１のＳＧＳＮ１２４はＲＮＣ１２２と第２のＧＧＳＮ１４２の間でメッセージ・トラフィックを渡し得る。というのは、第２のＧＧＳＮ１４２が、例示的ネットワーク１１０と他の公衆陸上モバイル・ネットワーク１５０の間のゲートウェイまたはインターフェイスとして働くからである。

課金ゲートウェイ機能１３２は、会計装置である。ＣＧＦ１３２は、加入者（モバイル機器１１４のユーザなど）の課金勘定または借方勘定のための課金データ記録（ＣＤＲ）を受け取る。

例えば、３ＧＰＰ技術仕様公開ＴＳ２９．０６０などで概説されるように、例示的ネットワーク１１０などのネットワークにおける制御機能は、たとえば、ＳＧＳＮ（１２４、１３６など）とＧＧＳＮ（１２８、１４２など）の間のＧＴＰ−Ｃまたは制御プレーン・メッセージの交換を介して達成される。しかしながら、ＲＮＣとＳＧＳＮの間のｌｕ−ｐｓインターフェイスでは、制御プレーンは、広帯域ＳＳ７標準により無線アクセス・ネットワーク適用部分（ＲＡＮＡＰ）メッセージを伝送するのに使用される非同期転送モード（ＡＴＭ）技術に基づくものであり、ＧＴＰ−Ｕはユーザ・プレーンを提供する。これは、ＰＤＰ（パケット・データ・プロトコル）コンテキストに関連付けられたユーザ・パスが使用不能になっているときでさえも、ＰＤＰコンテキスト全体が確立され得ることを意味する。ＳＧＳＮノードとＧＧＳＮノードの間でも同様の問題が生じ得る。というのは、ＧＴＰ−ＣパスとＧＴＰ−Ｕパスが異なり得るからである。例えば、ＧＰＴポート番号は異なり得る。実際、現在の標準は、選択されたパスが現在利用可能であるという想定の下でＰＤＰコンテキストをセットアップすることを求める。この想定が誤っていることが判明すると、システム・オーバーヘッドが悪影響を受ける。メッセージは、数回の再試行に失敗するまで再送される。また、負荷分割アルゴリズムは、ロードされていないパスに、それらのパスがロードされていない理由はそれらが使用不能であり、あるいは管理上ロックされているからであることに気づかずにメッセージ・トラフィックを流そうとする。したがって、繰り返し再試行を行うためにネットワーク・リソースが無駄になり、通話が遅延し、かつ／または途切れることがある。
第３世代パートナーシップ・プロジェクト（３ＧＰＰ）ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ ３ＧＰＰ技術仕様公開ＴＳ２９．０６０ Recommendation X.731 of the International Telegraph and Telephone Consultative Committee (CCITT) of the International Telecommunication Union (ITU)

少なくとも前述の理由により、ネットワーク・メッセージ・トラフィックのために呼またはパスをセットアップするの、パスまたは経路を選択するノードのネットワーク状況認識を高めるシステムおよび方法が求められている。

ＵＭＴＳ／ＧＰＲＳネットワークにおいて改善されたＧＴＰパス保全保証を提供する方法は、ＧＴＰメッセージを受信する工程と、ＧＴＰメッセージに含まれる情報からレコードのパス保全表を構築する工程と、ＧＰＲＳネットワークの呼処理およびＯＡＭサブシステムからこのパス保全表中の情報を利用できるようにする工程とを含む。例えば、パス保全表中の各レコードは、パス定義、運用状態エントリおよびタイム・スタンプ・エントリを含む。パス定義は、少なくとも、発信元ＩＰアドレス、宛先ＩＰアドレスおよびポート番号を含む。運用状態エントリは、「使用可能」、「使用不能」、「不明」から選択された値を持ち得る。タイム・スタンプ・エントリは、そのレコードが最後に更新された時刻の情報を示す値を含む。また、この方法は、表中にレコードを持つパス定義に関連付けられた追加のＧＴＰメッセージを受信したときに、パス保全表中のレコードを更新する工程も含み得る。レコードは、追加のメッセージに含まれる情報に基づいて更新される。期待されるメッセージを受信しなかったとき、レコードは、期待されるメッセージを受信しなかったことに基づいて更新される。

ＧＴＰメッセージを受信する工程は、ＧＴＰ−Ｕメッセージおよび／またはＧＴＰ−Ｃメッセージを受信する工程を含み得る。例えば、ＧＴＰメッセージを受信する工程は、ＰＤＰコンテキスト作成要求メッセージ、ＧＴＰエコー要求メッセージ、ＧＴＰエコー応答メッセージ、ＰＤＰコンテキスト作成応答メッセージ、ＧＴＰユーザ・データグラムを受信する工程などを含み得る。また、ＧＴＰメッセージを受信する工程は、ノードのリソースに管理状態変更が行われたときにそのノードにより送信され得る、本明細書で無償ＧＴＰエコー応答メッセージと呼ぶ新しい種類のメッセージを受信する工程も含み得る。

この方法は、パスに関する管理状態情報を受け取る工程と、パス定義に関連付けてパス保全プロトコル表の管理状態エントリに管理状態情報を格納する工程とを含み得る。前述したように、いくつかの実施形態では、これが行われるとき、この方法は、別のノードに新しい管理状態を知らせるための管理状態エントリの値を指示する無償ＧＴＰエコー応答メッセージを送信する工程を含む。例えば、管理状態情報は、無償ＧＴＰエコー応答メッセージの回復情報要素内の再始動カウンタと、ローカルまたは受信側ノードの表に格納された再始動カウンタ値の比較から、受信側ノードによって推論され得る。

パス保全表中のレコードを更新する工程は、表中のレコードのタイム・スタンプ・エントリの値を現在時刻と比較してレコードの存続時間を求める工程と、所望のレコード存続時間限界より大きい存続時間を有する任意のレコードに関連付けられたポート番号と宛先ＩＰアドレスに、そのレコードに関連付けられた発信元ＩＰアドレスを含むＧＴＰエコー要求を送信する工程と、ＧＴＰエコー要求に関連付けられた受信ＧＴＰエコー応答またはそれがないことに基づいて任意のレコードのエントリを更新する工程とを含み得る。

例えば、レコードのエントリを更新する工程は、ＧＴＰエコー応答メッセージを受信する工程と、運用状態エントリを「使用可能」に、タイム・スタンプ・エントリをＧＴＰエコー応答メッセージに関連付けられた時刻に更新する工程とを含み得る。ＧＴＰエコー応答メッセージを受信しなかったと判定された場合、この方法は、再試行カウンタ値を再試行限界と比較する工程と、再試行カウンタ値が再試行限界より小さい場合、別のＧＴＰエコー要求を送信する工程と、再試行カウンタを増分する工程と、運用状態エントリを「不明」に更新する工程とを含み得る。ＧＴＰエコー応答メッセージを受信しなかったと判定された場合、この方法は、再試行カウンタ値を再試行限界と比較する工程と、再試行カウンタ値が再試行限界以上である場合、運用状態エントリを「使用不可」に更新する工程と、タイム・スタンプ・エントリを運用状態エントリの「使用不可」への更新に関連付けられた時刻に更新する工程とを含み得る。

いくつかの実施形態では、運用状態エントリが使用不可に設定されたとき、この方法は、パス保全表中のパス定義に関連付けられたパス使用不可タイム・スタンプ・エントリを、運用状態エントリの「使用不可」への更新に関連付けられた時刻に設定する工程を含む。それらの実施形態は、パス使用不可タイム・スタンプ・エントリを現在時刻と比較し、それによってパス使用不可期間を判定し、そのパス使用不可期間が所定のパス使用不可制限時間より大きい場合、パス保全表からそのパス定義に関連付けられたレコードを削除する工程も含み得る。

パス保全表を構築する工程は、少なくとも発信元ＩＰアドレス、宛先ＩＰアドレスおよびポート番号を含む手動入力のパス定義を含むレコードを手動入力する工程をさらに含み得る。

例示的実施形態では、ＵＭＴＳ／ＧＰＲＳネットワークで改善されたＧＴＰパス保全保証を提供する方法は、第１のノードＩＰアドレス、第２のノードＩＰアドレスおよびＵＤＰポート番号に基づいてパスを定義する工程と、第１のノードで、第２のノードから第１のＧＴＰメッセージを受信する工程と、第１のＧＴＰメッセージから第１のノードＩＰアドレスを抽出する工程と、第１のＧＴＰメッセージから第２のノードＩＰアドレスを抽出する工程と、第１の受信メッセージに基づいてパスの運用状態を判定する工程と、パス定義および第１のＧＴＰメッセージを受信した時刻に関連するタイム・スタンプと関連付けてパス保全表にパスの運用状態を格納する工程とを含む。

パスを定義する工程は、静的な第１のノードＩＰアドレス、静的な第２のノードＩＰアドレスおよび静的なＵＤＰポート番号に基づいて静的パスを定義する工程と、その静的パス定義をパス保全表にパス・エントリとして格納する工程とを含み得る。代替として、またはそれに加えて、パスを定義する工程は、動的な第１のノードＩＰアドレス、動的な第２のノードＩＰアドレスおよびＵＤＰポート番号に基づいて動的パスを定義する工程も含み得る。パスを定義する工程は、一様な、または標準のＵＤＰポート番号に基づいてパスを定義する工程も含み得る。

この方法は、タイム・スタンプの値と現在時刻の差を求める工程と、タイム・スタンプの値と現在時刻の差が所定のリフレッシュ時間より大きい場合、ＵＤＰポート番号を使用し、第１のノードＩＰアドレスを発信元アドレスとして、第２のノードＩＰアドレスを宛先アドレスとして使用して、第１のノードから第２のノードにＧＴＰエコー要求メッセージを送信する工程とを含み得る。

例えば、ローカル・ノードが無線ノード制御装置である場合、この方法は、無線ノード制御装置からＧＴＰエコー要求を送信する工程を含み得る。

第２のノードから第１のＧＴＰメッセージを受信する工程は、例えば、前述のような、ＰＤＰコンテキスト作成要求、ＧＴＰエコー要求メッセージ、ＰＤＰコンテキスト作成応答メッセージ、ＧＴＰユーザ・データグラム、無償ＧＴＰエコー応答メッセージ、あるいはその他のＧＴＰメッセージを受信する工程を含み得る。

また、この方法は、第１のノードで、第２のノードから第２のＧＴＰメッセージを受信する工程と、第２のＧＴＰメッセージから第１のノードＩＰアドレスを抽出する工程と、第２のＧＴＰメッセージから第２のノードＩＰアドレスを抽出する工程と、第２のＧＴＰメッセージからＵＤＰポート番号を抽出する工程と、第１のノードＩＰアドレス、第２のノードＩＰアドレスおよびＵＤＰポート番号に基づいてパス定義を決定する工程と、第２の受信メッセージに基づいてパスの運用状態を判定する工程と、パス保全表中のパス定義に関連付けられた運用状態エントリを更新する工程と、第２のＧＴＰメッセージを受信した時刻に関連する値でタイム・スタンプを更新する工程も含み得る。

第２のノードが送信されたＧＴＰエコー要求メッセージに応答していないと判定された場合、この方法は、第２のノードが送信されたＧＴＰエコー要求メッセージに応答していないという判定に基づいてパスの運用状態が「使用不能」であると判定する工程と、パス保全表中のパス定義に関連付けられた運用状態エントリを「使用不能」に更新する工程と、第２のノードが送信されたＧＴＰエコー要求メッセージに応答していないという判定に関連する値でタイム・スタンプを更新するする工程とを含み得る。これらの状況下では、この方法は、パス使用不能タイム・スタンプ・エントリを、第２のノードが送信されたＧＴＰエコー要求メッセージに応答していないという判定に関連する値に設定する工程も含み得る。また、この方法は、パス使用不能期間が所定のパス使用不能制限期間より大きい場合、パス保全表からパス定義および関連情報を削除する工程も含み得る。

ＧＴＰエコー応答を受信しなかったと判定された場合、この方法は、パスの運用状態を「不明」に更新する工程と、ポート番号を使用し、第１のノードＩＰアドレスを発信元アドレスとして、第２のノードＩＰアドレスを宛先アドレスとして使用し、第１のノードから第２のノードに第２のＧＴＰエコー要求メッセージを送信する工程とを含み得る。
いくつかの実施形態では、この方法は、第１のＧＴＰメッセージから再始動カウンタ値を抽出する工程と、その再始動カウンタ値をパス保全表にパス定義と関連付けて格納する工程とを含む。

いくつかの実施形態は、パス保全表にパス定義と関連付けてパスの管理状態を格納する工程を含む。

いくつかの実施形態では、この方法は、パスに関する管理状態情報を受け取る工程と、パス定義と関連付けてパス保全プロトコル表の管理状態エントリに管理状態情報を格納する工程とを含む。これらの実施形態の一部では、この方法は、無償ＧＴＰエコー要求メッセージを送信する工程を含む。

好ましくは、パス保全プロトコル表中の情報を用いてネットワーク効率が改善される。例えば、この方法は、パス上にＧＴＰトンネルをセットアップしようとする前にパスの運用状態を判定するためにパス保全表を調べる工程と、パス保全表がそのパスが使用不能または不明であることを指示している場合、そのＧＴＰトンネルの代替の経路を選択する工程とを含み得る。

パス保全方法を実行するように動作するノードの一実施形態は、主要なネットワーク・ノード機能ブロックと、そのＵＭＴＳ／ＧＰＲＳネットワーク・ノードの他の構成要素によってそうするように指図されたときにＵＭＴＳ／ＧＰＲＳネットワーク中の他のノードにＧＴＰエコー要求を送信し、そのＵＭＴＳ／ＧＰＲＳネットワーク・ノードの他の構成要素によって指図されたようにＵＭＴＳ／ＧＰＲＳネットワーク中の他のノードからＧＴＰエコー応答メッセージを受信し、それを処理するように動作するＧＴＰエコー要求／応答プロセッサと、そのノードに関連付けられたネットワーク・メッセージ・トラフィックからパス保全情報を抽出し、抽出した情報をパス保全プロトコル表に記録することによってパス保全プロトコル表を構築し、そのノードに関連付けられた追加のネットワーク・メッセージ・トラフィックから更新されたパス保全情報を抽出し、抽出した更新情報を表に記録することによって表に記録された情報を更新し、表に格納された記録情報の存続時間を監視し、ＧＴＰエコー要求／応答プロセッサに、古い表の情報に関連付けられたパスを介してＧＴＰエコー要求を送信し、それらのＧＴＰエコー要求に関連付けられたＧＴＰエコー応答メッセージを受信したこと、または受信しなかったことに関してパス保全プロトコル・モジュールに情報を提供するように指図することによって表中の古い情報を更新するように動作するパス保全プロトコル・モジュールであって、さらに、ＧＴＰエコー要求／応答プロセッサによってパス保全プロトコル・モジュールに提供された情報に基づき、古い記録情報を新しい情報で置き換えるように動作するパス保全プロトコル・モジュールを含む、ＵＭＴＳ／ＧＰＲＳネットワーク・ノードである。

主要なネットワーク・ノード機能ブロックは、無線ノード制御装置主要機能ブロック、サービングＧＰＲＳサポート・ノード主要機能ブロック、および／またはゲートウェイＧＰＲＳサポート・ノード主要機能ブロックとし得る。

パス保全プロトコル・モジュールは、ＰＤＰコンテキスト作成要求メッセージ・トラフィック、ＧＴＰエコー要求メッセージ・トラフィック、ＧＴＰエコー応答メッセージ・トラフィック、ＰＤＰコンテキスト作成応答メッセージ・トラフィック、ＧＴＰユーザ・データグラム・メッセージ・トラフィックまたはその他のメッセージ・トラフィックからパス保全情報を抽出することによってパス保全プロトコル表を構築するように動作し得る。
パス保全プロトコル・モジュールは、さらに、ノードに関連付けられたネットワーク・メッセージ・トラフィックからパス定義およびパス運用状態情報を抽出し、抽出した情報をパス保全プロトコル表に記録することによってパス保全プロトコル表を構築するように動作し得る。例えば、パス定義情報は、ノードに関連付けられたネットワーク・メッセージ・トラフィックから抽出された発信元ＩＰアドレス、宛先ＩＰアドレスおよびポート番号を含み得る。

パス保全プロトコル・モジュールは、さらに、ネットワーク・メッセージ・トラフィックから再始動カウンタ情報を抽出し、抽出したパス定義情報と関連付けでその再始動カウンタ情報を格納することによってパス保全プロトコル表を構築するように動作し得る。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、パス情報に関連付けられたパスの運用状況が、パス使用不能制限期間より長い間「使用不能」であったとき、パス保全表からパス情報を削除するように動作する。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、手動のパス定義入力を受け入れ、手動のパス定義入力に関連付けられたレコードをパス保全プロトコル表に含めるように動作する。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、パス定義レコードに関連付けられた手動入力の管理状態情報を受け入れ、手動入力の管理状態情報に従ってパス定義レコードに関連付けられたパス保全プロトコル表中の管理状態エントリを更新するように動作する。それらの実施形態の一部では、パス保全プロトコル・モジュールは、さらに、管理状態エントリの値を表示する無償ＧＴＰエコー応答メッセージを送信するように動作する。

本発明は、様々な構成要素および構成要素の構成として、かつ／または様々な手順および手順の構成としての形を取り得る。図面は、好ましい実施形態を例示するためのものにすぎない。それらは基準とするものではなく、本発明を限定するものと解釈すべきではない。

現在、一部のＵＭＴＳ／ＧＰＲＳネットワーク・ノード（ＧＴＰエコー要求／応答（１５４など）を含むもの）は、ＧＴＰエコー要求メッセージを送信し、ＧＴＰエコー応答メッセージを受信、処理することにより、それに沿ったＰＤＰコンテキストがすでに確立されているパスの状況を判定することができる。しかしながら、それらのノードは、アクティブなＰＤＰコンテキストと現在関連付けられていないパスを介したＧＴＰエコー要求を認識せず、それらを送信することができない。さらに、無線ノード制御装置（ＲＮＣ）（例えば１２２）などのいくつかのノードには、従来、ＧＴＰエコー要求を送信するための装備を備えていない。パス状況情報を要求し、受信するための装備を備えているノードでさえも、その状況情報を格納する装備を備えていない。そうではなく、それらのノードは、そのノードの目的が必要とするときは常に、確立されたＰＤＰコンテキストに関連付けられたパスに沿って新しいＧＴＰエコー要求を送信する。したがって、それらのノード（１２２、１２４、１２８、１３６、１４２など）は、それに沿ったＰＤＰコンテキストが現在確立されていないパスの状況を全く認識せず、一部のノードだけが、それに沿ったＰＤＰコンテキストが確立されているパスの状況を判定し得る。前述したように、これは、例えば、ネットワークまたはネットワーク・ノードの障害などの場合には、リソースの無駄、サービス品質の低下、および通話の途切れをもたらし得る。

図２を参照すると、呼処理および／または運用管理維持（ＯＡＭ）プロセスは、ネットワーク・ノードがネットワーク状況またはパス保全情報に容易にアクセスできる場合、より効率的に行われ得る。この情報は、パス保全プロトコルに従って収集され、格納され得る。パス保全プロトコルは、呼処理および／またはＯＡＭ機能を有する各ネットワーク・ノード（ＲＮＣ、ＳＧＳＮ、ＧＧＳＮなど）ごとでのパス保全プロトコル表２１０の確立を求める。パス保全プロトコル（ＰＩＰ）表中の各エントリ２１４は、パス定義２１８およびそのパス定義２１８に関連付けられたその他の情報２２２を含む。各パス定義２１８は、第１のまたはローカル・ノードＩＰアドレス２２６、第２のまたはリモート・ノードＩＰアドレス２３０およびＵＤＰポート番号２３４またはＧＴＰバージョン番号を含む。パス定義２１８に関連付けられた情報２２２は、例えば、パスの種類２３８、管理状態２４２、運用状態２４６、タイム・スタンプ２５０、パス使用不能時刻２５４およびリモート・ノード再始動カウンタ２５８などを含む。

一意のＧＴＰパスは、２つの端点間の、ＧＴＰユーザ・データグラム・プロトコル／インターネット・プロトコル（ＵＤＰ／ＩＰ）コネクションレス、単方向または双方向パスである。ＩＰアドレスおよびＵＤＰポート番号はＧＴＰ端点を定義する。関連付けられた１対のＧＴＰ端点はＧＴＰパスを定義する。

ローカル・ノードＩＰアドレス２２６は、当該の特定のＰＩＰ表（２１０など）を構築し、維持するノードに関連付けられたＩＰアドレスである。リモート・ノードＩＰアドレス２３０は、そのローカル・ノードがやりとりする別のネットワーク装置に関連付けられたＩＰアドレスである。例えば、ローカル・ノードがＳＧＳＮである場合、ＰＩＰ表２１０は、ＲＮＣ、ＧＧＳＮおよび他のＳＧＳＮと関連付けられたリモート・ノード・アドレス・エントリ２３０を含み得る。

ＵＤＰポート番号は、ＧＴＰバージョンに直接関連付けられ、パスの両端点は同じＧＴＰバージョンを使用する。したがって、パスを定義（２１８）するには１つＵＤＰポート・エントリ２３４さえあればよい。しかしながら、拡張された、または異なるパス定義が予期される。ローカル・ノードで、リモート・ノードで使用されるものと異なるポート番号を使用するプロトコルが発展し、または開発された場合、ＰＩＰ表は、ローカルとリモートのＵＤＰポート番号またはＧＴＰバージョンを含むように拡張され得る。

パスの種類エントリ２３８は任意選択である。ＰＩＰ表（２１２など）にパスの種類エントリ２３８が含まれる場合、パスの種類エントリ２３８は、「静的」または「動的」の値を持ち得る。静的パスとは、そのためにリソースが永続的に割り当てられ、あるいは少なくとも長期間の間割り当てられているものである。動的パスは、ネットワーク・メッセージ・トラフィック・レベルが変化するときに、異なるパスに自動的に再割り振りされ得るリソースを介して確立される。

管理状態エントリ２４２も任意選択である。これが含まれる場合、管理状態エントリ２４２は、「ロック状態」または「ロック解除状態」の値を持ち得る。管理状態エントリ２４２は、手動で設定される。例えば、技術者が保守または修理のためにリソースをオフラインにするとき、技術者は、構成入力または調整を行ってそれをノードに通知する。それらの入力または構成は、ＰＩＰ表２１０の管理情報エントリ２４２にデータを取り込むのに必要な情報を提供する。

いくつかの実施形態では、管理状態エントリ２４２は、ローカル・ノードだけに関連する。他の実施形態では、ローカル・ノードに、リモート・ノードの管理状態を知らせることができ、そのため、管理状態エントリ２４２は、そのパス全体に関連し得る。例えば、以下でより詳細に説明するように、技術者がリモート・ノードを管理「ロック」状態にすると、そのリモート・ノードによって、更新された再始動カウンタ値を含む無償ＧＴＰエコー応答メッセージが送信され得る。代替として、ＰＩＰ表を、ローカル・ノードとリモート・ノードのそれぞれでの管理状態エントリを含むように拡張することもできる。

運用状態エントリ２４６の値は、ローカル・ノードによって決定される。例えば、パスの運用状態は、そのパスを介したＧＴＰメッセージを受信したこと、または受信しなかったことから判定され、導出され、または推論される。以下でより詳細に説明するように、運用状態エントリ２４６の値は、「使用可能」、「使用不能」、「不明」とすることができる。

管理状態パラメータおよび運用状態パラメータに関する詳細は、国際電気通信連合（ＩＴＵ）の国際電信電話諮問委員会（ＣＣＩＴＴ）の勧告Ｘ．７３１に記載されている。

ＰＩＰ表２１０中の各エントリ２１４は、パス定義２１８に関連付けられたデータ２２２の新しさを示すタイム・スタンプ・エントリ２５０を含む。パス・エントリ２１４に関連付けられたパス保全データが更新されるたびに、タイム・スタンプ・エントリ２５０は、現在時刻、または表の更新が遅延した場合には、パス保全判定に関連付けられた時間を反映するように修正される。

パス使用不能時刻エントリ２５４は第２のタイム・スタンプである。パス使用不能時刻エントリ２５４は、「使用不能」の値を持つ運用状態エントリ２４６に関連付けられているレコード２１４またはパス定義２１８にのみ有効である。パス使用不能時刻２５４は、パス２１８が使用不能であると最初に判定された時刻を示す。それに加えて、あるいは代替として、いくつかの実施形態では、パス使用不能時刻は、「ロック状態」の管理状態値を持つパスに関連付けられ、それについて有効とすることができる。

パス使用不能時刻エントリ２５４は、ＰＩＰ表２１０が大きくなり過ぎるのを防ぐと共に、多数の無効な、または無駄なエントリを含むのを防ぐために使用される。以下でより詳細に説明するように、パス使用不能時刻エントリ２５４が、動的パスに関連付けられたパス・エントリ２１４が、その動的パスが長期間の間使用不能になっており、またはロックされていることを示していると示しているとき、その動的パス・エントリ２１４は、ＰＩＰ表２１０から除去され、または追い出される。定義によれば、静的パスは、ＰＩＰ表２１０から自動的に消去されない。そうではなく、それらは、関連付けられたリソースが再割り振りされ、またはサービスを解除されたときに表２１０から手動で除去され得る。

リモート・ノード再始動カウンタ・エントリ２５８は任意選択である。以下でより詳細に説明するように、所与のパスのリモート・ノード再始動カウンタは、そのパスを介して受信したＧＴＰメッセージから判定され得る。ＧＴＰメッセージが、リモート・ノードの再始動カウントがそのパスでのリモート・ノード再始動カウンタ・エントリ２５８のカウント値と異なることを示している場合、そのリモート・ノードは最近再始動しており、そのパスに関連付けられたＰＤＰコンテキストは取り外され、かつ／または再確立される必要があると考えられる。

図３を参照すると、ＰＩＰ表（２１０など）を構築し、かつ／または維持する方法３１０は、パスを定義する工程３１４と、パス状況情報を受信する工程３１８と、定義されたパスにすでにエントリ（２１４など）が存在するかどうか判定する工程３２２とを含む。すでにエントリが存在する場合、方法３１０は、受信した（３１８）情報に基づいて定義されたパスのレコードまたはエントリ（２１４など）を更新する工程３２６を含む。３２２で、パスがまだＰＩＰ表に含まれていない場合、方法３１０は、そのパスのレコードまたはエントリ（２１４など）を加える工程３３０を含む。

パスは、技術者によって、システムの性能検証またはプロビジョニング（サービス提供）時に定義（３１４）され得る。例えば、技術者は、２つの端点間で予期されるメッセージ・トラフィックの最低限のレベルに適応するように静的パスを定義することができる。それに加えて、あるいは代替として、技術者は、動的パスを事前定義（および事前ロード）することもできる。代替として、パスは、呼処理および／または管理システム構成要素によっても動的に定義される。したがって、パス状況に関する情報は、ノードにおいて、手動の技術者入力から受け取られ得る（３１８）。また、パス状況情報は、通常のネットワーク・メッセージ・トラフィック処理の一部として受け取られ得る（３１８）。例えば、ＧＴＰメッセージは、その経路指定情報の一部としてパス定義を含む。少なくとも一部のＧＴＰメッセージ（ＧＴＰエコー応答、ＰＤＰコンテキスト作成要求など）は、例えば、リモート装置再始動カウンタ値などを含むリモート装置回復情報を運ぶ。ＧＴＰメッセージが定義されたパスに沿ってリモート装置から受け取られるということは、そのリモート装置に関連付けられたパスの管理状態エントリ２４２を「ロック解除状態」に設定すべきであり、そのパスの運用状態エントリ２４６を「使用可能」に設定すべきであることを表す。

本明細書では、説明を容易にするために、パス状況または状態情報を表に格納されているものとして記述しているが、状況情報は、実際には、何らかの電子的形態として格納される。例えば、ＰＩＰ表２１０情報は、データベースに格納され得る。状況または状態情報２２２は、適当なパス定義２１８またはパス・エントリ２１４と関連付けてそのデータベースに格納される。パス定義２１８は、そのデータベースへの一意のキーとして使用され、またはそれを生成するために使用され得る。パスがすでにＰＩＰ表に含まれているかどうか判定する工程３２２は、受け取った（３１８）パス情報を用いてデータベースへのキーを生成する工程を含み得る。キーに基づく問い合わせが結果をもたらした場合、そのパスはすでのＰＩＰ表に含まれており、受け取った（３１８）パス状況情報に基づいて状態情報２２２が更新され得る（３２６）。受け取った（３１８）パス定義に基づくデータベース問い合わせの結果３２２が、そのパスに関連付けられたレコードが存在しないことを示す場合、受け取った（３１８）パス定義および状態情報２２２を含み、またはそれらに関連付けられた新しいレコードが加えられる（３３０）。

例えば、ＵＭＴＳ／ＧＰＲＳネットワークでは、パス保全プロトコル表を構築し、維持する方法３１０の実施形態は、ＧＴＰパス保全プロトコル表を構築し、維持する方法４１０を含む。この方法は、ＧＴＰメッセージを受信する工程４１４と、ＧＴＰメッセージからパス情報を抽出する工程４１８と、抽出したパスがすでにパス保全プロトコル表に含まれているかどうか判定する工程４２２とを含む。４２２で、パス保全プロトコル表がすでに抽出したパスでのエントリを含む場合、ＧＴＰメッセージから抽出された（４１８）パス状況情報に基づいてそのパスの状況情報が更新される（４３０）。４２２で、パスがまだパス保全プロトコル表に含まれていない場合、抽出した（４１８）パス定義および関連するパス状況情報を含むレコードが加えられる（４２６）。例えば、ＧＴＰメッセージを受信したことは、そのパスが管理上ロック解除され、運用上使用可能であることを指示する。

パス状況情報は、受信した（４１４）ＧＴＰ−ＣメッセージとＧＴＰ−Ｕメッセージの両方から抽出され得る（４１８）。例えば、任意のＧＴＰメッセージを受信したことは、関連付けられたパスがロック解除され、使用可能であることを示す。ＧＴＰエコー応答、ＰＤＰコンテキスト作成およびその他のＧＴＰメッセージは、リモート・ノード再始動カウンタ・エントリ２５８情報を含む。パス情報がそこから抽出され得る（４１８）ＧＴＰ−Ｃメッセージには、それだけに限らないが、ＰＤＰコンテキスト作成要求、ＰＤＰコンテキスト作成応答、ＰＤＰコンテキスト更新要求、ＰＤＰコンテキスト更新応答、ＰＤＰコンテキスト削除要求およびＰＤＰコンテキスト削除応答メッセージが含まれる。パス状況情報がそこから抽出され（４１８）得るＧＴＰ−Ｕメッセージには、ＧＴＰユーザ・データグラムが含まれる。ＧＴＰエコー要求およびＧＴＰエコー応答メッセージは、制御プレーンまたはユーザ・プレーンに関連付けられ得る。

前述のように、パス状況情報を受け取る工程３１８は、管理情報を受け取る工程も含み得る。例えば、管理状態情報を更新する方法５１０は、ＰＩＰ表中の情報に関連付けられたパスの管理状態情報を受け取る工程５２０と、そのパスの管理状態情報を更新する工程５３０とを含む。以下でより詳細に説明するように、いくつかの実施形態は、本明細書で無償ＧＴＰエコー応答メッセージと呼ぶ、管理状態エントリ（２４２など）の値を含む新しいメッセージを送信する工程５４０を含む。無償ＧＴＰエコー応答メッセージは、それが、ＧＴＰエコー要求メッセージに応答してではなく、送信側ノードでの管理状態変化（「ロック解除状態」から「ロック状態」へ）に応答して送信されるという点で新しい。また、無償ＧＴＰエコー応答メッセージ内の管理状態は、受信側ノードによって、無償ＧＴＰエコー応答メッセージの回復情報要素内の再始動カウンタの増分から推論され得る。代替として、専用拡張情報要素を用いた無償ＧＴＰエコー応答メッセージの専有のバージョンを使用して明示的な管理状態フィールドを運ぶこともできる。

例えば、システム・プロビジョニングまたは保守プロセス時に、技術者は、ノードに関連付けられたリソースをインストールし、除去し、テストし、または修理する。ノードには、ユーザ・インターフェイスを介した手動入力により、またはリソースのインストールまたはアンインストールが自動的に感知される「プラグアンドプレイ」機構を介して自動的に知らされる。これらの機構の１つ、または他の機構により、ノードは、リソースに関連付けられたパスがロックされることを知らされる。次いで、ノードは、技術者により処置が行われているリソースに関連付けられているＰＩＰ表２１０中のエントリ２１４を探す。次いで、ノードは、関連する管理状態エントリ２４２を更新し（５３０）、それらの値を、その技術者の処置に合わせて、「ロック状態」または「ロック解除状態」に設定する。いくつかの実施形態では、状態変化が「ロック状態」へのものであるとき、ノードは、新しくロックされたパスに関連付けられたノードに無償ＧＴＰエコー応答メッセージを送信する。これらの無償ＧＴＰエコー・メッセージは、回復情報要素内に更新された（増分された）再始動カウンタ情報を含む。受信側ノードは、（それぞれのローカルＰＩＰ表２１０に格納された再始動カウンタ２５８情報と比較することによって）変更された再始動カウンタ情報に気付き、関連付けられたＰＤＰコンテキストを取り外し、または整理し、それぞれのＰＩＰ表２１０をしかるべく更新することができる。

その更新する工程５３０を説明しているＰＩＰ表２１０は、ローカル・ノードのものである。いくつかの実施形態では、方法５１０は、リモート・ノードがそれ自体のＰＩＰ表を更新できるように、リモート・ノードにローカル・ノードの管理状態を知らせる工程を含む。前述のように、これらの実施形態では、ローカル・ノードは、本明細書で無償ＧＴＰエコー応答メッセージと呼ぶ、新しいメッセージを送信する。無償ＧＴＰエコー応答メッセージは、ＧＴＰエコー応答メッセージと同一の形とし得る。しかしながら、無償ＧＴＰエコー応答メッセージは、ＧＴＰエコー要求メッセージに応答して送信されない。そうではなく、無償ＧＴＰエコー応答メッセージは、ローカル・ノードの１つまたは複数のリソースの管理状態の変化に応答して送信される。適切な場合には、複数の無償ＧＴＰエコー応答メッセージが送信され（５４０）、リモート・ノードの１つまたは複数に、関連付けられたパスへの管理状態の変更を知らせる。例えば、管理状態情報は、受信側ノードによって、無償ＧＴＰエコー応答メッセージの回復情報要素内の再始動カウンタと、そのローカルまたは受信側ノードのＰＩＰ表に格納された再始動カウンタ値との比較から推論され得る。代替として、無償ＧＴＰエコー応答メッセージは、送信側ノードまたはパスの管理状態を明示的に伝達するための専用拡張フィールド情報要素を含む無償ＧＴＰエコー応答メッセージの専有バージョンとすることもできる。当然ながら、無償ＧＴＰエコー応答メッセージ送信（５４０）を含む実施形態では、リモート・ノードで管理状態変更が行われたときに、それらのノードもまたローカル・ノードに無償ＧＴＰエコー応答メッセージを送信する。そのような無償ＧＴＰエコー応答メッセージは、受信され（４１４）、そこからパス情報が抽出され（４１８）、それを用いてパス・レコード情報が更新され（４３０）、または加えられ（４２６）得るＧＴＰメッセージに含まれることを理解すべきである。

図６を参照すると、パス保全プロトコル表（２１０など）をさらに維持する方法６１０は、表中の状況情報の存続時間を監視する工程を含む。パスの状態エントリが失効し、または所望の存続時間閾値またはリフレッシュ時間を上回る存続時間を有するとき、更新された情報が要求される。更新情報が受け取られなかった場合、そのパス（２１４、２１８など）に関連付けられた運用状態エントリ２４６は、「使用不能」の値を持つように更新される。パスが長時間、または使用不可時間閾値を上回る時間、使用不可のままであった場合、そのパス・エントリ２１４および関連付けられた状態情報２２２は、ＰＩＰ表から除去され、または消去される。

例えば、図６を参照すると、パス保全プロトコル表（２１０など）をさらに維持する方法６１０は、ポール・タイマの期限が切れるのを待つ工程６１４を含む。ポール・タイマの期限が切れる（６１４）と、第１の動的パス・レコードが所望の存続時間、レコード存続時間閾値またはリフレッシュ時間より古いか否かが判定される（６１８）。例えば、そのレコードのタイム・スタンプ・エントリ２５０が検査され、あるいは現在時刻と比較される。現在時刻とタイム・スタンプ・エントリ２５０の値の差がパス状況情報存続時間閾値またはリフレッシュ時間より大きい場合、そのレコードに関連付けられた動的パスを介してＧＴＰエコー要求メッセージが送信される（６２２）。６２４で、応答（すなわちＧＴＰエコー応答）が受け取られた場合、パスの運用状態エントリが「使用可能」の値に更新され（６２６）、すべてのレコードが検査されたか否かが判定され（６２７）、そうでない場合、検査のために次のレコードが選択される（６２８）。６２７で、ＰＩＰ表中のすべてのレコード（２１４など）が検査された場合、ポール・タイマがリセットされる（６２９）。

このように、ＰＩＰ表に動的パスが含められると、そのパスがそれに関連付けられたアクティブなＰＤＰコンテキストを持たないときでさえ、ノードはそのパスの状況情報を認識し、それを維持することができる。これにより、呼処理やＯＡＭ機能などのネットワーク動作は、パスが利用可能であるという仮定のみに基づいてパスをやみくもに選択するのではなく、利用可能であることが知られているパスを選択することができるようになる。パスの運用状態が更新されると（６２６）、処理のために次のレコードが選択される（６２８）。

応答が受け取られなかった場合、処理は、応答タイマの期限が切れるまで待機する（６３０）。応答タイマの期限が切れると、再試行タイマが増分される（６３２）。再試行カウンタが増分されると、再試行カウント限界を超えたかどうかが判定される（６３４）。再試行カウント限界を超えていない場合、パス・レコードの運用状態が「不明」の値に更新され（６３６）、新しいＧＴＰエコー要求メッセージが送信される（６２２）。

再試行カウントを超えている場合（６３４）、レコードの運用状態エントリ２４６がすでに「使用不能」に設定されているかどうかが判定される（６４０）。レコードの運用状態エントリ２４６がまだ「使用不能」に設定されていなかった場合、その動的パス・レコードの運用状態が「使用不能」に設定され（６４４）、パス使用不能時刻エントリ２５４が、現在時刻、またはパスが使用不能であるとの最初の判定に関連付けられた時刻と同じに設定される。運用状態２４６およびパス使用不能時刻エントリ２５４が適正に設定されると、すべてのレコードが検査されたかどうが判定される（６２７）。すべてのレコードが検査されていない場合、次のレコードが選択される（６２８）。すべてのレコードが検査されている場合（６２７）、ポール・タイマがリセットされる（６２９）。

６４０で、パスの運用状態エントリ２４６がすでに「動作不能」に設定されていた場合、そのパスが、使用不能パス制限時間より長い期間使用不能であったかどうかが判定される（６５０）。例えば、そのレコードのパス使用不能時刻エントリ２５４が現在時刻と比較される。パス使用不能時刻エントリ２５４と現在時刻の差が使用不能パス制限時間より大きい場合、そのレコードはパス保全プロトコル表（２１０など）から削除され（６５４）、または消去される。レコードが削除される（６５４）と、すべてのレコードが検査されたかどうかが判定され（６２７）、前述のように処理が続行される。６５０で、パスが、使用不能パス制限時間より長い間使用不能にされていなかった場合、削除は行われず、再度、すべてのレコードが検査されたかどうかが判定され（６２７）、前述のように処理が続行される。

パス保全プロトコルを実施するように動作するネットワーク・ノードは、そのネットワーク・ノードの主要目的または機能を実行する主要ネットワーク・ノード機能ブロックを含む。また、パス保全プロトコルを実行するように動作するネットワーク・ノードは、ＧＴＰエコー要求／応答プロセッサおよびパス保全プロトコル・モジュールまたはその機能的均等物を含む。主要ネットワーク・ノード機能ブロック、ＧＴＰエコー要求／応答プロセッサおよびパス保全プロトコル・モジュールのそれぞれは、ソフトウェア、ハードウェア、またはソフトウェアとハードウェアの組み合わせとして実施され得る。「プロセッサ」という用語の使用は、ハードウェア実装形態を示唆するためのものではない。ＧＴＰエコー要求／応答プロセッサ、ならびにその他の機能ブロックは、複数のハードウェアまたはソフトウェア・モジュール上に分散された１つまたは複数のプロセス、あるいは１つまたは複数のサブプロセス・セットとして実施され得る。

ＧＴＰエコー要求／応答プロセッサ（１５４など）は、そのネットワーク・ノードの他の構成要素によってそうするように指図されたとき、ＵＭＴＳ／ＧＰＲＳネットワークでＧＴＰエコー要求を送信するように動作する。また、ＧＴＰエコー要求／応答プロセッサは、そのネットワーク・ノードの他の構成要素またはモジュールによって指図されたようにネットワーク中の他のノードから受信したＧＴＰエコー応答メッセージを受け取り、それを処理するようにも動作する。

パス保全プロトコル・モジュールは、ノードに関連付けられたネットワーク・メッセージ・トラフィックからパス保全情報を抽出し（４１８）、抽出した情報をパス保全プロトコル表（２１０など）に記録する（４２６）ことによってパス保全プロトコル表（２１０など）を構築するように動作する。パス保全プロトコル・モジュールは、ノードに関連付けられた追加のネットワーク・メッセージ・トラフィックから更新されたパス保全情報を抽出し（４１８など）、抽出した更新情報を表（２１０など）に記録する（４３０など）ことによって表に記録された情報を更新する（４３０など）ようにも動作する。さらに、パス保全プロトコル・モジュールは、表に格納された記録情報の存続時間を監視し（６１８など）、ＧＴＰエコー要求／応答プロセッサに、古い表の情報に関連付けられたパスを介してＧＴＰエコー要求を送信し（６２２など）、そのＧＴＰエコー要求に関連付けられたＧＴＰエコー応答メッセージを受信したこと、または受信しなかったことに関してパス保全プロトコル・モジュールに情報を提供する（６２４、６３４、６４０など）ように指図することによって表中の古い情報を更新するように動作する。次いで、パス保全プロトコル・モジュールは、さらに、ＧＴＰエコー要求／応答プロセッサによってパス保全プロトコル・モジュールに提供された情報に基づき、古い記録情報を新しい情報で置き換える（６２６、６３６、６４４など）ように動作する。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、パス使用不能制限時間または期間より長い（６５０など）とき、パス保全プロトコル表（２１０など）から動的パス情報を削除する（６５４など）ように動作する。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、手動のパス定義入力を受け入れ、それら手動のパス情報入力に基づいてパス保全プロトコル表中にレコードを含め、かつ／または表中のレコードを更新することによってパス保全表（２１０など）を構築し、維持するように動作する。例えば、いくつかの実施形態では、パス保全プロトコル・モジュールは、パス定義レコード（２１４、２１８など）に関連付けられた手動入力された管理状態情報を受け入れ、パス保全プロトコル表（２１０など）中の管理状態エントリ（２４２など）を更新するように動作する。

いくつかの実施形態では、パス保全プロトコル・モジュールは、さらに、ノードまたはパスの再始動カウンタの新しい値を示す無償ＧＴＰエコー応答メッセージを送信するように動作する。パスに関連付けられた管理状態エントリ２４２は、受信側ノードによって推論され、更新され得る。それらのノードは、無償ＧＴＰエコー応答メッセージとして受信した再始動カウンタ情報を、以前ＰＩＰ表に格納した再始動カウンタ２５８と比較する。受信した再始動カウンタ情報が異なる場合、受信側ノードは、関連付けられたパスの管理状態が「ロック状態」に変更されていると推論することができ、そのローカルＰＩＰ表を更新すると共に、他の適当な措置を講じることができる。

図７を参照すると、パス保全プロトコルを実行するように動作するネットワークの例示的部分７１０は、複数のネットワーク・ノード７１４を含む。例えば、それら複数のネットワーク・ノードは、ＵＭＴＳ／ＧＰＲＳネットワーク・ノードである。例えば、ネットワークの例示的部分７１０は、ＲＮＣ７１８、第１のＳＧＳＮ７２２、第１のＧＧＳＮ７２６、第２のＳＧＳＮ７３０および第２のＧＧＳＮ７３４を含む。

各ネットワーク・ノード（７１８、７２２、７２６、７３０、７３４など）は、パス保全プロトコル・モジュール７３８およびＧＴＰエコー要求／応答プロセッサ７４２を含む。また、各ネットワーク・ノード（７１８、７２２、７２６、７３９、７３４など）は、そのノードの主要機能を実行する主要ネットワーク・ノード機能ブロックを含む。

例えば、ＲＮＣ７１８は、無線ノード制御装置機能ブロック７５０を含み、少なくともその一部は、パス保全プロトコル・モジュール７３８によって収集され、パス保全プロトコル・モジュール７３８によってＲＮＣ７１８のパス保全プロトコル表７５２に格納された情報（２１８、２２２など）を利用するように適合される。例えば、呼処理およびＯＡＭ主要ＲＮＣ機能ブロックは、ＲＮＣ ＰＩＰ表７５２を利用して、呼処理およびＯＡＭ機能の効率を高めるように適合される。

前述のように、パス保全プロトコル・モジュール７３８は、ＲＮＣ７１８が受信した（４１４）ネットワーク・メッセージ・トラフィックからパス保全情報を抽出する（４１８）ことによってＲＮＣ７１８のパス保全プロトコル表７５２を構築する。パス保全プロトコル・モジュール７３８は、抽出した情報を用いて、抽出した情報が、それについての状況情報がまだ表７５２に記録されていないパスに関連するときには、表７５２を構築し、またはそれに加え（４２６）、あるいは、抽出した情報を用いて、ＲＮＣ７１８のパス保全プロトコル表７５２にエントリ（２１４など）を持つパスのレコードを更新する（４２２）。また、ＲＮＣ７１８のパス保全プロトコル・モジュール７３８は、表に格納された記録情報の存続時間を監視し（６１８）、ＲＮＣ７１８のＧＴＰエコー要求／応答プロセッサ７４２に、古い情報に関連付けられたパスを介してエコー要求メッセージを送信し（６２２など）、そのＧＴＰエコー要求に関連付けられたＧＴＰエコー応答メッセージを受信したことまたは受信しなかったこと（６２４）に関してＲＮＣ７１８のパス保全プロトコル・モジュール７３８に情報を提供するよう指図することによって、表中の古い情報を更新する（６２６、６３６、６４４など）。次いで、パス保全プロトコル・モジュールは、ＲＮＣ７１８のＧＴＰエコー要求／応答プロセッサ７４２によって提供された情報に基づき、古い記録情報を新しい情報で更新する（６２６、６３６、６４４など）。

パス保全プロトコル・モジュール７３８は、多数のＧＴＰ−ＵおよびＧＴＰ−Ｃメッセージのいずれかからパス保全情報を抽出すことによってパス保全プロトコル表（７５２など）を構築し、維持し得る。例えば、パス保全プロトコル・モジュール７３８は、受信した（４１４）ＧＴＰ−Ｕ（ユーザ・プレーン）データグラムまたはパケット・データ・ユニット（ＰＤＵ）、ＰＤＰコンテキスト作成要求メッセージ、ＧＴＰエコー要求メッセージ、ＧＴＰエコー応答メッセージ、ＰＤＰコンテキスト作成応答メッセージ、ＰＤＰコンテキスト更新要求メッセージ、およびＰＤＰコンテキスト更新応答メッセージからパス保全情報を抽出することができる。前述のように、図２を参照すると、ＲＮＣ７１８のパス保全プロトコル表７５２に格納され、そこで更新される抽出情報には、第１の、またはローカル・ノードＩＰアドレス２２６、第２の、またはリモート・ノードＩＰアドレス２３０およびポート番号２３４、ならびにそのパス定義２１８に関連付けられた状況または状態情報（２２２など）が含まれる。参照点、および送信メッセージを指しているか、それとも受信メッセージを指しているかに応じて、ローカルとリモートのノードＩＰアドレスは、交互に、発信元および／または宛先アドレスと呼ばれる。

状況または状態情報は、パスを介したメッセージの受信、またはＧＴＰエコー要求メッセージの送信（６２２）への応答がないことから判定され、または推論され得る運用状態２４６を含む。この状況情報は、状態情報２２２の新しさを指示するタイム・スタンプ（２５０など）も含む。

任意選択で、パス保全プロトコル・モジュールは、受信した（４１４）メッセージから管理状態情報（２４２など）を推論し、または抽出する（４１８）。例えば、複数のモジュール７１４のパス保全プロトコル・モジュール７３８は、管理状態情報を受け取り（５２０）、それぞれのパス保全プロトコル表（７５２、７５６、７６０、７６４、７６８など）を更新する（５３０）。これが行われるとき、それぞれのリモート・ノード（７２２、７２６、７３０、７３４など）は、前述のように、ＰＩＰ表中の情報を更新するのに使用され得る更新された再始動カウンタ情報を含む無償ＧＴＰエコー応答メッセージを送信する（５４０）。ローカル・ノード（この例ではＲＮＣ７１８）は、無償ＧＴＰエコー応答メッセージを受信し（４１４）、ローカル・ノード（またはＲＮＣ７１８）のパス保全プロトコル・モジュール７３８は、そのパスおよび管理状態情報を推論または抽出し（４１８）、その管理状態情報を適当なパス（２１８、２１４など）と関連付けてパス保全プロトコル表７５２に格納する。例えば、リモート・ノードは、管理上「ロック状態」にあることが知られているため、ローカル・ノードのパス保全プロトコル・モジュール７３８は、ローカル・ノードのＰＩＰ表で、リモート・ノードに関連付けられたパスの運用状態値２４６を「使用不能」の値に設定する。

いくつかの実施形態では、管理状態２４２情報は、ローカル・ノードだけに関連し、そのノードで作業する技術者から受け取られ（５２０）、構成情報およびそのローカル・ノード（ＲＮＣ７１８など）のパス保全プロトコル表７５２を更新する（５３０）ためにだけ使用される。

いくつかの実施形態では、パス保全プロトコル・モジュール７３８は、パスの種類（２３８など）を受け取り、または判定し、格納するように動作する。例えば、技術者は、性能検証プロセスまたはプロビジョニング・プロセス中に静的および動的パスを識別することができる。また、動的パスは、通常のネットワーク・メッセージ・トラフィックの受信４１４に基づき、パス情報抽出４１８を介してパス保全プロトコル・モジュール７３８によっても識別される。

前述のように、いくつかの実施形態は、受信した（４１４）ネットワーク・メッセージ・トラフィックからリモート・ノード再始動カウンタ情報（２５８など）を抽出する（４１８）。それらの実施形態では、リモート・ノード再始動カウンタが、ローカル・ノード（７１８など）のパス保全プロトコル表（７５２など）に加えられ（４２６）、またはそこで更新される（４３０）。

いくつかの実施形態では、ＰＩＰ表保守手順の一部として、パス保全プロトコル・モジュール７３８は、使用不能パス制限期間または時間より長い間「使用不能」の運用状態エントリ２４６を持つパスに関連付けられたエントリ（２１４など）を削除する。パスが使用不能であることが最初に判定されると（６４０）、パス保全プロトコル・モジュール７３８は、その判定に関連付けられた時刻を、そのパスに関連付けられたレコード（２１４など）にパス使用不能時刻（２５４など）として記録する。６５０で、パスが、使用不能パス制限時間または期間より長い間使用不能のままであった場合、パス保全プロトコル・モジュール７３８は、パス保全プロトコル表からその使用不能パスに関連する情報（２１４など）を削除する（６５４）。

他のネットワーク・ノード（７２２、７２６、７３０、７３４など）のパス保全プロトコル・モジュール７３８は、ＲＮＣ７１８のパス保全プロトコル・モジュール７３８を参照して説明したものと類似の機能を提供する。当然ながら、主要ＲＮＣネットワーク・ノード機能ブロックを含む代わりに、ＳＧＳＮ（７２２、７３０など）は、主要ＳＧＳＮネットワーク・ノード機能ブロック７８０を含み、ＧＧＳＮ（７２６、７３４など）は、主要ＧＧＳＮネットワーク・ノード機能ブロック７８４を含む。ＳＧＳＮ機能ブロック７８０とＧＧＳＮ機能ブロック７８４の少なくとも一部は、それぞれ、それらに関連付けられたパス保全プロトコル表７５６、７６４、７６０、７６８を利用するように適合される。例えば、ＳＧＳＮ（２２２、２３０など）およびＧＧＳＮ（２２６、２３４など）の呼処理およびＯＡＭ機能ブロック（図示せず）は、呼処理およびＯＡＭ機能に使用するために、表（７５６、７６４、７６０、７６８など）中の情報に基づいて使用可能でロック解除状態にあるパスを選択するように適合される。

以上、本発明を好ましい実施形態を参照して説明してきた。明らかに、本明細書を読み、理解すれば、改変形態および変更形態が想起されるであろう。本発明は、そのような改変形態および変更形態が添付の特許請求の範囲またはその均等物の範囲内に含まれる限りにおいて、それらすべてを含むと解釈されることを意図するものである。

従来技術のネットワークの一部を示す構成図である。 例示的パス保全プロトコル表を示す図である。 パス保全プロトコル表を構築し、維持する方法を示す流れ図である。 図３の方法の一実施形態を示す流れ図である。 パス状況情報を受け取る方法を示す流れ図である。 図３の方法に加えて、パス保全プロトコル表をさらに維持する方法を示す流れ図である。 図３および図６の方法に従ってパス保全プロトコル表を構築し、維持するように動作するネットワークの一部を示す構成図である。

Claims (10)

1. 第１のノードＩＰアドレス、第２のノードＩＰアドレスおよびＵＤＰポート番号に基づいてパスを定義する工程と、
   第１のノードで、第２のノードから第１のＧＴＰメッセージを受信する工程と、
   前記第１のＧＴＰメッセージから、前記第１のノードＩＰアドレス、前記第２のノードＩＰアドレスおよび前記ＵＤＰポート番号の１つまたは複数を抽出する工程と、
   前記第１の受信メッセージに基づいて前記パスの運用状態を判定する工程と、
   前記パス定義、および前記第１のＧＴＰメッセージを受信した時刻に関連するタイム・スタンプに関連付けて、パス保全表に前記パスの前記運用状態を格納する工程と
   を含む、ＵＭＴＳ／ＧＰＲＳネットワークにおいて改善されたＧＴＰパス保全保証を提供する方法。
2. 前記タイム・スタンプの値と現在時刻の差を求める工程と、
   前記タイム・スタンプの前記値と前記現在時刻の前記差が所定のリフレッシュ時間より大きい場合、前記ＵＤＰポート番号を使用し、前記第１のノードＩＰアドレスを発信元アドレスとして、前記第２のノードＩＰアドレスを宛先アドレスとして使用して、前記第１のノードから前記第２のノードにＧＴＰエコー要求メッセージを送信する工程と
   をさらに含む請求項１に記載の方法。
3. 前記第１のノードで、前記第２のノードから第２のＧＴＰメッセージを受信する工程と、
   前記第２のＧＴＰメッセージから前記第１のノードＩＰアドレスを抽出する工程と、
   前記第２のＧＴＰメッセージから前記第２のノードＩＰアドレスを抽出する工程と、
   前記第２のＧＴＰメッセージから前記ＵＤＰポート番号を抽出する工程と、
   前記第１のノードＩＰアドレス、前期第２のノードＩＰアドレスおよび前記ＵＤＰポート番号に基づいて前記パス定義を決定する工程と、
   前記第２の受信メッセージに基づいて前記パスの運用状態を判定する工程と、
   前記パス保全表中の前記パス定義と関連付けられた前記運用状態エントリを更新する工程と、
   前記第２のＧＴＰメッセージを受信した時刻に関連する値で前記タイム・スタンプを更新する工程と
   をさらに含む請求項１に記載の方法。
4. 前記第２のノードが前記送信されたＧＴＰエコー要求メッセージに応答していないと判定する工程と、
   前記第２のノードが前記送信されたＧＴＰエコー要求メッセージに応答していないという前記判定に基づき、前記パスの運用状態が「使用不能」であると判定する工程と、
   前記パス保全表中の前記パス定義に関連付けられた前記運用状態エントリを「使用不能」に更新する工程と、
   前記第２のノードが前記送信されたＧＴＰエコー要求メッセージに応答していないという前記判定に関連する値で前記タイム・スタンプを更新する工程と
   をさらに含む請求項２に記載の方法。
5. パス使用不能タイム・スタンプを、前記第２のノードが前記送信されたＧＴＰエコー要求メッセージに応答していないという前記判定に関連する値に設定する工程
   をさらに含む請求項４に記載の方法。
6. 前記パス使用不能タイム・スタンプ・エントリの前記値を現在時刻と比較し、それによってパス使用不能期間を求める工程と、
   前記パス使用不能期間が所定のパス使用不能制限期間より大きい場合、前記パス保全表から前記パス定義および関連付けられた情報を削除する工程と
   をさらに含む請求項５に記載の方法。
7. ＧＴＰメッセージを受信する工程と、
   前記ＧＴＰメッセージに含まれる情報からのレコードのパス保全表を構築する工程であって、前記パス保全表中の各レコードは、パス定義、運用状態エントリおよびタイム・スタンプ・エントリを含み、前記パス定義は、少なくとも発信元ＩＰアドレス、宛先ＩＰアドレスおよびポート番号を含み、前記運用状態エントリは、「使用可能」、「使用不能」、「不明」から選択された値を持ち、前記タイム・スタンプ・エントリは、前記レコードが最後に更新された時間の情報を示す値を持つ工程と、
   前記表中にレコードを持つパス定義に関連付けられた追加のＧＴＰメッセージを受信したとき、前記追加メッセージに含まれる情報に基づいて前記パス保全表中のレコードを更新し、あるいは、期待されるメッセージを受信しなかったとき、前記期待されるメッセージを受信しなかったことに基づいて前記レコードを更新する工程と、
   前記ＧＰＲＳネットワークの呼処理およびＯＡＭサブシステムから前記パス保全表中の情報を利用できるようにする工程と
   を含む、ＵＭＴＳ／ＧＰＲＳネットワークにおいて改善されたＧＴＰパス保全保証を提供する方法。
8. 前記パス保全表中のレコードを更新する工程が、
   前記表中のレコードの前記タイム・スタンプ・エントリの値を現在時刻と比較して前記レコードの存続時間を求める工程と、
   所望のレコード制限存続時間より大きい存続時間を有する任意のレコードに関連付けられた前記宛先ＩＰアドレスおよびポート番号に、前記レコードに関連付けられた前記発信元ＩＰアドレスを含むＧＴＰエコー要求を送信する工程と、
   前記ＧＴＰエコー要求に関連付けられた受信ＧＴＰエコー応答またはその欠如に基づいて前記任意のレコードの前記エントリを更新する工程と
   を含む請求項７に記載の方法。
9. 主要ネットワーク・ノード機能ブロックと、
   ＵＭＴＳ／ＧＰＲＳネットワーク・ノードの他の構成要素によってそうするよう指図されたときにＵＭＴＳ／ＧＰＲＳネットワーク中の他のノードにＧＴＰエコー要求を送信し、前記ＵＭＴＳ／ＧＰＲＳネットワーク・ノードの前記他の構成要素によって指図されたように前記ＵＭＴＳ／ＧＰＲＳネットワーク中の前記他のノードからのＧＴＰエコー応答メッセージを受信し、処理するように動作するＧＴＰエコー要求／応答プロセッサと、
   前記ノードに関連付けられたネットワーク・メッセージ・トラフィックからパス保全情報を抽出し、前記抽出した情報を前記パス保全プロトコル表に記録することによってパス保全プロトコル表を構築し、前記ノードに関連付けられた追加のネットワーク・メッセージ・トラフィックから更新されたパス保全情報を抽出し、前記抽出した更新情報を前記表に記録することによって前記表に記録された前記情報を更新し、前記表に格納された記録情報の存続時間を監視し、前記ＧＴＰエコー要求／応答プロセッサに、古い表の情報に関連付けられたパスを介してＧＴＰエコー要求を送信し、前記ＧＴＰエコー要求に関連付けられたＧＴＰエコー応答メッセージを受信したこと、またはそれを受信しなかったことに関して情報を提供するように指図することによって、前記表中の前記古い情報を更新するように動作するパス保全プロトコル・モジュールであって、さらに、前記ＧＴＰエコー要求／応答プロセッサによって提供された前記情報に基づき、前記古い記録情報を新しい情報で置き換えるように動作するパス保全プロトコル・モジュールと
   を含むＵＭＴＳ／ＧＰＲＳネットワーク・ノード。
10. 前記パス保全プロトコル・モジュールが、さらに、前記ノードに関連付けられた前記ネットワーク・メッセージ・トラフィックからパス定義およびパス運用状況情報を抽出し、前記抽出した情報を前記パス保全プロトコル表に記録することによってパス保全プロトコル表を構築するように動作する請求項９に記載のＵＭＴＳ／ＧＰＲＳネットワーク・ノード。
    

Images