(57)【特許請求の範囲】
【請求項１】
ＱｏＳ構成を動的に調整するためのシステムであって、
ネットワークを介して伝達されるパケットのトラフィック・タイプを識別し、前記ネットワークのトラフィック・ミックスを示す統計データを維持するように構成されたＱｏＳ制御エンジンと、
前記ＱｏＳ制御エンジンに結合され、前記トラフィック・タイプに対応するＱｏＳ構成情報を含むように構成され、前記ＱｏＳ制御エンジンからの要求に応答して、前記統計データに基づいて前記ネットワークに関するＱｏＳを実施するために前記ＱｏＳ構成情報の少なくとも一部を提供するように構成された、ＱｏＳ構成データベースと
を含むシステム。
【請求項２】
前記ＱｏＳ制御エンジンに関連付けられ、前記ＱｏＳ制御エンジンが前記統計データを維持できるように構成された、トラフィック・クラス・カウンタをさらに含む、請求項１に記載のシステム。
【請求項３】
前記トラフィック・タイプが、
音声、
映像、
データ、および
センサ
から構成されるグループから選択される、請求項１に記載のシステム。
【請求項４】
ＱｏＳ構成を動的に調整する方法であって、
ネットワークを介して伝達されるパケットのトラフィック・タイプを識別するステップと、
前記ネットワークのトラフィック・ミックスを示す統計データを維持するステップと、
前記統計データに基づいて前記ネットワークに関するＱｏＳを実施するためにＱｏＳ構成情報のうちの少なくともいくつかを自動的に提供するステップと
を含む方法。
【請求項５】
前記維持するステップがトラフィック・クラス・カウンタを更新するステップを含み、前記自動的に提供するステップが、
格納された複数のＱｏＳ構成のうちの１つを自動的に提供するステップ、および
動的にＱｏＳ構成を生成するために使用することができる値を自動的に提供するステップ
から構成されるグループから選択されたアクションを含む、請求項４に記載の方法。
【請求項６】
前記トラフィック・タイプが、
音声、
映像、
データ、および
センサ
から構成されるグループから選択される、請求項４に記載の方法。
【請求項７】
前記ＱｏＳ構成情報が、
音声中心ＱｏＳ構成、
映像中心ＱｏＳ構成、
データ中心ＱｏＳ構成、および
センサ中心ＱｏＳ構成
から構成されるグループから選択されたＱｏＳ構成を含む、請求項４に記載の方法。
【請求項８】
前記識別するステップが、前記パケットのＤｉｆｆＳｅｒｖ制御ポイントの値に基づいて前記トラフィック・タイプを識別するステップを含む、請求項４に記載の方法。
【請求項９】
前記トラフィック・タイプ毎に移動平均速度を計算するステップと、
それらに基づいてトラフィック・ミックスの候補を評価するステップと
をさらに含む、請求項４に記載の方法。
【請求項１０】
前記識別するステップが、前記ネットワークのノードを介して伝達されるすべてのパケットの前記トラフィック・タイプを識別するステップを含み、前記方法が、前記トラフィック・タイプ毎に移動平均速度を周期的に計算するステップをさらに含む、請求項４に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本出願は、一般にネットワーク管理に関し、より詳細には、リアルタイム・トラフィックに基づいてサービス品質（ＱｏＳ）の構成を動的に調整するためのシステムおよび方法に関する。
【背景技術】
【０００２】
次世代ネットワーキングが現れるにつれて、組織は自分達のネットワークにますます依拠し、インターネット・プロトコル（ＩＰ）通信およびミッション・クリティカルな情報を配信しつつある。ＩＰ電話通信および集中アプリケーションに向かう傾向が現実になるにつれて、今やネットワーク・インフラにＱｏＳを取り入れる必要が大きくなっている。ＱｏＳは、遅延に影響されるアプリケーションに優先度を与え、すべてのアプリケーションに対してネットワークをより効率的で信頼できるようにする、一組のメカニズムを含む。
【０００３】
ＱｏＳは、トラフィックに優先順位をつけ、ネットワーク・リソースを割り当て、その結果情報が円滑かつ予測通りにその宛先に到着するように設計される。それによって、トラフィックが共通する特徴に基づいてカテゴリに分類され、優先順位づけおよびサービスがユーザまたはアプリケーションのレベルで適用されることが可能になる。優先度のレベルは「ミッション・クリティカル」（最高優先度）から「ベスト・エフォート」（最低優先度）まで及ぶ。オーバ・プロビジョニング帯域幅はＱｏＳの使用を代替し、一部のネットワークでは帯域幅を管理する効果的な方法であるが、音声および映像のような遅延に影響されるトラフィックがその宛先に送信者が意図したように到着することを保証することはできない。ＱｏＳは、容量を追加せずに帯域幅およびトラフィックの管理をより効率的に使用することができ、したがって遅延に影響されるトラフィックの必要性を満たし、企業のリソース（例えば、帯域幅および設備投資）をより適切に使用する、魅力的な方法である。
【０００４】
所与のネットワークにおけるＱｏＳの挙動は、一組の選択可能なＱｏＳパラメータである、そのＱｏＳ構成に依存する。ＱｏＳパラメータは、ネットワークのＱｏＳの挙動を決定するＱｏＳアルゴリズムを調整する。すべての起こり得るトラフィック・シナリオに最適なＱｏＳ構成は存在しない。したがって、ＱｏＳパラメータは予期されるトラフィック・シナリオに基づいて選択すべきである。残念ながら、ＱｏＳアルゴリズムはより入り組んだものになりつつあり、ＱｏＳ構成をはるかに複雑にしている。ＱｏＳアルゴリズムの知識をほとんどまたは全くもたない通常のネットワーク管理者には、ＱｏＳパラメータを効果的に構成する機会がほとんどなく、トラフィック・シナリオが変化するに伴ってＱｏＳパラメータを調整するのを期待することはできない。
【発明の概要】
【０００５】
一態様は、ＱｏＳ構成を動的に調整するためのシステム、および、その中で前記システムまたは前記方法が使用されるネットワークを提供する。一実施形態では、システムは、（１）ネットワークを介して伝達されるパケットのトラフィック・タイプを識別し、ネットワークのトラフィック・ミックスを示す統計データを維持するように構成されたＱｏＳ制御エンジン、および（２）ＱｏＳ制御エンジンに結合され、トラフィック・タイプに対応するＱｏＳ構成情報を含むように構成され、ＱｏＳ制御エンジンからの要求に応答してネットワークに関するＱｏＳを実施するためにＱｏＳ構成情報の少なくとも一部を提供するように構成された、ＱｏＳ構成データベースを含む。
【０００６】
別の態様はＱｏＳ構成を動的に調整する方法を提供する。一実施形態では、方法は、（１）ネットワークを介して伝達されるパケットのトラフィック・タイプを識別すること、（２）ネットワークのトラフィック・ミックスを示す統計データを維持すること、および（３）統計データに基づいてネットワークに関するＱｏＳを実施するために格納された複数のＱｏＳ構成のうちの１つを自動的に提供することを含む。
【０００７】
さらに別の態様は、複数のトラフィック・タイプを伝えるように構成され、（１）複数のノード、ならびに、（２）ＱｏＳ構成を動的に調整するために少なくとも１つのノードと協働でき、（２ａ）ネットワークを介して伝達されるパケットのトラフィック・タイプを識別し、ネットワークを介して伝達されるパケットのトラフィック・タイプをＤｉｆｆＳｅｒｖ制御ポイント（ＤＳＣＰ）の値に基づいて識別するように構成されたＱｏＳ制御エンジン、および、（２ｂ）ＱｏＳ制御エンジンに結合され、トラフィック・タイプに対応するＱｏＳ構成情報を含むように構成され、ＱｏＳ制御エンジンからの要求に応答してネットワークに関するＱｏＳを実施するためにＱｏＳ構成情報の少なくとも一部を提供するように構成された、ＱｏＳ構成データベースを有するシステムを含む、ネットワークを提供する。
【０００８】
ここで添付図面と併用して以下の説明を参照する。
【図面の簡単な説明】
【０００９】
【図１】本明細書の教示に従って、その中で構築されるシステムまたは実施される方法が、そのようなシステムの一実施形態とともに使用することができる、ネットワークの一実施形態のブロック図である。
【図２】リアルタイム・トラフィックに基づいてＱｏＳ構成を動的に調整する方法の一実施形態の流れ図である。
【発明を実施するための形態】
【００１０】
さまざまな従来のネットワーク・アーキテクチャは、フローベースまたはクラスベースのＱｏＳメカニズムを提供する。フローベース・メカニズムは、リソース予約プロトコル（ＲＳＶＰ）を使用して、ネットワークを介した特定のデータ・フロー毎にネットワークのリソースを予約する、統合型サービス（ＩｎｔＳｅｒｖまたはＩＳ）を含む。
【００１１】
クラスベース・メカニズムは、「プロビジョンＱｏＳ」と呼ばれることがある、差別化サービス（ＤｉｆｆＳｅｒｖまたはＤＳ）を含む。特定のフローのためにリソースを予約する代わりに、ＤｉｆｆＳｅｒｖはトラフィックを優先順位づけされたサービス・クラス（ＣＯＳ）に分割し、次いで、クラスをホップバイホップ・ベースの集合フローとして扱う。現在のＤｉｆｆＳｅｒｖのＩＰ実装形態は８つのＣＯＳを定義する。これを達成するために、ＤｉｆｆＳｅｒｖはＩＰパケット・ヘッダの中の既存のサービス・タイプ（ＴＯＳ）欄をＤＳバイトとして符号化する標準方法を提供し、ＤＳバイトの最上位６ビットはＤＳＣＰとして定義される。ＤＳバイトの中の別の情報はホップ毎の振舞い（ＰＨＢ）を定義する。
【００１２】
ＩｎｔＳｅｒｖおよびＲＳＶＰに比べて、ＤｉｆｆＳｅｒｖは、実装するのにネットワーク・オーバヘッドを少ししか必要としない。その結果、ＤｉｆｆＳｅｒｖは、特により大きなネットワーク用の機器を製造するネットワーク機器製造業者の間で幅広い支持を受けた。ＤｉｆｆＳｅｒｖは、さまざまな製造業者からのルータを有するネットワークの中で、それらのルータがＤｉｆｆＳｅｒｖをサポートする限り有効に働く。
【００１３】
ＤｉｆｆＳｅｒｖを使用してネットワークの中のＱｏＳを手動で構成するための従来ツールが存在する。しかしながら、自動的にＱｏＳ構成を動的に調整するツールは存在しない。さらに、リアルタイム・トラフィック・ロードに基づいてＱｏＳ構成を調整するツールも存在しない。ネットワーク上のリアルタイム・トラフィック・ロードを判定することができ、トラフィック・ロードに基づいてＱｏＳ構成を調整することができる、さまざまなシステムおよび方法を本明細書において記載する。
【００１４】
本明細書に記載したさまざまな実施形態では、ＱｏＳ構成情報はＱｏＳ構成データベースの中に格納される。ある実施形態では、ＱｏＳ構成情報は、それら自体がＱｏＳ構成であるさまざまなトラフィック・シナリオ用の値のセットを含む。ある他の実施形態では、一緒に収集され、おそらく（例えば、補間、外挿、または、一部の他の機能もしくは関係によって）修正されて、動的にＱｏＳ構成を生成することができる値を、ＱｏＳ構成情報は含む。一部の実施形態では、（あらかじめ決定され、前もってＱｏＳ構成データベースに格納され、丸ごと取り出されるか、または、ＱｏＳ構成データベースの中に含まれるある特定の構成に基づいて動的に生成された）ＱｏＳ構成は、単一のトラフィック・タイプ（例えば、音声中心、映像中心、センサ中心またはデータ中心）によって特色づけられたトラフィック・ミックスに対応する。他の実施形態では、ＱｏＳ構成は、（その中で、音声／映像中心、またはセンサ／データ中心など、複数のトラフィック・タイプが特色づける）混合トラフィック・ミックスに対応する。ＱｏＳ構成の動的生成に関して、ＱｏＳ構成は調整するのがしばしば困難であり、広範なシミュレーションを頻繁に必要とすることは、述べておくべきである。その結果、構成情報から動的にＱｏＳ構成を生成することは、あらかじめ決定されたＱｏＳ構成を丸ごと取り出すのとは対照的に、困難である可能性がある。
【００１５】
ＱｏＳ制御エンジンは、少なくとも間断なく（おそらく中断ありで）ネットワークのトラフィック・ロードを監視する。一部の実施形態では、ＱｏＳ制御エンジンは間断なく（中断なしで）トラフィック・ロードを監視する。また、ＱｏＳ制御エンジンは、少なくとも時々（少なくとも１度、１度より多い場合非周期的または周期的に、おそらく明確な命令または既定のネットワーク状態に応答して）、トラフィック・ロード・シナリオが変化したかどうかを判定する。一部の実施形態では、ＱｏＳ制御エンジンは、周期的に（一定間隔で繰り返し）、トラフィック・ロード・シナリオが変化したかどうかを判定する。ＱｏＳ制御エンジンが、トラフィック・ロード・シナリオが変化したと判定する場合、ＱｏＳ制御エンジンによって、対応する適切なＱｏＳ構成がＱｏＳ構成データベースから生成され（例えば、取り出され）、ネットワークのＱｏＳを調整するために使用されることが可能になる。
【００１６】
例えば、ネットワークのＱｏＳが、ネットワークが主として音声トラフィック（「音声中心」）を伝えると最初に仮定する場合、音声中心トラフィック用に適切なＱｏＳ構成が、最初にネットワークのＱｏＳを設定するために適切に使用される。しかしながら、おそらく本明細書において教示した自動トラフィック解析によって、その後、ネットワークが代わりに主として映像トラフィック（「映像中心」）を伝えることが発見される場合がある。本明細書に記載したように、この場合、ネットワークのＱｏＳを調整するためにさまざまなＱｏＳ構成を使用することができる。したがって、ＱｏＳ構成は、ネットワークが現在処理しているトラフィック用に適切であり続けるように、動的に調整される。その結果ＱｏＳは改善される。
【００１７】
例えば、ネットワークは、ＤｉｆｆＳｅｒｖベースのＱｏＳを実装し、１４個の異なるトラフィック・クラスをサポートすることができる。したがって、各トラフィック・クラスは、ユニークなＤＳＣＰにマップされるはずである。ＤｉｆｆＳｅｒｖによれば、同じトラフィック・クラスに属するすべてのパケットは、同じ転送処理が提供される。ネットワークはさまざまなＱｏＳアルゴリズムを使用することができるが、この例の中のネットワークは、さまざまなアプリケーションの間で共有する帯域幅用の、よく知られている階層型トークン・バケット（ＨＴＢ）ＱｏＳアルゴリズムを使用する。ＨＴＢアルゴリズムは、優先度、保証速度、上限速度、待ち行列の長さおよび推定量値などの、さまざまなＱｏＳパラメータを有する。各ＨＴＢ  ＱｏＳパラメータの最適値は、トラフィック・シナリオに依存する。上述したように、パラメータの単一のＱｏＳ構成がすべてのトラフィック・シナリオに対して最適ではあり得ない。慣例的に、ネットワーク管理者は、さまざまなデフォルトのＱｏＳ構成（例えば、音声中心、映像中心、センサ中心、およびデータ中心の構成）から、所与の予想されるトラフィック・ミックス用に適切なＱｏＳ構成を、手動で選択することができる。時間の経過とともに、トラフィック・ミックスは変化しがちである。例えば、かつては映像中心であったトラフィック・ミックスが、後で音声中心になる場合がある。その結果、映像中心のトラフィック・ミックス用に調整された構成パラメータは、音声中心または映像／センサ中心のトラフィック・ミックス用には十分でない。慣例的に、ネットワーク管理者は、トラフィック・ミックスが変化したことを最初に検出し、次に新しいトラフィック・ミックスを識別し、次いで、新しいトラフィック・ミックスに適合する構成を手動で選択しロードしなければならない。
【００１８】
対照的に、さまざまなシステムおよび方法が本明細書において紹介され、それによってネットワーク上のリアルタイム・トラフィック・ロードを判定することができ、そのトラフィック・ロードに基づいてＱｏＳ構成を調整することができる。ここで図１に目を向けると、ネットワーク１００の一実施形態のブロック図が例示され、その中で、本明細書における教示に従って構築されたシステム、または実施された方法を使用することができる。図１の実施形態では、ＱｏＳ制御エンジン１１０が複数のトラフィック・クラス・カウンタ１２０およびＱｏＳ構成データベース１３０に関連している。トラフィック・クラス・カウンタ１２０は、音声トラフィック・カウンタ１２１、映像トラフィック・カウンタ１２２、データ・トラフィック・カウンタ１２３およびセンサ・トラフィック・カウンタ１２４を含む。ＱｏＳ構成データベース１３０は、音声中心ＱｏＳ構成１３１、映像中心ＱｏＳ構成１３２、データ中心ＱｏＳ構成１３３およびセンサ中心ＱｏＳ構成１３４を含む。代替の実施形態では、ＱｏＳ構成データベース１３０は、代わりに、または、さらに、ＱｏＳ制御エンジン１１０が動的にＱｏＳ構成を生成するために使用することができる、ＱｏＳ構成情報を含む。
【００１９】
図１が示すように、ネットワーク１００は、音声トラフィック、映像トラフィック、データ・トラフィックおよびセンサ・トラフィックを含む混成のトラフィックを、受信、伝達および送信する。混成のトラフィックを伝達するパケット１５０はＱｏＳ制御エンジン１１０に供給され、そこで、それらのトラフィック・クラスの観点から識別され、トラフィック・クラス・カウンタ１２０（すなわち、音声トラフィック・カウンタ１２１、映像トラフィック・カウンタ１２２、データ・トラフィック・カウンタ１２３およびセンサ・トラフィック・カウンタ１２４）のうちの対応するカウンタがそれに応じて更新される。例示された実施形態では、すべてのパケット１５０は、ネットワーク１００を通過するときＱｏＳ制御エンジン１１０に供給される。次いで、ＱｏＳ制御エンジン１１０は各パケットのＤＳＣＰ値を読み取る。例示された実施形態では、ＱｏＳ制御エンジン１１０は、あらゆるアクセス・インタフェースのノードに入る各パケットのＤＳＣＰ値を読み取る。したがって、トラフィック・クラス・カウンタ１２０は、トラフィック・ミックスを示す実行中のリアルタイム統計データを維持することができる。
【００２０】
下記でより詳細に記載するように、ＱｏＳ制御エンジン１１０はトラフィック・クラス・カウンタ１２０を使用してトラフィック・ミックスを判定し、対応するＱｏＳ構成（すなわち、音声中心ＱｏＳ構成１３１、映像中心ＱｏＳ構成１３２、データ中心ＱｏＳ構成１３３およびセンサ中心ＱｏＳ構成１３４）をＱｏＳ構成データベース１３０から取り出す。あるいは、ＱｏＳ制御エンジン１１０は、例えば、何らかの方法で情報を組み立て、修正、または、組み立ておよび修正することにより、ＱｏＳ構成データベース１３０の中に含まれるＱｏＳ構成情報から、適切なＱｏＳ構成を動的に生成することができる。ＱｏＳ制御エンジン１１０は、速度計算機１１１を使用してパケット速度の実行カウントを保持し、トラフィック・ミックスが経時的にどのように変化したかを判定する。図１が示すように、次いで、ＱｏＳ制御エンジン１１０は、取り出されたＱｏＳ構成を使用してＱｏＳ１６０をネットワークに供給し、その中でネットワークがトラフィック・ミックスのその伝達に優先順位をつける方式を適応させる。
【００２１】
一実施形態では、その中でシステムまたは方法が使用されるネットワークの例は、１４個のトラフィック・クラスをサポートするＱｏＳモデルを有する。下記表１は、１４個のユニークなＤＳＣＰ（欄３）にマップされ、５つの一般トラフィック・タイプ（欄１）に分類された、１４個のトラフィック・クラス（欄２）の一例を示す。他の実施形態が、異なるタイプおよび数の一般トラフィック・タイプ、トラフィック・クラスおよびＤＳＣＰへのマッピングのカテゴリおよび数を有することを、当業者は理解されよう。
【００２２】
【表１】
0005570652.tif 000002
【００２３】
図１の実施形態では、ＱｏＳ制御エンジン１１０は、あらゆるアクセス・インタフェースのノードに入る各パケットのＤＳＣＰ値を読み取る。一実施形態では、各ノードは６つのアクセス・インタフェースを有する。下記表２はノードの例示的な実施形態を説明し、そのようなインタフェースがどのように分配することができるかを示す。
【００２４】
【表２】
0005570652.tif 000003
【００２５】
上述したように、一実施形態は、４つのデフォルトのＱｏＳ構成を提供し、それぞれが異なるトラフィック・モデルの、音声中心、映像中心、データ中心およびセンサ中心に対応する。したがって、トラフィック・クラス・カウンタ１２０は、各一般トラフィック・タイプ用の４つの別々のカウンタ（すなわち、音声トラフィック・カウンタ１２１、映像トラフィック・カウンタ１２２、データ・トラフィック・カウンタ１２３およびセンサ・トラフィック・カウンタ１２４）を含む。下記表３は、トラフィック・ミックス（欄１）、ＱｏＳ構成（欄２）およびトラフィック・クラス・カウンタ（欄３）の間の対応関係を示す。
【００２６】
【表３】
0005570652.tif 000004
【００２７】
表１〜３を参照して、所与のネットワーク・ノードのいずれかのアクセス・インタフェースにパケットが到着すると、入力パケットのＤＳＣＰが読み取られる。入力パケットのＤＳＣＰが音声トラフィック・タイプ（すなわち、音声−高優先度、音声−中優先度または音声−低優先度）にマップする場合、音声カウンタが更新される。入力パケットのＤＳＣＰが映像トラフィック・タイプ（すなわち、映像−高優先度、映像−中優先度または映像−低優先度のトラフィック）にマップする場合、映像カウンタが更新される。入力パケットのＤＳＣＰがセンサ・トラフィック・タイプ（すなわち、センサ−高優先度、センサ−中優先度またはセンサ−低優先度）にマップする場合、センサ・カウンタが更新される。ＤＳＣＰがデータ・トラフィック・タイプ（すなわち、データベース同期またはベスト・エフォート）にマップする場合、データ・カウンタが更新される。この例では、ＤＳＣＰがネットワーク管理トラフィック・タイプ（すなわち、ルーティングおよびネットワークの制御；遭難連絡、避難命令および重大通信、またはセッション初期化プロトコル信号）にマップする場合、どのカウンタも更新されない。この理由は、ネットワーク・オーバヘッドを表すパケットを除いてネットワークが伝えるペイロード・パケット上の適切なＱｏＳ構成の選択に基づかないという考えである。
【００２８】
時々、および、おそらく周期的に、ＱｏＳ制御エンジン１１０は、音声、映像、センサおよびデータのトラフィック用カウンタ（すなわち、音声カウンタ１２１、映像カウンタ１２２、データ・カウンタ１２３およびセンサ・カウンタ１２４）を比較して、トラフィックが音声中心、映像中心、センサ中心またはデータ中心に向かったかどうかを判定する。トラフィック・モデルが変化した場合、ＱｏＳ制御エンジン１１０は、より適切なＱｏＳ構成のパラメータに従ってパラメータの値を変更する。次いで、カウンタがリセットされ、処理は間隔毎に繰り返される。
【００２９】
図２は、リアルタイム・トラフィックに基づいてＱｏＳ構成を動的に調整する方法の一実施形態の流れ図である。一般に、方法は２つの部分：トラフィック監視部分および動的ＱｏＳ調整部分に分割される。図２は破線の中にこれら２つの部分を示す。
【００３０】
方法は開始ステップ２１０で始まる。ステップ２２０では、パケットが受信される。ステップ２３０では、パケットが読み取られてパケットが属するトラフィック・クラスが判定される。一実施形態では、ＤＳＣＰが読み取られてパケットが属するトラフィック・クラスが判定される。ステップ２４０では、パケットが属するトラフィック・クラスに対応するトラフィック・カウンタが更新される。さらなるパケットが受信されると、ステップ２２０、２３０、２４０が繰り返される。
【００３１】
ステップ２５０では、カウンタ、および、カウンタの値をお互いと比較するための多くの可能な技法のうちの１つを使用することにより、ロード・シナリオが決定される。ステップ２６０では、ＱｏＳ構成情報が取り出される。ＱｏＳ構成情報は、あらかじめ決定されたＱｏＳ構成、または、ステップ２５０で決定されたロード・シナリオに適切なＱｏＳ構成を生成するために使用することができる値であり得る。ステップ２７０では、ネットワークのＱｏＳ構成が設定される。さまざまな実施形態では、トラフィックは監視され続け、それに従ってＱｏＳは間断なく動的に調整される。
【００３２】
システムおよび方法のさまざまな実施形態を記載したので、ここで実施形態の例を記載する。音声、映像、センサおよびデータのトラフィック用のトラフィック・クラス・カウンタが、所与のネットワーク１００のために確立される。次いで、ＱｏＳ制御エンジン１１０は、ネットワーク１００の所与のノードに入るあらゆるパケットのＤＳＣＰを調査し、それに応じてカウンタのうちの対応するカウンタの値を増加させる。
【００３３】
ＱｏＳ制御エンジン１１０は毎秒カウンタを読み取る。ＱｏＳ制御エンジン１１０は、カウンタを読み取った後それらをリセットする。カウンタから読み取った値は、パケット毎秒で表現される各トラフィック・タイプの平均速度を示す。次いで、速度計算機１１１は以下の数式を使用して、トラフィック・タイプ毎にパケットの指数移動平均速度を計算する。
ＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅ（ｔ）＝Ｃｕｒｒｅｎｔ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅ＊α＋ＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅ（ｔ−Ｔ）
ここでα＝２／（１＋Ｎ）およびＮ＝移動平均の期間の中に含まれる時間間隔の数である。
【００３４】
ＱｏＳ制御エンジン１１０の構成選択モジュールは、Ｔ時間単位毎に、トラフィック・タイプ毎のＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅを読み取る。最も高いＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅを有するトラフィック・タイプが候補として選択される。複数のトラフィック・タイプが同じＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅを有する場合、複数のトラフィック・タイプのそれぞれが候補として選択される。ＱｏＳ制御エンジン１００は候補選択の実行記録を保持する。
【００３５】
Ｎ回のＥＭＡ＿Ａｖｇ＿Ｐｋｔ＿Ｒａｔｅの読取りが完了した後、例示的な実施形態は以下の技法を使用して、どのＱｏＳ構成を選択すべきかを判定する。
ステップ１−Ｎ回の繰り返しで、最も多くの回数、候補として選択されたトラフィック・タイプが最終候補として選択される。
ステップ２−同点の場合、最も多くの回数連続して候補として選択されたトラフィック・タイプが最終候補である。
ステップ３−最終候補に対応するＱｏＳ構成がローディング用に選択される。
ステップ１〜３がＭ＊Ｎ＊Ｔ時間単位毎に繰り返される。ステップ１〜３が繰り返される毎にロード・シナリオが決定される。
【００３６】
下記表４は、候補選択を７回（Ｎ＝７）繰り返した結果の例を記録する。
【００３７】
【表４】
0005570652.tif 000005
表４が示すように、上述の技法のステップ１は、音声と映像のどちらも最も多い（５回）回数、候補として選択されたので、音声および映像のトラフィック・タイプを最終候補として選択する。次いで、技法のステップ２は、音声が最も多い回数連続して最終候補として選択されたので、音声を最終候補として選択する。次いで、技法のステップ３は、現在のロード・シナリオが音声中心であると結論づけ、音声中心ＱｏＳ構成（すなわち、音声中心ＱｏＳ構成１３１）がロードされることを可能にする。
【００３８】
本願が関連する当業者なら、他の、およびさらなる追加、削除、交換、および修正が、記載した実施形態に対して実施できることを理解されよう。
【図１】
0005570652.tif 000006
【図２】
0005570652.tif 000007