A method and apparatus for network resources to pool |
|||||||
| 申请号 | JP2010543390 | 申请日 | 2008-01-23 | 公开(公告)号 | JP5323861B2 | 公开(公告)日 | 2013-10-23 |
| 申请人 | テレフオンアクチーボラゲット エル エム エリクソン(パブル); | 发明人 | アッティラ ミハーリー，; ガーボル トース，; ラース ウェストベリ，; | ||||
| 摘要 | A method and apparatus for selecting a network resource from a plurality of network resources in a communications network. A selection node receives a request for a network resource from a terminal, and then retrieves, from at least one further network node, data relating to the plurality of network resources. On the basis of the retrieved data, the selection node selects a network resource from the plurality of network resources. A response is then sent to the terminal, the response including information identifying the selected network resource. | ||||||
| 权利要求 | 通信ネットワーク内の複数のネットワーク・リソースからネットワーク・リソースを選択するための方法であって、 選択ノードにおいて、ネットワーク・リソースを求める要求を端末から受信する工程と、 動的に更新されるデータベースから前記複数のネットワーク・リソースのそれぞれの状態及び能力に関するデータを読み出す工程と、 ホーム加入者サーバからユーザ又は前記端末に関する加入契約情報を読み出す工程と、 前記読み出されたデータ と前記読み出された加入契約情報とに基づいて、前記複数のネットワーク・リソースからネットワーク・リソースを選択する工程と、 前記選択されたネットワーク・リソースを識別する情報を含む応答を前記端末へ送信する工程とを有 し、 前記加入契約情報は、容量、速度及びモビリティに関する制限を含み、前記複数のネットワーク・リソースは当該制限に基づいて絞り込まれることを特徴とする方法。 前記読み出されたデータは、前記ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、前記端末と前記ネットワーク・リソースとの間の経路に関する前記ネットワークの現在の容量とのうちの何れかを含むことを特徴とする請求項１に記載の方法。 ドメイン・ネーム・サーバから前記複数のネットワーク・リソースのそれぞれについてのアドレスを読み出す工程をさらに有することを特徴とする請求項１又は２に記載の方法。 前記要求及び前記応答はドメイン・ネーム・システム・メッセージであることを特徴とする請求項１乃至 ３の何れか１項に記載の方法。 ネットワーク・リソースを選択する際に、到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを前記複数のネットワーク・リソースから減らす工程をさらに有することを特徴とする請求項１乃至 ４の何れか１項に記載の方法。 通信ネットワークで用いられる選択ノードであって、 ネットワーク・リソースを求める要求を端末から受信するための受信器と、 動的に更新されるデータベースから複数のネットワーク・リソースのそれぞれの状態及び能力に関するデータを読み出すための手段と、 ホーム加入者サーバからユーザ又は前記端末に関する加入契約情報を読み出すための手段と、 前記読み出されたデータ と前記読み出された加入契約情報とに基づいて複数のネットワーク・リソースからネットワーク・リソースを選択するための手段と、 前記選択されたネットワーク・リソースを識別する情報を含むメッセージを前記端末へ送信するための送信器とを備え 、 前記加入契約情報は、容量、速度及びモビリティに関する制限を含み、前記複数のネットワーク・リソースは当該制限に基づいて絞り込まれることを特徴とする選択ノード。 前記データを読み出すための手段は、複数のネットワーク・ノードからデータを読み出すための手段を備えることを特徴とする請求項 ６に記載の選択ノード。 前記ネットワーク・リソースはサーバ機能又はゲートウェイ機能の一方から選択されることを特徴とする請求項 ６又は７に記載の選択ノード。 前記読み出されたデータは、前記ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、前記端末と前記ネットワーク・リソースとの間の経路に関する前記ネットワークの現在の容量とのうちの何れかから選択された情報を含むことを特徴とする請求項 ６乃至８の何れか１項に記載の選択ノード。 前記読み出されたデータは、 前記複数のネットワーク・リソースのそれぞれの前記ネットワーク上の位置と、 前記複数のネットワーク・リソースのそれぞれについての経路情報と、 前記複数のネットワーク・リソースのそれぞれに関する現在の負荷と、 前記複数のネットワーク・リソースのそれぞれの現在の容量と、 前記端末と前記複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、 前記複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、 前記複数のネットワーク・リソースのそれぞれから利用可能なサービスと 、 事業者ポリシー情報とのうちの何れかから選択された情報を含むことを特徴とする請求項 ６乃至９の何れか１項に記載の選択ノード。 到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを前記複数のネットワーク・リソースから減らすための手段をさらに備えることを特徴とする請求項 ６乃至１０の何れか１項に記載の選択ノード。 前記複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとるための手段をさらに備えることを特徴とする請求項 ６乃至１１の何れか１項に記載の選択ノード。 請求項１乃至 ５の何れか１項に記載の方法を実行するように装置を制御するためのプログラム。 |
||||||
| 说明书全文 | 本発明は通信ネットワークにおいて用いられる方法および装置に関し、特にプールされたサーバ・ノードまたはゲートウェイ・ノードを端末に割り当てるための方法および装置に関する。 汎欧州ディジタル移動電話方式（ＧＳＭ）および３Ｇのような通信ネットワークは、移動体端末（ＭＴ）が通信ネットワークにアクセスできるようにするとともに、サーバ・ノードがＭＴへサービスを提供できようにするようにゲートウェイ・ノードを使用する。 サーバ・ノードおよびゲートウェイ・ノードは、リソースの向上した可用性および良好な利用に加えて、プール・メンバ間の負荷分散およびバランスを可能とするように、しばしばネットワークに“プールされる”。 従来、プールはいずれも静的に構成され、静的プールはドメイン・ネーム・システム（ＤＮＳ）に基づきうる。 静的に構成されたプールは、所定のサービスのついての選択可能なサーバ／ゲートウェイ・ノードに関する静的な事前に構成された情報の概念に基づく。 この事前に構成された情報は、各ＭＴおよびこの情報を必要としうるその他のノードに記憶される。 ＭＴがサーバまたはゲートウェイを選択したい場合に、選択を行なうために選択アルゴリズムが用いられる。 静的に構成されたプールは、類似の機能を持つノード間の負荷分散と、向上した可用性と、大きな地理的領域における優れたトラヒック推定に起因する単純化されたノード規模とを提供する。 サーバおよびゲートウェイ・ノードの静的プールは現在の移動体システムで幅広く用いられている。 ３Ｇネットワークでは、Ｉｕフレックスを用いてサービングＧＰＲＳサポート・ノード（ＳＧＳＮ）および移動交換局（ＭＳＣ）がプールされる。 ＧＳＭネットワークでは、ＡフレックスとＧｂフレックスとを用いてこれらのノードがプールされる。 Ｉｕフレックスは３ＧＰＰではリリース５ ＴＳ ２３．２３６に説明されており、無線ネットワーク制御装置（ＲＮＣ）がＭＳＣのプールからＭＳＣを選択し、ＳＧＳＮのプールからＳＧＳＮを選択することを可能にする。 ＧＳＭにおいて同じ概念が用いられ、基地局制御装置（ＢＳＣ）は（Ａフレックスを用いて）ＭＳＣのプールからＭＳＣを選択できるとともに、（Ｇｂフレックスを用いて）ＳＧＳＮのプールからＳＧＳＮを選択できる。 アクセス・ネットワーク・ノードが選択されうるコア・ネットワーク・ノードの集合はプールまたはクラスタと呼ばれる。 Ｉｕ／Ａ／Ｇｂフレックスを用いて、ＭＳＣのプールおよびＳＧＳＮのプールはサービス・エリアにサービスを提供してもよい。 この場合に、すべてのＲＮＣ（またはＧＳＭではＢＳＣ）はすべてのＭＳＣ／ＳＧＳＮに接続され、逆もまた同様である。 これらの接続は直接リンクを通して“物理的”であってもよいし、ＳＤＨ ＶＰまたはＡＴＭ ＰＶＣを通して“論理的”であってもよいし、ＩＰ接続を通して“仮想的”であってもよい。 プールのサービス・エリアは”プール・サービス・エリア”と称される。 移動局（ＭＳ）がプール・サービス・エリアへ登録またはローミングする場合に、ＭＳは負荷分散アルゴリズムに従って特定のＭＳＣ／ＳＧＳＮが割り当てられる。 ＭＳは、プールのその他のメンバの正体を知らず、ＭＳがプール・サービス・エリアに留まる間、選択されたＭＳＣまたはＳＧＳＮをすべての通信に対して使用する。 しかしながら、ＭＳがプール・サービス・エリアを離れ、その後に再登録する場合に、ＭＳが再登録する時点で、ネットワーク要求に従って異なるＭＳＣ／ＳＧＳＮが割り当てられるかもしれないことに留意されたい。 ＲＮＣおよびＢＳＣは構成されたテーブルに従ってメッセージをルーティングする。 ＭＳはノードが利用できないことをＲＮＤ／ＢＳＣへシグナリングでき、この場合にＲＮＣ／ＢＳＣはネットワークの負荷バランス要求に依存してＭＳのために異なるノードを選択してもよい。 静的に構成されたプールの別のタイプはＤＮＳベースのプールである。 この情報を必要としうる各ノードにプールを構成するのではなく、ＤＮＳサーバで構成が実行される。 ＭＳはＤＮＳサーバへＤＮＳクエリを送信し、ＤＮＳサーバはＭＳＣ／ＳＧＳＮプールのメンバを識別するＩＰアドレスのリストを返送する。 次いで、ＭＳは内部の選択アルゴリズムに基づいてリストから一つのアドレスを選択する。 この着想の改良版は、ＩＰアドレスのリストをＭＳへ送信する前に、ＤＮＳサーバが制限された選択を導入することである。 これらの例は“ソート・リスト”および“ラウンド・ロビン”である。 ソート・リストは、ＩＰアドレスのリスト内のアドレスの順番がクエリのソース・アドレスに基づいて整列されるというＤＮＳの機能である。 ラウンド・ロビンは、二つ以上のアドレス間のトラヒックをバランスさせるＤＮＳの機能である。 ラウンド・ロビンは、汎用パケット無線サービス（ＧＰＲＳ）ネットワークにおいて、複数のゲートウェイＧＰＲＳサポート・ノード（ＧＧＳＮ）間に負荷を分散するために用いられる。 ＤＮＳサーバでソート・リストを用いる不利な点は、ＤＮＳサーバからＤＮＳサーバへ情報が渡される場合に、当初の順番が常に維持されるという保証がないということである。 正しい順番が維持されることを保証するために、ネットワーク内のすべてのＤＮＳサーバでソート・リストが構成されなければならないが、これは大きなＤＮＳ解決策に対して著しい複雑さを付け加える。 いくつかの場合では、すべてのサーバにソート・リストを設定することは可能でないかもしれない。 ラウンド・ロビンはＤＮＳデータベースから取得した静的情報を用いて動作する。 ＤＮＳサーバが要求に応答する場合に、ノードの状態と実際の負荷は考慮されない。 ラウンド・ロビンは、権限のあるサーバから送信される応答の構造またはソート・リストの効果を上書きするかもしれない。 また、ＤＮＳプールは、いわゆるリソース・レコード（ＲＲ）の使用を通じてサービス固有の選択を可能にする。 ＩＥＴＦ ＲＦＣ １０３４／１０３５に記載される基本的なＤＮＳサーバでは、所定のホスト名についての複数の“アドレス”ＲＲ（Ａ ＲＲ）でプールが構成されうる。 ＤＮＳサーバがアドレスのリストを求める要求を受信する場合に、ＤＮＳサーバはクエリに整合するすべてのＲＲを返信する。 使用される一つを選択することはクライアントのタスクである。 更に拡張したサービス・ベースのプール解決策がＲＦＣ ２７８２で規定されており、ＳＲＶ ＲＲに対応したＤＮＳサーバについて記載する。 サービスについての複数の“サービス”リソース・レコード（ＳＲＶ ＲＲ）を用いてサーバ・プールが構成される。 また、ＲＲフォーマットは、ＰＲＩＯおよびＷＥＩＧＨＴパラメータを含む。 要求に対するＤＮＳサーバの応答は、優先度と重みの情報とを有するサーバのすべての取りうる選択を含み、受信した優先度および重みパラメータに基づく事前に定めたルールに基づいてＭＳがサーバ選択を行なうことを可能にする。 移動体ネットワークにおけるＤＮＳベースのプールの例はＧＧＳＮプールである。 ＭＳがネットワークへ登録される場合に、ＧＳＭおよび３Ｇネットワークにおける接続確立手順（ＰＤＰコンテキスト要求の活性化）の一部として、ＭＳが送信した要求におけるアクセス・ポイント名（ＡＰＮ）により識別されるパケット・データ・ネットワーク（ＰＤＮ）への接続を有するＧＧＳＮを見つけるため、ＳＧＳＮはＤＮＳクエリを送信する。 ＤＮＳサーバは、ＧＧＳＮノードのＩＰアドレスにＡＰＮ文字列をマッピングするデータベースを有する。 同一の外部のＰＤＮに複数のＧＧＳＮが接続されると、ＤＮＳサーバはＳＧＳＮへ送信される応答において複数のエントリを返信する。 ＳＧＳＮは、（一つ以上が返信されるなら）ＤＮＳ応答に含まれる最初のアドレスを選択し、ＧｎインタフェースでＰＤＰコンテキスト生成要求をＧＧＳＮノードへ送信する。 この手順により、（ＧＧＳＮプールであるとみなしうる）同一のＰＤＮに接続されるＧＧＳＮノード間の負荷分散を実装することが可能となる。 “ＧＧＳＮプール”の構成はＤＮＳでローカルに行われる。 ＤＮＳプールはある欠点を有する。 ＤＮＳプールは静的データベースを使用し、従って、ネットワーク・トポロジにおける変化のイベントで、影響を受けた各ノードが再構成されなければならない。 更に、ＤＮＳサーバはＡＰＮに関連付けられたアドレスの状態を知る方法を何も有していない。 ＤＮＳサーバはＧＧＳＮの状態に関係なくアドレスを返送する。 また、標準ＤＮＳサーバは、名前に関連付けられたすべてのアドレスを無作為に返送し、その結果、ＧＧＳＮ ＧＴＰ接続について非効率なルーティングを生じる。 ローカルＧＧＳＮが同一の外部のＰＤＮへのアクセスを提供できたとしても、ＤＮＳはもっと離れたＧＧＳＮへＳＧＳＮを向けるかもしれない。 ＧＰＲＳネットワークの規模および複雑性が増大するにつれて、インテリジェント・サービスが必要となるだろう。 これらの課題の一部に対処するために、図１に示されるような解決策が開発されてきた。 図１に示される解決策は、移動体ネットワークにおけるキー情報を監視することと、ＤＮＳ応答を動的に変更することとを提供し、到達可能であり、ネットワーク・アーキテクチャの観点からより近くにあり、トラヒックをＰＤＮへルーティングできるＧＧＳＮ１０２、１０３、１０４にＳＧＳＮ１０１を向ける。 特長として以下のことを含む。 １． ＧＧＳＮ１０２、１０３、１０４がＧｎネットワークを介して到達可能かどうかをチェックする状態監視は、トラヒックがＧＧＳＮを通してＧｉインタフェースでＰＤＮへ流れ、ＧＴＰトンネルが確立された後は逆方向に流れることができることを保証し、アドレスを割り当てるために認証のためのＲＡＤＩＵＳまたはＤＨＣＰのような外部サービスをＧＧＳＮ１０２、１０３、１０４が用いる場合に、これらのサービスの状態が監視されて報告される。 ２． 各ＧＧＳＮ１０２、１０３、１０４についての接続数の最適化を可能にする負荷監視。 ＧＧＳＮ１０２、１０３、１０４は異なる容量を有してもよい。 ラウンド・ロビンのようなＤＮＳ負荷バランス技術はＰＤＰコンテキストを均等に分配し、これにより、より低い容量のＧＧＳＮが過負荷になる結果となりうる。 ＧＧＳＮ１０２、１０３、１０４の異なる容量を反映するようにサーバで負荷の値が事前に構成されるか、または、ＣＰＵ使用率、パケット・スループット、接続数等のような属性について各ＧＧＳＮ１０２、１０３、１０４をポーリングすることによって負荷情報が監視される。 実際の監視技術は、ネットワークごとおよびオペレータごとに異なってもよい。 ＩＣＭＰ ＥＣＨＯ、ＳＮＭＰを用いるアクティブ監視は状態および負荷を得るか、状態および負荷を報告するためにＧＴＰプローブが用いられうる。 ＲＡＤＩＵＳのようなサービスの監視が必要となる状況について、ＲＡＤＩＵＳプロトコルを利用するインテリジェント・モニタが用いられうる。 これらの更に高度なモニタを用いて、サービスが稼動していることを検証し、移動体ネットワークが要求するタスクをサービスが実行しているかいないかを判定できる。 アクティブ監視により望まないネットワーク・トラヒックが負荷される状況では、関連するメッセージを求めてトラヒックをリッスンすることによってネットワークの状態を評価するためにパッシブ監視が用いられる。 このようなメッセージは経路広告、キープ・アライブ・メッセージ、ＳＮＭＰトラップ等を含む。 ＧＴＰ ＶＩＰのようなキーＩＰアドレスを求めて、例えばＯＳＰＦ、ＲＩＰまたはＢＧＰ経路告知が監視されうる。 これらのアドレスの一つに対する経路が到達不能であると判定された場合に、ＤＮＳサーバが通知を受ける。 フィルタリング・ルールと状態・負荷情報とを組み合わせることによって、ＧＧＳＮ１０２、１０３、１０４の最適リストがＳＧＳＮ１０１へ送信される。 以下のように、三つの主なタイプのトラヒック動作が移動体ネットワークに適用される。 システム・アーキテクチャ・エボリューション（ＳＡＥ）またはロング・ターム・エボリューション（ＬＴＥ）と呼ばれる将来の移動体ネットワークのシステム・アーキテクチャが現在開発中である（３ＧＰＰ ＴＳ ２３．４０１（Ｓ２−０７０５９１） Ｖ０．２．１、“３ＧＰＰ Ｓｙｓｔｅｍ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｅｖｏｌｕｔｉｏｎ：ＧＰＲＳ ｅｎｈａｎｃｅｍｅｎｔｓ ｆｏｒ ＬＴＥ ａｃｃｅｓｓ；Ｒｅｉｅａｓｅ ８”を参照）。 提案されたアーキテクチャが概略的に図２に示される。 このアーキテクチャの集中方式によるコア・ノードは、物理的に分離したユーザ・プレーンおよび制御プレーン（即ち、分割アーキテクチャ）を有しうる。 分割アーキテクチャ・モデルでは、以下のエンティティが定義される。 サービングＳＡＥＧＷ２０２機能は、 ＰＤＮ ＳＡＥＧＷ機能は、 インタフェースＳ１は、ユーザ・プレーン・トラヒックおよび制御プレーン・トラヒックのトランスポートのための発展型ＲＡＮの無線リソースへのアクセスを提供し、Ｓ１＿ＭＭＥ２０４とＳ１＿Ｕ２０５とを含む。 Ｓ１参照点は、ＭＭＥとＳＡＥＧＷとの分離を可能にするとともに、組み合わされたＭＭＥ２０１とサービングＳＡＥＧＷ２０２の解決策の配置も可能にする。 プールの概念は、容量を低減するため、信頼性を増強するためおよび簡素化された計画を可能にするため、コア・ネットワーク・ノード（ＭＭＥ２０１およびＳＡＥＧＷ２０２、２０３）についてＳＡＥ／ＬＴＥ文書に述べられている。 ＭＭＥプールは、ノードＢが複数のＭＭＥをあたかもそれらが単一の論理エンティティであるかのように処理できる機構である。 ＭＴがサービスを要求する場合に、ある機構が物理ＭＭＥノードのうちの一つを選択し、選択されたＭＭＥにＭＴをバインドする。 ユーザ・プレーン・ノードについて同様なプール概念が規定される。 例えば、ＭＴがネットワークに登録される場合に、プールからサービング／ＰＤＮ ＳＡＥＧＷ２０２，２０３の所定のペアを選択することはＭＭＥ（またはその他の制御プレーン・エンティティ）のタスクであり、従って、ＭＴ（およびノードＢ）は同一プール内のＳＡＥＧＷ間の相違を見ない。 ユーザ・プレーン（ＳＡＥＧＷ）のプール・エリアと制御プレーン（ＭＭＥ）のプール・エリアとは、必ずしも同じである必要はなく、次の何れかによって影響を受けうる。 様々なネットワーク事業者が、自身のネットワーク規模、（例えば、地域管理による）接続制限、モビリティ・パターン等に依存して、ＭＭＥ／ＳＡＥＧＷプール設計について様々なシナリオを選択するだろうということはありそうである。 プール／選択のための取り得るＳＡＥアーキテクチャは、プール選択のすべての相異なる可能性に対処できるべきである。 静的プールが有する主な問題は、複数のノードでプールが構成されなければならないということである。 従って、プールの詳細を維持することは、著しい量の構成作業を必要とする。 例えば、ネットワークが拡張される場合に、既存のプールの再設計を必要とするかもしれず、それ故、新規導入のホストのみならず、既存のものについての再構成を必要とするかもしれない。 同様に、トポロジ、サービス・ネットワーク等における変更も再構成を必要とする。 静的およびＤＮＳベースのプール解決策の共通の問題は、サーバが利用できないことやネットワーク・トポロジの変更のような動的なネットワーク変更について利用可能な情報に欠けることである。 図１に示された解決策は部分的にその問題を解決するが、いまだ多くの不備を示す。 発明者らは、サーバおよびゲートウェイのようなネットワーク・リソースについてのプール情報を静的に提供することに内在する課題および制限について明確に理解した。 本発明の第１の側面によれば、通信ネットワーク内の複数のネットワーク・リソースからネットワーク・リソースを選択するための方法が提供される。 選択ノードは、ネットワーク・リソースを求める要求を端末から受信し、次いで少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出す。 読み出されたデータに基づいて、選択ノードは複数のネットワーク・リソースからネットワーク・リソースを選択する。 次いで、選択されたネットワーク・リソースを識別する情報を含む応答が端末へ送信される。 ネットワーク・リソースの集中方式による選択は多くの相異なるネットワーク・ノード内に選択機能を構成する必要性を低減し、プールされたネットワーク・リソースを用いる効率を向上する。 オプションとして、ネットワーク・リソースはサーバ機能又はゲートウェイ機能の一方から選択される。 複数のネットワーク・リソースに関するデータはオプションとして少なくとも一つのデータベースから読み出される。 このデータは複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含む。 これにより、選択ノードが各ネットワーク・リソースの能力に基づいて選択を行い、端末について最適なネットワーク・リソースを選択することが可能となる。 ネットワーク・リソースに関する最新の情報及びそれらの可用性を選択ノードが受信することを保証するために、データベースはオプションとして複数のネットワーク・リソースのぞれぞれの能力及び状態が変わるにつれて更新される。 さらなるオプションとして、複数のネットワーク・リソースに関するデータは、ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、端末とネットワーク・リソースとの間の経路に関するネットワークの現在の容量とのうちの何れかである。 この種の情報はデータベースへ頼ることなく取得されえ、選択ノードに現在のネットワーク状況に関する情報を与える。 オプションとして、本方法はドメイン・ネーム・サーバから複数のネットワーク・リソースのそれぞれについてのアドレスを読み出すことを含む。 オプションとして、本方法はホーム加入者サーバからユーザ又は端末に関する加入契約及びサービス情報を読み出すことを含む。 これにより、ユーザの加入契約又は端末の能力に基づいてネットワーク・リソースが選択されることが可能となる。 要求及び応答はオプションとしてドメイン・ネーム・システム・メッセージである。 これにより、本発明は既存のネットワークに容易に統合されることが可能となる。 読み出されたデータはオプションとして、 ネットワーク・リソースを選択する際に、本方法はオプションとして、到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを複数のネットワーク・リソースから減らすことを含む。 このようにして、利用不可能な又は不適切なネットワーク・リソースは端末へ送信されない。 ネットワーク・リソースを選択する際に、本方法はオプションとして、複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとることを含む。 これは、ネットワーク・リソースがより効率的に用いられることを保証し、一つのネットワーク・リソースが過負荷になりつつ、別のものが十分に利用されないリスクを低減する。 オプションとして、端末エンティティへの応答はネットワーク・リソースのＩＰアドレスを含む。 通信ネットワークはオプションとしてシステム・アーキテクチャ・エボリューション・ネットワーク及びＩＰマルチメディア・サブシステム・ネットワークから選択される。 本発明の第２の側面によれば、通信ネットワークで用いられる選択ノードが提供される。 選択ノードはネットワーク・リソースを求める要求を端末から受信するための受信器と、少なくとも一つの更なるネットワーク・ノードから複数のネットワーク・リソースに関するデータを読み出すための手段とを備える。 選択ノードはさらに、読み出されたデータに基づいて複数のネットワーク・リソースからネットワーク・リソースを選択するための手段と、選択されたネットワーク・リソースを識別する情報を含むメッセージを端末へ送信するための送信器とを備える。 選択ノードは多くの相異なるネットワーク・ノードに選択機能を構成する必要性を低減し、プールされたネットワーク・リソースを使用する効率を向上する。 オプションとして、様々なソースからの情報が選択処理に関連するかもしれないため、データを読み出すための手段は、複数のネットワーク・ノードからデータを読み出すための手段を備える。 ネットワーク・リソースはオプションとしてサーバ機能又はゲートウェイ機能の一方から選択される。 オプションとして、複数のネットワーク・リソースに関するデータを読み出すための手段は、少なくとも一つのデータベースからデータを読み出すための手段を含み、データは複数のネットワーク・リソースのそれぞれの状態及び能力に関する情報を含む。 さらなるオプションとして、複数のネットワーク・リソースに関するデータを読み出すための手段は、ネットワーク内の各ネットワーク・リソースのトポロジと、各ネットワーク・リソースに関する現在の負荷と、端末とネットワーク・リソースとの間の経路に関するネットワークの現在の容量とのうちの何れかを読み出すための手段を備える。 このようにして現在のネットワーク状況とネットワーク・リソースに関して記憶された情報とを選択ノードに知らせる情報が取得されうる。 読み出されたデータはオプションとして、複数のネットワーク・リソースのそれぞれのネットワーク上の位置と、複数のネットワーク・リソースのそれぞれについての経路情報と、複数のネットワーク・リソースのそれぞれに関する現在の負荷と、複数のネットワーク・リソースのそれぞれの現在の容量と、端末と複数のネットワーク・リソースのそれぞれとの間の経路に関する現在のネットワーク容量と、複数のネットワーク・リソースのそれぞれに関するセキュリティ情報と、複数のネットワーク・リソースのそれぞれから利用可能なサービスと、ユーザ又は端末に関する加入契約情報と、事業者ポリシー情報とのうちの何れかから選択された情報を含む。 不適切な又は利用不可能なネットワーク・リソースが選択されることを防ぐために、選択ノードはオプションとして到達可能性又は利用可能なサービスの要件を満たさないネットワーク・リソースを複数のネットワーク・リソースから減らすための手段をさらに備える。 ネットワーク・リソースが過負荷となるリスク又は十分に使用されないリスクを低減するために、選択ノードはオプションとして複数のネットワーク・リソースのネットワーク・リソースに関する負荷のバランスをとるための手段をさらに備える。 本発明の第３の側面によれば、通信ネットワークで用いられる端末が提供される。 本端末は、ネットワーク・リソースを求める要求メッセージを生成するためのプロセッサを備え、要求メッセージはドメイン・ネーム・システム・クエリを含み、ドメイン・ネーム・システム・クエリは完全修飾ドメイン名に符号化された端末の識別子を含む。 ＤＮＳクエリの形式で要求メッセージを送信することによって、メッセージは直接にＤＮＳサーバへ転送されえ、様々なネットワーク・ノードでメッセージを処理するために必要となる処理を低減する。 さらに、端末の識別子をＦＱＤＮに符号化することによって、端末に代わって通信するホストからのシグナリングを選択機能が受信する場合であっても、選択機能によって本端末が識別されうる。 以下の記載は説明を目的とし制限を目的ではなく特定の実施形態、手順、技術等のような個別の詳細について説明する。 ある場合には、不必要な詳細さで説明を不明瞭にしないように、周知の方法、インタフェース、回路およびデバイスの詳細な説明が省略される。 さらに、幾つかの図において個別のブロックが示される。 個別のハードウエア回路を用いて、適切にプログラムされたデジタル・マイクロプロセッサまたは汎用コンピュータと連動するソフトウエア・プログラムとデータとを用いて、特定用途向け集積回路を用いて、および／または一つ以上のデジタル・シグナル・プロセッサを用いて、これらのブロックの機能が実装されてもよいことが理解されるだろう。 以下の記載は、ＳＡＥ／ＬＴＥシステムにおける拡張されたゲートウェイ／サーバ選択概念を開示する。 しかしながら、本概念は、その他のタイプのネットワークで用いられてもよいことが理解されるだろう。 本概念により、通信ホストのために複数のネットワーク・リソースから最適なサーバまたはゲートウェイが自動的に選択されることが可能となる。 図３は本発明の実施形態によるネットワークのハイレベル・アーキテクチャを示す。 サーバまたはゲートウェイを求めるＤＮＳ要求３０２をリクエスタ３０３から受信する選択ロジック機能３０１が提供される。 リクエスタ３０３と通信のためにサーバ／ゲートウェイのＩＰアドレスを必要とするＩＰホストとは同一エンティティでなくてもよいが、この場合に通信ホスト３０４を識別する情報は要求メッセージで伝達されることに留意されたい。 選択ロジック３０１は、状態（負荷および到達可能性）、能力、機能、トランスポート情報ならびに加入契約情報および最小サービス品質等のサービス固有の情報のような基準に基づいて、ホスト３０４のために最適なサーバ／ゲートウェイを選択し、（選択されたサーバ／ゲートウェイの）単一のＩＰアドレスをリクエスタ３０３に返信する（３０５）。 選択ロジック３０１は、選択に必要となる必須パラメータを推測（infer）するために複数のデータ・ソースから情報を取得できる。 これらのデータ・ソースは、所与のサービスのための取り得るサーバ／ゲートウェイのリストを読み出すためのＤＮＳ３０６と、加入契約とサービス関連情報とを読み出すためのホーム加入者サーバ（ＨＳＳ）３０７と、トポロジ情報だけでなくプール・メンバの状態／機能／能力情報のためのトポロジ・データベース３０８とを含む。 データ・ソースへのクエリはリクエスタ３０３からの要求により始動されてもよいが、選択ロジック３０１は応答時間を短縮するためにあらかじめ独立にクエリを起動してもよい。 トポロジ・データベース３０８は、データベース同期機能３０９により動的に更新される。 データベース同期機能３０９は以下の機能を有する。 図４は、ノードのサービス情報と、状態と、能力／機能とだけでなくトランスポート情報に基づいて、複数のサーバ／ゲートウェイのプールから最適なサーバ／ゲートウェイを選択するための例示の方法を示すフローチャートである。 下記のステップ番号は図４の番号を示す。 上記ステップの各々を順に取り上げて、最適なゲートウェイ／サーバを求める要求は、必要となる情報を交換できる任意のタイプの適切なシグナリングを用いる。 好ましい実施形態では、大部分のＩＰホストがＤＮＳをサポートし、それ故リクエスタ機能に対する影響が低いために、要求はＤＮＳクエリに基づく。 ゲートウェイ／サーバ要求のためにＤＮＳクエリが用いられると仮定して、サービス識別はクエリの完全修飾ドメイン名（ＦＱＤＮ）に符号化された文字列、例えば、＿ｉｎｅｔ． ｔｃｐ． ｅｘａｍｐｌｅ． ｎｅｔに基づき、ここで＿ｉｎｅｔは必要となるサービス、例えば、インターネット接続を示す。 選択のために必要となるホスト・パラメータはホストの位置である。 ホストがリクエスタ自身である場合に、これはリクエスタのＩＰアドレスから識別される。 しかしながら、ホストとリクエスタとが同じでないならば、ホスト識別子はＤＮＳクエリ・メッセージで転送される。 これは以下の何れかにより行われる。 ここでステップ４０３と４０４に戻って、サービスについてのサーバまたはゲートウェイのプールとプールのメンバのＩＰアドレスとが識別されなければならない。 好ましい実施形態では、サービスのためのプール識別は標準ＤＮＳ機能に基づき、従って、プールのためのデータ・ソースは標準ＤＮＳサーバである。 各サービスのための選択可能なノードのリストを有するＤＮＳサーバの構成はネットワーク管理システムによって実行される。 プール識別は、以下のステップを備える。 好ましい実施形態では、最初の要求はＤＮＳクエリの型式である。 そのため、元もとの要求をほとんどまたは全く変更することなしに、選択ロジック３０１はＤＮＳサーバ３０６へ要求を転送してもよい。 また、ＤＮＳサーバからの回答から最適なエントリを除去し、それをリクエスタに転送することがより速くなる。 サーバまたはゲートウェイのプールを選択する処理が図５に示される。 ここでステップ４０５に戻って、トポロジ情報だけでなくプール・メンバの状態、能力および機能が識別される。 上記の情報に対するデータ・ソースは、動的に更新されるトポロジ・データベース３０８であり、図６に提案されるシステム・アーキテクチャが概略的に示される。 選択ロジック３０１は最も近いサーバ／ゲートウェイと、トランスポート容量と、ノード状態／負荷情報等とを見つけるために、トポロジ・データベース３０８を参照する。 トポロジ・データベース３０８は、選択ロジック３０１と同じボックスに構築されてもよいが、代わりに別個のノードであってもよい標準のリレーショナル・データベースでありうる。 データベース３０８の初期構成は、移動体ネットワークのＯ＆Ｍシステムのような管理システムによって行われてもよい。 トポロジ・データベース３０８を更新された状態に保つために、本発明の好ましい実施形態では、図６に示されるように、データベース同期機能３０９が提供される。 データベース同期機能３０９は以下のような主な機能を有する。 端末登録の間、複数の関連するＳＡＥ−ＧＷシナリオが可能である。 以下は、同じ位置のサービングＳＡＥＧＷおよびＰＤＮ ＳＡＥＧＷを仮定し、これらのシナリオの各々に関連する選択に重要なパラメータの例を提供する。 ＩＭＳシナリオでは、ローカル・スイッチングを有する最短経路を実現するために、“最も近い”ＧＷサイトにアンカ・ポイントが選択されなければならず、従って、サイト位置はアンカ・ポイント選択に必要となる。 ネットワーク冗長シナリオでは、ＧＷ選択は、“立ち上がって稼動している（up-and-running）”ＧＷ集合に基づく。 欠陥のあるＧＷはブロックされて、プールで用いられてはならない。 また、“立ち上がって稼動している”情報はアンカ・ポイントの選択で必要となり、負荷情報はノード容量の利用を最適化してもよく、従って、また、アンカ・ポイント選択に負荷情報が含まれうる。 モビリティ固有のＧＷ／ＳＡＥＧＷシナリオでは、問題は、例えばＭＩＰを扱う能力を有するＧＷが用いられることを保証するため、能力に基づいてＧＷが再選択されることである。 この場合に、アンカ・ポイント選択においてモビリティ・タイプが用いられる。 企業シナリオでは、セルラ・ネットワークのアウトドアのｅノードＢでインドアのネットワークがカバーされるアウト・ドア・インのシナリオの状況で、事業者バックボーンを介して企業トラヒックがルーティングされ、従って、ＩＰＳｅｃトンネルが必要となる。 企業ネットワーク・シナリオにおけるＧＷ／ＬＴＥでは、ｅノードＢとＧＷとを有するインドア・ネットワークがＬＡＮに接続される。 従って、ネットワーク内にローカル・スイッチングが存在し、そのためＩＰＳｅｃトンネルは必要ないが、もしトラヒックが事業者ネットワークを介して企業ネットワークへルーティングされるならば、ＩＰＳｅｃトンネルが必要となる。 これらのシナリオでは、アンカ・ポイントの選択において、企業ネットワークに接続するＧＷ／ＳＡＥＧＷおよびＩＰＳｅｃ能力を有するＧＷが用いられるべきである。 さらに、ある環境では、アンカ・ポイントの選択において企業ＧＷが用いられるべきである。 インターネットがトランスポート・ネットワークとして用いられる場合に、ＩＰＳｅｃおよびサービス妨害（ＤｏＳ）耐性のあるＧＷが必要となり、“緩和された”ＱｏＳ要件を有するトラヒックのみが送信されるべきである。 インターネット・トラヒックがインターネットへ直接に転送される場合に、アンカ・ポイントの選択において“インターネット・ピアリング”パラメータに最も近いＧＷが用いられるべきである。 さらに、ＤｏＳ耐性のあるＧＷが必要となり、特定のＱｏＳ情報に適合するＧＷが選択されてもよい。 サービス固有のＧＷシナリオでは、すべてのサービスに対して一つのＧＷが提供される。 サービスのタイプに基づいてアンカ・ポイントが選択され、それ故、アンカ・ポイントの選択においてサイト位置とサービス情報とが用いられる。 モビリティ・シナリオでは、ユーザの位置変更に基づいて、ＭＭＥはＧＷの再選択を強制する。 ＧＷの再選択は、プール内またはプール間のいずれかで可能である。 このシナリオでは、アンカ・ポイントの選択において、トポロジ（サイト位置）情報が必要となる。 上述の場合から、ＳＡＥ ＧＷの選択について、以下のパラメータ集合が導出されうる。 最適なプール要素を選択するために、個別の選択アルゴリズムが選択ロジックで必要となる。 選択アルゴリズムは典型的には制御プレーン（サーバ）またはユーザ・プレーン（ゲートウェイ）の要素選択で異なり、そのため、ＣＰサーバについての現在のアルゴリズムはゲートウェイに直接に適用できないかもしれない。 トランスポート・トポロジの近さは、より良好な特性と効率的なトランスポート利用を提供するが、同時にノードが過負荷から保護されないため、しばしば、ＧＷノードの選択についてより重要な要因である。 プールから要素を選択する一つの方法は、以下のように、負荷と最小コストとに基づく。 また、ユーザ加入契約に基づいてプールから要素が選択されてもよい。 この場合に、ＨＳＳのようなユーザ加入契約を扱うノードから加入契約情報が読み出されうる。 これにより、高度なプールの使用が可能になり、その例を以下に示す。 上記の例では、以下の選択アルゴリズムが適用可能である。 プールから要素が選択されると、ＤＮＳ回答において選択ロジックにより選択された要素のＩＰアドレスが返信される。 本提案によれば、ＤＮＳ回答は常に単一のＩＰアドレスを含むだろう。 図７に、ＳＡＥネットワーク・アーキテクチャにおける端末登録の例が示される。 制御プレーンとユーザ・プレーンとについての分割アーキテクチャが仮定され、２種類のＳＡＥＧＷが、ＳＡＥＧＷと呼ばれる同一の物理ノードに存在すると仮定する。 しかしながら、ＳＡＥＧＷは分離したサービングおよびＰＤＮのＳＡＥＧＷを代替として備えてもよいことに留意されたい。 端末７０１がネットワークに登録される場合に、以下のタスクが実行される。 図８に、提案されるアーキテクチャに基づく選択を含む端末７０１の登録のためのシグナリング・シーケンス図が示され、以下のステップを含む。 端末７０１がＳＡＥＧＷ３１４に割り当てられると、サービス領域でサービス稼動中に、ＣＳＣＦ９０２によるアプリケーション・サーバ（ＡＳ）の選択またはＡＳ９０１によるメディア・サーバ（ＭＳ）９０３の選択のような、制御プレーン・サーバ選択およびユーザ・プレーン・サーバ選択の両方を含むその他の選択タスクが可能である。 図９はマルチメディア・サービスの選択を示すシーケンス図であり、以下のステップを含む。 本発明は、上述の場合に限定されず、ＳＡＥにおけるその他の取り得る選択シナリオで用いられてもよい。 一つの例は、移動体端末アイドル状態のＳＡＥＧＷ再配置に対するサポートである。 例えば、移動体ユーザについてＳ１経路最適化を達成するため、幾つかの状況では、ＳＡＥＧＷを再選択することは有用でありうる。 ＳＡＥＧＷプールの規模が小さいなら、Ｓ１経路はあまり大きくないかもしれないが、他方、ユーザ・モビリティは、しばしばＳＡＥＧＷ再配置の原因になり得るであろうが、これは進行中のセッションに影響を与えるかもしれず、乏しい制御リソースを消費するかもしれない。 アイドル端末および利用可能な制御リソースの場合に、ＳＡＥＧＷを選択することによって、ＳＡＥＧＷ再配置をサポートすることは望ましいだろう。 また、選択ロジックは、適切なローカルＰＤＮ ＳＡＥＧＷの選択において、最適化されたネットワーク利用（ローカル・ブレイクアウト）のため、ローミング中のユーザにＩＰ ＰＯＰとして助けるかもしれない。 図１０を参照すると、選択ロジック機能ノード３０１が示される。 上記で説明したように、ＤＮＳサーバ、ＨＳＳおよびトポロジ・データベースのようなその他のリソースからの情報を読み出す手段１００２とともに、ゲートウェイまたはサーバを求めるＤＮＳ要求を受信する手段１００１が提供される。 ゲートウェイまたはサーバの選択を行うようにプロセッサ１００３が提供され、リクエスタへ応答メッセージを送信するための送信器１００４が提供される。 サーバまたはゲートウェイが選択された記録を保持するためのデータベース１００５が提供されてもよい。 図１１を参照すると、本発明の実施形態による端末が示される。 端末３０４は、サーバまたはゲートウェイのようなネットワーク・リソースを要求するＤＮＳクエリを生成するためのプロセッサ１１０１を有する。 ＤＮＳクエリは、完全修飾ドメイン名に符号化された必要となるネットワーク・リソースのタイプを含む。 端末はまた、クエリを送信する送信器１１０２と、クエリへの応答を受信する受信器１１０３とを有する。 本発明は、異なる制御ノードに実装されて構成される選択ロジックを有する代わりに、要素のプールから要素を選択するための共通アーキテクチャ（単一の集中管理ロジック）を提供する。 これは、ネットワーク内のゲートウェイまたはサーバのプールからの選択を担当するかもしれない異なる論理ノードすべてにおいて選択に関する機能を実装して構成する必要がないため、資金および運営費を低減する。 集中型の選択がより良いサポートを与える多くのユースケース（ネットワーク拡張、保守等）において、運営費の削減は特に明白である。 本発明の別の利点は、標準のＤＮＳクエリに基づいており、それゆえ既存のノード機能およびシグナリング・チェーンに大幅な変更を必要としない点である。 大抵の場合に、すべてのＩＰホストはＤＮＳをサポートする。 ＤＮＳベースの選択に比較して、本発明は、以下のことを提供するトポロジ・データベースを用いることによって、十分にトポロジを認識した選択を可能にする。 アーキテクチャ上の拡張により、ＤＮＳリクエスタおよび通信ホストが同じでない（例えば、ＭＭＥによる新たに登録されたＭＴのためのＳＡＥＧＷ選択）場合に対して、ＤＮＳベースの選択を実装することが可能となる。 さらに、オペークＬＳＡを介して、トポロジ・データベース内のノード能力、状態および機能関連情報の動的知識により、所与のサービスに対してプール構成の自動管理が提供される。 プラグ・アンド・プレイ、ネットワーク障害またはネットワーク・アップグレードのような多くの重要なシナリオがサポートされてもよい。 様々な実施形態が示され詳細に説明されたが、特許請求の範囲はどの特定の実施形態または例にも限定されない。 任意の特定の要素、ステップまたは機能が必須であり特許請求の範囲に含まれなければならないということを意味するように、上記の説明が読まれるべきでない。 特許対象の範囲は特許請求の範囲によって規定される。 この明細書において以下の略語が用いられる。 |
||||||
