(57)【特許請求の範囲】
【請求項１】
コアネットワーク要素における分散型システム内のリソース管理方法において、
コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；
前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；
プライオリティ数を各セットに指定し；
インターバルを、アクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化し、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び
前記インターバルからのランダム数を到来する要求に割り当て、そして前記割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースに前記要求を転送する；
ことを含み、
新たなセットに負荷がかかる場合には、そのプライオリティ数が、リアルタイムトラフィックに基づいて、プリセット出発値からその最大値まで動的に変化する、ことを特徴とする方法。
【請求項２】
プライオリティ数が大きいほど、サブインターバルの長さが長い、請求項１に記載の方法。
【請求項３】
コンピューティングリソースのセットがインアクティブ状態であるか又は既にスケールインされたときには、そのプライオリティ数がゼロプライオリティを指示する、請求項１又は２に記載の方法。
【請求項４】
単一セットの負荷が上限スレッシュホールドに到達する場合には、そのプライオリティ数が最大となり、そのセットが、最も高いプライオリティで到来要求を受け取ることを指示する、請求項１から３のいずれかに記載の方法。
【請求項５】
前記コアネットワーク要素は、テレコミュニケーションアプリケーションサーバー、移動交換サーバー、移動管理エンティティ、サービングＧＰＲＳサポートノード、又はコール処理ノードである、請求項１から４のいずれかに記載の方法。
【請求項６】
コアネットワーク要素における分散型システム内のリソース管理装置において、
少なくとも１つのプロセッサ、及び
前記プロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリ、
を備え、前記少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、
コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；
前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；
プライオリティ数を各セットに指定する；
ことを行うようにさせるよう構成され、更に、
インターバルをアクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化するように構成されたセグメント化ユニットを備え、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び
前記インターバルからのランダム数を到来する要求に割り当て、そして前記割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースに前記要求を転送する；
ことを行うようにさせ、
新たなセットに負荷がかかる場合には、そのプライオリティ数が、リアルタイムトラフィックに基づいて、プリセット出発値からその最大値まで動的に変化する、ように構成された装置。
【請求項７】
プライオリティ数が大きいほど、サブインターバルの長さが長い、請求項６に記載の装置。
【請求項８】
コンピューティングリソースのセットがインアクティブ状態であるか又は既にスケールインされたときには、そのプライオリティ数がゼロプライオリティを指示する、請求項６又は７に記載の装置。
【請求項９】
単一セットの負荷が上限スレッシュホールドに到達する場合には、そのプライオリティ数が最大となり、そのセットが、最も高いプライオリティで到来要求を受け取ることを指示する、請求項６から８のいずれかに記載の装置。
【請求項１０】
前記コアネットワーク要素は、テレコミュニケーションアプリケーションサーバー、移動交換サーバー、移動管理エンティティ、サービングＧＰＲＳサポートノード、又はコール処理ノードである、請求項６から９のいずれかに記載の装置。
【請求項１１】
コンピュータプログラムにおいて、そのコンピュータプログラムがコンピュータで実行されるときに、
コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；
前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；
プライオリティ数を各セットに指定し；
インターバルをアクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化し、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び
前記インターバルからのランダム数を到来する要求に割り当て、そして前記割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースに前記要求を転送する；
というステップを遂行し、
新たなセットに負荷がかかる場合には、そのプライオリティ数が、リアルタイムトラフィックに基づいて、プリセット出発値からその最大値まで動的に変化する、ようにするためのコンピュータプログラム。
【請求項１２】
前記コンピュータプログラムは、コンピュータ読み取り可能な記録媒体に記憶され、
前記コンピュータプログラムは、コンピュータの内部メモリに直接ロード可能であり、及び／又はアップロード、ダウンロード、及びプッシュ手順の少なくとも１つによりネットワークを経て送信可能である、請求項１１に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、有線及び無線通信ネットワークに関するもので、より詳細には、分散型システムにおける改善された水平スケーリングのために、改善された負荷バランシング、特に、コアネットワーク要素における最適なリソース管理を可能にする方法、装置及びコンピュータプログラム製品に関する。
【背景技術】
【０００２】
コストを節減するため、テレコミュニケーション運営者は、インフラストラクチャーの売主から無線及びコアネットワークコンポーネントのバーチャル化をしばしば要求する。実際に、全てのコアネットワークコンポーネントは、同じクラウドインフラストラクチャーにおいて実行できねばならない。例えば、全てのコアネットワークコンポーネントに対する均一ハードウェア（ＨＷ）に関する支出によるコストを節減する他に、運営者は、バーチャルネットワーク要素のようなコンピューティングリソースが、例えば、クラウドの利益も利用し、従って、入手可能なハードウェアリソースの利用を更に最適化することを希望する。そのような利益の１つは、クラウドにおけるバーチャルアプライアンスのスケールイン／アウトとしても知られている水平スケーラビリティの可能性である。
【０００３】
例えば、クラウドにおける普通の（バーチャル）アプライアンスとして、コアネットワーク要素は、そのような水平スケーリング振舞いをサポートしなければならない。実際には、これは、バーチャルマシン（ＶＭ）のような（スケールイン）コンピューティングリソースを（バーチャル）アプライアンス（ここではコアネットワーク要素）から除去するか又は（スケールアウト）コンピューティングリソースをそこに追加することができねばならないことを意味する。これは、高トラフィック期間（例えば、昼間の時間）中の容量ニーズに基づいて、バーチャルマシンＶＭのような新たなコンピューティングリソースを動的に追加しながら、低トラフィック（例えば、夜間の時間）中のトラフィックを取り扱うために必要なコンピューティングリソースの数を「縮小」する能力を与える。
【０００４】
厳密な予想サービスグレードを伴うテレコミュニケーションネットワーク要素に関しては、スケールイン手順におけるコンピューティングリソース除去がサービス障害を生じてはならない。本発明により取り扱われるネットワーク要素の場合には、提供される主たるサービスが加入者間のコールの取り扱いである。即ち、例えば、移動交換センターサーバー（ＭＳＳ）又はテレコミュニケーションアプリケーションサーバー（ＴＡＳ）からのコンピューティングリソースの除去が進行中のコール設定又は進行中のアクティブフェーズコールを妨げてはならない。換言すれば、ＶＭのようなコンピューティングリソースの除去は、率直なものでなければならない。データセッションのためのそのような率直なスケールイン手順が要求される対応ネットワーク要素は、例えば、ＳＧＳＮ／ＭＭＥである。
【０００５】
ネットワーク要素のコンピューティングリソースのこのスケーリングを外界から隠すために、良く知られた習慣は、ネットワーク要素の縁で負荷バランサーを利用することである。負荷バランサー（ＬＢ）は、外界からのトラフィックを終了させ、そして到来するトラフィックをネットワーク要素の内部コンピューティングリソース間に配布する。このように、負荷バランサーを使用して、特定のアクティブなコンピューティングリソースが新たなコール要求を受け取るかどうか決定することができ、或いは内部コンピューティングリソースが率直な遮断に対してマークされる場合には、そのマークされたコンピューティングリソースが新たなコール要求を受け取ってはならず、当然、そのコンピューティングリソースに関する進行中セッションのトラフィックが依然としてそのコンピューティングリソースに向けられねばならない。
【０００６】
従って、このロジックでは、コンピューティングリソースにより取り扱われる進行中セッションが関係者により終了されると、コンピューティングリソースは、暫くして「空」になることが明らかである。
【０００７】
他方、一般的に、コールの長さは予想できないことが明らかである。即ち、進行中のアクティブフェーズコールが関係者によっていつ終了されるかは、予想できない。これは、幾つかの少数の非常に長いコールセッションのためにＶＭのようなコンピューティングリソースを遮断できない状態が生じ得ることを意味する。
【０００８】
本明細書は、水平スケーリングと称されるスケールイン及びスケールアウトに関するものである。
【０００９】
基本的に、スケールアウト機能は、増加したトラフィックを取り扱うためにコンピューティングリソースを追加することにより機能的ユニット（ＦＵ）容量を増加できるようにする。逆に、スケールイン機能は、トラフィックからコンピューティングリソースを除去することにより機能的ユニット容量を減少できるようにする。水平スケーリングは、既に、全ての装置売主により対処されねばならない事実上の運営者の要求事項となっている。
【発明の概要】
【発明が解決しようとする課題】
【００１０】
以上の序文から明らかなように、コールの長さを一般的に予想できないという問題がある。従って、一般的な負荷バランサーロジックに従い、且つ内部コンピューティングリソース間の到来するトラフィックが、全てのコンピューティングリソースが同じＣＰＵ負荷及びメモリ消費量を有するように共有される場合、それは、低トラフィック時間にコンピューティングリソースを率直に遮断することが望まれるとき、遮断のために選択されないコンピューティングリソースと同じ量のコールを取り扱うことができ、即ち長いコールは、他のコンピューティングリソースの場合と同じ確率でそのコンピューティングリソースに現われることを意味する。この確率を下げるためには、改善された負荷バランサーロジックが要望される。
【課題を解決するための手段】
【００１１】
それ故、従来技術の欠点を克服するため、本発明の基礎的な目的は、改善された負荷バランシングを可能にすることである。
【００１２】
特に、本発明の目的は、クラウドベース環境又は非クラウド環境のいずれかにおいて構成されて、コアネットワーク要素における最適なリソース管理を与えるための方法、装置及びコンピュータプログラム製品を提供することである。
【００１３】
本発明の第１の観点によれば、コアネットワーク要素における分散型システム内のリソース管理方法において、コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；プライオリティ数を各セットに指定し；要求配布をランダム化するためのランダム数のインターバルをアクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化し、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び前記インターバルからのランダム数を到来する要求に割り当てそしてその割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースにその要求を転送する；ことを含む方法が提供される。
【００１４】
本発明の第２の観点によれば、コアネットワーク要素における分散型システム内のリソース管理装置において、少なくとも１つのプロセッサ、及び該プロセッサにより実行されるべきインストラクションを記憶するための少なくとも１つのメモリを備え、その少なくとも１つのメモリ及びインストラクションは、少なくとも１つのプロセッサとで、装置が、少なくとも、コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；プライオリティ数を各セットに指定し；要求配布をランダム化するためのランダム数のインターバルをアクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化し、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び前記インターバルからのランダム数を到来する要求に割り当て、そしてその割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースにその要求を転送する；ことを行うようにさせるよう構成された装置が提供される。
【００１５】
本発明の第３の観点によれば、プログラムが実行されるときに、コアネットワーク要素のコンピューティングリソースをセットへと編成し、第１セットは、常に、アクティブであり；前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定し、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされ；プライオリティ数を各セットに指定し；要求配布をランダム化するためのランダム数のインターバルをアクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化し、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定され；及び前記インターバルからのランダム数を到来する要求に割り当て、そしてその割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースにその要求を転送する；というステップを実行するように構成されたコンピュータ実行可能なコンポーネントを含むコンピュータプログラム製品が提供される。
【００１６】
本発明の前記規範的観点の好都合な更なる開発又は変更は、従属請求項に規定される。
【００１７】
本発明のある実施形態によれば、プライオリティ数が大きいほど、サブインターバルの長さが長くなる。
【００１８】
更に、本発明のある実施形態によれば、コンピューティングリソースのセットがインアクティブな状態にあるか又は既にスケールインされたときには、そのプライオリティ数がゼロプライオリティを指示する。
【００１９】
更に、本発明のある実施形態によれば、単一セットの負荷が上限スレッシュホールドに到達する場合に、そのプライオリティ数が最大となり、そのセットが、最高プライオリティで到来要求を受け取ることを指示する。
【００２０】
更に、本発明のある実施形態によれば、新たなセットがロードされる場合には、そのプライオリティ数が、リアルタイムトラフィックに基づいて、プリセット出発値から、その最大値まで、動的に変化することができる。
【００２１】
更に、本発明のある実施形態によれば、コアネットワーク要素は、テレコミュニケーションアプリケーションサーバー（ＴＡＳ）、移動交換サーバーＭＳＳ、移動管理エンティティＭＭＥ、サービングＧＰＲＳサポートノードＳＧＳＮであってもよいし、或いはコールセッションコントロールファンクションＣＳＣＦ、ホーム加入者サーバーＨＳＳ、ゲートウェイＧＰＲＳサポートノードＧＧＳＮ、等のいずれでもよい。
【００２２】
本発明の規範的実施形態をより完全に理解するため、添付図面を参照して以下に詳細に説明する。
【図面の簡単な説明】
【００２３】
【図１】本発明のある実施形態による方法を示す。
【図２】本発明のある実施形態による装置を概略的に示す。
【図３】ＦＵがセットに編成される本発明のある実施形態によるネットワーク要素構成を概略的に示す。
【図４】本発明のある実施形態によるランダム化アルゴリズムの概念図である。
【図５】本発明のある実施形態によるアルゴリズムのシグナリングチャートを示す。
【図６ａ】新たなセットをスケールアウトできるときの負荷状態において本発明のある実施形態による管理を概略的に示す（オーバーフロー）。
【図６ｂ】最後の（アクティブな）セットのプライオリティ数を増加できるときの負荷状態において本発明のある実施形態による管理を概略的に示す（オーバーフロー）。
【図６ｃ】最後の（アクティブな）セットのプライオリティ数を減少できるときの負荷状態において本発明のある実施形態による管理を概略的に示す（バックフロー）。
【図６ｄ】最後の（アクティブな）セットをスケールインできるときの負荷状態において本発明のある実施形態による管理を概略的に示す（バックフロー）。
【図７】図７ａ及び７ｂで構成され、本発明のある実施形態によるフローチャートを示す。
【発明を実施するための形態】
【００２４】
本発明の規範的観点を以下に説明する。より詳細には、本発明の規範的観点は、特定の非限定例、及び本発明の想像し得る実施形態と現在考えられるものを参照して以下に説明する。当業者であれば、本発明は、それらの例に限定されず、より広く適用できることが明らかであろう。
【００２５】
本発明及びその実施形態の以下の説明は、主として、ある規範的ネットワーク構成及び配備に対して非限定例として使用される仕様を参照することに注意されたい。即ち、本発明及びその実施形態は、主として、例えば、ある規範的ネットワーク構成及び配備に対して非限定例として使用される３ＧＰＰ仕様に関して説明する。従って、ここに述べる規範的実施形態の説明は、それに直接関連した用語を特に参照する。そのような用語は、ここに述べる非限定例の文脈にのみ使用されるもので、当然、本発明を何ら限定するものではない。むしろ、他のネットワーク構成又はシステム配備、等も、ここに述べる特徴に適合する限り使用できる。
【００２６】
以下、本発明の種々の実施形態及び具現化、並びにその観点又は実施形態は、多数の代替物を使用して説明する。一般的に、あるニーズ及び制約に基づき、ここに述べる全ての代替物は、単独で与えられてもよいし、又は想像可能な組み合せ（種々の代替物の個々の特徴の組み合せも含めて）で与えられてもよいことに注意されたい。
【００２７】
特に、以下の例、態様及び実施形態は、例示に過ぎないことを理解されたい。本明細書は、多数の位置で、「一」、「１つの」又は「幾つかの」規範的態様又は実施形態を参照するが、これは、そのような各参照が同じ規範的態様又は実施形態に対するものであるか又は特徴が単一の規範的態様又は実施形態のみに適用されることを必ずしも意味していない。又、異なる実施形態の単一の特徴を結合して他の実施形態を形成してもよい。更に、「備える(comprising)」及び「含む(including)」という語は、ここに述べる実施形態を、ここに述べた特徴のみで構成されるように限定するものでなく、且つそのような規範的態様及び実施形態は、特にここに述べない特徴、構造、ユニット、モジュール、等も含むことを理解しなければならない。
【００２８】
一般的に、テレコミュニケーションネットワークは、複数のネットワーク要素、例えば、ベースステーションＢＴＳ、進化型ＮｏｄｅＢ（ｅＮＢ、即ち、ＬＴＥ環境におけるベースステーション）、ユーザ装置ＵＥ（例えば、移動電話、スマートホン、コンピュータ、等）、コントローラ、インターフェイス、等、及び特に、テレコミュニケーションサービスの提供に使用される装置を備えている。
【００２９】
更に、ここに述べるコアネットワーク要素は、例えば、テレコミュニケーションアプリケーションサーバー（ＴＡＳ）、移動交換サーバー（ＭＳＳ）、移動管理エンティティ（ＭＭＥ）、サービングＧＰＲＳサポートノード（ＳＧＳＮ）、又はコール処理ノードであるが、これに限定されないことに注意されたい。
【００３０】
ここに述べる要素の一般的な機能及び相互接続は、実際のネットワークタイプにもよるが、当業者に良く知られ且つ対応仕様に規定されたものであり、従って、その詳細は、ここでは省略する。しかしながら、多数の付加的なネットワーク要素及びシグナリングリンクは、以下に詳細に述べるものの他に、ベースステーション及び通信ネットワークへの又はそれらからの通信に使用できることに注意されたい。
【００３１】
既に述べたように、現在の負荷バランスアルゴリズムは、ＶＭのような幾つかのコンピューティングリソースをプライオリティ決めしなければならないことを伴うロジックはサポートしない。しかしながら、そのようなアルゴリズムは、高次のコンピューティングリソースに負荷を掛け、そしてそれら高次のコンピューティングリソースが所与の負荷レベルに到達した場合だけ他の低次のコンピューティングリソースへトラフィックをオーバーフローさせることができる。そのようなアルゴリズムは、多数の状況において役立つ。例えば、クラウドベースの環境では、システムは、ＶＭのような幾つかのコンピューティングリソースに負荷を集中させ、そして必要なときだけ、ＶＭのような他のコンピューティングリソースへ負荷をオーバーフローさせることができ、これは、クラウドにおいてより顕著な動的リソース管理を可能にし、不必要なコンピューティングリソース（ＣＲ）を他の目的で使用できるか又はそれらを遮断することもできる。
【００３２】
又、そのようなアルゴリズムは、セッションの長さ（例えば、コール時間巾）に作用を及ぼすことができずに、長いセッションがシステムからのコンピューティングリソースの率直な除去を妨げる状況においても役立つ。そのような新たなアルゴリズムは、長いセッションがそれら低次のコンピューティングリソースに低い確率で維持されることを意味する。というのは、コンピューティングリソースの除去のために非常に長いコールを強制的に切断することは望ましくないからである。
【００３３】
更に、クラウド環境が本発明の１つのアプリケーションフィールドであっても、本発明は、クラウド環境のみに限定されず、非クラウド環境にも適用できることに注意されたい。更に、バーチャルマシン（ＶＭ）は、本発明の幾つかの観点によるコンピューティングリソースの一例であるが、本発明は、それに限定されない。
【００３４】
図１は、本開示の幾つかの規範的態様による方法を示す。
【００３５】
ステップＳ１１において、コアネットワーク要素のコンピューティングリソースがセットへと編成され、第１セット（即ち、基本的増分）は、常に、アクティブである。
【００３６】
次いで、ステップＳ１２において、セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドが設定され、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、最後にアクチベートされたセットの負荷が下限スレッシュホールドより下がると、最後にアクチベートされたセットがデアクチベートされる。
【００３７】
更に、ステップＳ１３において、プライオリティ数が各セットに指定される。この指定されるプライオリティ数は、各セットに対する最大の実現可能なプライオリティでなければならない。
【００３８】
更に、ステップＳ１４において、要求配布をランダム化するためのランダム数のインターバルが、アクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化され、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定される。
【００３９】
更に、ステップＳ１５において、前記インターバルからのランダム数が到来する要求に割り当てられ、そして前記割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースに前記要求が転送される。
【００４０】
図２は、本開示の幾つかの規範的態様による（テレ）コミュニケーションネットワーク要素に含まれる要素の構成を示す図で、この要素は、本開示の規範的態様の幾つかに関連して述べるようにクラウドベース環境においてコアネットワーク要素のリソース管理を実施するよう構成される。この実施形態は、ネットワーク要素において又はネットワーク要素により具現化される。ネットワーク要素は、チップセット、チップ、モジュール、等の要素又は機能を含み、これは、ネットワーク要素の一部分であってもよいし、或いは個別の要素としてネットワーク要素、バーチャルマシン、等にアタッチされてもよい。各ブロック及びその組み合せは、種々の手段又はそれらの組み合せ、例えば、ハードウェア、ソフトウェア、ファームウェア、１つ以上のプロセッサ及び／又は回路により実施されてもよいことを理解されたい。
【００４１】
図２に示すネットワーク要素は、処理機能、制御ユニット又はプロセッサ２１、例えば、ＣＰＵ、等を含み、これは、ネットワーク要素制御手順に関連したプログラム等により与えられるインストラクションを実行するのに適したものである。
【００４２】
プロセッサ２１は、クラウドベース環境におけるコアネットワーク要素の前記リソース管理に関連した処理を実行するように構成される。特に、プロセッサ２１は、コアネットワーク要素のコンピューティングリソースをセットへと編成するように構成された編成ユニットとしてサブ部分２１０を備え、ここで、第１セットは、常に、アクティブである。この部分２１０は、図１のＳ１１による処理を遂行するように構成される。更に、プロセッサ２１は、前記セットの負荷に対して上限スレッシュホールド及び下限スレッシュホールドを設定するように構成された設定ユニットとして使用可能なサブ部分２１１を備え、動作中のセットは、動作中のセットの平均負荷が上限スレッシュホールドに到達する限り負荷が掛けられ、そして上限スレッシュホールドを越えると、新たなセットがアクチベートされ、一方、その負荷が下限スレッシュホールドより下がると、その最後にアクチベートされたセットがデアクチベートされる。この部分２１１は、図１のＳ１２による処理を遂行するように構成される。更に、プロセッサ２１は、プライオリティ数を各セットに指定するように構成された指定ユニットとして使用可能なサブ部分２１２を備えている。この部分２１２は、図１のＳ１３による処理を遂行するように構成される。更に、プロセッサ２１は、要求配布をランダム化するためのランダム数のインターバルを、アクティブなセットのコンピューティングリソースに割り当てられるサブインターバルでセグメント化するように構成されたセグメント化ユニットとして使用可能なサブ部分２１３を備え、各サブインターバルの長さは、各コンピューティングリソースのセットのプライオリティ数に基づいて決定される。この部分２１３は、図１のＳ１４による処理を遂行するように構成される。更に、プロセッサ２１は、前記インターバルからのランダム数を到来する要求に割り当て、そしてその割り当てられたランダム数を含むサブインターバルに属するコンピューティングリソースにその要求を転送するように構成された処理ユニットとして使用可能なサブ部分２１４を備えている。この部分２１４は、図１のＳ１５による処理を遂行するように構成される。
【００４３】
参照符号２２及び２３は、プロセッサ２１に接続されたトランシーバ又は入力／出力（Ｉ／Ｏ）ユニット（インターフェイス）を表わす。Ｉ／Ｏユニット２２は、例えば、ネットワーク要素と通信するために使用される。Ｉ／Ｏユニット２３は、例えば、管理アプリケーションと通信するために使用される。参照符号２４は、例えば、プロセッサ２１により実行されるべきプログラム及びデータを記憶するために使用可能な、及び／又はプロセッサ２１のワーキングストレージとしても使用可能なメモリを表わす。
【００４４】
本発明の幾つかの実施形態によれば、先ず、コンピューティングリソースがセットへと編成される。そのようなセットは、理論的に、いかなる数のコンピューティングリソースを含んでもよいが、せいぜい、完全に利用可能な程度である。しかしながら、実際には、本発明の範囲を限定することなく、基本的増分は、最小値が２であり、他の増分は、少なくとも１つのＦＵを有する。一方では、新たにアクチベートされたコンピューティングリソースが、コンピューティングリソースをセットへと編成することで直ちに（スケールアウト後に）過負荷となる機会を最小にすることができる。他方では、一度により多くのＣＰＵリソースを管理することができる。
【００４５】
基本的増分とは、常に存在し且つ常にアクティブであるセットである。
【００４６】
この種の構成が図３に示されている。特に、図３は、コンピューティングリソース（ＣＲ）がバーチャル化コアネットワーク要素においてセットＳ１からＳｎへと編成され、それらセットが複数の負荷バランサー、例えば、ＬＢ−０からＬＢ−ｍに接続された本発明の幾つかの実施形態によるネットワーク要素構成を概略的に示す。ＬＢは、例えば、マルチレイヤサイトスイッチにより切り換えることができる。
【００４７】
第２のステップは、セットの負荷の上限スレッシュホールド（例えば、ＬUT＝６０％）を固定する。その目標は、平均負荷が所与の上限スレッシュホールド（ＬUT）に到達する限りアクティブなセットに負荷がかかるようにすることである。これは、非常に有用である。というのは、新たなセットは、アクティブなセットの平均負荷に関してこの所与の上限を越えた場合及びその場合だけアクティブな状態に入れられるからである。
【００４８】
同様に、セットの負荷の下限スレッシュホールド（例えば、ＬLT＝１０又は２０％）を設定する。これも非常に有用である。というのは、最後の（アクティブな）セットは、その最後のセットの負荷がこの所与の下限スレッシュホールドより低い場合及びその場合だけインアクティブな状態に入れられるからである。
【００４９】
更に、全てのセットにはプライオリティ数が与えられる。従って、次の条件の少なくとも１つを満足しなければならない。第１に、各コンピューティングリソースは、そのセット内に同じプライオリティ数を有するが、コンピューティングリソースのプライオリティ数は、リアルタイムトラフィックに基づいて動的に変化可能でもある。コンピューティングリソースのプライオリティ数が大きいほど、そのコンピューティングリソースに要求を指定する確率が高くなる。従って、ＣＲのセットがインアクティブ状態にあるか又は既にスケールインされた場合には、このプライオリティ数がゼロとなる。あるセットが下限に到達し、即ち下限スレッシュホールドより下がる場合には、そのセットがデアクチベートされることになり、即ちそのセットにはそれ以上の負荷が向けられないことを意味する。更に、単一セットの負荷が上限スレッシュホールド（ＬUT）に到達する場合には、そのプライオリティ数が最大Ｍとなる（ここで、Ｍは、既にＬUTに到達した全てのセットに共通である）。Ｍは、構成可能なパラメータである。更に、新たなセットに負荷がかかる場合には、そのプライオリティ数が（リアルタイムトラフィックに基づき）Ｍまで動的に変化可能である。ここに示す実施形態の場合には、プライオリティ数の出発値がＭ／３であるが、必要に応じて調整することができる。
【００５０】
即ち、プライオリティ数は、必要に応じて調整することができ、例えば、異なるスケールを使用することができる。ここに示す実施形態では、最大Ｍが所与の上限スレッシュホールドに基づいて６０に設定される。
【００５１】
最後に、要求配布がランダム化される。本発明の幾つかの実施形態によるランダム化プロセスが図４に示されている。
【００５２】
図４において、最上行は、到来する要求を示す。インターバルのそのような細分化、例えば、［０、１］は、図４の下部に見ることができ、各サブインターバルは、異なるコンピューティングリソース（ＣＲ）に属する。ＣＲの各陰影は、それらが属するセットを指示する。
【００５３】
サブインターバルの長さは、次の式によりリアルタイムで決定される。
0006487045.tif 000002
即ち、ＣＲのプライオリティ数が大きいほど、それに対応するサブインターバルが大きくなる。到来する要求は、ランダムに配布される。というのは、各要求が、例えば、［０、１］からランダム数を得るからである。要求は、割り当てられたランダム数を含むサブインターバルに属するＣＲへ転送される。
【００５４】
以上を要約すると、アルゴリズムの理論的なシグナリングチャートを図５に見ることができる。
【００５５】
ステップ１において、到来する要求、例えば、ＳＩＰ招待メッセージは、負荷バランサーの外部インターフェイスへ転送される。
【００５６】
負荷バランサープロセスにおいて次のステップが実行される。特に、ステップ２では、その要求に対するランダム数が発生される。次いで、ステップ３において、その発生された数を含むサブインターバルが選択される。ステップ４において、その選択されたサブインターバルに属するＣＲが選択される。その後、ステップ５において、負荷バランサーの内部インターフェイスからその選択されたＣＲへ要求が転送される。最後に、ステップ６において、その選択されたＣＲにより要求が取り扱われる。
【００５７】
以上に基づき、幾つかの実施形態による本発明は、図６ａないし６ｄに示す次のような負荷状態を管理することができる。
【００５８】
図６ａは、新たなセットをスケールアウトできるときの負荷状態において本発明の幾つかの実施形態による管理を概略的に示す（オーバーフロー）。特に、図７ａに見られるように、全てのアクティブなセットＳ1ないしＳkの負荷が所与の上限スレッシュホールドＬUTに到達し、それ故、新たなセットへのオーバーフロートラフィックが遂行される。即ち、スレッシュホールドを越えるトラフィックは、新たなセットＳk+1へ流し込まねばならない。
【００５９】
図６ｂは、最後の（アクティブな）セットのプライオリティ数を増加できるときの負荷状態において本発明の幾つかの実施形態による管理を概略的に示す（オーバーフロー）。特に、図７ｂに示す場合には、負荷が増加し（Ｌ↑）、それ故、最後のセットのプライオリティ（数）を増加することができる。即ち、最後のセットは、より多くのトラフィックを管理しなければならない。
【００６０】
図６ｃは、最後の（アクティブな）セットのプライオリティ数を減少できるときの負荷状態において本発明の幾つかの実施形態による管理を概略的に示す（バックフロー）。特に、図７ｃに示す場合から明らかなように、負荷が減少し（Ｌ↓）、それ故、最後のセットのプライオリティ（数）を減少することができる。即ち、最後のセットは、少ないトラフィックを管理すればよい。
【００６１】
図６ｄは、最後の（アクティブな）セットをスケールインできるときの負荷状態において本発明の幾つかの実施形態による管理を概略的に示す（バックフロー）。即ち、最後のアクティブなセットの負荷は、所与の下限スレッシュホールドＬLTより低く、それ故、最後のセットＳk+1は、デアクチベートすることができる。
【００６２】
図６ａないし６ｄに示すこの方法は、両方向性の変形リーキーバケット(leaky bucket)モデルのように考えることができる。負荷をオーバーフローさせそして同様にバックフローさせられることに注意するのが非常に重要である。又、到来する要求は、アクティブなセット間に均一に配布されないことにも触れる価値がある。最後のセットは、典型的に、僅かな要求しか取り扱わず、それ故、最後のセットは、スケールインする（速く空にする）ことが明らかな目標である。
【００６３】
図７ａ及び７ｂより成る図７は、本発明のある実施形態によるフローチャートである。
【００６４】
手順を開始した後に、基本的増分がアクチベートされる。ステップ１において、全てのアクティブなセットのリソースの利用が監視される。ステップ２において、基本的増分だけがアクティブであるかどうか決定される。基本的増分のみがアクティブである（Ｓ２がイエス）ときには、ステップ３において、基本的セットのリソースの利用が上限スレッシュホールドに到達したかどうか決定される。もしそうでなければ（Ｓ３がノー）、プロセスは、ステップ１へ戻り、一方、スレッシュホールドに到達した（Ｓ３がイエス）場合には、ステップ４において、プライオリティ数（ｐｎ）Ｍ／３をもつ新たなセットがアクチベートされ、そしてプロセスは、ステップ１へ戻る。又、他のセットがアクティブであるときには（Ｓ２がノー）、ステップ５において、全てのアクティブなセットのリソースの利用が上限スレッシュホールドに到達したかどうか決定される。その場合には（Ｓ５がイエス）、ステップＳ６において、依然アクチベートできる新たなセットが更にあるかどうか決定される。もしそうであれば（Ｓ６がイエス）、プロセスは、ステップ４へ進む。さもなければ、アクチベートできるセットが他になければ（Ｓ６がノー）、全てのセットが既にアクチベートされている。ステップ７において、上限スレッシュホールドを最大設計スレッシュホールドへ増加され、そしてシステムが最大容量に到達したというアラームが発せられる。プロセスは、ステップ１へ戻る。
【００６５】
ステップ５において「ノー」が決定された場合には、ここで図７ｂを参照すれば、ステップ８において、セットのリソースの利用が上限スレッシュホールドに到達するかどうか決定される。そのような場合には（Ｓ８がイエス）、ステップ９において、最後にアクチベートされたセットのプライオリティ数がＭ／６で増加され、そしてプロセスは、ステップ１へ戻る。さもなければ（Ｓ８がノー）、ステップ１０において、最後にアクチベートされたセットのリソースの利用が下限スレッシュホールドより下であるかどうか決定される。そのような場合には（Ｓ１０がイエス）、最後にアクチベートされたセットがステップ１１においてデアクチベートされ、そしてプロセスは、ステップ１へ戻る。さもなければ（Ｓ１０がノー）、ステップ１２において、リソースの利用が減少しているかどうか決定される。もしそうであれば（Ｓ１２がイエス）、ステップ１３において、最後にアクチベートされたセットのプライオリティ数がＭ／６で減少され、そしてプロセスは、ステップ１へ戻る。さもなければ（Ｓ１２がノー）、プロセスは、直ちにステップ１へ戻る。
【００６６】
本発明は、分散型構造をもつ全てのネットワーク要素へ拡張することができる。即ち、多数のコンピュータリソースを備えた分散型システムに適用することができる。
【００６７】
基本的に、本発明によるアルゴリズムを使用する主要な効果がある。一方では、既存のリソースの良好な利用が考えられる。更に、スイッチオフ不要のコンピューティングリソースによりエネルギーを節約できるか、又は空きコンピューティングリソースを他の処理に割り当てることができる。更に、タスクの取り扱いは、よりコスト効率の良いものにすることができる。
【００６８】
最大の効果は、必要量のリソースしか使用しないことである。低負荷時にシステムからコンピューティングリソース（コンピューティングリソースのセット）を除去することが決定されると、低次のコンピューティングリソースは、高次のコンピューティングリソースより取り扱うトラフィックが少ないことが保証される。従って、最も低次のコンピューティングリソースは、率直な仕方でより速く空にすることができ、これは、サービスの継続性を許す。
【００６９】
本発明の実施形態は、ソフトウェア、ハードウェア、アプリケーションロジック又はそれらの組み合せにおいて回路として実施されることに注意されたい。規範的実施形態において、アプリケーションロジック、ソフトウェア又はインストラクションセットは、種々の従来のコンピュータ読み取り可能な媒体のいずれか１つに維持される。この文書の文脈において、「コンピュータ読み取り可能な媒体」は、インストラクション実行システム、装置又はデバイス、例えば、コンピュータ又はスマートホン又はユーザ装置により又はそれに関連して使用するためのインストラクションを含み、記憶し、通信し、伝播し或いは搬送することのできる媒体又は手段である。
【００７０】
本出願で使用される「回路」という語は、次の全てを指す。（ａ）ハードウェアのみの回路実施（例えば、アナログ及び／又はデジタル回路のみでの実施）；（ｂ）回路及びソフトウェア（及び／又はファームウェア）の組み合せ、例えば、（該当するもの）（ｉ）プロセッサの組み合せ又は（ii）プロセッサ／ソフトウェアの部分（デジタル信号プロセッサを含む）、ソフトウェア、及びメモリで、一緒に働いて、移動電話又はサーバーのような装置が種々の機能を遂行するようにさせるもの；及び（ｃ）マイクロプロセッサ又はマイクロプロセッサの一部分のような回路で、ソフトウェア又はファームウェアが物理的に存在しなくても動作のためにソフトウェア又はファームウェアを要求するもの。「回路」のこの定義は、特許請求の範囲も含めて本出願におけるこの用語の全ての使用に適用される。又、更に別の例として、本出願で使用される「回路」という語は、単なるプロセッサ（又は多数のプロセッサ）或いはプロセッサの一部分及びそれに（又はそれらに）付随するソフトウェア及び／又はファームウェアも網羅する。又、「回路」という語は、例えば、請求項の特定の要素に適用する場合には、基本帯域集積回路、又は移動電話のためのアプリケーションプロセッサ集積回路、或いはサーバーにおける同様の集積回路、又はセルラーネットワーク装置、又は他のネットワーク装置も網羅する。
【００７１】
本発明は、特に、移動通信、例えば、ＧＳＭ（登録商標）、３Ｇ、ＬＴＥTM又はＬＴＡ−アドバンストのもとの環境に関連するが、これに限定されず、そしてコントローラ、ベースステーション、ユーザ装置、又はスマートホン、或いはそのようなネットワークに接続可能なコンピュータにおいて効果的に実施することができる。即ち、例えば、接続される装置へのチップセットとして／チップセットにおいて実施することができる。
【００７２】
要望があれば、ここに述べる異なる機能が異なる順序で及び／又は互いに同時に遂行されてもよい。更に、要望があれば、上述した機能の１つ以上は、任意でもよいし、結合されてもよい。
【００７３】
本発明の種々の観点は、独立請求項に規定するが、本発明の他の観点は、単に請求項に明示的に規定する組み合せではなく、ここに述べる実施形態及び／又は従属請求項からの特徴と、独立請求項の特徴との他の組み合せも包含する。
【００７４】
又、本発明の規範的実施形態を上述したが、それらの説明は、限定の感覚で考えてはならないことにも注意されたい。むしろ、特許請求の範囲に規定された本発明の範囲から逸脱せずに多数の変更や修正がなされ得る。
【００７５】
本明細書で使用する略語の意味は、次の通りである。
ＣＰＵ：中央処理ユニット
ＣＲ：コンピューティングリソース（例えば、ネットワーク要素又はバーチャルマシンの機能的ユニット）
ＨＷ：ハードウェア
ＩＰ：インターネットプロトコル
ＩＰ  ＢＢ：ＩＰバックボーン
Ｌ：負荷
ＬＢ：負荷バランサー
ＬLT：下限負荷スレッシュホールド
ＬUT：上限負荷スレッシュホールド
ＮＥ：ネットワーク要素
ＭＧＷ：メディアゲートウェイ
ＭＳＣ：移動交換センター
ＭＳＳ：ＭＳＣサーバー
ＴＡＳ：テレコミュニケーション（電話とも称される）アプリケーションサーバー
Ｓi：ｉ番目のセット
ＳＲ：サイトルーター
ＶＭ：バーチャルマシン
【００７６】
更に、次の用語は、本明細書に使用されるもので、次のように理解される。
プール：コンピューティングリソースのグループで、ここでは、「セット」という語が使用される
ｐｎ：プライオリティ数
セット：コンピューティングリソースのグループ
アクティブなセット：要求を受け取りそしてコールを取り扱えるＣＲのセット
インアクティブなセット：進行中のコールだけは取り扱えるが、新たな要求を受け容れることが許されないＣＲのセット
【符号の説明】
【００７７】
２０：ネットワーク要素
２１：プロセッサ
２２、２３：Ｉ／Ｏユニット
２１０、２１１、２１２、２１３、２１４：サブ部分
【図１】
0006487045.tif 000003
【図２】
0006487045.tif 000004
【図３】
0006487045.tif 000005
【図４】
0006487045.tif 000006
【図５】
0006487045.tif 000007
【図６ａ】
0006487045.tif 000008
【図６ｂ】
0006487045.tif 000009
【図６ｃ】
0006487045.tif 000010
【図６ｄ】
0006487045.tif 000011
【図７ａ】
0006487045.tif 000012
【図７ｂ】
0006487045.tif 000013