(57)【要約】  セキュア・ロケーション・セッション・マネージャ（ＳＬＳＭ）は、地理的に多様な複数のＳＵＰＬサーバが、無線通信事業者ネットワーク内のアクティブ−アクティブ冗長構成などの分散環境内に配備されるときに最良に実施されるオープン・モバイル・アライアンス（ＯＭＡ）セキュア・ユーザ・プレーン・ロケーション（ＳＵＰＬ）バージョン１．０（およびそれ以降の）メッセージ用のインテリジェント・ルータである。スタンドアロン・オプションの場合、ＳＬＳＭは、モバイル・デバイスと担当のＳＵＰＬサーバとの間のすべてのＳＵＰＬポジショニング・メッセージのための「媒介者」として動作する。組込みオプションの場合、ＳＬＳＭは既存のサーバ内に設けられる。ＳＬＳＭは、すべての保留中および進行中のＳＵＰＬポジショニング・セッションのセッション情報を管理し、ルーティングおよび負荷分散の目的で内部テーブルの中にその情報を格納する。ＳＬＳＭの外部インターフェースは、ＯＭＡ  ＵＬＰメッセージからなる。
2010509889.tif 000002
【特許請求の範囲】
【請求項１】
セキュア・ユーザ・プレーン・ロケーション（ＳＵＰＬ）セッション・ルータと、
ネットワークＳＵＰＬエージェントからモバイル・デバイスへのＳＵＰＬロケーション要求を受信するとＳＵＰＬセッション・レコードを作成し、前記ＳＵＰＬセッションに関する後続のメッセージを受信すると前記ＳＵＰＬセッション・レコードを検索し、対応するＳＵＰＬセッションが完了すると前記ＳＵＰＬセッション・レコードを削除するセッション・レコード・マネージャと
を備えるロケーション・セッション・マネージャ。
【請求項２】
前記ＳＵＰＬセッション・ルータが、起動ＳＵＰＬエージェントとは別のスタンドアロン・セッション・ルータである、
請求項１に記載のロケーション・セッション・マネージャ。
【請求項３】
前記ＳＵＰＬセッション・ルータが起動ＳＵＰＬエージェント内に組み込まれている、
請求項１に記載のロケーション・セッション・マネージャ。
【請求項４】
前記ＳＵＰＬセッション・ルータが、ルーティングの目的で内部テーブルの中に、保留中および進行中のＳＵＰＬポジショニング・セッションのセッション情報を格納する、
請求項１に記載のロケーション・セッション・マネージャ。
【請求項５】
前記セッション情報の前記格納がルーティングおよび負荷分散の両方を目的とする、
請求項４に記載のロケーション・セッション・マネージャ。
【請求項６】
複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法であって、
ＳＵＰＬセッション・ルータにおいてネットワーク主導型ＳＵＰＬロケーション要求を捕捉することと、
モバイル・デバイスと前記ＳＵＰＬロケーション要求を処理するために割り当てられた前記複数のＳＵＰＬサーバから選択された１つのＳＵＰＬサーバとの間で、前記ＳＵＰＬセッション・ルータを介して、前記ＳＵＰＬロケーション要求に関する後続のメッセージングを引き渡すことと、
前記ＳＵＰＬロケーション要求を処理する前記複数のＳＵＰＬサーバから選択された前記１つのＳＵＰＬサーバに前記後続のメッセージングをルーティングすることと
を含む方法。
【請求項７】
前記ＳＵＰＬセッション・ルータが、起動ＳＵＰＬエージェントとは別のスタンドアロン・セッション・ルータである、
請求項６に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法。
【請求項８】
前記ＳＵＰＬセッション・ルータが起動ＳＵＰＬエージェント内に組み込まれている、
請求項６に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法。
【請求項９】
ルーティングの目的で内部テーブルの中に、保留中および進行中のＳＵＰＬポジショニング・セッションのセッション情報を格納すること
をさらに含む請求項６に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法。
【請求項１０】
前記セッション情報の前記格納がルーティングおよび負荷分散の両方を目的とする、
請求項９に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法。
【請求項１１】
複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する装置であって、
ＳＵＰＬセッション・ルータにおいてネットワーク主導型ＳＵＰＬロケーション要求を捕捉するための手段と、
モバイル・デバイスと前記ＳＵＰＬロケーション要求を処理するために割り当てられた前記複数のＳＵＰＬサーバから選択された１つのＳＵＰＬサーバとの間で、前記ＳＵＰＬセッション・ルータを介して、前記ＳＵＰＬロケーション要求に関する後続のメッセージングを引き渡すための手段と、
前記ＳＵＰＬロケーション要求を処理する前記複数のＳＵＰＬサーバから選択された前記１つのＳＵＰＬサーバに前記後続のメッセージングをルーティングするための手段と
を備える装置。
【請求項１２】
前記ＳＵＰＬセッション・ルータが、起動ＳＵＰＬエージェントとは別のスタンドアロン・セッション・ルータである、
請求項１１に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理するための装置。
【請求項１３】
前記ＳＵＰＬセッション・ルータが起動ＳＵＰＬエージェント内に組み込まれている、
請求項１１に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理するための装置。
【請求項１４】
ルーティングの目的で内部テーブルの中に、保留中および進行中のＳＵＰＬポジショニング・セッションのセッション情報を格納するための手段
をさらに備える請求項１１に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理するための装置。
【請求項１５】
前記セッション情報の前記格納がルーティングおよび負荷分散の両方を目的とする、
請求項１４に記載の複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理するための装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、その全体が参照によって本明細書に明示的に組み込まれる、２００６年１１月１３日出願のＧｈｏｚａｔｉらに帰せられる「ＳＵＰＬ  Ｉｎｔｅｌｌｉｇｅｎｔ  Ｓｅｓｓｉｏｎ  Ｒｏｕｔｅｒ」と題する米国特許仮出願第６０／８５８，３３７号の優先権を主張する。
【０００２】
本発明は、位置情報サービス（ＬＢＳ：Ｌｏｃａｔｉｏｎ  Ｂａｓｅｄ  Ｓｅｒｖｉｃｅｓ）、アシスト型全地球測位システム（Ａ−ＧＰＳ：Ａｓｓｉｓｔｅｄ  Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍ）、およびセキュア・ユーザ・プレーン・ロケーション（ＳＵＰＬ：Ｓｅｃｕｒｅ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ）のサービスに関する。
【背景技術】
【０００３】
その現在位置を要求されるモバイル・デバイスでは、多数のメッセージがインターネット・プロトコル（ＩＰ）ネットワークを介して交換される。メッセージをモバイル・デバイスとロケーション・サーバとの間で引き渡し、モバイル・デバイスの位置を判定する。
【０００４】
しかし、分散サーバ環境では、現行のＩＰベースのロケーション・サービス・システムは、同じロケーション要求に属するメッセージを適切なサーバにルーティング可能にするためのセキュアかつ整合性のとれた方法を提供しない。この環境では、同じロケーション・セッションに属するメッセージが、セッションを開始した適切なサーバにルーティングされることが保証されず、その結果、ロケーション要求がしばしば失敗する。分散サーバ環境においてロケーション・セッションを管理するための標準的かつ効率的な方法を提供する従来のシステムは、知られていない。
【０００５】
非送信請求（漂遊）メッセージが分散サーバのうちの１つで受信されたときメッセージを正しくルーティングするための可能な１つの方法は、分散サーバ・ネットワーク内のすべてのサーバにブロードキャストすることである。しかし、これは強引で、通信リソースおよび処理リソースを浪費する。しかも、分散サーバの数が増大するにつれて、ブロードキャスト・メッセージの数が指数的に増加することになる。
【０００６】
セキュア・ユーザ・プレーン・ロケーション（ＳＵＰＬ）は、モバイル・ハンドセット・クライアントがロケーション・サーバと通信できるようにするために開発された標準ベースのプロトコルである。ＳＵＰＬ仕様は、オープン・モバイル・アライアンス（ＯＭＡ）標準ワーキング・グループによって定義されている。ＯＭＡ  ＳＵＰＬコール・フローのさらなる詳細については、ＯＭＡ  Ｓｅｃｕｒｅ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｄｏｃｕｍｅｎｔ、ＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ１＿０−２００６０１２７−Ｃ、およびＯＭＡ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｏｃｕｍｅｎｔ、ＯＭＡ−ＴＳ−ＵＬＰ−Ｖ１＿０−２００６０１２７−Ｃを参照されたい。
【０００７】
ＯＭＡ  ＳＵＰＬバージョン１は、（１）ＳＵＰＬネットワーク主導型（ＮＩ：ｎｅｔｗｏｒｋ  ｉｎｉｔｉａｔｅｄ）コール・フロー、および（２）ＳＵＰＬ  ＳＥＴ主導型（ＳＩ：ＳＥＴ  ｉｎｉｔｉａｔｅｄ）コール・フローという基本的なコール・フローを規定している。
【０００８】
図９は、ＳＵＰＬロケーション要求用の通常のＯＭＡモバイル終端コール・フローを示す。
【０００９】
具体的には、図９に示すように、メッセージは、ネットワーク内にあるＳＵＰＬエージェント８０２、衛星参照サーバ８０４、ＳＵＰＬサーバ８０６、ＰＰＧ８０８、およびＳＵＰＬ対応端末（ＳＥＴ）８１２の間で引き渡される。
【００１０】
ＳＵＰＬサーバ（またはＳＬＰ）８０６は、ＳＵＰＬロケーション・センタ（ＳＬＣ）およびＳＵＰＬポジショニング・センタ（ＳＰＣ）を備える。モバイル・デバイスは、ＳＵＰＬ対応端末（ＳＥＴ）８１２と称する（ｇｅｎｅｒａｌｉｚｅｄ）。ＳＬＣは、ネットワーク内のＳＵＰＬ通信の動作を連係させ、ＳＰＣ構成要素と通信する。ＳＰＣは、ＳＥＴ８１２にＧＰＳ支援データを提供し、ＳＥＴ８１２の正確なポジション計算を行う。
【００１１】
ＳＬＰは、プロキシまたは非プロキシのいずれかで動作することが可能である。プロキシ・モードの場合、ＳＥＴは、正確なロケーション決定計算中にＳＬＣをプロキシとして使用するＳＰＣと通信するが、非プロキシ・モードの場合は、ＳＰＣは、ＳＥＴと直接通信して正確なポジション計算を行う。
【００１２】
図９に示すように、ネットワーク主導型ＳＵＰＬポジショニング要求では、コール・フロー・ルーティングの問題が存在する。例えば、ネットワーク主導型ロケーション要求８２０が、ＭＬＰインターフェースを介してＳＵＰＬサーバ８０６に到着する。このネットワーク主導型要求を処理するＳＵＰＬサーバ８０６は、ＳＵＰＬポジショニング・セッション８２８を検証および開始するために、ＳＥＴ８１２にトリガ・メッセージ（ＳＵＰＬ  ＩＮＩＴメッセージ）８２２を送信するように要求される。このトリガ・メッセージ８２２は、ＰＰＧ８０８からプッシュ・メッセージ８２４として（またはＳＭＳＣ／ＭＣからＳＭＳメッセージとして）ＳＥＴ８１２に送信される。その時点で、ＳＥＴ８１２は、ＳＵＰＬサーバ８０６へのセキュアなＴＣＰ／ＩＰ接続を確立してＳＵＰＬポジショニング要求に応答することを必要とする。
【００１３】
しかし、無線プロバイダが、冗長性を得るためにアクティブ−アクティブ構成の複数のＳＵＰＬサーバを有する場合、ＳＥＴ８１２からの接続要求は、このトランザクションを起動しなかったＳＵＰＬサーバを用いて確立される可能性がある。これにより、結果としてポジショニング要求のタイムアウトまたは終了となり得る。
【００１４】
ＯＭＡユーザ・プレーン・ロケーション・プロトコル仕様（ＯＭＡ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｏｃｕｍｅｎｔ、ＯＭＡ−ＴＳ−ＵＬＰ−Ｖ１＿０−２００６０１２７−Ｃを参照）は、ＳＥＴ８１２からの受信ＳＵＰＬメッセージをルーティングするために使用できるＳＵＰＬ  ＩＮＩＴメッセージ８２２内のフィールドを定義しているが、この仕様にはルーティング障害を生じ得るという盲点がある。ＳＵＰＬ規格によれば、セッションＩＤは、サーバ部分（ＳＬＰセッションＩＤ）およびハンドセット部分（ＳＥＴセッションＩＤ）という２つの部分から構成される一意の値である。ＳＬＰ８０６は、ＳＬＰセッションＩＤパラメータ内で、またＵＬＰ  ＳＵＰＬ  ＩＮＩＴメッセージのオプションの「ＳＬＰアドレス」フィールド内においても、そのＳＬＰ８０６のアドレスを指定することができる。それにもかかわらず、ルーティングは、以下の潜在的理由によって失敗する可能性がある。第１に、「ＳＬＰアドレス」フィールドはプロキシ・モードではオプションであり、ＳＬＰベンダは、このフィールドを使用しないように選択することもできる。第２に、一部のＳＵＰＬサーバ・ベンダは、特定のＳＵＰＬサーバ・インスタンスにルーティングするように解決されることが不可能なパブリックＦＱＤＮをＳＬＰセッションＩＤ中に含めることがある。さらに、ＳＥＴ８１２は、ＳＥＴ内にあらかじめプロビジョニングされたＳＵＰＬサーバ・アドレスを採用してＳＵＰＬ  ＩＮＩＴメッセージの「ＳＬＰアドレス」フィールドの値を無視するように選択することができる。その上、ＳＵＰＬサーバ８０６は、「ＳＬＰアドレス」または「ＳＬＰセッションＩＤ」フィールド内にそのＳＵＰＬサーバ８０６自体のローカル・インターフェース・アドレスを指定することがある。しかし、このローカル・インターフェース・アドレスは、仮想ＬＡＮ内におけるそのＳＵＰＬサーバ８０６自体のアドレスである場合もあるので、通信事業者の地理的に多様なネットワーク全体にわたって一意であることは保証されない。
【００１５】
この問題は、通信事業者が１つのみのＳＵＰＬサーバ８０６を使用している場合なら目に見えない可能性があるが、これは一般的に当てはまらない。通常、無線通信事業者は、負荷分散、冗長性を得るためおよびサービス可用性を確保するために、地理的に多様な複数のＳＵＰＬサーバを有する。ＳＥＴ８１２が、ＦＱＤＮまたはあらかじめプロビジョニングされたよく知られているＳＬＰアドレスを使用しているＳＵＰＬサーバ８０６に接続する場合、通信事業者ネットワーク内のスイッチ／ルータは、特定のＳＵＰＬサーバ・インスタンスへの要求を解決しようと試みる。しかし、ＳＥＴから要求を受信するＳＵＰＬサーバが、ＳＵＰＬポジショニング・セッションのイニシエータではないこともあり、これが原因で、多くのネットワーク主導型ポジショニング要求が失敗するか、タイムアウトするか、または規定されていない挙動を起こす。
【００１６】
加入者のプライバシーが損なわれる可能性のある上記問題の予期されない挙動の１つは、ＳＵＰＬサーバ８０６が、キャッシュされたポジションをすでに有し、このキャッシュされたポジションを外部のＳＵＰＬエージェント８０２に返信するための承諾をＳＥＴ８１２から得ようと試みるときである。ＳＬＰ８０６における通知および検証のタイプが「無応答のとき許可される」ように設定され、ＳＥＴ承諾拒否メッセージが、適切なＳＵＰＬサーバ８０６に到着することができない場合、ＳＬＰ８０６は、キャッシュされたＳＥＴポジションを権限のない外部エンティティに公開するおそれがある。
【先行技術文献】
【特許文献】
【００１７】
【特許文献１】米国特許仮出願第６０／８５８，３３７号
【非特許文献】
【００１８】
【非特許文献１】ＯＭＡ  Ｓｅｃｕｒｅ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ  ｄｏｃｕｍｅｎｔ、ＯＭＡ−ＡＤ−ＳＵＰＬ−Ｖ１＿０−２００６０１２７−Ｃ
【非特許文献２】ＯＭＡ  Ｕｓｅｒ  Ｐｌａｎｅ  Ｌｏｃａｔｉｏｎ  Ｐｒｏｔｏｃｏｌ  ｄｏｃｕｍｅｎｔ、ＯＭＡ−ＴＳ−ＵＬＰ−Ｖ１＿０−２００６０１２７−Ｃ
【発明の概要】
【課題を解決するための手段】
【００１９】
本発明の原理によれば、ロケーション・セッション・マネージャは、ＳＵＰＬセッション・ルータおよびセッション・レコード・マネージャを備える。セッション・レコード・マネージャは、ネットワークＳＵＰＬエージェントからモバイル・デバイスへのＳＵＰＬロケーション要求を受信すると、ＳＵＰＬセッション・レコードを作成する。またセッション・レコード・マネージャは、ＳＵＰＬセッションに関する後続のメッセージを受信するとＳＵＰＬセッション・レコードを検索する。またセッション・レコード・マネージャは、対応するＳＵＰＬセッションが完了するとＳＵＰＬセッション・レコードを削除する。
【００２０】
本発明の別の一態様による複数のＳＵＰＬサーバを備えるネットワークにおいてネットワーク主導型ＳＵＰＬロケーション要求を管理する方法は、ＳＵＰＬセッション・ルータにおいてネットワーク主導型ＳＵＰＬロケーション要求を捕捉することを含む。ＳＵＰＬロケーション要求に関する後続のメッセージングは、モバイル・デバイスとＳＵＰＬロケーション要求を処理するために割り当てられた複数のＳＵＰＬサーバから選択された１つのＳＵＰＬサーバとの間で、ＳＵＰＬセッション・ルータを介して引き渡される。後続のメッセージングは、ＳＵＰＬロケーション要求を処理する複数のＳＵＰＬサーバから選択された１つのＳＵＰＬサーバにルーティングされる。
【００２１】
本発明の特徴および利点は、図面を参照して以下の説明から当業者に明らかとなるであろう。
【図面の簡単な説明】
【００２２】
【図１】本発明の原理による、プロキシ・モードにおけるネットワーク主導型の（ＳＥＴベースまたはＳＥＴ支援の）非ローミングによる成功したコール・フローを示す図である。
【図２】本発明の原理による、プロキシ・モードにおけるＳＥＴ主導型の（ＳＥＴベースまたはＳＥＴ支援のコール・フローの）非ローミングによる成功したコール・フローを示す図である。
【図３】本発明の原理による、ネットワーク主導型非ローミング・プロキシ・モードでの起動ＳＬＣからサービングＳＬＣへのセッション・ルーティングの成功した場合を示す組込みセッション管理を示す図である。
【図４】本発明の原理による拡張プロトコルの完全ユニフォーム・リソース・ロケータ（ＵＲＬ）を用いるスタンドアロン・セッション・ルータを示す図である。
【図５】本発明の原理による相関キーを使用するセッション・ルーティングを示す組込みセッション管理を示す図である。
【図６】本発明の原理によるＳＳＲから起動ＳＬＰへのセッション・ルーティングを示すスタンドアロン・セッション・ルータを示す図である。
【図７】本発明の原理によるＳＳＲから起動ＳＬＰへのセッション・ルーティングを示すスタンドアロン・セッション・ルータ（ＳＳＲ）を示す図である。
【図８】本発明の原理によるスタンドアロン・セッション・ルータ（ＳＳＲ）用の例示的なセキュリティ機構を示す図である。
【図９】ＳＵＰＬロケーション要求用の通常のＯＭＡモバイル終端コール・フローを示す図である。
【発明を実施するための形態】
【００２３】
本発明の６つのアーキテクチャおよび方法が、配備されるロケーション・サーバのネットワーク・アーキテクチャの性質に応じて開示および実装される。開示されるアーキテクチャおよび方法の各々は、従来のアーキテクチャおよび方法に関連する欠点を回避し、適切なＳＬＰ（またはＳＵＰＬサーバ）へのメッセージの適切なルーティングを保証する。ＳＥＴ主導型（ＳＩ）コール・フローには、ネットワーク主導型（ＮＩ）コール・フローについて述べたものと類似するルーティングの問題はないが、本発明の使用により、結果として負荷分散の負担が他のネットワーク・エンティティと分担されることになる。
オプション１：スタンドアロン・セッション・ルータにおいて、このセッション・ルータがセッションを管理する場合
オプション２：既存サーバ内の組込みセッション・ルーティングにおいて、起動ＩＰアドレスがＳＬＰセッションＩＤ内に組み込まれる場合
オプション３：スタンドアロン・セッション・ルータが拡張プロトコルの完全ＵＲＬを使用する場合
オプション４：拡張プロトコルの組込みセッション相関キーにおいて、ネットワーク主導型要求に対する起動ＳＬＣの識別情報を保持するためにＳＬＰセッションＩＤが相関キーを用いて拡張される場合
オプション５：拡張プロトコルの相関キーを用いるスタンドアロン・セッション・ルータ（ＳＳＲ）において、ＩＰアドレスまたは識別パラメータが、新規の相関キー・フィールド内に含まれ、ネットワーク主導型セッションを起動ＳＬＰにルーティングするためにＳＳＲによって使用される場合
オプション６：拡張プロトコルの追加の相関キーを用いるスタンドアロン・セッション・ルータにおいて、新規の相関キー・フィールド内に含まれるＩＰアドレスまたは識別パラメータが、ＳＥＴへの発信メッセージに追加され、ネットワーク主導型セッションを起動ＳＬＰにルーティングするためにＳＳＲによって使用される場合
【００２４】
オプション１−スタンドアロン・セッション・ルータ
スタンドアロン・セッション・ルータ（ＳＳＲ）は、ＳＥＴとＳＵＰＬサーバとの間でＯＭＡ  ＳＵＰＬポジショニング・メッセージをインテリジェントにルーティングする構成要素である。ＳＳＲの主な役目は、ＳＥＴからのＯＭＡ  ＳＵＰＬポジショニング・メッセージが、常にＳＵＰＬサーバの適切なインスタンスで終端することを保証することである。
【００２５】
ＳＳＲは、通信事業者ネットワーク内の冗長ＳＵＰＬサーバとＳＥＴとの間に位置するエア・インターフェースから独立した構成要素であることが好ましい。ＳＳＲは、発信および着信のＳＵＰＬメッセージの両方を傍受し、これらメッセージのそれぞれの宛先にＳＵＰＬポジショニング・メッセージをルーティングおよび負荷分散する内蔵機能を有する。異なるベンダからのＳＵＰＬサーバが通信事業者によって使用される場合、ＳＵＰＬメッセージをルーティングするためにＳＳＲを同一通信事業者のネットワーク内で使用することができる。
【００２６】
ＳＳＲのアーキテクチャおよび方法論は、ＳＥＴまたはＳＵＰＬサーバの既存の実装に対するいかなる変更も必要とせず、したがって無線通信事業者ネットワークにシームレスに統合することができる。開示されるアーキテクチャは、任意のベンダからの任意のＯＭＡ  ＳＵＰＬバージョン１対応ＳＵＰＬサーバ、ならびに任意のベンダからの任意のＯＭＡ  ＳＵＰＬバージョン１対応ＳＥＴと相互運用できることが好ましい。
【００２７】
アーキテクチャ
複数の冗長で地理的に多様なＳＵＰＬサーバが無線通信事業者ネットワーク内にアクティブ−アクティブ構成で配備される場合、ＳＳＲは、ＯＭＡ  ＳＵＰＬバージョン１．０メッセージ用のインテリジェント・ルータとして働く。ＳＳＲは、ＳＥＴとＳＵＰＬサーバとの間のすべてのＳＵＰＬポジショニング・メッセージについての媒介者として働く。ＳＳＲは、ルーティングおよび負荷分散の目的で内部テーブルの中に、すべての保留中および進行中のＳＵＰＬポジショニング・セッションのセッション情報を格納する。ＳＳＲの外部インターフェースは、ＯＭＡ  ＵＬＰメッセージのみを伝送し理解する。
【００２８】
ＳＵＰＬロケーション・センタ（ＳＬＣ）は、ＳＵＰＬサーバのゲートウェイとして働く。このＳＬＣは、ＳＥＴを含む他のネットワーク・ノードへの接続を管理し、最適のネットワーク性能を確保する役割を果たす。ＳＬＣモジュールは、以下の主要な構成要素、すなわち外部インターフェース、セッション管理、トランザクション管理、キャッシュ管理、およびネットワーク・ロケーション・インターフェースの構成要素を含む。
【００２９】
外部インターフェースは、Ｌｅインターフェースをサポートし、ＯＭＡモバイル・ロケーション・プロトコル（ＭＬＰ）３．２．０を実装する。このインターフェースは、ＳＬＣと外部ロケーション・サービス・クライアント（すなわちＬＣＳクライアント）との間の接続ポイントとして働く。開示される実装では、外部インターフェースは、プッシュ・アクセス・プロトコル（ＰＡＰ）メッセージを受理することによって別のＳＵＰＬサーバに直接接続する。
【００３０】
セッション・ルーティング機能は、トランザクションごとに一意のセッションＩＤを生成し、局所的に冗長なシステム内でまたは地理的に冗長なシステム全体にわたってセッションを管理する。
【００３１】
トランザクション管理は、ロケーション要求のフローを調整してロケーション・サーバ自体および無線ネットワークの両方を保護する。トランザクション管理を使用することにより、ロケーション要求が処理される速度を最適化するようにシステムを構成することができる。
【００３２】
キャッシュ管理は、内部ポジション・キャッシュの使用をサポートする。このキャッシュは、キャッシュ情報を使用して着信ロケーション要求に役立つことができるように構成することができ、したがってシステム効率を増大させネットワーク・リソースを節約する。
【００３３】
ネットワーク・ロケーション・インターフェースは、無線ネットワーク内の他のノードとインターフェース接続する。ネットワーク・ロケーション・インターフェースは、すべての標準インターネット・プロトコル（ＩＰ）インターフェースをサポートする。Ｌｕｐインターフェースは、ＳＥＴにより生成されたＵＬＰ接続を受理および管理する。ＷＡＰプッシュは、プッシュ・アクセス・プロトコル（ＰＡＰ）メッセージをフォーマットし、このメッセージをプッシュ・プロキシ・ゲートウェイに送信する。
【００３４】
開示されるＳＵＰＬサーバは、ネットワーク主導型ロケーション要求およびＳＥＴ主導型ロケーション要求のロケーション・サービス手続きをサポートすることが好ましい。通常、ロケーション・サービス・アプリケーションは、ネットワーク主導型ロケーション要求を起動し、ネットワークは、ターゲットＳＥＴを位置決めするための適切な手続きをトリガする。ＳＥＴは、ネットワークからの暗号化キーを有するＳＥＴ主導型ロケーション要求を用いてそのＳＥＴ自体のロケーションまたはロケーション支援データを要求する。ＳＵＰＬサーバは、マルチキャスト・トラフィックの伝送をサポートする地理的に冗長なサイト間のデータ接続を必要とする。
【００３５】
接続管理
ＳＳＲは、ＳＥＴがこのＳＳＲに接続しＳＵＰＬポジショニング・メッセージの配信を要求するとき、ＳＵＰＬサーバ・インスタンスとの新規なＴＣＰ／ＩＰ接続を確立する。ネットワーク主導型（ＮＩ）コール・フローの場合、ＳＳＲは、格納されたルーティング情報に基づいてＳＵＰＬサーバ・インスタンスを判定する。ＳＥＴ主導型（ＳＩ）コール・フローの場合、ＳＳＲは、内部負荷分散アルゴリズムに基づいてＳＵＰＬサーバ・インスタンスをインテリジェントに識別する。
【００３６】
ＳＥＴがＳＳＲとのＴＣＰ／ＩＰ接続を破棄しない限り、または休止状態が原因で接続がタイムアウトする場合、ＳＵＰＬサーバとのＴＣＰ／ＩＰ接続は維持されることが好ましい。
【００３７】
ＳＳＲは、ＳＥＴからのセキュアなＴＣＰ／ＩＰ（ＴＬＳ）接続をうまく処理して受理する機能を有する。各ＳＳＲには、ＳＥＴにおいてプロビジョニングされたサーバ・ルート証明書がロードされる。さらにＳＳＲは、着信ＳＵＰＬセッションごとにＳＵＰＬサーバとのＴＬＳセッションを確立してＳＥＴの正確な擬態をするように構成することができる。これにより、エンド・ツー・エンド・セキュリティが強化され、ＳＵＰＬサーバのソフトウェア変更が回避される。
【００３８】
ＳＳＲは、同じＳＥＴからの複数の接続をサポートすることができ、ＳＵＰＬサーバ・インスタンスとの複数の（セキュアなまたは非セキュアな）接続を確立する能力を有する。
【００３９】
ＳＥＴがＳＳＲへのＴＣＰ／ＩＰ（ＴＬＳ）接続を終了する場合、ＳＳＲは、その接続についてのセッション・ルーティング・レコードをすべて削除し、（１つまたは複数の）ＳＵＰＬサーバとの対応するＴＣＰ／ＩＰ接続をただちに破棄する。
【００４０】
一方、サービングＳＵＰＬサーバがＳＳＲへのＴＣＰ／ＩＰ（ＴＬＳ）接続を終了する場合、ＳＳＲは、セッション・ルーティング・レコードを削除し、ＳＥＴとの対応するＴＬＳ接続をただちに破棄する。ＳＳＲは、エラー状態に基づいて、それだけでＳＵＰＬ  ＥＮＤメッセージをフォーマットしないことが好ましい。
【００４１】
冗長性
したがって、ＳＳＲの複数インスタンスが存在できるため冗長性が許され、冗長構成が形成される。ＳＳＲの各インスタンスは、他のピアＳＳＲと通信する機能を有する。これは、専用の永続性ＴＣＰ／ＩＰ接続、マルチキャスト・インターフェース、または特定のＳＳＲ構成にとって適切と考えられる他の任意のプロトコルを介することができる。
【００４２】
ルーティング・キー
ＳＳＲの情報は、このＳＳＲの内部ルーティング・テーブル中に格納される。ルーティング・テーブル項目は、セッション・ベース当たりで生成され、ＳＵＰＬセッションが動作している限り存続する。ルーティング項目は、新規のＳＵＰＬポジショニング・セッション（ＳＩまたはＮＩ）が開始されると作成され、セッションが（成功またはエラーのいずれかで）完了すると削除される。
【００４３】
ＳＳＲセッション・ルーティング・レコードは、以下のフィールドを有することが好ましい。
【００４４】
【表１】
2010509889.tif 000003
【００４５】
セッション・レコードは、各ＳＵＰＬポジショニング・コール・フローの開始時においてのみ検索またはチェックされることが必要である。ネットワーク主導型（ＮＩ）コール・フローの場合、検索されたセッション・レコードは、ポジショニング要求を処理しているＳＵＰＬサーバのインスタンスを判定する。ＳＥＴ主導型（ＳＩ）コール・フローの場合、負荷分散の目的でルーティング・テーブルに問い合わせてＳＵＰＬサーバ・インスタンスを判定する。
【００４６】
ルーティング・テーブルは、インメモリとして形成することができ、または情報をデータベースまたはメモリ・マップト・ファイル中に格納することによって持続性にすることができる。ルーティング・レコードが不揮発性である場合、ＳＳＲのインスタンスが異常終了したときにセッション情報が失われない。
【００４７】
古くなったセッション・ルーティング・レコードはＳＳＲ内で自動的に消去され、関連するリソースが解放されることが好ましい。
【００４８】
ＳＳＲ  ＳＬＰセッションＩＤ
ＳＳＲは、新規のコール・フローごとに一意のＳＬＰセッション識別子を生成する。ＳＬＰからのＳＬＰセッションＩＤは複数のＳＵＰＬサーバ全体にわたって一意ではないことがあるので、ＳＳＲは、このＳＳＲ自体のＳＬＰセッションＩＤを作成する。このようにして、ＳＳＲによって生成されたＳＬＰセッションＩＤは、冗長な配備構成のＳＳＲインスタンスすべてにわたって一意であることが保証される。また、一意のＳＳＲ  ＳＬＰセッションＩＤは、通信事業者が複数ベンダからのＳＵＰＬサーバを同時に使用することを可能にする。さらに、ＳＳＲによって生成されたＳＬＰセッションＩＤは、セッション・レコードを所有するＳＳＲを確認するのに役立つ一意の識別子を含むように増強されている。
【００４９】
サービングＳＳＲが、特定のネットワーク主導型（ＮＩ）ＳＵＰＬセッションについてのルーティング情報の検索に失敗すると、このサービングＳＳＲは、ＳＳＲによって生成されたＳＬＰセッションＩＤを調査し、所有者ＳＳＲのアドレスを検索する。次いでサービングＳＳＲは、ピアＳＳＲからルーティング・レコードの所有権を転送し、ＳＵＰＬセッション・コール・フローを完了する。
【００５０】
ＳＥＴへのすべての発信ＳＵＰＬメッセージ中において、ＳＬＰによって生成されたＳＬＰセッションＩＤは、このＳＳＲによって生成されたＳＬＰセッションＩＤに置換される。逆方向では、ターゲットＳＵＰＬサーバへのＳＵＰＬメッセージ中に、元のＳＬＰセッションＩＤは置換される。
【００５１】
ネットワーク主導型コール・フロー
ネットワーク主導型（ＮＩ）コール・フローをサポートするために、セッション・ルータ（すなわち、ＳＳＲと総称されるスタンドアロン・セッション・ルータまたは一体型セッション・ルータ）は、ＯＭＡ  ＳＵＰＬ  Ｖ１仕様に対応しているいかなるＳＵＰＬサーバからもＷＡＰプッシュを受理するように構成可能である。ＳＳＲは、ＳＵＰＬ  ＩＮＩＴメッセージを受信すると、ＳＬＰセッションＩＤ中に含まれる情報から一意のセッションを作成し、指定されたプッシュ・プロキシ・ゲートウェイに、例えばＷＡＰゲートウェイ内にＰＡＰメッセージを転送する。ＰＰＧから受信される肯定応答メッセージは、発信側ＳＵＰＬサーバにも返信されることが好ましい。
【００５２】
いかなるＳＳＲも、共通のＩＰサブネットを介してＳＥＴから、対応するＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信することができる。ＳＳＲは、ＳＥＴとの接続およびＳＥＴに関するデータ・セキュリティを管理するとともに、発信側ＳＵＰＬサーバを判定し、そのサーバにＳＵＰＬ  ＰＯＳ  ＩＮＩＴを転送する。次いで、ＳＵＰＬサーバからＳＵＰＬ  ＥＮＤメッセージが送信されるまでＳＥＴとＳＵＰＬサーバとの間にＩＰトンネルが確立され、ＳＵＰＬ  ＥＮＤメッセージが送信された時点で、ＳＥＴに関して別の進行中のセッションが存在しなければ、ＳＳＲはこの２つのエンティティ間のＩＰ接続を破棄することができる。
【００５３】
したがって、ネットワーク主導型（ＮＩ）コール・フローは、ＳＬＰによってＰＰＧまたはＳＭＳＣ／ＭＣを介してＳＥＴに送信されるＳＵＰＬ  ＩＮＩＴメッセージで開始される。このメッセージは、ＳＥＴがＳＥＴセッションＩＤを占有しているので、ＳＬＰセッションＩＤしか有さない。ＳＳＲは、ＳＬＰからＳＵＰＬ  ＩＮＩＴメッセージを傍受して、ルーティング情報テーブル中に新規のセッション・レコードを作成する。
【００５４】
ＳＥＴがＳＵＰＬ  ＩＮＩＴに対してＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージで応答すると、最初に要求はＳＳＲに到着する。ＳＳＲは、ＳＳＲセッションＩＤのルックアップを実行してセッションのルーティング情報を検索する。次いでレコードが、ＳＥＴセッションＩＤによって更新され、無線通信事業者ネットワーク内の正しいＳＵＰＬサーバ・インスタンスに送信される。
【００５５】
ＳＥＴ主導型コール・フロー
無線通信事業者は、ＧＧＳＮを介するサービングＳＳＲへのＳＥＴ主導型（ＳＩ）ポジショニング要求のためのＳＵＰＬ接続要求を終了するようにプロビジョニングされる。いったんＳＥＴがＳＳＲとのＴＬＳ接続を確立すると、ＳＳＲは、ＳＵＰＬサーバのインスタンスを判定し、セッションのルーティング・レコードを作成する。次いでＳＳＲは、ＳＵＰＬサーバに接続して、サービングＳＵＰＬサーバにＳＵＰＬメッセージを転送する。
【００５６】
ＳＥＴ主導型ＳＵＰＬロケーション要求は、同じＴＬＳ接続を介して複数の要求を送信することができる。サービングＳＵＰＬサーバが多数の要求を処理している場合、ＳＳＲは、同じ接続内のどの新規のロケーション要求も別のＳＵＰＬサーバ・インスタンスにインテリジェントにルーティングすることができる。これは、ＳＥＴからの１つのＴＬＳ接続ごとに、各ロケーション要求を処理しているＳＵＰＬサーバのいくつかのインスタンスに対して複数のＴＣＰ／ＩＰ接続が存在し得ることを意味する。セッション・ルーティング・レコード中のそれぞれの接続識別子は、ＳＥＴとＳＵＰＬサーバとの間の接続を相関させる。
【００５７】
ルーティング・レコードがＳＳＲによって発見されない
ＳＳＲは、特定のセッションについてルーティング・レコードを取得できない場合、ＳＥＴとの接続を断つ。これは、所有者ＳＳＲのセッション・タイムアウトまたはロスに起因する可能性がある。
【００５８】
ＳＵＰＬセッションＩＤ
ネットワーク主導型要求について一意のセッションを割り当てて管理するためのセッション・ルータのためには、一意のセッション識別子が必要とされる。ＯＭＡ  ＳＵＰＬ  Ｖ１規格は、セッションＩＤ一意性のためのＳＵＰＬ仕様を満たすために、ＳＬＰセッションＩＤがグローバルに一意でなければならないと規定している。これは、セッションＩＤフィールド（ＳＬＰセッションＩＤの一部）が特定のＳＬＰに対して一意であることを必要とし、ＳＬＰ  ＩＤは、ＳＬＰ全体にわたって一意でなければならない。ＳＵＰＬサーバがＯＭＡ  ＳＵＰＬ  Ｖ１規格のこの部分に準拠していない場合、擬似一意性アプローチを実施することができる。例えば、ＳＬＰセッションＩＤ一意性を規定するＯＭＡ  ＳＵＰＬ  Ｖ１規格を別のやり方で満たすために、一意のセッションＩＤ＋ＳＥＴ  ＩＤを使用することができる。
【００５９】
セッション・ルータ（ＳＳＲ）は、ＦＱＤＮまたはＩＰアドレスのいずれかをサポートすることが好ましい。特定のホストまたはＳＬＰに対して解決するＦＱＤＮを使用することが可能である。複数のＳＬＰに対して解決するグローバルに一意のＦＱＤＮは、ＳＵＰＬセッションＩＤ一意性の要件を満たさない。しかし、ＮＡＴのＶＩＰへのマッピングをサポートすることができる。
【００６０】
セッション・ルータ（ＳＳＲ）への接続
好ましくは、ＳＳＲがＳＥＴ−ＳＳＲ接続を終了する。ＳＳＲは、ＳＥＴ内でプロビジョニングされたサーバ・ルート証明書を用いてプロビジョニングされることが好ましい。さらにＳＳＲは、ＳＵＰＬサーバに対するＴＬＳセッションを確立してエンド・ツー・エンド・セキュリティを確保するように構成されることが好ましい。
【００６１】
図８は、本発明の原理によるセッション・ルータ（ＳＳＲ）用の例示的なセキュリティ機構を示す。
【００６２】
コール・フロー
図１および２は、オプション１について説明した本発明の解決策が、既存のＳＵＰＬコール・フローおよびアーキテクチャとどのように相互作用するかを示す２つの基本的なコール・フローを開示している。
【００６３】
図１は、本発明の原理による、プロキシ・モードにおけるネットワーク主導型の（ＳＥＴベースまたはＳＥＴ支援の）非ローミングによる成功したコール・フローを示す。
【００６４】
図１のステップ１において、ＳＵＰＬエージェント（ＬＣＳクライアント）は、ＳＥＴのロケーションを要求しているＳＵＰＬサーバにＭＬＰ  ＳＬＩＲメッセージを送信する。
【００６５】
ステップ２において、ＳＵＰＬサーバは、ＳＥＴとのポジショニング・セッションを開始する必要があると判定し、ＰＰＧまたはＳＭＳＣを介してトリガ・メッセージを送信してＳＥＴにＳＵＰＬロケーション要求を通知する。
【００６６】
ステップ３において、ＳＳＲは、ＳＵＰＬサーバ・インスタンスからＰＡＰメッセージを傍受し、そのＳＳＲのルーティング・テーブル中にセッション・レコードを作成する。ＳＳＲは、新規のＳＬＰセッションＩＤを作成し、発信ＳＵＰＬ  ＩＮＩＴメッセージ中において元のＳＬＰセッションＩＤを前述の新規の値に置き換える。
【００６７】
ステップ４において、ＳＳＲは、通信事業者ネットワーク中の外部エンティティ（ＰＰＧ／ＳＭＳＣ／ＭＣ）を介してトリガ・メッセージを送信し、外部エンティティ（ＰＰＧ／ＳＭＳＣ／ＭＣ）からＳＵＰＬサーバ・インスタンスに応答を送り返す。ここでセッション・タイマを開始することができる。
【００６８】
ステップ５において、ＳＥＴは、ＳＳＲとのＴＬＳ接続を確立した後、ＳＳＲにＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを送信する。
【００６９】
ステップ６において、ＳＳＲは、着信ＵＬＰメッセージを解析し、サービングＳＵＰＬサーバ・アドレスについてルーティング・テーブルに問い合わせる。
【００７０】
ステップ７において、ルーティング情報の検索に成功すると、ＳＳＲは、ＳＵＰＬサーバとの（セキュアなまたは非セキュアな）ＴＣＰ／ＩＰ接続を確立する。ＳＳＲは、ＳＬＰセッションＩＤを、セッション・ルーティング・レコードからの元の値に置換し、ＳＵＰＬサーバにＵＬＰ  ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを送信する。ＳＳＲは、通信事業者ネットワーク内にあるので、ＳＵＰＬサーバと直接通信できることが想定される。
【００７１】
ステップ８において、サービングＳＵＰＬサーバおよびＳＥＴは、ポジショニング・セッションが完了するまで、複数のＳＵＰＬ  ＰＯＳメッセージを、サポートされているポジショニング・プロトコル（ＲＲＬＰ／ＲＲＣ／ＩＳ−８０１）ペイロードと交換する。これらのＵＬＰメッセージはＳＳＲを通過し、このＳＳＲは、トランザクションごとにセッション状態を用いてＳＬＰセッション識別子を置換しセッション・レコードを更新する。
【００７２】
ステップ９において、成功したポジショニング・セッションの終了時に、サービングＳＵＰＬサーバは、以前に確立したＴＣＰ／ＩＰ接続を介してＳＳＲにＳＵＰＬ  ＥＮＤメッセージを送信する。
【００７３】
ステップ１０において、サービングＳＵＰＬサーバは、外部のＳＵＰＬエージェント（ＬＣＳクライアント）にＭＬＰ  ＳＬＩＡメッセージ内でＳＥＴのロケーションを返信する。
【００７４】
ステップ１１において、ＳＳＲは、ＳＵＰＬサーバからＳＵＰＬ  ＥＮＤメッセージを受信すると、セッション状態を用いてセッション・レコードを更新し、ＳＬＰセッション識別子を、セッション・ルーティング・レコード内に格納されているＳＳＲ生成のセッション識別子に置換する。
【００７５】
ステップ１２において、ＳＳＲは、ステップ５で確立されたＴＬＳ接続を介してＳＥＴにＳＵＰＬ  ＥＮＤメッセージを送信する。
【００７６】
ステップ１３において、ＳＥＴは、ＳＵＰＬ  ＥＮＤメッセージを受信するとＳＳＲとのＴＬＳ接続を破棄し、これが原因でＳＳＲはそれが所有していたセッション・レコードを削除する。次にＳＳＲは、永続するＴＣＰ／ＩＰ接続を使用するように構成されていない場合、サービングＳＵＰＬサーバとの接続を終了する。
【００７７】
図２は、本発明のオプション１の解決策が、既存のＳＵＰＬコール・フローおよびアーキテクチャとどのように相互作用するかを示す別の基本的なコール・フローを示す。具体的には、図１は、本発明の原理による、プロキシ・モードにおけるＳＥＴ主導型の（移動局ベースまたは移動局支援のコール・フローの）非ローミングによる成功したコール・フローを示す。
【００７８】
ステップ１において、ＳＵＰＬエージェント（ＳＥＴ内のアプリケーション）は、アプリケーションＡＰＩを使用してロケーション要求を起動する。
【００７９】
ステップ２において、ＳＥＴは、ＳＳＲとのＴＬＳ接続を確立し、ＳＳＲにＳＵＰＬ  ＳＴＡＲＴメッセージを送信する。
【００８０】
ステップ３において、ＳＳＲは着信ＵＬＰメッセージを解析する。このメッセージはＳＵＰＬ  ＳＴＡＲＴメッセージであるので、新規のセッション・レコードが作成され、適切な負荷分散アルゴリズムを使用してサービングＳＵＰＬサーバが特定される。このセッション・レコードは、ルーティングの目的では使用されずその代わり各ＳＬＣインスタンス上での負荷を確認するためにのみ使用されることが好ましい。
【００８１】
ステップ４において、サービングＳＵＰＬサーバの判定に成功すると、ＳＳＲは、ＳＵＰＬサーバとの（セキュアなまたは非セキュアな）ＴＣＰ／ＩＰ接続を確立する。ＳＳＲは、通信事業者ネットワーク内にあるので、ＳＵＰＬサーバ・インスタンスと直接通信できることが想定される。
【００８２】
ステップ５において、サービングＳＵＰＬサーバは、ＳＳＲにＳＵＰＬ  ＲＥＳＰＯＮＳＥメッセージを送信する。
【００８３】
ステップ６において、ＳＳＲは、以前に確立したＴＬＳ接続を介して、対応するＳＥＴにＳＵＰＬ  ＲＥＳＰＯＮＳＥメッセージを転送する。
【００８４】
ステップ７において、ＳＥＴは、ＳＳＲにＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを返信する。
【００８５】
ステップ８において、ＳＳＲは、以前に確立したＴＣＰ／ＩＰ接続を介してサービングＳＵＰＬサーバにＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを転送する。
【００８６】
ステップ９において、サービングＳＵＰＬサーバおよびＳＥＴは、ポジショニング・セッションが完了するまで、複数のＳＵＰＬ  ＰＯＳメッセージを、サポートされているポジショニング・プロトコル（ＲＲＬＰ／ＲＲＣ／ＩＳ−８０１）ペイロードと交換する。
【００８７】
ステップ１０において、成功したポジショニング・セッションの終了後、サービングＳＵＰＬサーバは、以前に確立したＴＣＰ／ＩＰ接続を介してＳＳＲにＳＵＰＬ  ＥＮＤメッセージを送信する。
【００８８】
ステップ１１において、ＳＳＲは、ＳＵＰＬサーバからＳＵＰＬ  ＥＮＤメッセージを受信すると、セッション・ルーティング・テーブルからセッション・レコードを削除する。
【００８９】
ステップ１２において、ＳＳＲは、以前に確立したＴＬＳ接続を介してＳＵＰＬ  ＥＮＤメッセージをＳＥＴに送信する。ＳＥＴは、ＳＵＰＬ  ＥＮＤメッセージを受信するとＳＳＲとのＴＬＳ接続を破棄する。これは、ＳＳＲがサービングＳＵＰＬサーバとのＴＣＰ／ＩＰ接続を終了する原因となる。
【００９０】
オプション２−組込みセッション・マネージャ・ルーティング
図３は、本発明の原理による、ネットワーク主導型非ローミング・プロキシ・モードでの起動ＳＬＣからサービングＳＬＣへのセッション・ルーティングの成功した場合を示す組込みセッション管理を示す。
【００９１】
具体的には、図３に示すように、ネットワーク構成要素間でメッセージを調整させるために外部構成要素を有する代わりに、この解決策ではＳＬＰ内でルーティング機構を実施する。図３に示すコール・フローは成功したシナリオにおけるメッセージングを説明しているが、同じルーティング機構はエラーのシナリオにも等しく適用可能である。
【００９２】
図３のステップ１において、起動ＳＬＣは、ＳＬＰセッション識別子に起動ＳＬＣのＩＰアドレスを取り込むことにより、ＳＥＴにＳＵＰＬ  ＩＮＩＴトリガ・メッセージを送信する。
【００９３】
ステップ２において、ＳＥＴは、セッション識別子のＳＥＴセッション識別子部分を取り込み、サービングＳＵＰＬサーバとの（セキュアなまたは非セキュアな）ＴＣＰ／ＩＰ接続を確立し、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを送信する。
【００９４】
ステップ３において、サービングＳＬＣは、ＳＵＰＬ  ＩＮＩＴトリガ・メッセージに応答してＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信する。組込みセッション・ルータは、ＳＬＰセッションＩＤを抽出して、メッセージを起動ＳＬＣに直接ルーティングする。しかし、ＳＬＰの地理的に多様な分散配備におけるネットワーク待ち時間を減らすために、すべてのセッション情報が起動ＳＬＣからサービングＳＬＣに転送されるようにサービングＳＬＣが要求することを可能にする、ＳＬＣ間転送要求メッセージが定義される。
【００９５】
ステップ４において、起動ＳＬＣは、転送要求に応答して、進行中のセッションの所有権をサービングＳＬＣに転送し、セッション情報を用いてサービングＳＬＣに応答する。これにより、セッション・ルーティング処理が完了される。
【００９６】
ステップ５において、必要であれば、ＳＥＴおよびＳＬＣはポジショニング・セッションを完了する。（ＳＰＣは図中に示されていないことに留意されたい）
【００９７】
ステップ６において、ステップ５でＳＵＰＬ  ＥＮＤメッセージがＳＥＴから受信されたとき、またはＳＵＰＬ  ＥＮＤメッセージがサービングＳＬＣから送信されたとき、ＳＵＰＬセッションが完了する。
【００９８】
オプション３−スタンドアロン・セッション・ルータが拡張プロトコルの完全ＵＲＬを使用する場合
図４は、本発明の原理による拡張プロトコルの完全ユニフォーム・リソース・ロケータ（ＵＲＬ）を用いるスタンドアロン・セッション・ルータを示す。
【００９９】
図４はオプション１の変形である。図４に示すように、この解決策では、ネットワーク主導型要求に対する起動ＳＬＰを確認するために、ＳＬＰアドレスが完全ＵＲＬによって拡張される。完全ＵＲＬのクエリ文字列は、実際の起動ＳＬＰを確認するための一意のキーを含む。
【０１００】
ステップ１において、起動ＳＬＰは、ＳＬＰアドレスにＳＳＲのアドレスおよびその一意のキーを取り込むことによりＳＥＴにＳＵＰＬ  ＩＮＩＴトリガ・メッセージを送信する。
【０１０１】
ステップ２において、ＳＥＴは、セッション識別子のＳＥＴセッション識別子部分を取り込み、ＳＳＲとの（セキュアなまたは非セキュアな）ＴＣＰ／ＩＰ接続を確立し、トリガ・メッセージに対してＳＵＰＬ  ＰＯＳ  ＩＮＩＴ応答によって返答する。
【０１０２】
ステップ３において、ＳＳＲは、ＳＥＴから着信ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信し、ＳＬＰアドレスを抽出し、テーブル・ルックアップを実行して起動ＳＬＰのアドレスを解決する。次に、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージは起動ＳＬＰに直接送信される。
【０１０３】
ステップ４において、必要であれば、ＳＥＴおよびＳＬＰはポジショニング・セッションを開始する。
【０１０４】
ステップ５において、ステップ４でＳＵＰＬ  ＥＮＤがＳＥＴから受信されたとき、またはＳＵＰＬ  ＥＮＤがサービングＳＬＰから送信されたとき、ＳＵＰＬセッションが完了する。
【０１０５】
ステップ６において、ＳＳＲはＳＥＴにＳＵＰＬ  ＥＮＤメッセージを転送する。
【０１０６】
オプション４−拡張プロトコルの組込みセッション相関キー
図５は、本発明の原理による相関キーを使用するセッション・ルーティングを示す組込みセッション管理を示す。
【０１０７】
具体的には、図５に示す実施形態において、ＳＬＰセッションＩＤが相関キーによって拡張され、ネットワーク主導型要求に対する起動ＳＬＣの識別情報を保持する。
【０１０８】
図５のステップ１において、起動ＳＬＣは、ＳＬＰセッション識別子の相関キーを取り込むことによりＳＵＰＬ  ＩＮＩＴトリガ・メッセージをＳＥＴに送信する。
【０１０９】
ステップ２において、ＳＥＴは、セッション識別子のＳＥＴセッション識別子部分を取り込み、サービングＳＬＣとの（セキュアなまたは非セキュアな）ＴＣＰ／ＩＰ接続を確立し、トリガ・メッセージに対してＳＵＰＬ  ＰＯＳ  ＩＮＩＴ応答によって返答する。
【０１１０】
ステップ３において、サービングＳＬＣは、ＳＵＰＬ  ＩＮＩＴトリガ・メッセージに応答してＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信する。組込みセッション・ルータは、ＳＬＰセッションＩＤを抽出し、相関キーを使用してメッセージを起動ＳＬＣにルーティングすることができる。しかし、ＳＬＰの地理的に多様な分散配備におけるネットワーク待ち時間を減らすために、すべてのセッション情報が起動ＳＬＣからサービングＳＬＣに転送されるようにサービングＳＬＣが要求することを可能にする、ＳＬＣ間転送要求メッセージが定義される。次にサービングＳＬＣは、トランザクションに関するすべての後続メッセージを処理する。
【０１１１】
ステップ４において、起動ＳＬＣは、転送要求に応答して、進行中のセッションの所有権をサービングＳＬＣに転送し、セッション情報を用いてサービングＳＬＣに応答する。これにより、セッション・ルーティング処理が完了される。
【０１１２】
ステップ５において、必要であれば、ＳＥＴおよびＳＬＣはポジショニング・セッションを完了する。（ＳＰＣは図５に示されていないことに留意されたい）
【０１１３】
ステップ６では、ステップ５においてＳＵＰＬ  ＥＮＤがＳＥＴから受信されると、またはＳＵＰＬ  ＥＮＤがサービングＳＬＣから送信されると、ＳＵＰＬセッションが完了する。
【０１１４】
オプション５−スタンドアロン・セッション・ルータが拡張プロトコルの相関キーを使用する場合
図６は、本発明の原理による起動ＳＬＰからサービングＳＬＰへのセッション・ルーティングを示すスタンドアロン・セッション・ルータを示す。
【０１１５】
具体的には、図６に示す実施形態において、ＳＬＰセッションＩＤが相関キーを用いて拡張され、ネットワーク主導型要求に対する起動ＳＬＰの識別情報を保持する。
【０１１６】
図６のステップ１において、起動ＳＬＰは、ＳＬＰセッションＩＤ内に相関キーを取り込むことによりＳＥＴにＳＵＰＬ  ＩＮＩＴトリガ・メッセージを送信する。
【０１１７】
ステップ２において、ＳＥＴは、セッション識別子のＳＥＴセッション識別子部分を取り込み、ＳＳＲとのＴＣＰ／ＩＰ接続を確立し、トリガ・メッセージに対してＳＵＰＬ  ＰＯＳ  ＩＮＩＴ応答によって返答する。
【０１１８】
ステップ３において、ＳＳＲは、ＳＥＴから着信ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信し、相関キーを抽出し、テーブル・ルックアップを実行して起動ＳＬＰのアドレスを解決する。次に、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージは起動ＳＬＰに直接送信される。
【０１１９】
ステップ４において、必要であれば、ＳＥＴおよびＳＬＰはポジショニング・セッションを開始する。
【０１２０】
ステップ５において、ステップ４でＳＵＰＬ  ＥＮＤがＳＥＴから受信されると、またはＳＵＰＬ  ＥＮＤがサービングＳＬＰから送信されると、ＳＵＰＬセッションは完了する。
【０１２１】
ステップ６において、ＳＳＲはＳＥＴにＳＵＰＬ  ＥＮＤメッセージを転送する。
【０１２２】
オプション６−スタンドアロン・セッション・ルータに拡張プロトコルの相関キーを追加する場合
図７は、本発明の原理による起動ＳＬＰからサービングＳＬＰへのセッション・ルーティングを示すスタンドアロン・セッション・ルータを示す。
【０１２３】
具体的には、図７に示すように、ＳＬＰセッションＩＤが、相関キーを追加することによって拡張され、起動ＳＬＰの識別情報を保持する。
【０１２４】
図７のステップ１において、起動ＳＬＰは、ＳＬＰセッション識別子を取り込むことによりＳＳＲにＳＵＰＬ  ＩＮＩＴトリガ・メッセージを送信する。
【０１２５】
ステップ２において、ＳＳＲは、起動ＳＬＰからの発信ＳＵＰＬ  ＩＮＩＴトリガ・メッセージを受信し、一意の相関キーを用いてＳＬＰセッションＩＤを更新する。次にＳＳＲは、ＳＥＴにＳＵＰＬ  ＩＮＩＴメッセージを転送する。
【０１２６】
ステップ３において、ＳＥＴは、セッション識別子のＳＥＴセッション識別子部分を取り込み、ＳＳＲとのＴＣＰ／ＩＰ接続を確立し、トリガ・メッセージに対してＳＵＰＬ  ＰＯＳ  ＩＮＩＴ応答で返答する。
【０１２７】
ステップ４において、ＳＳＲは、ＳＥＴから着信ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージを受信し、相関キーを抽出し、テーブル・ルックアップを実行して起動ＳＬＰのアドレスを解決する。次いで、元のＳＬＰセッションＩＤに変更が加えらないままで、ＳＵＰＬ  ＰＯＳ  ＩＮＩＴメッセージが起動ＳＬＰに直接送信される。
【０１２８】
ステップ５において、必要であれば、ＳＥＴおよびＳＬＰはポジショニング・セッションを開始する。
【０１２９】
ステップ６では、ステップ４においてＳＵＰＬ  ＥＮＤメッセージがＳＥＴから受信されたとき、またはＳＵＰＬ  ＥＮＤメッセージがサービングＳＬＰから送信されたとき、ＳＵＰＬセッションが完了する。
【０１３０】
ステップ７において、ＳＳＲはＳＥＴにＳＵＰＬ  ＥＮＤメッセージを転送する。
【０１３１】
本発明の利益には、サービングＳＬＣが、インテリジェント転送方式を使用して起動ＳＬＣからサービングＳＬＣに要求を転送することによりＷＡＮ接続全体にわたる場合に、本発明が、オプション２、３および４によって実施されるようにネットワーク待ち時間を低減させることが含まれる。転送要求は、サービングＳＬＣ距離が起動ＳＬＣから遠いときにのみ行われる。さらに、本発明はオプション１、５および６によって実施されるように、整合性のとれた方式で種々のシステムのＴＬＳ証明書の管理および施行のすべての態様を取り扱うことにより、システムに対して整合性のとれた機密保持を提供する。
【０１３２】
本発明を、その例示的な実施形態を参照して説明したが、当業者は、本発明の真の精神および範囲を逸脱することなく、本発明の説明された実施形態に様々な変更を行うことが可能である。
【図１】
2010509889.tif 000004
【図２】
2010509889.tif 000005
【図３】
2010509889.tif 000006
【図４】
2010509889.tif 000007
【図５】
2010509889.tif 000008
【図６】
2010509889.tif 000009
【図７】
2010509889.tif 000010
【図８】
2010509889.tif 000011
【図９】
2010509889.tif 000012
【国際調査報告】
2010509889.tif 000013