IPマルチメディアサブシステム、IMSにおいて、ネットワークにおけるデータトラフィック負荷分散を決定するための方法であって、前記ネットワークが、クライアント送信元ノードと、少なくとも2つのサーバ宛先ノードとを含み、前記少なくとも2つのサーバ宛先ノードが、データ送信要求を処理するための異なるキャパシティを有し、前記方法が、-前記クライアント送信元ノードが、クライアント-サーバプロトコルに従って、前記ネットワークを介して前記少なくとも2つのサーバ宛先ノードにデータ送信の要求を送るステップと、-前記少なくとも2つのサーバ宛先ノードのそれぞれが、前記要求に応答して、その実際のキャパシティの状況に関する表示を送信するステップと、-前記クライアント送信元ノードが、前記サーバ宛先ノードにおける前記データトラフィックの負荷分散を決定するために前記状況表示を利用するステップとを含む、方法。実際のキャパシティの状況に関する前記表示が、使用されているキャパシティの量または空いているキャパシティの量を表す、請求項1に記載のトラフィック負荷分散を決定するための方法。実際のキャパシティの状況が、少なくともメモリおよび/または処理時間を考慮して決定される、請求項1または2に記載のトラフィック負荷分散を決定するための方法。前記ネットワークが、前記クライアント送信元ノードと前記サーバ宛先ノードとの間の接続を確立するためのプロキシノードをさらに含む、請求項1から3のいずれかに記載のトラフィック負荷分散を決定するための方法。IPマルチメディアサブシステム、IMSにおいて、ネットワーク内で使用するためのインターフェースデバイスであって、前記ネットワークが、クライアント送信元ノードと、少なくとも2つのサーバ宛先ノードとを含み、前記少なくとも2つのサーバ宛先ノードが、データ送信要求を処理するための異なるキャパシティを有し、前記インターフェースデバイスが、-前記少なくとも2つのサーバ宛先ノードからその実際のキャパシティの状況の表示を受信するための受信手段と、-受信された状況表示に基づいて、前記宛先ノードにおける負荷分散を決定するための処理手段と、-決定された負荷分散を前記クライアント送信元ノードに通信するための通信手段とを含む、インターフェースデバイス。前記処理手段が、ロードバランシングアルゴリズムを実行するように構成され、前記状況表示が、重み付け係数として使用される、請求項5に記載のインターフェースデバイス。前記受信された状況表示を記憶するための記憶手段をさらに含む、請求項5および6のいずれかに記載のインターフェースデバイス。RADIUSまたはDiameterプロトコルに従って動作するように構成される、請求項5から7のいずれかに記載のインターフェースデバイス。IPマルチメディアサブシステム、IMSにおいて、請求項5から8のいずれかに記載のインターフェースデバイスを含む、ネットワーク内で使用するためのクライアント送信元ノード。本発明は、キャパシティが異なるノードを含む構成においてロードバランシングを使用するときに適用することができ、従来技術の解決策の制限が克服される方法およびデバイスを提供することを目的とする。本発明は、IPマルチメディアサブシステムIMSにおいて、ネットワークにおけるデータトラフィック負荷分散を決定するための適応方法に関する。ネットワークは、クライアント送信元ノードと、少なくとも2つのサーバ宛先ノードとを含み、少なくとも2つのサーバ宛先ノードは、データ送信要求を処理するための異なるキャパシティを有する。この方法は、-クライアント送信元ノードが、クライアント-サーバプロトコルに従って、ネットワークを介して少なくとも2つのサーバ宛先ノードにデータ送信の要求を送るステップと、-少なくとも2つのサーバ宛先ノードのそれぞれが、要求に応答して、その実際のキャパシティの状況に関する表示を送信するステップと、-クライアント送信元ノードが、サーバ宛先ノードにおけるデータトラフィックの負荷分散を決定するために前記状況表示を利用するステップとを含む。実際に、提案された解決策は本発明の目的を達成する。クライアントノードがデータトラフィックを送信するためのリソースを要求するたびに、サーバ宛先ノードはその実際の状況の表示、例えば、使用中であるまたは空いているその利用可能な最大キャパシティの割合を提供する。次いで、サーバノードから来る情報から、リソースを要求したクライアントノードによって、次のデータトラフィック送信を考慮して、どのように負荷を平衡化させるかが決定され得る。この決定は、クライアントノードによって要求されたデータ送信にどのサーバノードを使用するかを示す。好ましい実施形態では、実際のキャパシティの状況に関する表示は、使用されているキャパシティの量または空いているキャパシティの量を表す。実際のキャパシティの状況は、有利には、少なくともメモリサイズ、CPU処理時間またはこれらのパラメータの組合せを考慮して決定される。別の実施形態では、ネットワークは、クライアント送信元ノードとサーバ宛先ノードとの間の接続を確立するためのプロキシノードをさらに含む。第2の態様では、本発明は、IPマルチメディアサブシステムIMSにおいて、ネットワーク内で使用するためのインターフェースデバイスに関し、ネットワークは、クライアント送信元ノードと、少なくとも2つのサーバ宛先ノードとを含み、少なくとも2つのサーバ宛先ノードは、データ送信要求を処理するための異なるキャパシティを有する。インターフェースデバイスは、-少なくとも2つのサーバ宛先ノードからその実際のキャパシティの状況の表示を受信するための受信手段と、-受信された状況表示に基づいて、宛先ノードにおける負荷分散を決定するための処理手段と、-決定された負荷分散をクライアント送信元ノードに通信するための通信手段とを含む。好ましくは、処理手段は、ロードバランシングアルゴリズムを実行するように構成され、状況表示は、重み付け係数として使用される。別の実施形態では、インターフェースデバイスは、受信された状況表示を記憶するための記憶手段をさらに含む。最も好ましい実施形態では、インターフェースデバイスは、RADIUSまたはDiameterプロトコルに従って動作するように構成される。また、本発明は、IPマルチメディアサブシステム、IMSにおいて、先に説明したインターフェースデバイスを含む、ネットワーク内で使用するためのクライアント送信元ノードに関する。本発明では、クライアント-サーバ構成で、ネットワークにおいてマルチメディアサービスを提供するためのIPマルチメディアサブシステムIMSが考慮される。サーバノードは全て、同じサーバキャパシティを有するわけではない。サーバキャパシティとは、CPU時間、メモリサイズ、CPUとメモリサイズの組合せ、いくつかのシステム測定値の組合せなどに関するキャパシティを意味する。この文脈におけるキャパシティは、将来の類似の要求を扱う能力の表示を与えるものである。最も好ましい実施形態では、クライアント-サーバ構成は、DiameterプロトコルまたはDiameterの前身であるRADIUSに従って動作するように構成される。RadiusRemoteAuthenticationDialInUserServiceは、ネットワークサービスに接続し、ネットワークサービスを使用するために、集中型の認証、認可、課金AAA管理をコンピュータに提供するネットワーキングプロトコルである。RADIUSプロトコルの広範なサポートおよびユビキタスな性質により、RADIUSプロトコルは、インターネットサービスプロバイダおよび企業によって、インターネットまたは内部ネットワーク、ワイヤレスネットワーク、および統合電子メールサービスへのアクセスを管理するために使用されることが多い。RADIUSは、UDPを伝送路として使用して、アプリケーションレイヤで動作するクライアント/サーバプロトコルである。RADIUSは、3つの機能、すなわち、ネットワークへのアクセスを許可する前にユーザまたはデバイスを認証すること、特定のネットワークサービスに対してこれらのユーザまたはデバイスを認可すること、およびこれらのサービスの使用に対して課金することを果たす。RADIUSは、リモートアクセス、IPモビリティおよびポリシー制御に効率的にうまく対処することができない。Diameterプロトコルは、RADIUSのためのアップグレード経路を提供する。Diameterは、認証者と認証を要求する任意のネットワークエンティティとの間の通信を制御する。Diameterプロトコルは、ポリシー、AAAおよびリソース制御を実行するためにクライアントによって使用されるポリシープロトコルを定義する。これにより、単一のサーバは、多くのサービスのポリシーを処理することができる。RADIUSとの相違点の1つは、Diameterプロトコルはより信頼性の高い伝送プロトコルTCPまたはSCTPを使用するということである。Diameterプロトコルは、やはり上記に説明した3GPPIPマルチメディアサブシステムIMSの発展によってさらに強化される。Diameterアプリケーションは、ソフトウェアアプリケーションではなく、Diameterベースのプロトコルに基づくプロトコルである。それぞれのアプリケーションはアプリケーション識別子によって定義され、新しいコマンドコードおよび/または新しい必須の属性-値の組Attribute-ValuePairsを追加することができる。新しい任意選択のAVPを追加するのに、新しいアプリケーションは必要ない。任意選択で、クライアント-サーバネットワークは、クライアントとサーバとの間に配置された1つまたは複数のプロキシノードをさらに含む。プロキシノードは典型的には、ルーティングタイプの機能および場合によってはバッファリングも実行するように構成される。Diameterプロキシは、Diameterベースのプロトコルrfc3588において定義される。プロキシノードを含むセットアップの例示は、図3に挙げられている。クライアントとサーバ-xとの間のリンクは、Diameterプロキシノードを介して確立される。通信は示された順序で行われる、すなわち、クライアントがプロキシにコンタクトし、プロキシが当該のサーバと通信し、その後クライアントに戻る。提案された解決策によれば、データ送信の要求がクライアントノードから受信されると、サーバノードは、例えば、最後のx秒間にわたる、その実際のキャパシティに関する表示を返す。この表示は、例えば、利用可能な最大キャパシティの割合、または逆に、既に使用中である割合を含むことができる。ネットワークにおけるサーバノードの実際のキャパシティについての情報は、本発明によるインターフェースデバイスによって受信され、データトラフィックが送信されたときの宛先ノードにおける負荷分散を決定するために使用される。瞬間的に空いているキャパシティが大きいサーバが、より高い確率で、次のデータ送信に選択される。また、選択アルゴリズムは、より低い利用可能性表示を返したサーバノードについては、選択される確率がより低くなることを保証する。次いで、その結果として生じた実際の負荷分散に関する情報は、実際の送信が開始する前に、クライアント送信元ノードに提供される。本発明によるインターフェースデバイスは、好ましくは、送信元クライアントノードに含まれる。あるいは、このインターフェースデバイスはスタンドアロンデバイスとすることができる。そうすると、そのようなスタンドアロンデバイスは典型的には、プロトコルとしてはDiameterプロキシノードとして挙動する。提案された方法は、いくつかの利点を提供する。この方法により、レセプタすなわち、サーバの容量キャパシティに従った、複数の宛先ノードにおけるトラフィックの最適な異種分散が可能になる。したがって、通信の安定性および効率性が大幅に増大する。さらに、キャパシティおよび処理特性が異なる構成要素を使用して、データ収集キャパシティ構成を構築することができる。これにより、構成は、世代が異なるまたはベンダが異なる構成要素を用いて拡大することができる。反対に、従来技術の解決策では、収集キャパシティが追加されるたびに、既存の構成はアップグレードを必要とした。本発明の重要な長所は、負荷分散が新しい状況に動的に適応するということである。例えば、バッチプロセスがサーバノードで動作しているために、そのノードの残りの収集キャパシティが一時的に低下すると、トラフィック分散は新しい最適条件を目指して動的に更新される。次に、一例が提供される図4参照。やはり、異なるキャパシティを有する4つのサーバ宛先ノードが考慮される。それぞれのノードについて、使用されているキャパシティの部分が示されている。クライアント送信元ノードは、データトラフィックを宛先ノードに送信するための要求を送ってある。ステップ[1]は、前記要求に応答して、キャパシティに関するその実際の状況の表示を送るサーバノードを示す。この例では、サーバノードは、CDFTS32.240における3GPPによって定義されたIMS機能である、課金データ機能として示されている。サーバノードの応答メッセージは、2つの部分、すなわち、依然として利用可能であるCPUおよび/またはメモリサイズに関するキャパシティの測定値の応答コード要求が処理されたかどうかを示すおよび追加の表示場合によってはサブコードとして実装されるを含む。当業者であれば容易に理解するように、応答メッセージの他の構造も想到され得る。有利には、様々なノードの利用可能性に関する表示は、TS32.240における3GPPによって定義されたIMS機能である、CTF課金トリガ機能に記憶される。CTFはRfDiameterクライアントを実装することに留意されたい。この例では、受信された負荷表示の解釈は、実際にはCTFの一部である。しかし、これはスタンドアロン機能またはDiameterプロキシもしくはさらにはDiameterリダイレクトに実装された機能とすることもできる。実際に、Diameterプロトコルは、Diameterリダイレクトノードも定義する。このノードは、クライアントとサーバとの間の実際の通信の前に、ルーティング目的で参照される。シグナリング経路にリダイレクトノードがある場合、実際の負荷分散は依然としてクライアントによって実行される。この場合、ルーティングタスクはリダイレクトノードおよびクライアントノードにおいて共有される。次のメッセージのためのサーバ宛先ノードを選択する場合、利用可能性情報が重み付けとしてロードバランシングアルゴリズムによって考慮され、サーバノードが選択される。起動時または低トラフィック時には、全てのサーバが高い利用可能性の数値例えば、95を返すので、CTFは全てのサーバにおいて負荷を均等に分散する。負荷が増加すると、より低いキャパシティを有するサーバによって返される利用可能性の数値は減少する。より多くの利用可能なキャパシティが残っているおよび、したがって、より高い利用可能性の数値を返すサーバノードは、空いているキャパシティがほとんどまたは全く残っていないサーバよりも、宛先として選択される確率が高い。比較的多くの数の要求がそのようなサーバのアドレスを有することになる。したがって、高負荷の宛先サーバが選択される頻度は低い。その結果として、少ない数の要求がそのような高負荷のサーバのアドレスを得る。このようにして、最適なロードシェアリングが達成される。サーバのうちの1つで収集状態が変化する例えば、CPUを消費するバッチジョブが実行されると、分散パターンは実際の状況に動的に適応される。あらゆるロードバランシングアルゴリズムの目的は、サーバ毎の重み付け表示を動的にリアルタイムで生成し、これらの表示を使用して、例えば、DNSで使用される重み付けされたサーバ選択を適用することである。1つの考えられるアルゴリズムは、以下のように実装され得る。負荷分散機能は、○それぞれのサーバについて、負荷表示を受信し、記憶する○そのサーバの受信された値に一致する、サーバ毎のいくつかのエントリを有する動的なリストまたは配列を作成する。負荷インジケータが利用可能なリソースに対応するとき、そのままの値が使用され得る。負荷インジケータが使用されているリソースに対応するとき、100-使用されている負荷の情報が適用される。○配列の全ての要素において、対応するサーバのアドレスまたはそれに対するポインタが記憶される送信されるべき全ての新しい要求に対して、送信側は、0から負荷インジケータサーバ1負荷インジケータサーバ2などの間のランダムな数を生成する。ランダムな値は、動的な配列にアクセスするための指標として使用される。要求の宛先は、配列要素に記憶される。サーバxの受信された負荷表示が高いとき、比較的大きい数の配列エントリがサーバxのアドレスを有することになる。サーバyの受信された負荷表示が低いとき、その結果として、少ない数の配列エントリがそのサーバyのアドレスを有することになる。ランダムな数がサーバxを指す確率のほうが高い。例示的なケースは、異なる収集キャパシティを有するノードのファームにおいて共有された3GPPRfトラフィックDiameter負荷に関する。利用可能なキャパシティのフィードバックは、最適なロードシェアリングを保証する。本発明において提案された解決策によって達成される性能利得を示すために、従来技術におけるラウンドロビンアルゴリズムの性能との比較を以下に挙げる。図6は、利用可能なサーバキャパシティのカットオフ閾値の80が使用されているときにラウンドロビン選択を適用することによって得られた性能曲線を示す。この閾値レベルに達した瞬間からnot-OKメッセージが送られる。レベルが60に低下すると、トラフィックが再開される。これらの値は典型的には、過負荷状態における安定性を微調整するために構成毎に設定される。これらの値は、サーバ状況がオン状態とオフ状態との間で変動している状況を回避するためにたどる一種のヒステリシス曲線を定義する。この図は、異なるキャパシティならびに累積スループットを有する4つのサーバを有する構成について、時間に応じた1秒毎の要求の数を示す。オーバーヘッドトラフィックが特に、より低いキャパシティノードで見られる。累積スループット合計帯域幅の大きな変動に注目されたい。最大レベルこの場合は、個々のサーバノードキャパシティの合計の80に等しいに達することができない。図7は、本発明によるキャパシティフィードバック解決策を使用したときに得られた性能を示す。やはり、図6の場合のサーバノードならびに最適な累積スループットの同じ構成について、時間に応じた1秒毎の要求の数が示されている。図6とは対照的に、オーバーヘッドトラフィックはもはや見られない。変動性の挙動はなくなっている。過渡期の後、累積キャパシティは最適レベルに対応する。特定の実施形態を参照することによって本発明が示されてきたが、本発明が上記の例示的な実施形態の詳細に限定されないこと、また、本発明の範囲から逸脱することなく本発明が様々な変更および修正によって具体化され得ることは当業者には明らかであろう。したがって、本実施形態は、限定的なものではなく例示的なものとして、全ての点において考慮されるべきであり、本発明の範囲は、上記の説明によってではなく、添付の特許請求の範囲によって示され、したがって、特許請求の範囲と均等であるものの意味および範囲内に入る全ての変更は、特許請求の範囲に包含されるものとする。言い換えれば、根底にある基本的な原理の趣旨および範囲内にあり、その不可欠な属性がこの特許出願において特許請求される、任意のおよび全ての修正、変形または均等物を網羅することが企図される。さらに、comprisingまたはcompriseという語は他の要素またはステップを除外しないこと、aまたはanという語は複数を除外しないこと、また、コンピュータシステム、プロセッサまたは別の統合ユニットなどの単一の要素は特許請求の範囲に記載されたいくつかの手段の機能を実行し得ることが、この特許出願の読者によって理解されよう。特許請求の範囲におけるいかなる参照符号も、関係するそれぞれの請求項を限定するものとして解釈されるべきではない。first、second、third、a、b、cなどの用語は、本明細書においてまたは特許請求の範囲において使用されるとき、類似の要素またはステップを区別するために導入され、必ずしも連続した順番または時間的な順番を説明するものではない。同様に、top、bottom、over、underなどの用語は、説明目的で導入され、必ずしも相対的な位置を示すものではない。そのように使用される用語は、適切な状況下で互いに交換可能であり、本発明の実施形態は、本発明に従って、上記に説明されたまたは示されたものとは異なる他の順序または向きで動作することができることを理解されたい。