(57)【要約】ＥＮＲＰサーバ（１２４、１３０）は、第１のプール要素（ＰＥ）（１１２）および第２のＰＥ（１１８）のそれぞれから登録情報を受け取る。各ＰＥから受け取った登録情報には、同一のプール・ハンドルが含まれる。第１のＰＥからの登録情報にはさらに、冗長性モデルが含まれる。ＥＮＲＰサーバは、第１のＰＥおよび第２のＰＥの両方を含むプール（１０８）を形成し、プールに対して、受け取った冗長性モデルを採用する。次いで、プール・ユーザ（ＰＵ）（１０２）は、ＥＮＲＰサーバにプール・ハンドルを伝達することによってプールにアクセスしてもよく、それに応答して、それらのＰＥに対応するトランスポート・アドレスおよびプールによって実施される冗長性モデルを受け取る。次いで、ＰＵは、受け取ったトランスポート・アドレス、および、適切な場合には、受け取った冗長性モデルに基づいて、プールにアクセスすることができる。
2006515734.tif 000002
【特許請求の範囲】
【請求項１】
インターネット・プロトコル・ベースの通信システムにおけるリソースをプールする方法であって、
プール・ハンドルおよび冗長性モデルを備える第１の登録情報を第１のプール要素から受け取ること、
前記第１の登録情報と同一のプール・ハンドルを備える第２の登録情報を第２のプール要素から受け取ること、
前記第１のプール要素および前記第２のプール要素を備えるプールを形成することであって、該プールに対して前記受け取った冗長性モデルを採用することを備える、プールを形成すること、
を備える方法。
【請求項２】
請求項１に記載の方法において、前記第１の登録情報はさらに第１のプール要素識別子を備え、前記第２の登録情報はさらに第２のプール要素識別子を備え、前記方法はさらに、前記プール・ハンドルに関連して、前記第１の登録情報のうちの少なくとも一部、前記第２の登録情報のうちの少なくとも一部、および前記冗長性モデルを記憶することを備える、方法。
【請求項３】
インターネット・プロトコル・ベースの通信システムにおいてプールされたリソースにアクセスする方法であって、
プール・ハンドル用のデータ・パケットを構築すること、
ネーム・サーバからのプール・ハンドルの変換をリクエストすること、
前記リクエストに応答して、複数のトランスポート・アドレスと前記プール・ハンドルに対応する冗長性モデルとを受け取ること、
前記受け取った複数のトランスポート・アドレスおよび前記受け取った冗長性モデルを記憶すること、
前記複数のトランスポート・アドレスの中からトランスポート・アドレスを選択して、選択されたトランスポート・アドレスを生成すること、
前記選択されたトランスポート・アドレスに前記データ・パケットを伝達すること、
を備える方法。
【請求項４】
請求項３に記載の方法において、
前記構築することは、プール・ユーザのアプリケーション層がプール・ハンドル用のデータ・パケットを構築することを備え、
前記リクエストすることは、前記プール・ユーザのセッション層が前記プール・ハンドルからトランスポート・アドレスを取得することを試み、前記セッション層が前記プール・ハンドルからトランスポート・アドレスを取得することができない場合には、ネーム・サーバのセッション層が前記プール・ハンドルの変換をリクエストすることを備える、方法。
【請求項５】
請求項３に記載の方法において、
前記受け取ることは、複数のトランスポート・アドレスと前記プール・ハンドルに対応する負荷共有ポリシとを受け取ることを備え、前記データ・パケットは第１のデータ・パケットを備え、前記選択されたトランスポート・アドレスは第１のトランスポート・アドレスを備え、
前記方法はさらに、
前記プール・ハンドル用の第２のデータ・パケットを構築すること、
前記負荷共有ポリシに基づいて、前記複数のトランスポート・アドレスのうちから第２のトランスポート・アドレスを決定すること、
前記第２のデータ・パケットを前記第２のトランスポート・アドレスに伝達すること、
を備える、方法。
【請求項６】
請求項３に記載の方法において、
前記受け取ることは、複数のトランスポート・アドレスと前記プール・ハンドルに対応する冗長性モデルとを受け取ることを備え、前記データ・パケットは少なくとも第１のデータ・パケットを備え、前記選択されたトランスポート・アドレスは第１のトランスポート・アドレスを備え、
前記方法はさらに、
少なくとも第１のデータ・パケットのデータ・パケットが、該データ・パケットの意図された送信先において無事に受け取られなかったことを判断すること、
前記冗長性モデルに基づいて、前記複数のトランスポート・アドレスのうちから第２のトランスポート・アドレスを決定すること、
前記無事に受け取られなかったデータ・パケットを前記第２のトランスポート・アドレスに再び伝達すること、
を備える、方法。
【請求項７】
請求項３に記載の方法において、
前記データ・パケットは少なくとも第１のデータ・パケットを備え、
前記方法はさらに、
前記選択されたトランスポート・アドレスに関連するプール要素から、少なくとも１つのバックアップ・プール要素の指定を受け取ること、
トランスポート障害を検出すること、
前記少なくとも１つのバックアップ・プール要素の指定に基づいて、バックアップ・プール要素を決定すること、
前記トランスポート障害を検出した後に、前記決定されたバックアップ・プール要素にデータ・パケットを伝達すること、
を備える、方法。
【請求項８】
請求項７に記載の方法において、
前記複数のトランスポート・アドレスと冗長性モデルとを受け取ることは、複数のトランスポート・アドレスと前記プール・ハンドルに対応する冗長性モデルとを受け取ることを備え、
前記少なくとも１つのバックアップ・プール要素の指定を受け取ることは、複数のプール要素の中からの少なくとも１つのバックアップ・プール要素の指定を、前記選択されたトランスポート・アドレスに関連するプール要素から受け取ることを備え、
前記方法はさらに、
前記プール・ハンドルの変換に対するリクエストに応答して、前記複数のプール要素の各プール要素のサービス状態を受け取ること、
対応するプール要素に関連して、前記受け取ったサービス状態を記憶すること、
前記少なくとも１つのバックアップ・プール要素の指定に基づいて、指定されたバックアップ・プール要素を決定すること、
前記少なくとも１つのバックアップ・プール要素の指定に基づいて、かつ前記記憶されたサービス状態を参照することによって、前記指定されたバックアップ・プール要素のサービス状態を判断すること、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス中であるときには、前記指定されたバックアップ・プール要素にデータ・パケットを伝達すること、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス休止中であるときには、前記冗長性モデルに基づいてバックアップ・プール要素を決定し、前記冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達すること、
を備える、方法。
【請求項９】
複数のプール要素の中から代替プール要素を決定する方法であって、
前記複数のプール要素におけるプール要素との通信に関するトランスポート障害を検出すること、
前記複数のプール要素の中からのバックアップ・プール要素の指定に基づいて、バックアップ・プール要素を決定すること、
前記指定されたバックアップ・プール要素のサービス状態を判断すること、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス中であるときには、前記指定されたバックアップ・プール要素にデータ・パケットを伝達すること、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス休止中であるときには、冗長性モデルに基づいてバックアップ・プール要素を決定し、前記冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達すること、
を備える方法。
【請求項１０】
インターネット・プロトコル・ベースの通信システムにおいて動作可能なネーム・サーバであって、
第１のプール要素および第２のプール要素から第１の登録情報および第２の登録情報をそれぞれ受け取ることが可能なプロセッサであって、前記第１の登録情報は、プール・ハンドル、第１のプール要素識別子、および冗長性モデルを備え、前記第２の登録情報は、前記第１の登録情報におけるプール・ハンドルと同一のプール・ハンドル、および第２のプール要素識別子を備え、該プロセッサは、前記第１のプール要素および第２のプール要素を含むプールを形成し、該プールに対して前記冗長性モデルを採用する、プロセッサと、
前記プロセッサに結合された少なくとも１つのメモリ・デバイスと、を備え、
前記プロセッサは、前記少なくとも１つのメモリ・デバイス内に、前記第１のプール要素識別子に関連するプール・ハンドル、前記第２のプール要素識別子、および前記冗長性モデルを記憶する、ネーム・サーバ。
【請求項１１】
請求項１０に記載のネーム・サーバにおいて、前記プロセッサはさらに、前記第１の登録情報および前記第２の登録情報のそれぞれの受け取りに対して確認応答する、ネーム・サーバ。
【請求項１２】
請求項１０に記載のネーム・サーバにおいて、前記プロセッサは、複数のプロトコル層を備え、該複数のプロトコル層は、トランスポート層とアプリケーション層との間にセッション層を備え、前記第１の登録情報は、第１のセッション層登録メッセージにより受け取られ、前記第２の登録情報は、第２のセッション層登録メッセージにより受け取られる、ネーム・サーバ。
【請求項１３】
エンドポイント・ネーム・レゾルーション・プロトコル（ＥＮＲＰ）サーバを備えるインターネット・プロトコル・ベースの通信システムにおいて、ＥＮＲＰサーバからトランスポート・アドレスを取り出すことが可能な通信装置であって、
少なくとも１つのメモリ・デバイスと、
プロセッサであって、
プール・ハンドル用のデータ・パケットを構築し、
前記ＥＮＲＰサーバからの前記プール・ハンドルの変換をリクエストし、
前記リクエストに応答して、複数のトランスポート・アドレスと前記プール・ハンドルに対応する冗長性モデルとを受け取り、
前記受け取った複数のトランスポート・アドレスおよび前記受け取った冗長性モデルを、前記少なくとも１つのメモリ・デバイスに記憶し、
前記複数のトランスポート・アドレスの中からトランスポート・アドレスを選択して、選択されたトランスポート・アドレスを生成し、
前記選択されたトランスポート・アドレスに前記データ・パケットを伝達する、プロセッサと、
を備える通信装置。
【請求項１４】
請求項１３に記載の通信装置において、前記プロセッサは複数のプロトコル層を備え、該複数のプロトコル層は、アプリケーション層、アプリケーション層より下位のセッション層、およびセッション層より下位のトランスポート層を備え、アプリケーション層は、前記プール・ハンドル用のデータ・パケットを構築し、セッション層は、前記プール・ハンドルからトランスポート・アドレスを取得することを試み、セッション層が前記プール・ハンドルからトランスポート・アドレスを取得することができない場合には、ネーム・サーバに、前記プール・ハンドルの変換をリクエストする、通信装置。
【請求項１５】
請求項１３に記載の通信装置において、前記データ・パケットは第１のデータ・パケットを備え、前記選択されたトランスポート・アドレスは、第１のトランスポート・アドレスを備え、前記プロセッサはさらに、前記プール・ハンドル用の第２のデータ・パケットを構築し、前記少なくとも１つのメモリ・デバイスに記憶された負荷共有ポリシを参照することによって前記複数のトランスポート・アドレスのうちから第２のトランスポート・アドレスを決定し、該第２のトランスポート・アドレスに前記第２のデータ・パケットを伝達する、通信装置。
【請求項１６】
請求項１３に記載の通信装置において、前記プロセッサは複数のトランスポート・アドレスおよび冗長性モデルを受け取り、前記データ・パケットは少なくとも第１のデータ・パケットを備え、前記選択されたトランスポート・アドレスは第１のトランスポート・アドレスを備え、前記プロセッサはさらに、前記少なくとも第１のデータ・パケットのデータ・パケットが、前記選択されたトランスポート・アドレスに関連するプール要素によって無事に受け取られなかったことを判断し、前記複数のトランスポート・アドレスにおける第２のトランスポート・アドレスを、前記少なくとも１つのメモリ・デバイスに記憶された前記冗長性モデルを参照することによって決定し、前記無事に受け取られなかったデータ・パケットを前記第２のトランスポート・アドレスに再び伝達する、通信装置。
【請求項１７】
請求項１３に記載の通信装置において、前記データ・パケットは、少なくとも第１のデータ・パケットを備え、前記プロセッサはさらに、前記選択されたトランスポート・アドレスに関連するプール要素から、少なくとも１つのバックアップ・プール要素の指定を受け取り、該少なくとも１つのバックアップ・プール要素の指定を前記少なくとも１つのメモリ・デバイスに記憶し、トランスポート障害を検出し、前記少なくとも１つのメモリ・デバイスに記憶された少なくとも１つのバックアップ・プール要素の指定を参照することによってバックアップ・プール要素を決定し、前記トランスポート障害を検出した後に、前記決定されたバックアップ・プール要素にデータ・パケットを伝達する、通信装置。
【請求項１８】
請求項１７に記載の通信装置において、前記プロセッサは、複数のトランスポート・アドレスと前記プール・ハンドルに対応する冗長性モデルとを受け取って、前記少なくとも１つのメモリ・デバイスに記憶し、
前記プロセッサは、前記プール・ハンドルの変換に対するリクエストに応答して、さらに複数のプール要素の各プール要素のサービス状態を受け取って、該受け取ったサービス状態を、対応するプール要素に関連して前記少なくとも１つのメモリ・デバイスに記憶し、
前記プロセッサが、少なくとも１つのバックアップ・プール要素の指定を受け取ることは、前記プロセッサが、前記選択されたトランスポート・アドレスに関連するプール要素から、複数のプール要素の中からの少なくとも１つのバックアップ・プール要素の指定を受け取ることを備え、
前記プロセッサはさらに、前記少なくとも１つのバックアップ・プール要素の指定に基づいて、指定されたバックアップ・プール要素を決定し、前記指定されたバックアップ・プール要素のサービス状態を前記少なくとも１つのメモリ・デバイスを参照することによって判断し、前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス中であるときには、前記指定されたバックアップ・プール要素にデータ・パケットを伝達し、前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス休止中であるときには、前記記憶された冗長性モデルに基づいてバックアップ・プール要素を決定し、前記冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達する、通信装置。
【請求項１９】
インターネット・プロトコル・ベースの通信システムにおいて動作可能な通信装置であって、
プール内の複数のプール要素の各プール要素に関連するトランスポート・アドレスおよびサービス状態と、前記プールに関連する冗長性モデルとを記憶する少なくとも１つのメモリ・デバイスと、
前記少なくとも１つのメモリ・デバイスに結合されるプロセッサであって、
前記複数のプール要素におけるプール要素との通信に関するトランスポート障害を検出し、
前記複数のプール要素の中からのバックアップ・プール要素の指定に基づいて、バックアップ・プール要素を決定し、
前記少なくとも１つのメモリ・デバイスを参照して、前記指定されたバックアップ・プール要素のサービス状態を判断し、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス中であるときには、前記指定されたバックアップ・プール要素にデータ・パケットを伝達し、
前記トランスポート障害を検出した後であり、かつ前記指定されたバックアップ・プール要素がサービス休止中であるときには、前記少なくとも１つのメモリ・デバイスを参照して、冗長性モデルに基づいてバックアップ・プール要素を決定し、前記冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達する、プロセッサと、
を備える通信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、インターネット・プロトコル・ベースの通信システムに関し、特にインターネット・プロトコル・ベースの通信システムおけるリソース・プーリングに関する。
【背景技術】
【０００２】
システムの有効性は、すべての通信システムにとって重要な側面である。すなわち、あらゆる通信システムは、目標として、高い有効性を実現して、システムの一部がクラッシュした場合でもシステムが依然としてサービスを提供できるようにすることを目指している。高い有効性を実現する方法の１つは、システムに冗長性を設けることである。冗長性としては、動作中のシステムに対してバックアップ・システムを設けることが挙げられる。そうすることにより、動作中のシステムがクラッシュした場合でも、バックアップ・システムが介入して、動作中のシステムが行なっていた機能を行なうことができる。
【０００３】
冗長性の欠点は、バックアップ・システムのコストである。バックアップ・システムは、動作中のシステムがクラッシュするまでアイドル状態にある。そのため、バックアップ・システムを設けることはコストがかかる。冗長性のコストをより望ましいものにする方法の１つは、リソースを「プール」することである。「プーリング」としては、同様の機能を行なう複数のリソースを１つに束ねてプールにして、プール・ユーザ（ＰＵ：Pool User ）が、プールされたリソースの任意の１つまたは複数を利用できるようにすることが挙げられる。プール内のあるリソース、すなわちプール要素（ＰＥ:Pool Element ）が破損した場合には、他のＰＥ、通常はバックアップまたはスタンバイＰＥが、破損したＰＥを引き継ぐため、ＰＵに対するサービスの中断を最小限にすることができる。破損した動作中のＰＥからスタンバイＰＥへスイッチングする技術は、フェイル・オーバとして知られている。
【０００４】
インターネット・プロトコル（ＩＰ：Internet Protocol ）環境では、複数のアプリケーション・プロセッサ、たとえばウェブ・ベースのサーバ上で実行される複数のプロセッサ（それぞれがアプリケーションに対して特定のサービスを提供する）をプールすることができる。このようなアプリケーション・プロセッサのそれぞれは、他のプール要素（ＰＥ）、すなわちアプリケーション・プロセッサと機能的に同一であり、アプリケーションに対して特定のサービスを提供する。ＰＥのプーリングは、プール上で実行されるアプリケーションに対して透過的である。すなわちアプリケーションにとっては、すべてのＰＥが単一の要素のように見える。ＰＥをプールすることによって、システム・コストを下げることができる。これは、規格品のコンポーネントを１つに結合してプールにすることで、極めて高価なコンピュータを用いた場合に得られるものと同等のサービスが得られるからである。さらに、ＰＥをプールすることによって、ＰＥがクラッシュしただけの場合には、ＰＥのみを取り替えればよく、システム全体を取り替える必要はない。
【０００５】
別の観点から言えば、プーリングは、アプリケーション層よりも下位のプロトコル層の要素を、アプリケーション層にとって透過的な方法により束ねることを伴う。アプリケーション層は、インターネット・プロトコル（ＩＰ）ベースのネットワーク・システムの相互接続用に広く用いられる４層プロトコル・スタックにおける最上位の層である。最上位から最下位に向かって、スタックには、アプリケーション層、トランスポート層、ネットワーク層、および物理層が含まれる。プロトコルによって、ネットワークを通じて交換されるデータ・パケットの各データ・ビットを解釈する方法が特定される。プロトコルのレイヤリングによって、ネットワーク・デザインを機能層に分割した後、各層のタスクを行なうように別個のプロトコルを割り当てる。プロトコルのレイヤリングを用いることによって、プロトコルは簡単化され、各プロトコルが有する特定のタスクの数は少なくなる。次にプロトコルを組み合わせて、有用な全体にすることができる。個々のプロトコルは、必要に応じて取り除くかまたは取り替えることができる。プーリングを用いるシステムでは、アプリケーション層が下位層の複雑さを認識することはない。そのため下位層を、任意の方法により組織化することができるとともに、容易に取り替えることができる。その結果、アプリケーション層では、サービスを実施する方法よりも、アプリケーション層に提供されるサービスの品質の方に関心を払えばよい。
【０００６】
アプリケーション層に高い有効性を与えることを目的として、通信システム内の冗長性を実現する複数のモデルが開発されている。このようなモデルの１つは、「Ｎ＋１」冗長性モデルである。このモデルでは、「Ｎ」個の動作中のサーバによってノードが共有され、１つのサーバがバックアップとして取っておかれる。「Ｎ」個のサーバの１つがクラッシュした場合には、バックアップが介入してその場所を占める。このようなモデルの他のものは、「Ｎ＋Ｍ」冗長性モデルである。このモデルでは、「Ｎ」個の動作中のサーバによってノードが共有され、「Ｍ」個のサーバがバックアップとして取っておかれる。このようなモデルのさらに他のものは、「Ｍペア」冗長性モデルである。このモデルでは、「２×Ｍ」個のサーバが対になって「Ｍ」個のペアを形成し、各ペアには、動作中のサーバとバックアップ・サーバとが含まれている。動作中のサーバがクラッシュした場合には、ペアのバックアップ・サーバが代わりをする。バックアップがクラッシュしたときには、バックアップは取り替えない。各モデルには、それぞれ長所および短所がある。「Ｍペア」モデルの長所は、各バックアップがその対応する動作中のシステムの状態を認識しているため、システム・デザインの複雑さが減少することである。「Ｎ＋１」および「Ｎ＋Ｍ」冗長性モデルでは、各バックアップがユーザに通知することなく動作中のシステムの代わりができるように、各バックアップは、動作中のすべてのシステムの状態を認識しなければならない。そのため、このような状態共有は、非常にコストがかかる。しかし、「Ｍペア」モデルでは、場合によっては、システムに障害がないときにアイドル状態にさせてしまうリソースの量が大きくなる。以上のことから、各冗長性モデルのコストおよび利益を比較検討し、どの冗長性モデルを実施するかを決定することを、システム設計者に一任することが望まれる。さらに、通信システムによって冗長性モデルを動的に実施できるようにすることが望まれる。たとえば、場合によっては、システムにおけるすべてのプールに対して単一の冗長性モデルに固定する代わりに、プールごとのベースで冗長性モデルを確立することが望ましい。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
現在のところ、インターネット・プロトコル（ＩＰ）通信システムに対する規格がサポートしている冗長性モデルは唯一つである。このモデルでは、プール内のＰＥはそれぞれ、プール内の他のすべてのＰＥのバックアップである。この冗長性モデルは、実施にかかるコストが大きく、最適とは言えない状況が多い、またシステム設計に対して非常に制限的である。
【０００８】
したがって、複数の冗長性モデルの実施をサポートし、さらにＩＰ通信システムにおける冗長性モデルの動的な実施をサポートする方法および装置が求められている。
【課題を解決するための手段】
【０００９】
複数の冗長性モデルの実施をサポートし、またＩＰ通信システムにおける冗長性モデルの動的な実施をサポートする方法および装置に対する必要性に対処するために、ＩＰベースの通信システムにおけるＥＮＲＰサーバが、第１のプール要素（ＰＥ）および第２のＰＥのそれぞれから登録情報を受け取る。各ＰＥから受け取った登録情報には、同一のプール・ハンドルが含まれている。第１のＰＥからの登録情報にはさらに、冗長性モデルが含まれている。ＥＮＲＰサーバは、第１のＰＥおよび第２のＰＥの両方を含むプールを形成し、その冗長性モデルを採用する。次いで、プール・ユーザ（ＰＵ）は、プール・ハンドルをＥＮＲＰサーバに伝達し、それに応答して、それらのＰＥに対応するトランスポート・アドレスとプールに対して採用される冗長性モデルとを受け取ることによって、プールへのアクセスを行なってもよい。次いで、ＰＵは、受け取ったトランスポート・アドレスおよび、適切な場合には、冗長性モデルに基づいて、プールにアクセスすることができる。
【００１０】
一般的に、本発明の実施形態には、インターネット・プロトコル・ベースの通信システムにおけるリソースをプールする方法が包含される。本方法には、プール・ハンドルおよび冗長性モデルを含む第１の登録情報を第１のプール要素から受け取ること、第１の登録情報と同一のプール・ハンドルを含む第２の登録情報を第２のプール要素から受け取ること、が含まれる。本方法にはさらに、第１のプール要素および第２のプール要素を備えるプールを形成することであって、プールに対して、受け取った冗長性モデルを採用することを備えるプールを形成することが、含まれる。
【００１１】
本発明の別の実施形態には、インターネット・プロトコル・ベースの通信システムにおいてプールされたリソースにアクセスする方法が包含される。本方法には、プール・ハンドル用のデータ・パケットを構築すること、ネーム・サーバからのプール・ハンドルの変換をリクエストすること、リクエストに応答して、複数のトランスポート・アドレスとプール・ハンドルに対応する冗長性モデルとを受け取ること、が含まれる。本方法にはさらに、受け取った複数のトランスポート・アドレスおよび受け取った冗長性モデルを記憶すること、複数のトランスポート・アドレスの中からトランスポート・アドレスを選択して、選択されたトランスポート・アドレスを生成すること、選択されたトランスポート・アドレスにデータ・パケットを伝達すること、が含まれる。
【００１２】
本発明のさらに別の実施形態には、複数のプール要素の中から代替プール要素を決定する方法が包含される。本方法には、複数のプール要素のうちのプール要素との通信に関するトランスポート障害を検出するステップと、複数のプール要素の中からのバックアップ・プール要素の指定に基づいてバックアップ・プール要素を決定するステップと、指定されたバックアップ・プール要素のサービス状態を判断するステップと、が備わっている。本方法にはさらに、トランスポート障害を検出した後であり、かつ指定されたバックアップ・プール要素がサービス中であるときには、指定されたバックアップ・プール要素にデータ・パケットを伝達すること、トランスポート障害を検出した後であり、かつ指定されたバックアップ・プール要素がサービス休止中であるときには、冗長性モデルに基づいてバックアップ・プール要素を決定し、冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達すること、が備わっている。
【００１３】
本発明のさらに別の実施形態には、インターネット・プロトコル・ベースの通信システムにおいて動作可能なネーム・サーバが包含される。本ネーム・サーバには、少なくとも１つのメモリ・デバイスに結合されたプロセッサが含まれる。プロセッサは、プール・ハンドル、第１のプール要素識別子、および冗長性モデルを含む第１の登録情報を第１のプール要素から受け取ること、第１の登録情報と同一のプール・ハンドルおよび第２のプール要素識別子を含む第２の登録情報を第２のプール要素から受け取ること、第１のプール要素および第２のプール要素を備えるプールを形成すること、プールに対して、受け取った冗長性モデルを採用すること、が可能である。プロセッサはさらに、少なくとも１つのメモリ・デバイス内に、第１のプール要素識別子に関連するプール・ハンドル、第２のプール要素識別子、および冗長性モデルを記憶する。
【００１４】
本発明のさらに別の実施形態には、エンドポイント・ネーム・レゾルーション・プロトコル（ＥＮＲＰ）サーバを備えるインターネット・プロトコル・ベースの通信システムにおいて、ＥＮＲＰサーバからトランスポート・アドレスを取り出すことが可能な通信装置が包含される。通信装置には、少なくとも１つのメモリ・デバイスに結合されたプロセッサが含まれる。プロセッサは、プール・ハンドル用のデータ・パケットを構築し、ＥＮＲＰサーバからのプール・ハンドルの変換をリクエストし、リクエストに応答して、複数のトランスポート・アドレスと、プール・ハンドルに対応する負荷共有ポリシおよび冗長性モデルのうちの少なくとも一方とを受け取り、受け取った複数のトランスポート・アドレスと、受け取った負荷共有ポリシおよび冗長性モデルのうちの少なくとも一方とを、少なくとも１つのメモリ・デバイスに記憶し、複数のトランスポート・アドレスの中からトランスポート・アドレスを選択して、選択されたトランスポート・アドレスを生成し、選択されたトランスポート・アドレスにデータ・パケットを伝達する。
【００１５】
本発明のさらに別の実施形態には、インターネット・プロトコル・ベースの通信システムにおいて動作可能な通信装置が包含される。通信装置には、プール内の複数のプール要素の各プール要素に関連するトランスポート・アドレスおよびサービス状態と、プールに関連する冗長性モデルとを記憶する少なくとも１つのメモリ・デバイスが含まれる。通信装置にはさらに、少なくとも１つのメモリ・デバイスに結合されるプロセッサであって、複数のプール要素のうちのプール要素との通信に関してトランスポート障害を検出し、複数のプール要素の中からのバックアップ・プール要素の指定に基づいてバックアップ・プール要素を決定し、少なくとも１つのメモリ・デバイスを参照して、指定されたバックアップ・プール要素のサービス状態を判断し、トランスポート障害を検出した後であり、かつ指定されたバックアップ・プール要素がサービス中であるときには、指定されたバックアップ・プール要素にデータ・パケットを伝達し、トランスポート障害を検出した後であり、かつ指定されたバックアップ・プール要素がサービス休止中であるときには、少なくとも１つのメモリ・デバイスを参照して、冗長性モデルに基づいてバックアップ・プール要素を決定し、冗長性モデルに基づいて決定されたバックアップ・プール要素にデータ・パケットを伝達する、プロセッサが含まれる。
【発明を実施するための最良の形態】
【００１６】
図１〜８を参照しながら、本発明をより詳しく説明する。図１は、本発明の実施形態によるインターネット・プロトコル（ＩＰ）通信システム１００のブロック・ダイアグラムである。通信システム１００には、少なくとも１つのプール・ユーザ（ＰＵ）１０２、すなわちクライアント通信装置、たとえば電話機またはデータ端末機器、たとえばパーソナル・コンピュータ、ラップトップ・コンピュータ、またはワークステーションと、複数のホスト通信装置１１０、１１６（２つを示す）、たとえば（ＰＵがアクセスするアプリケーションが実行される）コンピュータ、ワークステーション、またはサーバとが、含まれる。ＰＵ１０２上で実行されるアプリケーションは、１つまたは複数のホスト通信装置１１０、１１６のそれぞれ上で実行されるアプリケーションと、データ・パケットを交換する。しかし、１つまたは複数のホスト通信装置１１０、１１６の下位レベルのプロトコル層は、ＰＵ１０２のアプリケーション層にとって透過的である。そのため、１つまたは複数のホスト通信装置１１０、１１６は、ＰＵのアプリケーション層にとって単一のホストのように見える。ＩＰ環境においては、ＰＵ１０２はさらに、無線通信装置、たとえば携帯電話、無線電話、または無線モデムであって、データ端末機器、たとえばパーソナル・コンピュータ、ラップトップ・コンピュータ、またはワークステーションに結合されるかその中に含まれるものであってもよい。
【００１７】
各ホスト通信装置１１０、１１６には、プール１０８の処理リソースまたはプール要素（ＰＥ）１１２、１１８が、それぞれ含まれている。プール１０８は、ＰＵ１０２上で実行されるアプリケーションに対してアプリケーション処理サービスを提供する。プール１０８内のそれぞれの処理リソースまたはＰＥ１１２、１１８は、特定の同等のサービスをアプリケーションに提供するアプリケーション・プロセッサであり、プール内の他のＰＥと機能的に同一である。各ＰＥ１１２、１１８は、ホスト通信装置１１０、１１６、たとえばコンピュータまたはサーバ、たとえばウェブ・ベースのサーバ内にあってもよいが、各ＰＥ１１２、１１８の具体的な位置は、本発明にとってはそれほど重要ではない。また通信システム１００によって、プール内のＰＥに場所的な制約が課されることはない。すなわちプール１０８内の各ＰＥ１１２、１１８は、通信システム１００全体において任意のホスト通信装置上に自由に配置してもよい。しかし本発明の他の実施形態において、プール１０８が状態共有メカニズムを用いる場合には、通信システム１００は、プールに属するＰＥ１１２、１１８に場所的な制約を課す場合がある。さらにＰＵ１０２は、プール１０８と通信する他のプールのＰＥであってもよい。
【００１８】
プール１０８は、プールにアクセスするユーザにサービスするＰＥをプールが割り当てる順番を決定する負荷共有ポリシと関連している。たとえば、プール１０８がラウンド・ロビン負荷共有ポリシに関連しており、ＰＥ１１２に最新のユーザ・セッションが割り当てられているとき、ＰＥ１１８がラウンド・ロビン・キューにおける次のＰＥである場合には、プール１０８は、プールにアクセスする次のユーザにサービスするようにＰＥ１１８を割り当てる。しかし、当業者であれば分かるように、たとえば最小使用頻度および重み付きラウンド・ロビンのような多くの負荷共有ポリシが当該技術分野において知られている。そのうちのどれであっても、本発明の技術思想および範囲から逸脱することなく、プール１０８によって実施され得る。プール１０８はさらに、動作中のＰＥに対してバックアップＰＥを決定する冗長性モデルに関連している。その結果、動作中のＰＥがクラッシュした場合には、ＰＵは、動作中のＰＥが行なっていた機能を行なうバックアップＰＥを選ぶことができる。たとえば、プール１０８は「Ｎ＋１」冗長性モデルと関連していてもよい。この場合、「Ｎ」個の動作中のＰＥによってノードが共有され、１つのＰＥがバックアップとして取っておかれる。「Ｎ」個のＰＥのうちの１つがクラッシュしたときには、ＰＵが介入して、バックアップＰＥを選んで代わりをさせることができる。他の例としては、プール１０８は「Ｎ＋Ｍ」冗長性モデルと関連していてもよい。この場合、「Ｎ」個の動作中のＰＥによってノードが共有され、「Ｍ」個のＰＥがバックアップとして取っておかれる。さらに他の例としては、プール１０８は「Ｍペア」冗長性モデルと関連していてもよい。この場合、「２×Ｍ」個のＰＥが対になって「Ｍ」個のペアを形成し、各ペアには動作中のＰＥとバックアップＰＥとが含まれている。動作中のＰＥがクラッシュした場合には、ＰＵは、ペアのバックアップＰＥに切り換える。バックアップＰＥがクラッシュしたときには、バックアップＰＥは取り替えない。当業者であれば分かるように、種々の冗長性モデルが存在しており、そのうちのどれであっても、本発明の技術思想および範囲から逸脱することなく、プール１０８によって実施され得る。
【００１９】
通信システム１００にはさらに、プール１０８のそれぞれのＰＥ１１２、１１８と通信するエンドポイント・ネーム・レゾルーション・プロトコル（ＥＮＲＰ：End-Point Name Resolution Protocol）ネームスペース・サービス１２２が含まれる。ＥＮＲＰネームスペース・サービス１２２は、単一のＥＮＲＰサーバを含んでいてもよいし、完全に分散された複数のＥＮＲＰサーバ１２４、１３０（２つを示す）のプールを含んでいてもよい。ＥＮＲＰサーバのプールを含むことによって、ＥＮＲＰネームスペース・サービス１２２は、有効性の高いサービス、すなわち単一障害点のないサービスを提供することができる。ＥＮＲＰネームスペース・サービス１２２が、複数のＥＮＲＰサーバを含むときには、複数のＥＮＲＰサーバ１２４、１３０はそれぞれ、ネームスペース・サービスの他のＥＮＲＰサーバと通信するとともに、ＥＮＲＰプロトコルを用いることによって他のＥＮＲＰサーバとも通信する。
【００２０】
ＰＵ１０２とＥＮＲＰネームスペース・サービス１２２における１つまたは複数のＥＮＲＰサーバ１２４、１３０とは、プロセッサ１０４、１２６、１３２をそれぞれ含んでいる。プロセッサはたとえば、１つもしくは複数のマイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ（ＤＳＰ：Digital Signal Processor）、それらの組み合わせ、または当業者に知られている他のこのようなデバイスである。コンポーネント１０２、１１２、１１８、１２４、および１３０はさらに、１つまたは複数のメモリ・デバイス１０６、１１４、１２０、１２８、および１３４をそれぞれ含むかまたはそれらに関連している。メモリ・デバイスはたとえば、ランダム・アクセス・メモリ（ＲＡＭ：Random Access Memory）、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：Dynamic Random Access Memory）、および／もしくは読み出し専用メモリ（ＲＯＭ：Read Only Memory）、またはそれらの等価物であって、コンポーネントのプロセッサが実行し得るデータおよびプログラムを記憶するものである。
【００２１】
通信システム１００は、ＩＰベースの通信システムであって、インターネット・エンジニアリング・タスク・フォース（ＩＥＴＦ：Internet Engineering Task Force ）リライアブル・サーバ・プーリング（ＲＳＥＲＰＯＯＬ：Reliable Sever Pooling）プロトコル・スイート、ＩＥＴＦ  ＲＦＣ（Request For Comment （コメントに対するリクエスト））３２３７に従って動作し、本明細書で提供されるプロトコルに対する変更の影響を受ける。なおプロトコルは、本明細書において参照により取り入れられている。ＩＥＴＦ  ＲＳＥＲＰＯＯＬプロトコル・スイートは、クラスタまたはプール、ＩＰベースのネットワークにおけるマネージメントを提供し、その入手は、ＩＥＴＦオフィス（バージニア州レストン）におけるＩＥＴＦから、またはｉｅｔｆｏｒｇ／ｒｆｃにおいてオン・ラインで、行なうことができる。
【００２２】
相互接続されたネットワーク・システムたとえばシステム１００のレベルにおいて、プロトコルとして知られる合意が、ネットワークの複数のユーザ間のデータ交換に対して開発されてきている。プロトコルによって、ネットワークを通じて交換されるデータ・パケットのあらゆるデータ・ビットを解釈する方法が特定される。ネットワーク・デザインを簡単にするために、プロトコルを層状にするための良く知られた技術がいくつか開発されてきている。プロトコルのレイヤリングは、ネットワーク・デザインを機能層に分割した後、各層のタスクを行なうように別個のプロトコルを割り当てる。プロトコルのレイヤリングを用いることによって、プロトコルは簡単化され、各プロトコルが有する特定のタスクの数は少なくなる。そしてプロトコルを組み合わせて有用な全体にすることが可能であり、個々のプロトコルは、必要に応じて取り除くかまたは取り替えることができる。
【００２３】
プロトコルの層状表現は、プロトコル・スタックとして広く知られている。図２は、通信システム１００の各コンポーネント、すなわちＰＵ１０２、ＰＥ１１２および１１８、ならびにＥＮＲＰサーバ１２４および１３０に備わるプロトコル・スタック２００のブロック・ダイアグラムである。プロトコル・スタックには、５つの層が含まれている。これらの層は、最上位から最下位に向かって、アプリケーション層２１０、セッション層２０８、トランスポート層２０６、ネットワーク層２０４、および物理層２０２である。物理層以外のプロトコル・スタックの各層は、各コンポーネントのプロセッサ内に備わり、対応するメモリ・デバイス内に記憶される命令に基づいて動作する。
【００２４】
プロトコル・スタック２００の最下層、すなわち物理層２０２には、データ輸送のためのネットワーク・ハードウェアおよび物理的媒体、たとえばイーサネットが含まれる。次の上層、すなわちネットワーク層２０４は、データ供給源とデータに対する送信先とを相互接続する一連の様々な物理的ネットワークを通じてのデータ送出を担当する。ネットワーク層には、たとえば、ルーティング・プロトコル、ＩＰプロトコル、たとえばＩＰｖ４またはＩＰｖ６が含まれる。ピア・ネットワーク層間で交換されるＩＰデータ・パケットには、ＩＰプロトコルに対する情報とより高レベルのプロトコルに対するデータとを収容するＩＰヘッダが含まれる。ＩＰヘッダには、プロトコル識別フィールドが含まれ、さらにトランスポート・アドレスが含まれる。トランスポート・アドレスは通常、ＩＰアドレスであり、データ・パケットを供給するトランスポート層およびデータ・パケットの送信先であるトランスポート層のそれぞれに対応する。トランスポート・アドレスは、ネットワーク層を介してトランスポート層との間でデータ・パケットを送受信することができるインターフェースを一意に識別する。トランスポート・アドレスは、ＩＥＴＦ  ＲＦＣ１２４６、ＩＥＴＦの他の刊行物において詳細に説明されている。ＩＰプロトコルは、ＩＥＴＦ  ＲＦＣ７９１において詳細に規定されている。
【００２５】
ネットワーク層２０４の次の上層は、トランスポート層２０６である。トランスポート層２０６によって、相互接続されたネットワーク・システムを通じての端末間データ・フロー管理、たとえば接続ランデブおよびフロー制御が得られる。通常、トランスポート層には、複数のトランスポート・プロトコル、たとえばＳＣＴＰ（Stream Control Transmission Protocol（ストリーム制御伝送プロトコル））、ＴＣＰ（Transmission Control Protocol （伝送制御プロトコル））、またはＵＤＰ（User Datagram Protocol（ユーザ・データグラム・プロトコル））のうちの１つが含まれる。それぞれ、特定のポートにネットワーク層データ・パケットを送出するためのメカニズムをもたらす。トランスポート層２０６の上は、セッション層２０８である。セッション層２０８は、ＲＳＥＲＰＯＯＬプロトコル、たとえばＡＳＡＰ（Aggregate Server Access Protocol（集合体サーバ・アクセス・プロトコル））およびＥＮＲＰを実施する。またセッション層２０８は、通信システム１００のコンポーネント１０２、１１２、１１８、１２４、および１３０間でＲＳＥＲＰＯＯＬ信号送信が交換される層である。ＡＳＡＰおよびＥＮＲＰプロトコルは、ＩＥＴＦインターネット・ドラフトの論文「draft-ietf-rserpool-asap-05 」（２００２年１０月３１日付け）、および「draft-ietf-rsepool-commonparam-02 」（２００２年１０月１日付け）において説明されている。これらの論文は、ＩＥＴＦの刊行物であり、本明細書において参照により全体として取り入れられている。セッション層２０８の上は、アプリケーション層２１０である。この層には、ユーザ・レベルのアプリケーション、たとえばファイル転送およびメール送信を実施するプロトコルが収容されている。
【００２６】
複数の冗長性モデルの実施をサポートしさらに冗長性モデルの動的な実施をサポートするために、通信システム１００では、プール要素登録プロセスと、対応するプール形成プロセスとが提供される。プール形成プロセスは、複数の冗長性モデルのいずれか１つがプールによって実施されることをサポートする。またプールの負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシは、予め確定しておかなくてもよく、プールの形成時に確立することができる。そのため、通信システム１００によって、冗長性モデルの動的な実施がサポートされる。加えて、通信システム１００では、プールにアクセスするＰＵが、送信先ＰＥ、または破損したＰＥ用のバックアップＰＥを、プールの冗長性モデル／フェイル・オーバのポリシに基づいて選択することができる。その結果、システムのフレキシビリティが大きくなる。
【００２７】
図３は、本発明の実施形態によるプール要素登録プロセスの論理フロー・ダイアグラム３００である。論理フロー・ダイアグラム３００が開始され（３０２）、第１のＰＥ、たとえばＰＥ１１２が、ＥＮＲＰネームスペース・サービス１２２に、特に、ＥＮＲＰネームスペース・サービスに含まれるホームＥＮＲＰサーバ、たとえばＥＮＲＰサーバ１２４に登録する（３０４）。通常は、ＰＥのホームＥＮＲＰサーバは任意の所定の時間においてただ１つである。このホームＥＮＲＰサーバは、その時間においてＰＥにサービスを提供するＥＮＲＰサーバである。本発明の１つの実施形態においては、ホームＥＮＲＰサーバのトランスポート・アドレスを、各ＰＥ１１２、１１８のそれぞれのメモリ・デバイス１１４、１２０に、手動で記憶させてもよい。本発明の他の実施形態においては、各ＰＥ１１２、１１８は、ホームＥＮＲＰサーバ、たとえばＥＮＲＰサーバ１２４のトランスポート・アドレスを自動的に発見してもよい。発見は、サービス・リクエストをマルチキャスト・チャネルを通してＥＮＲＰネームスペース・サービス１２２内の１つまたは複数のＥＮＲＰサーバ１２４、１３０のそれぞれに伝達することによって行なう。ＰＥは、複数のＥＮＲＰサーバから応答を受け取ったときに、複数のＥＮＲＰサーバのうちＰＥのホームＥＮＲＰサーバとして機能する１つを選択してもよく、対応するトランスポート・アドレスをＰＥのメモリ・デバイスに記憶する。
【００２８】
ＰＥ１１２は、セッション層２０８の登録メッセージ１３６をホームＥＮＲＰサーバに伝達することによって登録を行なう。登録メッセージ１３６には、登録ＰＥ、すなわちＰＥ１１２が、ＥＮＲＰネームスペース・サービス１２２への登録を希望するプール・ハンドルすなわちプール名、たとえば「ｍｃ＿ｃｐ＿ｐｏｏｌ」が、含まれる。登録メッセージ１３６にはさらに、登録ＰＥに関連するＰＥ識別子が含まれる。ＰＥ識別子には、ＰＥに関連するトランスポート層プロトコルおよびトランスポート・アドレス、たとえばＩＰアドレスおよびポート番号が含まれる。登録メッセージ１３６はさらに、以下のものを通知する。すなわち、ＰＥが選んだ負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシ、ＰＥの役割、すなわちＰＥは、動作中のＰＥなのか、スタンバイＰＥなのか、動作中のＰＥおよびスタンバイＰＥの両方なのか、または役割が未規定のＰＥなのか、ならびにＰＥのサービス状態、すなわちＰＥは「サービス中なのか」なのかまたは「サービス休止中」なのか、である。加えて、登録メッセージ１３６にはさらに、ＰＥに関連する「重み」または「ノード・インデックス」、およびバックアップＰＥ識別子が含まれていてもよい。バックアップＰＥ識別子は、ＰＥの有するバックアップＰＥが１つなのか複数なのかを通知し、および／または１つまたは複数のバックアップＰＥを識別する。さらに、プール内の各ＰＥに関連する重みまたはノード・インデックスを、プールにアクセスするＰＵが用いて、プールにアクセスするときに複数のＰＥのうちのどのＰＥにアクセスするかを決定してもよいし、またはＰＵにサービスするＰＥが破損したときに複数のＰＥのうちのどのＰＥにアクセスするかを決定してもよい。
【００２９】
たとえば、図４は、本発明の実施形態による典型的な登録メッセージ４００のブロック・ダイアグラムである。登録メッセージ４００には、登録情報を含む複数のデータ・フィールド４０１〜４０９が含まれる。複数のデータ・フィールド４０１〜４０９のうちの第１のデータ・フィールド４０１は、メッセージ形式、すなわちメッセージがポリシ・メッセージであることを通知する。データ・フィールド４０１はさらに、メッセージを登録メッセージとして識別してもよい。複数のデータ・フィールド４０１〜４０９のうちの第２のデータ・フィールド４０２は、ＰＥが属するプールを識別する。これは、アプリケーション層２１０に、プール名すなわちプール・ハンドルたとえば「ｍｃ＿ｃｐ＿ｐｏｏｌ」（ＰＥのプールすなわちプール１０８に一意に関連する）を提供することによって行なわれる。複数のデータ・フィールド４０１〜４０９のうちの第３のデータ・フィールド４０３は、ＰＥ識別子、たとえばＰＥに関連するタグを提供する。複数のデータ・フィールド４０１〜４０９のうちの第４のデータ・フィールド４０４は、ＰＥがサポートすることを希望する１つまたは複数のトランスポート・プロトコル、たとえばＳＣＴＰを識別する。複数のデータ・フィールド４０１〜４０９のうちの第５のデータ・フィールド４０５は、ＰＥにおける特定のアプリケーションにアクセスするために、トランスポート・アドレス、たとえばＩＰアドレスおよびポート番号を提供する。複数のデータ・フィールド４０１〜４０９のうちの第６のデータ・フィールド４０６は、負荷共有関連の情報、たとえば負荷共有ポリシおよび／または冗長性モデル／フェイル・オーバ・ポリシを提供する。複数のデータ・フィールド４０１〜４０９のうちの第７のデータ・フィールド４０７は、ＰＥの役割を通知する。すなわち、ＰＥは、動作中のＰＥなのか、スタンバイＰＥなのか、動作中のＰＥおよびスタンバイＰＥの両方なのか、または役割が未規定のＰＥなのかを通知する。複数のデータ・フィールド４０１〜４０９のうちの第８のデータ・フィールド４０８は、ＰＥのサービス状態を通知する。すなわち、ＰＥはサービス中なのかまたはサービス休止中なのかを通知する。加えて、登録メッセージ１３６にはさらに、１つまたは複数のデータ・フィールド４０９が含まれていてもよい。データ・フィールド４０９は、ＰＥの有するバックアップＰＥが１つなのか複数なのかを通知し、および／または１つまたは複数のバックアップＰＥを識別し、ＰＥに関連する「重み」または「ノード・インデックス」を通知し、プール内のＰＥの動作に関する他の情報を提供する。他の情報とは、たとえば登録存続時間、すなわち登録が有効である時間量、ＰＥの負荷容量、およびＰＥに関連する負荷率、たとえば重みまたはノード・インデックス、ならびにＰＥに適用し得る負荷共有ポリシおよび／または冗長性モデル／フェイル・オーバ・ポリシである。
【００３０】
ＰＥ１１２から登録情報を受け取ると、ＥＮＲＰサーバ１２４は、受け取ったプール・ハンドルに対応するプール、すなわちプール１０８を形成する（３０６）。プールを形成する際、ＥＮＲＰサーバ１２４、好ましくはＥＮＲＰサーバのプロセッサ１２６は、プール１０８のプロファイルをサーバのメモリ・デバイス１２８に記憶する（３０８）。プール１０８のプロファイルに含まれるのは、ＰＥ１１２がＥＮＲＰサーバに伝達する登録情報たとえばプール・ハンドル、ＰＥ１１２のＰＥ識別子、ＰＥの役割およびサービス状態、ＰＥのトランスポート・アドレスおよびトランスポート・プロトコル、ＰＥが提供する負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシ、ならびに登録ＰＥが提供するさらなる情報、たとえば任意のバックアップＰＥである。加えて、ＰＥ１１２からの登録メッセージ１３６の受け取りに成功したら、ＥＮＲＰサーバ１２４、好ましくはプロセッサ１２６は、メッセージに対して確認応答する（３１０）。これは好ましくは、ＰＥに登録確認応答１３８を伝達することによって行なわれる。
【００３１】
プール１０８に割り当てられるホームＥＮＲＰサーバ１２４用のバックアップ・システムを提供するために、ＥＮＲＰネームスペース・サービス１２２は、プール１０８のプロファイルを、ＥＮＲＰネームスペース・サービスに含まれるすべてのサーバ１２４、１３０の間で分配する。本発明の１つの実施形態においては、ＥＮＲＰネームスペース・サービス１２２は、プール・プロファイル情報をプール１０８の初期設定時に分配してもよい。ＥＮＲＰネームスペース・サービス１２２は、その後にさらなるプール・プロファイル情報を分配してもよく、これは、ＰＥがプール１０８に登録するか、登録を取り消すか、または再登録する度に行なう。本発明の他の実施形態においては、ＥＮＲＰネームスペース・サービス１２２は、プール・プロファイル情報の断続的な更新を行なってもよい。たとえば、ＥＮＲＰネームスペース・サービス１２２の１つまたは複数のサーバ１２４、１３０がそれぞれ、他のサーバを断続的に照合検査してもよい。照合検査の間に、各サーバが他のサーバの更新を、サーバがサービスするＰＥおよびＰＵの登録、登録取り消し、および再登録に関して行なう。その結果、ＥＮＲＰネームスペース・サービス１２２における１つまたは複数のＥＮＲＰサーバ１２４、１３０がそれぞれ、サーバのメモリ・デバイス１２８、１３４に、ネームスペースの完全なコピーをそれぞれ保持する、すなわちネームスペース・サービスがサービスするプール、すなわちプール１０８に含まれる各ＰＥ１１２、１１８に対する登録情報の完全な記録を保持する。
【００３２】
複数のＰＥ１１２、１１８のうちの少なくとも第２のＰＥ、たとえばＰＥ１１８から少なくとも第２の登録メッセージ１３６を受け取ると（３１２）、ＥＮＲＰサーバ１２４、好ましくはプロセッサ１２６は、少なくとも第２のＰＥの登録メッセージ１３６に対して確認応答する（３１４）。少なくとも第２のＰＥ１１８から受け取った少なくとも第２の登録メッセージ１３６が特定するプール・ハンドルが、第１のＰＥ１１２が特定したものと同一の場合には、プロセッサ１２６は、サーバ１２４のメモリ・デバイス１２８に保持されるプール１０８のプロファイル内に、登録ＰＥと関連して、少なくとも第２のＰＥが提供する登録情報も記憶する（３１６）。ＥＮＲＰサーバ１２４のプロセッサ１２６はさらに、同一のプール・ハンドルを指定するそれぞれのＰＥ、すなわちＰＥ１１２、１１８を結合して（３１８）、単一のサーバ・プール、すなわちプール１０８にする。
【００３３】
本発明の１つの実施形態においては、ＥＮＲＰサーバ１２４のプロセッサ１２６は、第１の登録ＰＥ、すなわちＰＥ１１２の冗長性モデル／フェイル・オーバ・ポリシを、対応するプール、すなわちプール１０８の冗長性モデル／フェイル・オーバ・ポリシとして、採用する（３２０）。このようなモデル／ポリシは、第１のＰＥ１１２の登録時に、プール・モデル／ポリシとして採用してもよい。しかし、本発明の他の実施形態においては、同一の冗長性モデル／フェイル・オーバ・ポリシがプール全体で実施される限り、ＥＮＲＰサーバ１２４は、プール１０８に対して、プールの一部として登録するＰＥ１１２、１１８のどちらの冗長性モデル／フェイル・オーバ・ポリシを採用してもよい。その後、論理フロー３００は、終了する（３２２）。プール１０８内の各ＰＥ１１２、１１８は、プール内の他のＰＥと機能的に同一であると考えられる。しかし、プール１０８内の各ＰＥが、ＰＥのそれぞれの登録メッセージ１３６において表明する負荷容量は、プール内の他のＰＥと異なっていてもよい。
【００３４】
通信システム１００では、プールの動的な変更も可能である。ＰＥ１１２、１１８がプール１０８から出ることを要求する場合、ＰＥから登録取り消しメッセージが、ホームＥＮＲＰサーバ１２４に送られる。登録取り消しメッセージは、当該技術分野において周知である。登録取り消しメッセージには、ＰＥに関連するプール・ハンドルおよびＰＥ識別子が含まれているため、ＰＥのホームＥＮＲＰサーバは、登録取り消しＰＥの身元を確認することができる。ＥＮＲＰサーバ１２４は、登録取り消しメッセージを受け取ると、ＰＥ、およびＰＥの関連する登録情報を、プールのプロファイルから削除する。ＰＥ１１２、１１８は、それらの登録の更新を、新しい登録メッセージをホームＥＮＲＰサーバ１２４に送ることによって行なってもよい。新しい登録メッセージを受け取ると、ＥＮＲＰサーバは、プール・プロファイル内に記憶されたＰＥに関する情報を更新する。たとえばＰＥにかかる負荷が大きい場合には、ＰＥは、ＰＥに関連する重みまたはノード・インデックスを更新して、ＰＥにさらに処理が割り当てられる可能性を減らしてもよい。ＰＥの処理負荷が小さくなる場合の関連する重みまたはノード・インデックスを再調整してもよい。
【００３５】
プール１０８が確立すると、ＰＵたとえばＰＵ１０２上で実行されるアプリケーションは、プールが提供するサービスにアクセスすることができる。図５Ａおよび５Ｂに、本発明の実施形態によりプール１０８が提供するサービスにＰＵ１０２がアクセス可能なステップの論理フロー・ダイアグラム５００を示す。論理フロー・ダイアグラム５００が開始され（５０２）、ＰＵ１０２のアプリケーション層２１０上で実行されるアプリケーションが、プール１０８に関連するアプリケーション層プール・ハンドル、たとえば「ｍｃ＿ｃｐ＿ｐｏｏｌ」によってプール１０８に宛てられたアプリケーション層メッセージを構築する（５０４）。次に、ＰＵ１０２のセッション層２０８、好ましくはＡＳＡＰは、プール・ハンドルから、プール１０８のＰＥ、たとえばＰＥ１１２または１１８の下位層トランスポート・アドレス、たとえばＩＰアドレスおよびポート番号を取得しようと試みる（５０６）。これは、ＰＵのメモリ・デバイス１０６に保持されるセッション層キャッシュを参照することによって行なわれる。
【００３６】
ＰＵ１０２が、プール・ハンドルからトランスポート・アドレス、たとえばＩＰアドレスを取得することができないときには（５０８）、ＰＵ１０２、好ましくはＰＵのセッション層２０８は、ＥＮＲＰネームスペース・サービス１２２に、好ましくはＰＵにサービスするＥＮＲＰサーバ、たとえばＥＮＲＰサーバ１２４に、プール・ハンドルをプール・ハンドルに関連するトランスポート・アドレスに変換することをリクエストする（５１０）。ＰＵ１０２を、ＥＮＲＰサーバのアドレスによってプログラムしてもよいし、ＰＵ１０２は、既知のＥＮＲＰ発見メカニズムを通してアドレスを取得してもよい。たとえば、ＰＵ１０２のセッション層２０８がプール１０８に初めてアクセスしているとき、ＰＵ１０２は、プール１０８のプール・ハンドルに関連する下位層トランスポート・アドレスの記録を有していなくてもよい。このような場合、ＰＵ１０２は、ＰＵのメモリ・デバイス１０６から、プール・ハンドルに関連するトランスポート・アドレスを取り出すことができなくてもよい。次に図６を参照して、ＰＵ１０２がＥＮＲＰサーバ１２４に伝達するプール・ハンドル変換リクエスト１４０のブロック・ダイアグラムを、本発明の実施形態に基づいて例示する。プール・ハンドル変換リクエスト１４０には、複数のデータ・フィールド６０１、６０２を含むデータ・パケット、好ましくはネーム・レゾルーション・メッセージが含まれる。複数のデータ・フィールド６０１、６０２のうちの第１のデータ・フィールド６０１は、メッセージ形式を通知する。すなわち、メッセージはトランスポート・アドレス照会たとえばネーム・リクエスト・メッセージであることを通知する。複数のデータ・フィールド６０１、６０２のうちの第２のデータ・フィールド６０２は、プール・ハンドル、たとえば「ｍｃ＿ｃｐ＿ｐｏｏｌ」を与える。
【００３７】
次に、図１、５Ａ、５Ｂ、および７を参照して、ＰＵ１０２からプール・ハンドル変換リクエスト１４０を受け取った場合に、ＰＵにサービスするＥＮＲＰサーバ、すなわちＥＮＲＰサーバ１２４は、受け取ったプール・ハンドルに関連するプール・パラメータおよびＰＥパラメータをサーバのメモリ・デバイス１２８から取り出して（５１２）、取り出した情報を、要求元のＰＵ１０２へのプール・ハンドル変換応答１４２により伝達する（５１４）。図７は、本発明の実施形態によるプール・ハンドル変換応答１４２のブロック・ダイアグラムである。プール・ハンドル変換応答１４２には、複数のデータ・フィールド７０１〜７０４を含むデータ・パケット、好ましくは従来技術のネーム・レゾルーション応答メッセージの修正バージョンが含まれる。複数のデータ・フィールド７０１〜７０４のうちの第１のデータ・フィールド７０１は、メッセージ形式を通知する。すなわち、メッセージはプール・ハンドル変換応答であることを通知する。複数のデータ・フィールド７０１〜７０４のうちの第２のデータ・フィールド７０２は、プール・ハンドル変換リクエスト１４０に関連するプール・ハンドル、たとえば「ｍｃ＿ｃｐ＿ｐｏｏｌ」を与える。複数のデータ・フィールド７０１〜７０４のうちの第３のデータ・フィールド７０３は、プール・ハンドルに関連するプール、すなわちプール１０８に含まれるＰＥ、すなわちＰＥ１１２および１１８のそれぞれに対応するパラメータを与える。各ＰＥに関して設けられているパラメータには、ＩＰベースのシステムにおけるＰＥに関連する下位層トランスポート・アドレス、たとえばＩＰアドレスおよびポート番号、ならびにＰＥに関連する役割およびサービス状態が含まれる。好ましくは、ＰＥパラメータはさらに、１つまたは複数の負荷率、およびＰＥに関連する任意のさらなる登録情報、たとえば１つまたは複数のバックアップＰＥのリストを含む。複数のデータ・フィールド７０１〜７０４のうちの第４のデータ・フィールド７０４は、プールに関連するプール・パラメータ、たとえば負荷共有関連の情報、たとえば負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシを与える。
【００３８】
ＥＮＲＰサーバ１２４からプール・ハンドル変換応答１４２を受け取ると、ＰＵ１０２は、プール・ハンドル変換応答に含まれる情報を、ＰＵのメモリ・デバイス１０６内のセッション層キャッシュに記憶する（５１６）。好ましくは、ＰＵ１０２は、プール１０８に関連するテーブルを形成する。テーブルには、プール１０８内の各ＰＥ１１２、１１８が含まれ、さらに、各ＰＥについて、ＰＥに関して設けられたＰＥパラメータ、たとえばＰＥのトランスポート・アドレス、ＰＥの役割およびサービス状態、ならびにＰＥに関連する任意の負荷率が含まれる。ＰＵ１０２はさらに、キャッシュ内に、プール１０８について、プールに関して設けられたプール・パラメータを記憶する。これはたとえば、負荷共有関連の情報、すなわちプールの負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシである。ＰＵ１０２のセッション層２０８が、ＰＵのアプリケーション層から、同一のプール・ハンドルに宛てられたメッセージをその後に受け取った場合には、セッション層（すなわち、ＡＳＡＰ）は、ＥＮＲＰサーバ１２４に再び照会することなく、適切なＰＥにメッセージを送ることができる。すなわち、ＰＵ１０２がその後にプール１０８にアクセスしたときに、ＰＵのセッション層２０８は、送信先ＰＥ１１２、１１８を選択する。選択は、ＰＵのセッション層キャッシュを参照することにより、およびプールに関連する負荷共有ポリシおよびプール内の各ＰＥ１１２、１１８に関連する負荷率（もしあれば）に基づいて、行なう。たとえば、プール１０８がラウンド・ロビン負荷共有ポリシを実施し、ＰＵ１０２がＰＥ１１２と最後に通信している場合には、ＰＵ１０２は、ＰＵのセッション層キャッシュに記憶されるテーブル内で次に列挙されるＰＥ、または次のノード・インデックス番号を有するＰＥ、たとえばＰＥ１１８を選択してもよい。他の実施例として、プール１０８が、重み付きラウンド・ロビン負荷共有ポリシを実施し、ＰＵ１０２がＰＥ１１２と最後に通信している場合には、ＰＵ１０２は、プール１０８内のＰＥ１１２以外のＰＥとして、各ＰＥに関連するＰＵのセッション層キャッシュに記憶された重みに基づいて、割り当てられた重みが最も低いものを選択してもよい。
【００３９】
本発明の他の実施形態においては、プール・ハンドル変換応答１４２がＰＵ１０２に与える情報をＰＵ１０２にプログラムしてＰＵのセッション層キャッシュに記憶することを、ＰＵがプール１０８に最初にアクセスを試みる前に行なってもよい。このような実施形態においては、ＰＵがプール１０８にアクセスを試みる度（第１回目を含む）に、ＰＵのセッション層２０８は、プールの複数のＰＥ１１２、１１８の中から送信先ＰＥを選択してもよい。選択は、ＰＵのセッション層キャッシュを参照することにより、およびプール１０８に関連する負荷共有ポリシおよび各ＰＥ１１２、１１８に関連する負荷率に基づいて行なう。
【００４０】
ＰＵ１０２内のセッション層キャッシュに割り当てられるメモリ量を最小限にするために、セッション層キャッシュに記憶される情報は、タイム・アウト時間が満了したらタイム・アウトしてもよい。タイム・アウト時には、情報をキャッシュから一掃する。しかしタイム・アウト時間およびキャッシュからの一掃は、ＰＵの設計者に依るものであり、本発明にとっては重要ではない。
【００４１】
メッセージを送るための下位層トランスポート・アドレスを決定すると、ＰＵ１０２のセッション層２０８は、決定されたトランスポート・アドレスを介してプール１０８内の送信先ＰＥに送られるデータ・パケット１４４を構築する（５２０）。前述したように、プール１０８に複数のＰＥ、たとえばＰＥ１１２および１１８が含まれるときには、ＰＵ１０２、特にＰＵのセッション層２０８は、送信先ＰＥのトランスポート・アドレス、たとえばＰＥ１１２に関連するＩＰアドレスおよびポート番号を、複数のＰＥ１１２、１１８のそれぞれに対応するトランスポート・アドレスの中から、プール１０８の負荷共有ポリシおよびこのようなＰＥ１１２、１１８のそれぞれの負荷率に基づいて、選択してもよい（５１８）。さらに、ＰＵ１０２、特にＰＵのセッション層２０８は、データ・パケット１４４に、送信先ＰＥのトランスポート・アドレスおよびＰＵがサポートするトランスポート・プロトコルに関する情報を埋め込む。ＰＵ１０２は、データ・パケット１４４を、選択されたＰＥ１１２に、埋め込まれたトランスポート・アドレスを介して伝達する（５２２）。
【００４２】
ＰＵ１０２がトランスポート障害を検出したとき、たとえば、１つまたは複数のデータ・パケットに対してＰＥが確認応答しないときには、ＰＵのトランスポート層２０６は、ＰＵのセッション層２０８にトランスポート層障害を通知する。障害通知を受け取ると、ＰＵ１０２のセッション層２０８は、プール１０８の代替ＰＥ、たとえばＰＥ１１８のトランスポート・アドレスを、ＰＵ１０２のセッション層キャッシュ内のＰＥ１１２および／またはプール１０８に関連して記憶された情報に基づいて決定する（５２４）。ＰＵ１０２、特にＰＵのセッション層２０８はその後に、決定された代替ＰＥにデータ・パケットをＰＵのアプリケーション層２１０上で実行されるアプリケーションに対して透過的な方法で伝達する（５２６）。その後、論理フローは終了する（５２８）。しかしＰＵ１０２上で実行されるアプリケーションは、フェイル・オーバする方法および時期、強制的にロール・オーバさせる方法および時期、またはフェイル・オーバを一斉に無効にする方法および時期に関するルールを特定してもよい。またＰＵ１０２上で実行されるアプリケーションは、通信セッションの開始および終了を規定してもよく、また負荷共有およびフェイル・オーバをセッションごとのベースで行なうことができる。
【００４３】
図８は、本発明の実施形態により代替ＰＥのトランスポート・アドレスを決定する際に、ＰＵ１０２が、好ましくはＰＵ１０２のセッション層２０８が実行するステップの論理フロー・ダイアグラム８００である。論理フロー８００が開始され（８０２）、ＰＵ１０２が、送信先ＰＥ、すなわちＰＥ１１２によるパケットの受け取りが成功しなかったことを判断する（８０４）。次にＰＵ１０２は、ＰＵのメモリ・デバイス１０６に記憶されたセッション層キャッシュを参照することによって、バックアップＰＥ、たとえばＰＥ１１８が、ＰＵにサービスしていたＰＥ、すなわちＰＥ１１２に対して指定されているか否かを判断する（８０６）。バックアップＰＥが、障害ＰＥ、すなわちＰＥ１１２に対して指定されているときには、ＰＵは、指定されたバックアップＰＥが「サービス中」であるかどうかを判断する（８０８）。指定されたバックアップＰＥが「サービス中」である場合には、ＰＵ１０２は、指定されたバックアップＰＥを代替ＰＥとして選択する（８１０）。その後、論理フローは終了する（８１４）。好ましくは、ＰＵ１０２は、指定されたバックアップＰＥを、バックアップＰＥに関連してＰＵのセッション層キャッシュに記憶された役割にかかわらず、代替ＰＥとして選択する。しかし、本発明の他の実施形態においては、ＰＵが、指定されたバックアップＰＥを代替ＰＥとして選択するのは、ＰＵのキャッシュに記憶された代替ＰＥに関する情報が、ＰＥの役割は「スタンバイ」または「動作中およびスタンバイの両方」であると示す場合である。
【００４４】
ＰＵ１０２のセッション層キャッシュに、障害ＰＥ、すなわちＰＥ１１２に対して指定されたバックアップＰＥが含まれていない場合か、または指定されたバックアップＰＥが「サービス中」ではないか、もしくは「サービス中」であると判断できない場合には、ＰＵ１０２は、代替ＰＥを、セッション層キャッシュを参照することによって判断する（８１２）。その後、論理フローは終了する（８１４）。好ましくは、代替ＰＥとして適格であるためには、ＰＵのキャッシュに記憶されたＰＥに関する情報が、ＰＥの役割は「スタンバイ」または「動作中およびスタンバイの両方」すなわちデュアルであると示し、および代替ＰＥのサービス状態が「サービス中」であると示す。これらの基準の下で、プール１０８内の複数のＰＥが代替ＰＥとして適格であるときには、ＰＵ１０２は、プール１０８に関するキャッシュ内に記憶された冗長性モデル／フェイル・オーバ・ポリシを利用することによって、複数の適格ＰＥの中から代替ＰＥを決定する（８１２）。しかし、本発明の他の実施形態においては、ＰＵ１０２は、代替ＰＥを選択する際に、バックアップＰＥの指定を無視して、ＰＵのセッション層キャッシュ内に記憶された冗長性モデル／フェイル・オーバ・ポリシに基づいて代替ＰＥを選択してもよい。
【００４５】
要約すると、ＥＮＲＰサーバ１２４が第１のプール要素ＰＥ１１２および第２のＰＥ１１８のそれぞれから登録情報を受け取るインターネット・プロトコル・ベースの通信システム１００が提供された。各ＰＥ１１２、１１８から受け取った登録情報は、ＰＥに関連するプール・ハンドルおよびトランスポート層プロトコルおよびトランスポート・アドレス、たとえばＩＰアドレスおよびポート番号を含み、以下のものを通知する。すなわち、ＰＥが選択した負荷共有ポリシおよび冗長性モデル／フェイル・オーバ・ポリシ、ＰＥの役割、すなわちＰＥは動作中のＰＥなのか、スタンバイＰＥなのか、動作中のＰＥおよびスタンバイＰＥの両方なのか、または役割が未規定のＰＥなのか、およびＰＥのサービス状態、すなわち、ＰＥは「サービス中」なのかまたは「サービス休止中」なのか、である。登録情報にはさらに、ＰＥに関連する「重み」または「ノード・インデックス」、およびバックアップＰＥ識別子が含まれていてもよい。識別子は、ＰＥが有するバックアップＰＥが１つなのか複数なのかを通知し、および／または１つまたは複数のバックアップＰＥを識別する。プール内の各ＰＥに関連する重みまたはノード・インデックスを、プールにアクセスするＰＵが用いて、プールにアクセスするときに複数のＰＥ１１２、１１８のうちのどのＰＥにアクセスするのかを決定してもよいし、ＰＵにサービスするＰＥが破損したときに複数のＰＥのうちのどのＰＥにアクセスするのかを決定してもよい。ＥＮＲＰサーバ１２４は、各ＰＥが同じプール・ハンドルを与える場合には複数のＰＥ１１２、１１８のそれぞれを含むプール１０８を形成し、プールに対して、複数のＰＥのうちのあるＰＥが提供する冗長性モデルを採用する。
【００４６】
ＰＵ１０２は、プール１０８へのアクセスを、プールに関連するプール・ハンドル用のデータ・パケットを構築することによって、およびＥＮＲＰネームスペース・サービス１２２内のＥＮＲＰサーバ１２４または他の任意のサーバからプール・ハンドルの変換をリクエストすることによって、行なってもよい。リクエストに応答して、ＰＵ１０２は、プール１０８内の各ＰＥ１１２、１１８に関連するＰＥパラメータ、たとえばトランスポート・アドレス、ＰＥ役割、ＰＥサービス状態、およびＰＥ負荷率を、プール１０８内の各ＰＥ１１２、１１８に対応して受け取る。ＰＵ１０２はさらに、プールに対して採用された冗長性モデル／フェイル・オーバ・ポリシを含むプール・パラメータを受け取る。ＰＵ１０２は、セッション層キャッシュ内に、プール１０８に関連して受け取ったＰＥパラメータおよびプール・パラメータを記憶する。ＰＵ１０２が、プール１０８のＰＥと通信状態にあって、トランスポート障害を検出した場合には、ＰＵは、ＰＥパラメータとプールの採用された冗長性モデル／フェイル・オーバ・ポリシとに基づいて、代替ＰＥのトランスポート・アドレスを選択し、その後に、選択された代替ＰＥにデータ・パケットを伝達する。
【００４７】
本発明を、特にその特定の実施形態を参照して図示し説明してきたが、当業者であれば、添付の請求項で述べる本発明の範囲から逸脱することなく、本発明の要素に対して種々の変形を行ない均等物を置換してもよいことが理解される。したがって、明細書および図は、限定的な意味ではなく例示的なものであるとみなすべきであり、このような変形および置換はすべて、本発明の範囲に含まれることが意図される。
【００４８】
特定の実施形態に関して、利益、他の利点、および問題に対する解決方法を前述してきた。しかし利益、利点、問題に対する解決方法、および何らかの利益、利点、または解決方法を発生させるかまたはより明白にし得るいかなる要素も、請求項の何れかまたは全てにおける重大で、所要の、または本質的な特徴または要素であると解釈してはならない。本明細書で用いる場合、用語「備える」、「備えている」、またはそのいかなる変形も、非排他的に含むことに及ぶことが意図されており、したがって要素のリストを含むプロセス、方法、物品、または装置は、それらの要素だけを含むのではなく、明白に列挙されてはいない他の要素、またはこのようなプロセス、方法、物品、もしくは装置に固有の他の要素を含んでいてもよいことが意図される。さらに、関係語があった場合、たとえば第１のおよび第２の、頂部および底部などを用いることは単に、１つの実体または行為を他の実体または行為と区別するために用いており、必ずしも、このような実体または行為間に実際に何らかのこのような関係または順番があることは、必要とせず意味してもいないことが理解される。
【図面の簡単な説明】
【００４９】
【図１】本発明の実施形態による通信システムのブロック・ダイアグラム。
【図２】本発明の実施形態によるプロトコル・スタックのブロック・ダイアグラム。
【図３】本発明の実施形態によるプール要素登録プロセスの論理フロー・ダイアグラム。
【図４】本発明の実施形態によるプール要素登録メッセージのブロック・ダイアグラム。
【図５Ａ】本発明の実施形態による図１のプールにより提供されるサービスに図１のプール・ユーザがアクセスできる方法の論理フロー・ダイアグラム。
【図５Ｂ】本発明の実施形態による図１のプールにより提供されるサービスに図１のプール・ユーザがアクセスできる方法の図５Ａの論理フロー・ダイアグラムの続き。
【図６】本発明の実施形態によるプール・ハンドル変換リクエストのブロック・ダイアグラム。
【図７】本発明の実施形態によるプール・ハンドル変換応答のブロック・ダイアグラム。
【図８】本発明の実施形態によりプール・ユーザに対する代替プール要素を図１の通信システムが決定する方法の論理フロー・ダイアグラム。
【図１】
2006515734.tif 000003
【図２】
2006515734.tif 000004
【図３】
2006515734.tif 000005
【図４】
2006515734.tif 000006
【図５Ａ】
2006515734.tif 000007
【図５Ｂ】
2006515734.tif 000008
【図６】
2006515734.tif 000009
【図７】
2006515734.tif 000010
【図８】
2006515734.tif 000011
【国際調査報告】
2006515734.tif 000012