ネットワーク・リソースをプールするための方法および装置

专利摘要:
通信ネットワーク内の複数のネットワーク・リソースからネットワーク・リソースを選択するための方法及び装置が提供される。選択ノードは、ネットワーク・リソースを求める要求を端末から受信し、次いで少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出す。読み出されたデータに基づいて、選択ノードは複数のネットワーク・リソースからネットワーク・リソースを選択する。次いで、選択されたネットワーク・リソースを識別する情報を含む応答が端末へ送信される。
公开号:JP2011512715A
申请号:JP2010543390
申请日:2008-01-23
公开日:2011-04-21
发明作者:ラース ウェストベリ，；ガーボル トース，；アッティラ ミハーリー，
申请人:テレフオンアクチーボラゲット エル エム エリクソン（パブル）；
IPC主号:H04W48-18

专利说明:

[0001] 本発明は通信ネットワークにおいて用いられる方法および装置に関し、特にプールされたサーバ・ノードまたはゲートウェイ・ノードを端末に割り当てるための方法および装置に関する。]
背景技術

[0002] 汎欧州ディジタル移動電話方式（ＧＳＭ）および３Ｇのような通信ネットワークは、移動体端末（ＭＴ）が通信ネットワークにアクセスできるようにするとともに、サーバ・ノードがＭＴへサービスを提供できようにするようにゲートウェイ・ノードを使用する。サーバ・ノードおよびゲートウェイ・ノードは、リソースの向上した可用性および良好な利用に加えて、プール・メンバ間の負荷分散およびバランスを可能とするように、しばしばネットワークに“プールされる”。従来、プールはいずれも静的に構成され、静的プールはドメイン・ネーム・システム（ＤＮＳ）に基づきうる。]
[0003] 静的に構成されたプールは、所定のサービスのついての選択可能なサーバ／ゲートウェイ・ノードに関する静的な事前に構成された情報の概念に基づく。この事前に構成された情報は、各ＭＴおよびこの情報を必要としうるその他のノードに記憶される。ＭＴがサーバまたはゲートウェイを選択したい場合に、選択を行なうために選択アルゴリズムが用いられる。静的に構成されたプールは、類似の機能を持つノード間の負荷分散と、向上した可用性と、大きな地理的領域における優れたトラヒック推定に起因する単純化されたノード規模とを提供する。]
[0004] サーバおよびゲートウェイ・ノードの静的プールは現在の移動体システムで幅広く用いられている。３Ｇネットワークでは、Ｉｕフレックスを用いてサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）および移動交換局（ＭＳＣ）がプールされる。ＧＳＭネットワークでは、ＡフレックスとＧｂフレックスとを用いてこれらのノードがプールされる。]
[0005] Ｉｕフレックスは３ＧＰＰではリリース５ ＴＳ ２３．２３６に説明されており、無線ネットワーク制御装置（ＲＮＣ）がＭＳＣのプールからＭＳＣを選択し、ＳＧＳＮのプールからＳＧＳＮを選択することを可能にする。ＧＳＭにおいて同じ概念が用いられ、基地局制御装置（ＢＳＣ）は（Ａフレックスを用いて）ＭＳＣのプールからＭＳＣを選択できるとともに、（Ｇｂフレックスを用いて）ＳＧＳＮのプールからＳＧＳＮを選択できる。アクセス・ネットワーク・ノードが選択されうるコア・ネットワーク・ノードの集合はプールまたはクラスタと呼ばれる。]
[0006] Ｉｕ／Ａ／Ｇｂフレックスを用いて、ＭＳＣのプールおよびＳＧＳＮのプールはサービス・エリアにサービスを提供してもよい。この場合に、すべてのＲＮＣ（またはＧＳＭではＢＳＣ）はすべてのＭＳＣ／ＳＧＳＮに接続され、逆もまた同様である。これらの接続は直接リンクを通して“物理的”であってもよいし、ＳＤＨＶＰまたはＡＴＭＰＶＣを通して“論理的”であってもよいし、ＩＰ接続を通して“仮想的”であってもよい。プールのサービス・エリアは”プール・サービス・エリア”と称される。]
[0007] 移動局（ＭＳ）がプール・サービス・エリアへ登録またはローミングする場合に、ＭＳは負荷分散アルゴリズムに従って特定のＭＳＣ／ＳＧＳＮが割り当てられる。ＭＳは、プールのその他のメンバの正体を知らず、ＭＳがプール・サービス・エリアに留まる間、選択されたＭＳＣまたはＳＧＳＮをすべての通信に対して使用する。しかしながら、ＭＳがプール・サービス・エリアを離れ、その後に再登録する場合に、ＭＳが再登録する時点で、ネットワーク要求に従って異なるＭＳＣ／ＳＧＳＮが割り当てられるかもしれないことに留意されたい。]
[0008] ＲＮＣおよびＢＳＣは構成されたテーブルに従ってメッセージをルーティングする。ＭＳはノードが利用できないことをＲＮＤ／ＢＳＣへシグナリングでき、この場合にＲＮＣ／ＢＳＣはネットワークの負荷バランス要求に依存してＭＳのために異なるノードを選択してもよい。]
[0009] 静的に構成されたプールの別のタイプはＤＮＳベースのプールである。この情報を必要としうる各ノードにプールを構成するのではなく、ＤＮＳサーバで構成が実行される。ＭＳはＤＮＳサーバへＤＮＳクエリを送信し、ＤＮＳサーバはＭＳＣ／ＳＧＳＮプールのメンバを識別するＩＰアドレスのリストを返送する。次いで、ＭＳは内部の選択アルゴリズムに基づいてリストから一つのアドレスを選択する。]
[0010] この着想の改良版は、ＩＰアドレスのリストをＭＳへ送信する前に、ＤＮＳサーバが制限された選択を導入することである。これらの例は“ソート・リスト”および“ラウンド・ロビン”である。ソート・リストは、ＩＰアドレスのリスト内のアドレスの順番がクエリのソース・アドレスに基づいて整列されるというＤＮＳの機能である。ラウンド・ロビンは、二つ以上のアドレス間のトラヒックをバランスさせるＤＮＳの機能である。ラウンド・ロビンは、汎用パケット無線サービス（ＧＰＲＳ）ネットワークにおいて、複数のゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）間に負荷を分散するために用いられる。]
[0011] ＤＮＳサーバでソート・リストを用いる不利な点は、ＤＮＳサーバからＤＮＳサーバへ情報が渡される場合に、当初の順番が常に維持されるという保証がないということである。正しい順番が維持されることを保証するために、ネットワーク内のすべてのＤＮＳサーバでソート・リストが構成されなければならないが、これは大きなＤＮＳ解決策に対して著しい複雑さを付け加える。いくつかの場合では、すべてのサーバにソート・リストを設定することは可能でないかもしれない。]
[0012] ラウンド・ロビンはＤＮＳデータベースから取得した静的情報を用いて動作する。ＤＮＳサーバが要求に応答する場合に、ノードの状態と実際の負荷は考慮されない。ラウンド・ロビンは、権限のあるサーバから送信される応答の構造またはソート・リストの効果を上書きするかもしれない。]
[0013] また、ＤＮＳプールは、いわゆるリソース・レコード（ＲＲ）の使用を通じてサービス固有の選択を可能にする。ＩＥＴＦ ＲＦＣ １０３４／１０３５に記載される基本的なＤＮＳサーバでは、所定のホスト名についての複数の“アドレス”ＲＲ（Ａ ＲＲ）でプールが構成されうる。ＤＮＳサーバがアドレスのリストを求める要求を受信する場合に、ＤＮＳサーバはクエリに整合するすべてのＲＲを返信する。使用される一つを選択することはクライアントのタスクである。]
[0014] 更に拡張したサービス・ベースのプール解決策がＲＦＣ ２７８２で規定されており、ＳＲＶＲＲに対応したＤＮＳサーバについて記載する。サービスについての複数の“サービス”リソース・レコード（ＳＲＶ ＲＲ）を用いてサーバ・プールが構成される。また、ＲＲフォーマットは、ＰＲＩＯおよびＷＥＩＧＨＴパラメータを含む。要求に対するＤＮＳサーバの応答は、優先度と重みの情報とを有するサーバのすべての取りうる選択を含み、受信した優先度および重みパラメータに基づく事前に定めたルールに基づいてＭＳがサーバ選択を行なうことを可能にする。]
[0015] 移動体ネットワークにおけるＤＮＳベースのプールの例はＧＧＳＮプールである。ＭＳがネットワークへ登録される場合に、ＧＳＭおよび３Ｇネットワークにおける接続確立手順（ＰＤＰコンテキスト要求の活性化）の一部として、ＭＳが送信した要求におけるアクセス・ポイント名（ＡＰＮ）により識別されるパケット・データ・ネットワーク（ＰＤＮ）への接続を有するＧＧＳＮを見つけるため、ＳＧＳＮはＤＮＳクエリを送信する。ＤＮＳサーバは、ＧＧＳＮノードのＩＰアドレスにＡＰＮ文字列をマッピングするデータベースを有する。同一の外部のＰＤＮに複数のＧＧＳＮが接続されると、ＤＮＳサーバはＳＧＳＮへ送信される応答において複数のエントリを返信する。ＳＧＳＮは、（一つ以上が返信されるなら）ＤＮＳ応答に含まれる最初のアドレスを選択し、ＧｎインタフェースでＰＤＰコンテキスト生成要求をＧＧＳＮノードへ送信する。この手順により、（ＧＧＳＮプールであるとみなしうる）同一のＰＤＮに接続されるＧＧＳＮノード間の負荷分散を実装することが可能となる。“ＧＧＳＮプール”の構成はＤＮＳでローカルに行われる。]
[0016] ＤＮＳプールはある欠点を有する。ＤＮＳプールは静的データベースを使用し、従って、ネットワーク・トポロジにおける変化のイベントで、影響を受けた各ノードが再構成されなければならない。更に、ＤＮＳサーバはＡＰＮに関連付けられたアドレスの状態を知る方法を何も有していない。ＤＮＳサーバはＧＧＳＮの状態に関係なくアドレスを返送する。また、標準ＤＮＳサーバは、名前に関連付けられたすべてのアドレスを無作為に返送し、その結果、ＧＧＳＮＧＴＰ接続について非効率なルーティングを生じる。ローカルＧＧＳＮが同一の外部のＰＤＮへのアクセスを提供できたとしても、ＤＮＳはもっと離れたＧＧＳＮへＳＧＳＮを向けるかもしれない。ＧＰＲＳネットワークの規模および複雑性が増大するにつれて、インテリジェント・サービスが必要となるだろう。これらの課題の一部に対処するために、図１に示されるような解決策が開発されてきた。] 図１
[0017] 図１に示される解決策は、移動体ネットワークにおけるキー情報を監視することと、ＤＮＳ応答を動的に変更することとを提供し、到達可能であり、ネットワーク・アーキテクチャの観点からより近くにあり、トラヒックをＰＤＮへルーティングできるＧＧＳＮ１０２、１０３、１０４にＳＧＳＮ１０１を向ける。特長として以下のことを含む。] 図１
[0018] １． ＧＧＳＮ１０２、１０３、１０４がＧｎネットワークを介して到達可能かどうかをチェックする状態監視は、トラヒックがＧＧＳＮを通してＧｉインタフェースでＰＤＮへ流れ、ＧＴＰトンネルが確立された後は逆方向に流れることができることを保証し、アドレスを割り当てるために認証のためのＲＡＤＩＵＳまたはＤＨＣＰのような外部サービスをＧＧＳＮ１０２、１０３、１０４が用いる場合に、これらのサービスの状態が監視されて報告される。]
[0019] ２． 各ＧＧＳＮ１０２、１０３、１０４についての接続数の最適化を可能にする負荷監視。ＧＧＳＮ１０２、１０３、１０４は異なる容量を有してもよい。ラウンド・ロビンのようなＤＮＳ負荷バランス技術はＰＤＰコンテキストを均等に分配し、これにより、より低い容量のＧＧＳＮが過負荷になる結果となりうる。ＧＧＳＮ１０２、１０３、１０４の異なる容量を反映するようにサーバで負荷の値が事前に構成されるか、または、ＣＰＵ使用率、パケット・スループット、接続数等のような属性について各ＧＧＳＮ１０２、１０３、１０４をポーリングすることによって負荷情報が監視される。]
[0020] 実際の監視技術は、ネットワークごとおよびオペレータごとに異なってもよい。ＩＣＭＰＥＣＨＯ、ＳＮＭＰを用いるアクティブ監視は状態および負荷を得るか、状態および負荷を報告するためにＧＴＰプローブが用いられうる。ＲＡＤＩＵＳのようなサービスの監視が必要となる状況について、ＲＡＤＩＵＳプロトコルを利用するインテリジェント・モニタが用いられうる。これらの更に高度なモニタを用いて、サービスが稼動していることを検証し、移動体ネットワークが要求するタスクをサービスが実行しているかいないかを判定できる。]
[0021] アクティブ監視により望まないネットワーク・トラヒックが負荷される状況では、関連するメッセージを求めてトラヒックをリッスンすることによってネットワークの状態を評価するためにパッシブ監視が用いられる。このようなメッセージは経路広告、キープ・アライブ・メッセージ、ＳＮＭＰトラップ等を含む。ＧＴＰＶＩＰのようなキーＩＰアドレスを求めて、例えばＯＳＰＦ、ＲＩＰまたはＢＧＰ経路告知が監視されうる。これらのアドレスの一つに対する経路が到達不能であると判定された場合に、ＤＮＳサーバが通知を受ける。]
[0022] フィルタリング・ルールと状態・負荷情報とを組み合わせることによって、ＧＧＳＮ１０２、１０３、１０４の最適リストがＳＧＳＮ１０１へ送信される。以下のように、三つの主なタイプのトラヒック動作が移動体ネットワークに適用される。
（１）状態：ＳＧＳＮ１０１がＡＰＮを求めてＤＮＳクエリを送信する場合に、利用不可能なＧＧＳＮについてのＩＰアドレスが削除される。利用不可能なＧＧＳＮがもう一度利用可能となるならば、それに応じてＧＧＳＮが自動的にＧＧＳＮのリストに加えられる。
（２）位置：クエリのソースＩＰアドレスを用いて、要求を行うＳＧＳＮ１０１が決定され、リモートのＧＧＳＮが除去されうる。この方法で、同一のＰＯＰまたは領域内のＧＧＳＮにＳＧＳＮを常に向かわせる。これはＳＧＳＮ１０１へ送信されるアドレス数を制限する。
（３）負荷：ノードを監視して得られた負荷情報を用いて、ノード間の負荷をバランスされえ、特定のノードについて負荷が調整されうる。]
[0023] システム・アーキテクチャ・エボリューション（ＳＡＥ）またはロング・ターム・エボリューション（ＬＴＥ）と呼ばれる将来の移動体ネットワークのシステム・アーキテクチャが現在開発中である（３ＧＰＰ ＴＳ ２３．４０１（Ｓ２−０７０５９１） Ｖ０．２．１、“３ＧＰＰ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ：ＧＰＲＳ ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ ＬＴＥ ａｃｃｅｓｓ；Ｒｅｉｅａｓｅ ８”を参照）。提案されたアーキテクチャが概略的に図２に示される。このアーキテクチャの集中方式によるコア・ノードは、物理的に分離したユーザ・プレーンおよび制御プレーン（即ち、分割アーキテクチャ）を有しうる。分割アーキテクチャ・モデルでは、以下のエンティティが定義される。
（１）モビリティ管理エンティティ（ＭＭＥ）２０１は制御プレーン・シグナリングを処理し、モビリティに対して責任を持つ。
（２）ＳＡＥゲートウェイ（ＳＡＥＧＷ）は、ＥＵＴＲＡＮとＰＤＮとに向かうインタフェースをそれぞれ終端するサービングＳＡＥＧＷ２０２機能とＰＤＮ ＳＡＥＧＷ２０３機能とに分割される。ＰＤＮ ＳＡＥＧＷ２０３およびサービングＳＡＥＧＷ２０２は一つの物理ノードに実装されてもよいし、分割された物理ノードに実装されてもよい。後者の場合に、ＧＴＰトンネルまたはＩＥＴＦトンネル（プロキシＭＩＰ）を介して、二つのノード間でユーザ・プレーン・トラヒックのトンネルが存在する。] 図２
[0024] サービングＳＡＥＧＷ２０２機能は、
・ｅノードＢ間ハンドオーバのためのローカル・モビリティ・アンカ・ポイント、
・（Ｓ４を終端し、２Ｇ／３ＧシステムとＰＤＮ ＳＡＥ ＧＷの間のトラヒックを中継する）３ＧＰＰ間モビリティのためのモビリティ・アンカ、および
・合法傍受
を含む。]
[0025] ＰＤＮ ＳＡＥＧＷ機能は、
・ポリシー施行、
・（例えば、深いパケット検査による）ユーザ単位ベースのパケット・フィルタ、
・課金サポート、および
・合法傍受
を含む。]
[0026] インタフェースＳ１は、ユーザ・プレーン・トラヒックおよび制御プレーン・トラヒックのトランスポートのための発展型ＲＡＮの無線リソースへのアクセスを提供し、Ｓ１＿ＭＭＥ２０４とＳ１＿Ｕ２０５とを含む。Ｓ１参照点は、ＭＭＥとＳＡＥＧＷとの分離を可能にするとともに、組み合わされたＭＭＥ２０１とサービングＳＡＥＧＷ２０２の解決策の配置も可能にする。]
[0027] プールの概念は、容量を低減するため、信頼性を増強するためおよび簡素化された計画を可能にするため、コア・ネットワーク・ノード（ＭＭＥ２０１およびＳＡＥＧＷ２０２、２０３）についてＳＡＥ／ＬＴＥ文書に述べられている。ＭＭＥプールは、ノードＢが複数のＭＭＥをあたかもそれらが単一の論理エンティティであるかのように処理できる機構である。ＭＴがサービスを要求する場合に、ある機構が物理ＭＭＥノードのうちの一つを選択し、選択されたＭＭＥにＭＴをバインドする。ユーザ・プレーン・ノードについて同様なプール概念が規定される。例えば、ＭＴがネットワークに登録される場合に、プールからサービング／ＰＤＮ ＳＡＥＧＷ２０２，２０３の所定のペアを選択することはＭＭＥ（またはその他の制御プレーン・エンティティ）のタスクであり、従って、ＭＴ（およびノードＢ）は同一プール内のＳＡＥＧＷ間の相違を見ない。]
[0028] ユーザ・プレーン（ＳＡＥＧＷ）のプール・エリアと制御プレーン（ＭＭＥ）のプール・エリアとは、必ずしも同じである必要はなく、次の何れかによって影響を受けうる。
・ＭＭＥプール・エリア内で必要になる接続と比較した、Ｓ１のユーザ・プレーン・トラヒックに必要になるＩＰ接続の範囲、
・地域化ネットワークにおける地域境界をまたぐＳ１接続の存在、
・ＳＡＥＧＷが相互作用しなければならないＭＭＥおよびｅノードＢの数、および
・ＳＡＥＧＷ再配置が起こるだろう状況。]
[0029] 様々なネットワーク事業者が、自身のネットワーク規模、（例えば、地域管理による）接続制限、モビリティ・パターン等に依存して、ＭＭＥ／ＳＡＥＧＷプール設計について様々なシナリオを選択するだろうということはありそうである。プール／選択のための取り得るＳＡＥアーキテクチャは、プール選択のすべての相異なる可能性に対処できるべきである。]
[0030] 静的プールが有する主な問題は、複数のノードでプールが構成されなければならないということである。従って、プールの詳細を維持することは、著しい量の構成作業を必要とする。例えば、ネットワークが拡張される場合に、既存のプールの再設計を必要とするかもしれず、それ故、新規導入のホストのみならず、既存のものについての再構成を必要とするかもしれない。同様に、トポロジ、サービス・ネットワーク等における変更も再構成を必要とする。]
[0031] 静的およびＤＮＳベースのプール解決策の共通の問題は、サーバが利用できないことやネットワーク・トポロジの変更のような動的なネットワーク変更について利用可能な情報に欠けることである。図１に示された解決策は部分的にその問題を解決するが、いまだ多くの不備を示す。
・制限されたトポロジ情報のみが利用可能である。ＧＧＳＮ選択のために実装されたフィルタ機能を有したとしても、ローカルＧＧＳＮが利用可能でなく、複数の離れたＧＧＳＮが利用可能である場合に曖昧さがある。ローカルＧＧＳＮの選択が機能するために、プールからのサーバ／ゲートウェイを求めるリクエスタは、ＩＰホスト自身であるべきである。あるＳＡＥシナリオでは、これは可能ではない。例えば、ｅノードＢからの要求に基づいてＭＭＥが行なうべきであるＳＡＥＧＷ選択について機能しないであろう。
・トランスポート・ネットワークに関する負荷情報は利用可能でなく、従って、選択手順で考慮に入れることができない。それ故、トランスポート・ネットワークの幾つかの部分は過負荷になりうる。その他の部分は、異なる地域におけるユーザ活動に依存して、利用されないままでありうる。結果として、所与のサービスについてのＱｏＳ要件が保証されえない。
・プールからのサーバ／ゲートウェイの到達性情報が不十分である。所与の要素がＤＮＳサーバから到達可能かどうかを検証するためにピングが用いられるが、通信するＭＳのそれぞれから到達可能かどうかについての情報は存在しない。
・プール要素のその他の特性を考慮に入れることができない。このような特性の例は、特定のネットワークへの接続性、サポートされるサービス等を含む。すべてのプール要素は同様に構成され、すべての要求された機能を有さなければならない。
・ＤＮＳでは静的プール構成が用いられる。将来では、様々なＳＡＥＧＷノードの数および能力（例えば、ＩＰＳｅｃサポート、アクセス・タイプ・サポート等）が増加するであろうが、これは、プールの構成管理を現在よりも煩雑にする。このシナリオでは、あるプールへＳＡＥＧＷを（動的に）追加することおよびあるプールからＳＡＥＧＷを（動的に）除去することはしばしば生じるイベントとなり、構成に著しく影響を及ぼす。] 図１
発明が解決しようとする課題

[0032] 発明者らは、サーバおよびゲートウェイのようなネットワーク・リソースについてのプール情報を静的に提供することに内在する課題および制限について明確に理解した。]
課題を解決するための手段

[0033] 本発明の第１の側面によれば、通信ネットワーク内の複数のネットワーク・リソースからネットワーク・リソースを選択するための方法が提供される。選択ノードは、ネットワーク・リソースを求める要求を端末から受信し、次いで少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出す。読み出されたデータに基づいて、選択ノードは複数のネットワーク・リソースからネットワーク・リソースを選択する。次いで、選択されたネットワーク・リソースを識別する情報を含む応答が端末へ送信される。ネットワーク・リソースの集中方式による選択は多くの相異なるネットワーク・ノード内に選択機能を構成する必要性を低減し、プールされたネットワーク・リソースを用いる効率を向上する。]
[0034] オプションとして、ネットワーク・リソースはサーバ機能又はゲートウェイ機能の一方から選択される。複数のネットワーク・リソースに関するデータはオプションとして少なくとも一つのデータベースから読み出される。このデータは複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含む。これにより、選択ノードが各ネットワーク・リソースの能力に基づいて選択を行い、端末について最適なネットワーク・リソースを選択することが可能となる。ネットワーク・リソースに関する最新の情報及びそれらの可用性を選択ノードが受信することを保証するために、データベースはオプションとして複数のネットワーク・リソースのぞれぞれの能力及び状態が変わるにつれて更新される。]
[0035] さらなるオプションとして、複数のネットワーク・リソースに関するデータは、ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、端末とネットワーク・リソースとの間の経路に関するネットワークの現在の容量とのうちの何れかである。この種の情報はデータベースへ頼ることなく取得されえ、選択ノードに現在のネットワーク状況に関する情報を与える。]
[0036] オプションとして、本方法はドメイン・ネーム・サーバから複数のネットワーク・リソースのそれぞれについてのアドレスを読み出すことを含む。]
[0037] オプションとして、本方法はホーム加入者サーバからユーザ又は端末に関する加入契約及びサービス情報を読み出すことを含む。これにより、ユーザの加入契約又は端末の能力に基づいてネットワーク・リソースが選択されることが可能となる。]
[0038] 要求及び応答はオプションとしてドメイン・ネーム・システム・メッセージである。これにより、本発明は既存のネットワークに容易に統合されることが可能となる。]
[0039] 読み出されたデータはオプションとして、
複数のネットワーク・リソースのそれぞれのネットワーク上の位置と、
複数のネットワーク・リソースのそれぞれについての経路情報と、
複数のネットワーク・リソースのそれぞれに関する現在の負荷と、
複数のネットワーク・リソースのそれぞれの現在の容量と、
端末と複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、
複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、
複数のネットワーク・リソースのそれぞれから利用可能なサービスと、
ユーザ又は端末に関する加入契約情報と、
事業者ポリシー情報と
のうちの何れかから選択された情報を含む。]
[0040] ネットワーク・リソースを選択する際に、本方法はオプションとして、到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを複数のネットワーク・リソースから減らすことを含む。このようにして、利用不可能な又は不適切なネットワーク・リソースは端末へ送信されない。]
[0041] ネットワーク・リソースを選択する際に、本方法はオプションとして、複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとることを含む。これは、ネットワーク・リソースがより効率的に用いられることを保証し、一つのネットワーク・リソースが過負荷になりつつ、別のものが十分に利用されないリスクを低減する。]
[0042] オプションとして、端末エンティティへの応答はネットワーク・リソースのＩＰアドレスを含む。]
[0043] 通信ネットワークはオプションとしてシステム・アーキテクチャ・エボリューション・ネットワーク及びＩＰマルチメディア・サブシステム・ネットワークから選択される。]
[0044] 本発明の第２の側面によれば、通信ネットワークで用いられる選択ノードが提供される。選択ノードはネットワーク・リソースを求める要求を端末から受信するための受信器と、少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出すための手段とを備える。選択ノードはさらに、読み出されたデータに基づいて複数のネットワーク・リソースからネットワーク・リソースを選択するための手段と、選択されたネットワーク・リソースを識別する情報を含むメッセージを端末へ送信するための送信器とを備える。選択ノードは多くの相異なるネットワーク・ノードに選択機能を構成する必要性を低減し、プールされたネットワーク・リソースを使用する効率を向上する。]
[0045] オプションとして、様々なソースからの情報が選択処理に関連するかもしれないため、データを読み出すための手段は、複数のネットワーク・ノードからデータを読み出すための手段を備える。]
[0046] ネットワーク・リソースはオプションとしてサーバ機能又はゲートウェイ機能の一方から選択される。]
[0047] オプションとして、複数のネットワーク・リソースに関するデータを読み出すための手段は、少なくとも一つのデータベースからデータを読み出すための手段を含み、データは複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含む。さらなるオプションとして、複数のネットワーク・リソースに関するデータを読み出すための手段は、ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、端末とネットワーク・リソースとの間の経路に関するネットワークの現在の容量とのうちの何れかを読み出すための手段を備える。このようにして現在のネットワーク状況とネットワーク・リソースに関して記憶された情報とを選択ノードに知らせる情報が取得されうる。]
[0048] 読み出されたデータはオプションとして、複数のネットワーク・リソースのそれぞれのネットワーク上の位置と、複数のネットワーク・リソースのそれぞれについての経路情報と、複数のネットワーク・リソースのそれぞれに関する現在の負荷と、複数のネットワーク・リソースのそれぞれの現在の容量と、端末と複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、複数のネットワーク・リソースのそれぞれから利用可能なサービスと、ユーザ又は端末に関する加入契約情報と、事業者ポリシー情報とのうちの何れかから選択された情報を含む。]
[0049] 不適切な又は利用不可能なネットワーク・リソースが選択されることを防ぐために、選択ノードはオプションとして到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを複数のネットワーク・リソースから減らすための手段をさらに備える。ネットワーク・リソースが過負荷となるリスク又は十分に使用されないリスクを低減するために、選択ノードはオプションとして複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとるための手段をさらに備える。]
[0050] 本発明の第３の側面によれば、通信ネットワークで用いられる端末が提供される。本端末は、ネットワーク・リソースを求める要求メッセージを生成するためのプロセッサを備え、要求メッセージはドメイン・ネーム・システム・クエリを含み、ドメイン・ネーム・システム・クエリは完全修飾ドメイン名に符号化された端末の識別子を含む。ＤＮＳクエリの形式で要求メッセージを送信することによって、メッセージは直接にＤＮＳサーバへ転送されえ、様々なネットワーク・ノードでメッセージを処理するために必要となる処理を低減する。さらに、端末の識別子をＦＱＤＮに符号化することによって、端末に代わって通信するホストからのシグナリングを選択機能が受信する場合であっても、選択機能によって本端末が識別されうる。]
図面の簡単な説明

[0051] ＤＮＳアーキテクチャをブロック図で概略的に示す図である。
提案されたＳＡＥ／ＬＴＥアーキテクチャをブロック図で概略的に示す図である。
本発明の実施形態によるネットワーク・アーキテクチャをブロック図で概略的に示す図である。
本発明の実施形態のステップを示すフロー図である。
本発明の実施形態によるサーバまたはゲートウェイのプールを選択するシステムをブロック図で概略的に示す図である。
本発明の実施形態によるプール内のノードのトポロジと、状態と、能力と、機能情報とを識別するネットワーク・アーキテクチャをブロック図で概略的に示す図である。
本発明の実施形態によるＳＡＥネットワークにおける端末登録をブロック図で概略的に示す図である。
本発明の実施形態による端末登録のためのシグナリング・シーケンス図である。
本発明の実施形態によるＩＭＳベースのマルチメディア・サービスの選択を示すシグナリング・シーケンス図である。
本発明の実施形態による選択ロジック機能ノードをブロック図で概略的に示す図である。
本発明の実施形態による端末をブロック図で概略的に示す図である。]
実施例

[0052] 以下の記載は説明を目的とし制限を目的ではなく特定の実施形態、手順、技術等のような個別の詳細について説明する。ある場合には、不必要な詳細さで説明を不明瞭にしないように、周知の方法、インタフェース、回路およびデバイスの詳細な説明が省略される。さらに、幾つかの図において個別のブロックが示される。個別のハードウエア回路を用いて、適切にプログラムされたデジタル・マイクロプロセッサまたは汎用コンピュータと連動するソフトウエア・プログラムとデータとを用いて、特定用途向け集積回路を用いて、および／または一つ以上のデジタル・シグナル・プロセッサを用いて、これらのブロックの機能が実装されてもよいことが理解されるだろう。]
[0053] 以下の記載は、ＳＡＥ／ＬＴＥシステムにおける拡張されたゲートウェイ／サーバ選択概念を開示する。しかしながら、本概念は、その他のタイプのネットワークで用いられてもよいことが理解されるだろう。本概念により、通信ホストのために複数のネットワーク・リソースから最適なサーバまたはゲートウェイが自動的に選択されることが可能となる。]
[0054] 図３は本発明の実施形態によるネットワークのハイレベル・アーキテクチャを示す。サーバまたはゲートウェイを求めるＤＮＳ要求３０２をリクエスタ３０３から受信する選択ロジック機能３０１が提供される。リクエスタ３０３と通信のためにサーバ／ゲートウェイのＩＰアドレスを必要とするＩＰホストとは同一エンティティでなくてもよいが、この場合に通信ホスト３０４を識別する情報は要求メッセージで伝達されることに留意されたい。選択ロジック３０１は、状態（負荷および到達可能性）、能力、機能、トランスポート情報ならびに加入契約情報および最小サービス品質等のサービス固有の情報のような基準に基づいて、ホスト３０４のために最適なサーバ／ゲートウェイを選択し、（選択されたサーバ／ゲートウェイの）単一のＩＰアドレスをリクエスタ３０３に返信する（３０５）。選択ロジック３０１は、選択に必要となる必須パラメータを推測（infer）するために複数のデータ・ソースから情報を取得できる。これらのデータ・ソースは、所与のサービスのための取り得るサーバ／ゲートウェイのリストを読み出すためのＤＮＳ３０６と、加入契約とサービス関連情報とを読み出すためのホーム加入者サーバ（ＨＳＳ）３０７と、トポロジ情報だけでなくプール・メンバの状態／機能／能力情報のためのトポロジ・データベース３０８とを含む。] 図３
[0055] データ・ソースへのクエリはリクエスタ３０３からの要求により始動されてもよいが、選択ロジック３０１は応答時間を短縮するためにあらかじめ独立にクエリを起動してもよい。]
[0056] トポロジ・データベース３０８は、データベース同期機能３０９により動的に更新される。データベース同期機能３０９は以下の機能を有する。
・トポロジ発見。データベース同期機能３０９は、サーバ３１０、３１１、３１２、３１３およびゲートウェイ３１４の位置を含むトポロジおよびリンク／ルータ状態情報を発見する。
・監視機能。データベース同期機能３０９は、状態と、能力（例えば、ＶＰＮ構成）と、機能（例えば、セキュリティ・ゲートウェイ）と、トランスポート・ノードだけでなくプール・メンバの負荷情報とを取得する責任を負う。
・リソース管理。データベース同期機能３０９は、バランスのとれたトランスポート負荷を提供し、従って高いセッション完了率を提供するために、トランスポート・リソースを管理する責任を負う。]
[0057] 図４は、ノードのサービス情報と、状態と、能力／機能とだけでなくトランスポート情報に基づいて、複数のサーバ／ゲートウェイのプールから最適なサーバ／ゲートウェイを選択するための例示の方法を示すフローチャートである。下記のステップ番号は図４の番号を示す。
４０１リクエスタは、サーバまたはゲートウェイのＩＰアドレスを要求する。
４０２選択ロジックは要求しているホストと必要なサービス・パラメータとを識別する。
４０３ 選択ロジックはサーバまたはゲートウェイのプールを識別する。
４０４ 選択ロジックは関連する各プール・メンバのＩＰアドレスを識別する。
４０５ 選択ロジックはプールのトポロジに関する情報を識別する。
４０６ 選択ロジックはプール・メンバの状態と、能力と、機能とを識別する。
４０７ 選択ロジックは最適なプール・ノードを選択する。
４０８ 選択されたノードのＩＰアドレスを含むメッセージがリクエスタへ送信される。] 図４
[0058] 上記ステップの各々を順に取り上げて、最適なゲートウェイ／サーバを求める要求は、必要となる情報を交換できる任意のタイプの適切なシグナリングを用いる。好ましい実施形態では、大部分のＩＰホストがＤＮＳをサポートし、それ故リクエスタ機能に対する影響が低いために、要求はＤＮＳクエリに基づく。]
[0059] ゲートウェイ／サーバ要求のためにＤＮＳクエリが用いられると仮定して、サービス識別はクエリの完全修飾ドメイン名（ＦＱＤＮ）に符号化された文字列、例えば、＿ｉｎｅｔ．ｔｃｐ．ｅｘａｍｐｌｅ．ｎｅｔに基づき、ここで＿ｉｎｅｔは必要となるサービス、例えば、インターネット接続を示す。]
[0060] 選択のために必要となるホスト・パラメータはホストの位置である。ホストがリクエスタ自身である場合に、これはリクエスタのＩＰアドレスから識別される。しかしながら、ホストとリクエスタとが同じでないならば、ホスト識別子はＤＮＳクエリ・メッセージで転送される。これは以下の何れかにより行われる。
・ホスト識別子はＤＮＳ要求メッセージのＦＱＤＮに符号化される。例えば、所与のホストＡに対して、ＦＱＤＮは、＿ＨｏｓｔＡ＿ｉｎｅｔ．ｔｃｐ．ｅｘａｍｐｌｅ．ｎｅｔのように見えるかもしれない。ホスト識別子はＦＱＤＮからホストを識別するよう構成される選択ロジックで事前に構成された任意のテキスト文字列であってもよいことに留意されたい。この解決策は、ホストおよび対応する位置の静的事前構成が選択ロジックにおいて可能な場合に実行可能であり、従って、移動体端末またはノマディック（nomadic）端末に対しては適切でない。
・ホスト識別子はＤＮＳクエリの付加的なＲＲフィールドとして転送される。ホスト識別子はテキスト文字列とホストのＩＰアドレスとを含む。ＩＰアドレスは、移動体ホスト又はノマディック・ホストに対してさえもホストの位置を識別する。また、この場合に、選択ロジックはホストを識別するためにＤＮＳメッセージを解析しなければならないということに留意されたい。]
[0061] ここでステップ４０３と４０４に戻って、サービスについてのサーバまたはゲートウェイのプールとプールのメンバのＩＰアドレスとが識別されなければならない。好ましい実施形態では、サービスのためのプール識別は標準ＤＮＳ機能に基づき、従って、プールのためのデータ・ソースは標準ＤＮＳサーバである。各サービスのための選択可能なノードのリストを有するＤＮＳサーバの構成はネットワーク管理システムによって実行される。]
[0062] プール識別は、以下のステップを備える。
・リクエスタ３０３から選択ロジック３０１へ要求が到着する。
・上述のように、選択ロジック３０１はホストとサービス・パラメータとを推測し、要求されたサービスを指定する標準ＤＮＳクエリをＤＮＳサーバへ発行する。
・様々なサービスに対応するリソース・レコードがＤＮＳサーバ３０６に記憶される。要求内の指定されたサービスに基づいて、ＤＮＳ回答で、それらのＩＰアドレスを含むサービスに対応するレコード要素が選択ロジック３０１へ返信される。
・選択ロジック３０１は様々な基準に基づいてプールからサーバまたはゲートウェイを選択し、選択されたサーバまたはゲートウェイの単一のＩＰアドレスを含む応答をリクエスタ３０３へ送信する。]
[0063] 好ましい実施形態では、最初の要求はＤＮＳクエリの型式である。そのため、元もとの要求をほとんどまたは全く変更することなしに、選択ロジック３０１はＤＮＳサーバ３０６へ要求を転送してもよい。また、ＤＮＳサーバからの回答から最適なエントリを除去し、それをリクエスタに転送することがより速くなる。]
[0064] サーバまたはゲートウェイのプールを選択する処理が図５に示される。] 図５
[0065] ここでステップ４０５に戻って、トポロジ情報だけでなくプール・メンバの状態、能力および機能が識別される。上記の情報に対するデータ・ソースは、動的に更新されるトポロジ・データベース３０８であり、図６に提案されるシステム・アーキテクチャが概略的に示される。選択ロジック３０１は最も近いサーバ／ゲートウェイと、トランスポート容量と、ノード状態／負荷情報等とを見つけるために、トポロジ・データベース３０８を参照する。トポロジ・データベース３０８は、選択ロジック３０１と同じボックスに構築されてもよいが、代わりに別個のノードであってもよい標準のリレーショナル・データベースでありうる。] 図６
[0066] データベース３０８の初期構成は、移動体ネットワークのＯ＆Ｍシステムのような管理システムによって行われてもよい。トポロジ・データベース３０８を更新された状態に保つために、本発明の好ましい実施形態では、図６に示されるように、データベース同期機能３０９が提供される。データベース同期機能３０９は以下のような主な機能を有する。
・トポロジ発見。トポロジ発見機能６０１は、ルータによるオープン・ショーテスト・パス・ファースト（ＯＳＰＦ）広告をリッスンして、経路トポロジ及びリンク／ルータ状態情報を読み出す。トポロジ内のサーバおよびゲートウェイの位置の識別は任意の適切な方法で実行される。
・監視機能。監視機能６０２は、トランスポート・ノードだけでなくプール・メンバの状態と、能力（例えば、ＶＰＮ構成）と、機能（例えば、セキュリティ・ゲートウェイ）と負荷情報とを取得する責任を負う。ＩＰＷｏｒｋｓ、例えば、ピング、ＳＮＭＰｐｏｌｌ等に実装される図１に示される解決策におけるものと同様な方法を用いて、ＧＭＰＬＳ非認識ノードについての状態と、能力と、機能と、負荷情報とが取得されうる。監視機能は、関連するノードと直接にインタフェースしてもよいし、ネットワークをポーリングする管理システムから構成を取得してもよい。
・リソース管理。より平衡したトランスポート負荷と、それ故、より高いセッション完了率とを保証するために、リソース管理機能６０３はトランスポート・リソースを管理する。これは、事業者ポリシー、ＳＬＡ情報等に基づいて、ネットワーク管理システムにより事前に構成されるべきである。図における次世代リソース制御（ＮＧＲＣ）機能として総括的に示されるリソース情報を交換するため複数のエンティティにインタフェースすることによって、トランスポート・リソース情報における動的な変更の記帳（bookkeeping）が行われてもよい。ＮＧＲＣは、新規に登録された端末の加入契約情報を読み出すためのリソース管理、例えばＰＣＲＦまたはＨＳＳを担当するネットワーク内の別のロジック・エンティティであってもよいが、直接的に、アクティブなＰＤＰコンテキストのリソースの必要性に関する情報をすでに有しうる選択ロジックであってもよい。] 図１ 図６
[0067] 端末登録の間、複数の関連するＳＡＥ−ＧＷシナリオが可能である。以下は、同じ位置のサービングＳＡＥＧＷおよびＰＤＮ ＳＡＥＧＷを仮定し、これらのシナリオの各々に関連する選択に重要なパラメータの例を提供する。]
[0068] ＩＭＳシナリオでは、ローカル・スイッチングを有する最短経路を実現するために、“最も近い”ＧＷサイトにアンカ・ポイントが選択されなければならず、従って、サイト位置はアンカ・ポイント選択に必要となる。]
[0069] ネットワーク冗長シナリオでは、ＧＷ選択は、“立ち上がって稼動している（up-and-running）”ＧＷ集合に基づく。欠陥のあるＧＷはブロックされて、プールで用いられてはならない。また、“立ち上がって稼動している”情報はアンカ・ポイントの選択で必要となり、負荷情報はノード容量の利用を最適化してもよく、従って、また、アンカ・ポイント選択に負荷情報が含まれうる。]
[0070] モビリティ固有のＧＷ／ＳＡＥＧＷシナリオでは、問題は、例えばＭＩＰを扱う能力を有するＧＷが用いられることを保証するため、能力に基づいてＧＷが再選択されることである。この場合に、アンカ・ポイント選択においてモビリティ・タイプが用いられる。]
[0071] 企業シナリオでは、セルラ・ネットワークのアウトドアのｅノードＢでインドアのネットワークがカバーされるアウト・ドア・インのシナリオの状況で、事業者バックボーンを介して企業トラヒックがルーティングされ、従って、ＩＰＳｅｃトンネルが必要となる。企業ネットワーク・シナリオにおけるＧＷ／ＬＴＥでは、ｅノードＢとＧＷとを有するインドア・ネットワークがＬＡＮに接続される。従って、ネットワーク内にローカル・スイッチングが存在し、そのためＩＰＳｅｃトンネルは必要ないが、もしトラヒックが事業者ネットワークを介して企業ネットワークへルーティングされるならば、ＩＰＳｅｃトンネルが必要となる。これらのシナリオでは、アンカ・ポイントの選択において、企業ネットワークに接続するＧＷ／ＳＡＥＧＷおよびＩＰＳｅｃ能力を有するＧＷが用いられるべきである。さらに、ある環境では、アンカ・ポイントの選択において企業ＧＷが用いられるべきである。]
[0072] インターネットがトランスポート・ネットワークとして用いられる場合に、ＩＰＳｅｃおよびサービス妨害（ＤｏＳ）耐性のあるＧＷが必要となり、“緩和された”ＱｏＳ要件を有するトラヒックのみが送信されるべきである。インターネット・トラヒックがインターネットへ直接に転送される場合に、アンカ・ポイントの選択において“インターネット・ピアリング”パラメータに最も近いＧＷが用いられるべきである。さらに、ＤｏＳ耐性のあるＧＷが必要となり、特定のＱｏＳ情報に適合するＧＷが選択されてもよい。]
[0073] サービス固有のＧＷシナリオでは、すべてのサービスに対して一つのＧＷが提供される。サービスのタイプに基づいてアンカ・ポイントが選択され、それ故、アンカ・ポイントの選択においてサイト位置とサービス情報とが用いられる。]
[0074] モビリティ・シナリオでは、ユーザの位置変更に基づいて、ＭＭＥはＧＷの再選択を強制する。ＧＷの再選択は、プール内またはプール間のいずれかで可能である。このシナリオでは、アンカ・ポイントの選択において、トポロジ（サイト位置）情報が必要となる。]
[0075] 上述の場合から、ＳＡＥＧＷの選択について、以下のパラメータ集合が導出されうる。
・トポロジ関連パラメータ：
‐ＳＡＥＧＷ、ｅノードＢ、ピアリング・ポイントの位置、地理的および論理的のＰＯＩ、すなわちＩＰトポロジのＰＯＩだけでなく実際の経路情報
・性能関連パラメータ：
‐ＳＡＥＧＷの負荷／容量情報
‐ＳＡＥＧＷに関する“立ち上がって稼動中”／到達可能性情報
・能力／機能関連パラメータ：
‐ＩＰ−ｓｅｃ、“ＤｏＳ耐性”、サービング／ＰＤＮ ＳＡＥＧＷ等
‐モビリティ・タイプ、すなわちサポートされる（３ＧＰＰ、非３ＧＰＰ）アクセス
‐サービスへの接続性／アクセス
・企業ＶＰＮへのアクセスを有するＳＡＥＧＷ
・キャンパス／企業内のＳＡＥＧＷ
・インターネット・ピアリングを有するＳＡＥＧＷ
・サービス関連パラメータ：
‐ＱｏＳ情報およびその他の事業者ポリシー情報
‐加入契約情報、例えば、加入しているサービス、好ましいアプリケーション、サービス利用統計等。]
[0076] 最適なプール要素を選択するために、個別の選択アルゴリズムが選択ロジックで必要となる。選択アルゴリズムは典型的には制御プレーン（サーバ）またはユーザ・プレーン（ゲートウェイ）の要素選択で異なり、そのため、ＣＰサーバについての現在のアルゴリズムはゲートウェイに直接に適用できないかもしれない。トランスポート・トポロジの近さは、より良好な特性と効率的なトランスポート利用を提供するが、同時にノードが過負荷から保護されないため、しばしば、ＧＷノードの選択についてより重要な要因である。]
[0077] プールから要素を選択する一つの方法は、以下のように、負荷と最小コストとに基づく。
１）ＡＰＮに関連付けられた必要となる能力をフェッチ。
２） 到達可能（“立ち上がって活動している”）でない任意のプール・メンバを削除。
３）能力要件（セキュリティ、ＱｏＳ、ＩＰ−ｓｅｃ、モビリティ・タイプ等）を満たさないプール・メンバを削除。
４） 期待されるサービス（例えば企業ＶＰＮ、キャンパス、インターネット・ピアリング）へのアクセス要件のみを満たすプール・メンバを選択。
５）トポロジ・データベースにおけるＲＢＳからの経路長（即ち、ホップ数）を計算。
６） 必須ではない“あればよい”能力“Ｐ”のコストを計算／マッピング。
７） ａ、ｂおよびｃが任意に選択された定数である場合に、コスト＝（ａ×負荷＋ｂ×経路長＋ｃ×Ｐ）を計算。
８） 最小コストのプール・メンバを選択。]
[0078] また、ユーザ加入契約に基づいてプールから要素が選択されてもよい。この場合に、ＨＳＳのようなユーザ加入契約を扱うノードから加入契約情報が読み出されうる。これにより、高度なプールの使用が可能になり、その例を以下に示す。
１） ＨＳＳにおける選択制限。ＶＰＮ接続に対して、ＡＰＮが割り当てられうる。ＡＰＮは幾つかのＩＰアドレスを持つことができる。すなわち、ＶＰＮ接続加入者は幾つかのＳＡＥ−ＧＷに接続されうる。ＤＮＳを用いて各ＩＰアドレスを相異なるように構成する代わりに、これはＳＡＥ−ＧＷの限られた集合に制限されうる。プール・メンバの限られた集合を用いる一つの理由は、ＳＡＥ−ＧＷへのＩＰ−ｓｅｃトンネルの確立のために鍵管理における制限である。
２） “ＨＳＳにおけるＡＰＮ”。管理を容易にするために、ＤＮＳ名がＨＳＳに記憶される。この場合に、移動体端末からのＡＰＮ文字列は、ＨＳＳに構成されたＤＮＳ名によって上書きされる。それ故、大きなユーザのグループに対して共通のＡＰＮが用いられえ、ＨＳＳから明示的な名前が読み出されうる。
３） “ユーザのタイプ”。異なる加入契約は容量、速度およびモビリティに関して異なる制限を有する。加入者が固定‐無線の加入契約を有するなら、それらのモビリティは制限され、それ故、ローカルのＳＡＥＧＷの必要性のみが用いられる。それ故、ＨＳＳは、ＧＷのＤＮＳ名に関する情報を有しうる。]
[0079] 上記の例では、以下の選択アルゴリズムが適用可能である。
１） ＨＳＳからＤＮＳ名をフェッチ。
２） ＤＮＳ名に関連付けられた必要となる能力をフェッチ。
３）能力要件（セキュリティ、ＱｏＳ、ＩＰ−ｓｅｃ、モビリティ・タイプ等）を満たさないプール・メンバを削除。
４） 期待されるサービス（例えば、企業ＶＰＮ、キャンパス、インターネット・ピアリング）へのアクセス要件のみを満たすプール・メンバを選択。
５）トポロジ・データベースにおけるＲＢＳからの経路長（即ち、ホップ数）を計算。
６） 必須でない“あればよい”能力“Ｐ”のコストを計算／マッピング。
７） ａ、ｂおよびｃが任意に選択された定数である場合に、コスト＝（ａ×負荷＋ｂ×経路長＋ｃ×Ｐ）を計算。
８）最小コストのプール・メンバを選択。]
[0080] プールから要素が選択されると、ＤＮＳ回答において選択ロジックにより選択された要素のＩＰアドレスが返信される。本提案によれば、ＤＮＳ回答は常に単一のＩＰアドレスを含むだろう。]
[0081] 図７に、ＳＡＥネットワーク・アーキテクチャにおける端末登録の例が示される。制御プレーンとユーザ・プレーンとについての分割アーキテクチャが仮定され、２種類のＳＡＥＧＷが、ＳＡＥＧＷと呼ばれる同一の物理ノードに存在すると仮定する。しかしながら、ＳＡＥＧＷは分離したサービングおよびＰＤＮのＳＡＥＧＷを代替として備えてもよいことに留意されたい。] 図７
[0082] 端末７０１がネットワークに登録される場合に、以下のタスクが実行される。
・ｅノードＢにより端末７０１に対してＭＭＥ７０２が選択される。
・ＭＭＥはＳＡＥＧＷ３１４を選択する。
・ＭＭＥはＭＴに対するＳＩＰサーバ、即ちＣＳＣＦを選択する。]
[0083] 図８に、提案されるアーキテクチャに基づく選択を含む端末７０１の登録のためのシグナリング・シーケンス図が示され、以下のステップを含む。
・端末７０１はｅノードＢへ登録要求を出す。
・ｅノードＢは所与の端末７０１に対してＭＭＥを選択する。このために、ｅノードＢはＭＭＥアドレスを求めるＤＮＳ−クエリを出す。
・クエリは選択ロジック３０１に到着し、選択ロジック３０１は、所与のサービスのについて取り得るＭＭＥのリストを取得するためにＤＮＳサーバ３０６へクエリを転送する（これに代えて、選択ロジックは、以前に受信されたＭＭＥリストを自身のキャッシュに保持する）。
・選択ロジック３０１は（負荷、可用性等に基づいて）通信のために最適なＭＭＥを選択し、それをＤＮＳ返信８０３でｅノードＢへ転送する。
・ｅノードＢは登録要求８０４を所与のＭＭＥ７０２へ出す。ＭＭＥ７０２は、ＨＳＳ３０７を関与させる認証手順を開始する。この処理の間、例えば、接続できるはずのＰＤＮへの端末加入契約に関する情報を受信する。次に、それは、これらのすべてのネットワークに接続できるＳＡＥＧＷ３１４を選択する。このために、それは、所与のＳＡＥＧＷプールを識別するサービス・タイプを指定するＤＮＳクエリ８０５を出す（この目的のためにＡＰＮ名が用いられてもよい）。さらに、これはまたまた、選択ロジック３０１に実際の端末３０４の位置に関する情報を提供するために、登録要求を出すｅノードＢのＩＰアドレスを指定する。
・選択ロジック３０１はクエリを傍受し、それをＤＮＳサーバに転送して、所与のサービスについて取り得るＳＡＥＧＷのリストを取得する。
・選択ロジック３０１は、通信に最適なＳＡＥＧＷ３１４を選択し、それをＤＭＳ回答でＭＭＥへ転送し、次いで所与のＳＡＥＧＷへ‘接続性生成’８０６の要求を開始する。
・ＳＡＥＧＷ３１４はまた、端末７０１に対して適切なＣＳＣＦを選択してもよい。このために、それは、ＩＭＳについてＣＳＣＦが必要となることを識別するパラメータを指定するＤＮＳクエリ８０７を出す。
・選択ロジック３０１はクエリを傍受し、それをＤＮＳサーバへ転送して、取り得るＣＳＣＦのリストを取得する。
・選択ロジック３０１は、通信に最適なＣＳＣＦを選択し、ＤＮＳ回答８０８においてＳＡＥＧＷ３１４へそれを転送する。
・ＳＡＥＧＷ３１４は、端末７０１に対して選択されたＩＰアドレスのようなその他のパラメータから選択されたＣＳＣＦを指定して、‘接続性生成’要求８０６に返答８０９する。ＭＭＥ７０２は、ＳＡＥＧＷのＩＰアドレスと一緒に、これらを‘登録受理’メッセージ８１０において端末７０１へ転送する。この時点で、端末７０１は移動体ネットワークにより提供されるサービスを使用できる。] 図８
[0084] 端末７０１がＳＡＥＧＷ３１４に割り当てられると、サービス領域でサービス稼動中に、ＣＳＣＦ９０２によるアプリケーション・サーバ（ＡＳ）の選択またはＡＳ９０１によるメディア・サーバ（ＭＳ）９０３の選択のような、制御プレーン・サーバ選択およびユーザ・プレーン・サーバ選択の両方を含むその他の選択タスクが可能である。図９はマルチメディア・サービスの選択を示すシーケンス図であり、以下のステップを含む。
・端末７０１は以前に選択されたＣＳＣＦ９０２へＳＩＰ招待９０４を出す。
・ＣＳＣＦ９０２は所与のサービスに対するＡＳを選択する。このために、それは、より近いＡＳを選択するためにオプションとして端末７０１のＩＰアドレスを指定するＤＮＳ−クエリ９０５を出す（ＡＳは大抵、制御サーバであるので、これは必要でないかもしれない）。
・クエリは選択ロジック３０１に到着し、選択ロジック３０１は、所与のサービスについて取り得るＡＳのリストを取得するためにそれをＤＮＳサーバ３０６へ転送する（これに代えて、それは、以前に受信されたＡＳリストを自身のキャッシュに保持しうる）。
・選択ロジック３０１は通信に最適なＡＳ９０１を選択し、それをＤＮＳ返信９０６においてＣＳＣＦ９０２へ転送する。
・ＣＳＣＦ９０２はメディア要求９０７をＡＳ９０１へ出す。ＡＳ９０１はサービスについてメディア・サーバ９０３を選択する。このために、それは、メディア・サーバ・プールを識別するサービス・タイプを指定するＤＮＳクエリ９０８を出す。さらに、それはまた、端末７０１のＩＰアドレスを指定する。
・選択ロジック３０１はクエリを傍受し、それをＤＮＳサーバ３０６へ転送して、所与のサービスについて取り得るメディア・サーバのリストを取得する。
・選択ロジック３０１は通信に最適なメディア・サーバを選択し、それをＤＮＳ回答９０９においてＡＳ９０１へ転送し、次いでＡＳ９０１はメディア受理メッセージ９１０においてそれをＣＳＣＦ９０２へ転送する。
・ＣＳＣＦ９０２はＳＩＰ ｏｋメッセージ９１１において端末７０１へメディア・サーバ・アドレスを転送し、通信が始まりうる。] 図９
[0085] 本発明は、上述の場合に限定されず、ＳＡＥにおけるその他の取り得る選択シナリオで用いられてもよい。一つの例は、移動体端末アイドル状態のＳＡＥＧＷ再配置に対するサポートである。例えば、移動体ユーザについてＳ１経路最適化を達成するため、幾つかの状況では、ＳＡＥＧＷを再選択することは有用でありうる。ＳＡＥＧＷプールの規模が小さいなら、Ｓ１経路はあまり大きくないかもしれないが、他方、ユーザ・モビリティは、しばしばＳＡＥＧＷ再配置の原因になり得るであろうが、これは進行中のセッションに影響を与えるかもしれず、乏しい制御リソースを消費するかもしれない。アイドル端末および利用可能な制御リソースの場合に、ＳＡＥＧＷを選択することによって、ＳＡＥＧＷ再配置をサポートすることは望ましいだろう。]
[0086] また、選択ロジックは、適切なローカルＰＤＮ ＳＡＥＧＷの選択において、最適化されたネットワーク利用（ローカル・ブレイクアウト）のため、ローミング中のユーザにＩＰＰＯＰとして助けるかもしれない。]
[0087] 図１０を参照すると、選択ロジック機能ノード３０１が示される。上記で説明したように、ＤＮＳサーバ、ＨＳＳおよびトポロジ・データベースのようなその他のリソースからの情報を読み出す手段１００２とともに、ゲートウェイまたはサーバを求めるＤＮＳ要求を受信する手段１００１が提供される。ゲートウェイまたはサーバの選択を行うようにプロセッサ１００３が提供され、リクエスタへ応答メッセージを送信するための送信器１００４が提供される。サーバまたはゲートウェイが選択された記録を保持するためのデータベース１００５が提供されてもよい。] 図１０
[0088] 図１１を参照すると、本発明の実施形態による端末が示される。端末３０４は、サーバまたはゲートウェイのようなネットワーク・リソースを要求するＤＮＳクエリを生成するためのプロセッサ１１０１を有する。ＤＮＳクエリは、完全修飾ドメイン名に符号化された必要となるネットワーク・リソースのタイプを含む。端末はまた、クエリを送信する送信器１１０２と、クエリへの応答を受信する受信器１１０３とを有する。] 図１１
[0089] 本発明は、異なる制御ノードに実装されて構成される選択ロジックを有する代わりに、要素のプールから要素を選択するための共通アーキテクチャ（単一の集中管理ロジック）を提供する。これは、ネットワーク内のゲートウェイまたはサーバのプールからの選択を担当するかもしれない異なる論理ノードすべてにおいて選択に関する機能を実装して構成する必要がないため、資金および運営費を低減する。集中型の選択がより良いサポートを与える多くのユースケース（ネットワーク拡張、保守等）において、運営費の削減は特に明白である。]
[0090] 本発明の別の利点は、標準のＤＮＳクエリに基づいており、それゆえ既存のノード機能およびシグナリング・チェーンに大幅な変更を必要としない点である。大抵の場合に、すべてのＩＰホストはＤＮＳをサポートする。ＤＮＳベースの選択に比較して、本発明は、以下のことを提供するトポロジ・データベースを用いることによって、十分にトポロジを認識した選択を可能にする。
・選択でトランスポート負荷情報を用いることによる効率的なトランスポート使用。ある領域の移動体端末の進出だけでなくユーザの活動が動的に変化するかもしれないため、これは特に有益である。
・サーバ／ゲートウェイ到達可能性および利用可能なトランスポート・リソースの真の知識による呼／セッション設定時間および完了率のより良い特性。
・最も軽い負荷で、最短の取り得るユーザ・プレーン経路およびサービス・ノードを選択することによるＱｏＳに敏感なサービスの改善された応答時間および特性。]
[0091] アーキテクチャ上の拡張により、ＤＮＳリクエスタおよび通信ホストが同じでない（例えば、ＭＭＥによる新たに登録されたＭＴのためのＳＡＥＧＷ選択）場合に対して、ＤＮＳベースの選択を実装することが可能となる。さらに、オペークＬＳＡを介して、トポロジ・データベース内のノード能力、状態および機能関連情報の動的知識により、所与のサービスに対してプール構成の自動管理が提供される。プラグ・アンド・プレイ、ネットワーク障害またはネットワーク・アップグレードのような多くの重要なシナリオがサポートされてもよい。]
[0092] 様々な実施形態が示され詳細に説明されたが、特許請求の範囲はどの特定の実施形態または例にも限定されない。任意の特定の要素、ステップまたは機能が必須であり特許請求の範囲に含まれなければならないということを意味するように、上記の説明が読まれるべきでない。特許対象の範囲は特許請求の範囲によって規定される。]
[0093] この明細書において以下の略語が用いられる。
３ＧＰＰ 第３世代パートナーシップ・プロジェクト
ＢＧＰボーダ・ゲートウェイ・プロトコル
ＣＳＣＦ呼セッション制御機能
ＧＧＳＮ ゲートウェイＧＰＲＳサポート・ノード
ＬＴＥロング・ターム・エボリューション
ＭＭＥ 移動体管理エンティティ
ＭＳＣ移動体交換局
ＭＴ移動体体端末
ＮＴノマディック端末
ＯＳＰＦオープン・ショーテスト・パス・ファースト・プロトコル
ＰＤＡ携帯情報端末
ＰＤＮパケット・データ・ネットワーク
ＰＯＰポイント・オブ・プレゼンス
ＲＮＣ無線ネットワーク制御装置
ＳＡＥシステム・アーキテクチャ・エボリューション
ＳＧＳＮサービングＧＰＲＳサポート・ノード]

权利要求:

請求項1
通信ネットワーク内の複数のネットワーク・リソースからネットワーク・リソースを選択するための方法であって、選択ノードにおいて、ネットワーク・リソースを求める要求を端末から受信する工程と、少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出す工程と、前記読み出されたデータに基づいて、前記複数のネットワーク・リソースからネットワーク・リソースを選択する工程と、前記選択されたネットワーク・リソースを識別する情報を含む応答を前記端末へ送信する工程とを有することを特徴とする方法。
請求項2
前記ネットワーク・リソースはサーバ機能又はゲートウェイ機能の一方から選択されることを特徴とする請求項１に記載の方法。
請求項3
前記複数のネットワーク・リソースに関する前記データは少なくとも一つのデータベースから読み出され、前記データは前記複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含むことを特徴とする請求項１又は２に記載の方法。
請求項4
前記複数のネットワーク・リソースのぞれぞれの前記能力及び状態が変わるにつれて前記データベースを動的に更新する工程をさらに有することを特徴とする請求項３に記載の方法。
請求項5
前記複数のネットワーク・リソースに関する前記データは、前記ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、前記端末と前記ネットワーク・リソースとの間の経路に関する前記ネットワークの現在の容量とのうちの何れかを含むことを特徴とする請求項１乃至４の何れか１項に記載の方法。
請求項6
ドメイン・ネーム・サーバから前記複数のネットワーク・リソースのそれぞれについてのアドレスを読み出す工程をさらに有することを特徴とする請求項１乃至５の何れか１項に記載の方法。
請求項7
ホーム加入者サーバからユーザ又は前記端末に関する加入契約及びサービス情報を読み出す工程をさらに有することを特徴とする請求項１乃至６の何れか１項に記載の方法。
請求項8
前記要求及び前記応答はドメイン・ネーム・システム・メッセージであることを特徴とする請求項１乃至７の何れか１項に記載の方法。
請求項9
前記読み出されたデータは、前記複数のネットワーク・リソースのそれぞれの前記ネットワーク上の位置と、前記複数のネットワーク・リソースのそれぞれについての経路情報と、前記複数のネットワーク・リソースのそれぞれに関する現在の負荷と、前記複数のネットワーク・リソースのそれぞれの現在の容量と、前記端末と前記複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、前記複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、前記複数のネットワーク・リソースのそれぞれから利用可能なサービスと、ユーザ又は前記端末に関する加入契約情報と、事業者ポリシー情報とのうちの何れかから選択された情報を含むことを特徴とする請求項１乃至８の何れか１項に記載の方法。
請求項10
ネットワーク・リソースを選択する際に、到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを前記複数のネットワーク・リソースから減らす工程をさらに有することを特徴とする請求項１乃至９の何れか１項に記載の方法。
請求項11
ネットワーク・リソースを選択する際に、前記複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとる工程をさらに有することを特徴とする請求項１乃至１０の何れか１項に記載の方法。
請求項12
前記端末エンティティへの前記応答は前記ネットワーク・リソースのＩＰアドレスを含むことを特徴とする請求項１乃至１１の何れか１項に記載の方法。
請求項13
前記通信ネットワークはシステム・アーキテクチャ・エボリューション・ネットワーク及びＩＰマルチメディア・サブシステム・ネットワークから選択されることを特徴とする請求項１乃至１２の何れか１項に記載の方法。
請求項14
通信ネットワークで用いられる選択ノードであって、ネットワーク・リソースを求める要求を端末から受信するための受信器と、少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出すための手段と、前記読み出されたデータに基づいて複数のネットワーク・リソースからネットワーク・リソースを選択するための手段と、前記選択されたネットワーク・リソースを識別する情報を含むメッセージを前記端末へ送信するための送信器とを備えることを特徴とする選択ノード。
請求項14
前記データを読み出すための手段は、複数のネットワーク・ノードからデータを読み出すための手段を備えることを特徴とする請求項１４に記載の選択ノード。
請求項15
前記ネットワーク・リソースはサーバ機能又はゲートウェイ機能の一方から選択されることを特徴とする請求項１３又は１４に記載の選択ノード。
請求項16
前記複数のネットワーク・リソースに関するデータを読み出すための手段は、少なくとも一つのデータベースからデータを読み出すための手段を含み、前記データは前記複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含むことを特徴とする請求項１３乃至１５の何れか１項に記載の選択ノード。
請求項17
前記ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、前記端末と前記ネットワーク・リソースとの間の経路に関する前記ネットワークの現在の容量とのうちの何れかを特徴とする請求項１３乃至１６の何れか１項に記載の選択ノード。
請求項18
前記読み出されたデータは、前記複数のネットワーク・リソースのそれぞれの前記ネットワーク上の位置と、前記複数のネットワーク・リソースのそれぞれについての経路情報と、前記複数のネットワーク・リソースのそれぞれに関する現在の負荷と、前記複数のネットワーク・リソースのそれぞれの現在の容量と、前記端末と前記複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、前記複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、前記複数のネットワーク・リソースのそれぞれから利用可能なサービスと、ユーザ又は前記端末に関する加入契約情報と、事業者ポリシー情報とのうちの何れかから選択された情報を含むことを特徴とする請求項１３乃至１７の何れか１項に記載の選択ノード。
請求項19
到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを前記複数のネットワーク・リソースから減らすための手段をさらに備えることを特徴とする請求項１３乃至１８の何れか１項に記載の選択ノード。
請求項20
前記複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとるための手段をさらに備えることを特徴とする請求項１３乃至１９の何れか１項に記載の選択ノード。
請求項21
通信ネットワークで用いられる端末であって、ネットワーク・リソースを求める要求メッセージを生成するためのプロセッサを備え、前記要求メッセージはドメイン・ネーム・システム・クエリを含み、前記ドメイン・ネーム・システム・クエリは完全修飾ドメイン名に符号化された前記端末の識別子を含むことを特徴とする端末。
請求項22
請求項１乃至１３の何れか１項に記載の方法を実行するように装置を制御するためのプログラム。