QoS構成を動的に調整するためのシステムであって、ネットワークを介して伝達されるパケットのトラフィックタイプを識別し、前記ネットワークのトラフィックミックスを示す統計データを維持するように構成されたQoS制御エンジンと、前記QoS制御エンジンに結合され、前記トラフィックタイプに対応するQoS構成情報を含むように構成され、前記QoS制御エンジンからの要求に応答して前記ネットワークに関するQoSを実施するために前記QoS構成情報の少なくとも一部を提供するように構成された、QoS構成データベースとを含むシステム。前記QoS制御エンジンに関連付けられ、前記QoS制御エンジンが前記統計データを維持できるように構成された、トラフィッククラスカウンタをさらに含む、請求項1に記載のシステム。前記トラフィックタイプが、音声、映像、データ、およびセンサから構成されるグループから選択される、請求項1に記載のシステム。QoS構成を動的に調整する方法であって、ネットワークを介して伝達されるパケットのトラフィックタイプを識別するステップと、前記ネットワークのトラフィックミックスを示す統計データを維持するステップと、前記統計データに基づいて前記ネットワークに関するQoSを実施するために前記QoS構成のうちの少なくともいくつかを自動的に提供するステップとを含む方法。前記維持するステップがトラフィッククラスカウンタを更新するステップを含み、前記自動的に提供するステップが、格納された複数のQoS構成のうちの1つを自動的に提供するステップ、および動的にQoS構成を生成するために使用することができる値を自動的に提供するステップから構成されるグループから選択されたアクションを含む、請求項4に記載の方法。前記トラフィックタイプが、音声、映像、データ、およびセンサから構成されるグループから選択される、請求項4に記載の方法。前記QoS構成情報が、音声中心QoS構成、映像中心QoS構成、データ中心QoS構成、およびセンサ中心QoS構成から構成されるグループから選択されたQoS構成を含む、請求項4に記載の方法。前記識別するステップが、前記パケットのDiffServ制御ポイントの値に基づいて前記トラフィックタイプを識別するステップを含む、請求項4に記載の方法。前記トラフィックタイプ毎に移動平均速度を計算するステップと、それらに基づいてトラフィックミックスの候補を評価するステップとをさらに含む、請求項4に記載の方法。前記識別するステップが、前記ネットワークのノードを介して伝達されるすべてのパケットの前記トラフィックタイプを識別するステップを含み、前記方法が、前記トラフィックタイプ毎に移動平均速度を周期的に計算するステップをさらに含む、請求項4に記載の方法。さまざまな従来のネットワークアーキテクチャは、フローベースまたはクラスベースのQoSメカニズムを提供する。フローベースメカニズムは、リソース予約プロトコルRSVPを使用して、ネットワークを介した特定のデータフロー毎にネットワークのリソースを予約する、統合型サービスIntServまたはISを含む。クラスベースメカニズムは、プロビジョンQoSと呼ばれることがある、差別化サービスDiffServまたはDSを含む。特定のフローのためにリソースを予約する代わりに、DiffServはトラフィックを優先順位づけされたサービスクラスCOSに分割し、次いで、クラスをホップバイホップベースの集合フローとして扱う。現在のDiffServのIP実装形態は8つのCOSを定義する。これを達成するために、DiffServはIPパケットヘッダの中の既存のサービスタイプTOS欄をDSバイトとして符号化する標準方法を提供し、DSバイトの最上位6ビットはDSCPとして定義される。DSバイトの中の別の情報はホップ毎の振舞いPHBを定義する。IntServおよびRSVPに比べて、DiffServは、実装するのにネットワークオーバヘッドを少ししか必要としない。その結果、DiffServは、特により大きなネットワーク用の機器を製造するネットワーク機器製造業者の間で幅広い支持を受けた。DiffServは、さまざまな製造業者からのルータを有するネットワークの中で、それらのルータがDiffServをサポートする限り有効に働く。DiffServを使用してネットワークの中のQoSを手動で構成するための従来ツールが存在する。しかしながら、自動的にQoS構成を動的に調整するツールは存在しない。さらに、リアルタイムトラフィックロードに基づいてQoS構成を調整するツールも存在しない。ネットワーク上のリアルタイムトラフィックロードを判定することができ、トラフィックロードに基づいてQoS構成を調整することができる、さまざまなシステムおよび方法を本明細書において記載する。本明細書に記載したさまざまな実施形態では、QoS構成情報はQoS構成データベースの中に格納される。ある実施形態では、QoS構成情報は、それら自体がQoS構成であるさまざまなトラフィックシナリオ用の値のセットを含む。ある他の実施形態では、一緒に収集され、おそらく例えば、補間、外挿、または、一部の他の機能もしくは関係によって修正されて、動的にQoS構成を生成することができる値を、QoS構成情報は含む。一部の実施形態では、あらかじめ決定され、前もってQoS構成データベースに格納され、丸ごと取り出されるか、または、QoS構成データベースの中に含まれるある特定の構成に基づいて動的に生成されたQoS構成は、単一のトラフィックタイプ例えば、音声中心、映像中心、センサ中心またはデータ中心によって特色づけられたトラフィックミックスに対応する。他の実施形態では、QoS構成は、その中で、音声/映像中心、またはセンサ/データ中心など、複数のトラフィックタイプが特色づける混合トラフィックミックスに対応する。QoS構成の動的生成に関して、QoS構成は調整するのがしばしば困難であり、広範なシミュレーションを頻繁に必要とすることは、述べておくべきである。その結果、構成情報から動的にQoS構成を生成することは、あらかじめ決定されたQoS構成を丸ごと取り出すのとは対照的に、困難である可能性がある。QoS制御エンジンは、少なくとも間断なくおそらく中断ありでネットワークのトラフィックロードを監視する。一部の実施形態では、QoS制御エンジンは間断なく中断なしでトラフィックロードを監視する。また、QoS制御エンジンは、少なくとも時々少なくとも1度、1度より多い場合非周期的または周期的に、おそらく明確な命令または既定のネットワーク状態に応答して、トラフィックロードシナリオが変化したかどうかを判定する。一部の実施形態では、QoS制御エンジンは、周期的に一定間隔で繰り返し、トラフィックロードシナリオが変化したかどうかを判定する。QoS制御エンジンが、トラフィックロードシナリオが変化したと判定する場合、QoS制御エンジンによって、対応する適切なQoS構成がQoS構成データベースから生成され例えば、取り出され、ネットワークのQoSを調整するために使用されることが可能になる。例えば、ネットワークのQoSが、ネットワークが主として音声トラフィック音声中心を伝えると最初に仮定する場合、音声中心トラフィック用に適切なQoS構成が、最初にネットワークのQoSを設定するために適切に使用される。しかしながら、おそらく本明細書において教示した自動トラフィック解析によって、その後、ネットワークが代わりに主として映像トラフィック映像中心を伝えることが発見される場合がある。本明細書に記載したように、この場合、ネットワークのQoSを調整するためにさまざまなQoS構成を使用することができる。したがって、QoS構成は、ネットワークが現在処理しているトラフィック用に適切であり続けるように、動的に調整される。その結果QoSは改善される。例えば、ネットワークは、DiffServベースのQoSを実装し、14個の異なるトラフィッククラスをサポートすることができる。したがって、各トラフィッククラスは、ユニークなDSCPにマップされるはずである。DiffServによれば、同じトラフィッククラスに属するすべてのパケットは、同じ転送処理が提供される。ネットワークはさまざまなQoSアルゴリズムを使用することができるが、この例の中のネットワークは、さまざまなアプリケーションの間で共有する帯域幅用の、よく知られている階層型トークンバケットHTBQoSアルゴリズムを使用する。HTBアルゴリズムは、優先度、保証速度、上限速度、待ち行列の長さおよび推定量値などの、さまざまなQoSパラメータを有する。各HTBQoSパラメータの最適値は、トラフィックシナリオに依存する。上述したように、パラメータの単一のQoS構成がすべてのトラフィックシナリオに対して最適ではあり得ない。慣例的に、ネットワーク管理者は、さまざまなデフォルトのQoS構成例えば、音声中心、映像中心、センサ中心、およびデータ中心の構成から、所与の予想されるトラフィックミックス用に適切なQoS構成を、手動で選択することができる。時間の経過とともに、トラフィックミックスは変化しがちである。例えば、かつては映像中心であったトラフィックミックスが、後で音声中心になる場合がある。その結果、映像中心のトラフィックミックス用に調整された構成パラメータは、音声中心または映像/センサ中心のトラフィックミックス用には十分でない。慣例的に、ネットワーク管理者は、トラフィックミックスが変化したことを最初に検出し、次に新しいトラフィックミックスを識別し、次いで、新しいトラフィックミックスに適合する構成を手動で選択しロードしなければならない。対照的に、さまざまなシステムおよび方法が本明細書において紹介され、それによってネットワーク上のリアルタイムトラフィックロードを判定することができ、そのトラフィックロードに基づいてQoS構成を調整することができる。ここで図1に目を向けると、ネットワーク100の一実施形態のブロック図が例示され、その中で、本明細書における教示に従って構築されたシステム、または実施された方法を使用することができる。図1の実施形態では、QoS制御エンジン110が複数のトラフィッククラスカウンタ120およびQoS構成データベース130に関連している。トラフィッククラスカウンタ120は、音声トラフィックカウンタ121、映像トラフィックカウンタ122、データトラフィックカウンタ123およびセンサトラフィックカウンタ124を含む。QoS構成データベース130は、音声中心QoS構成131、映像中心QoS構成132、データ中心QoS構成133およびセンサ中心QoS構成134を含む。代替の実施形態では、QoS構成データベース130は、代わりに、または、さらに、QoS制御エンジン110が動的にQoS構成を生成するために使用することができる、QoS構成情報を含む。図1が示すように、ネットワーク100は、音声トラフィック、映像トラフィック、データトラフィックおよびセンサトラフィックを含む混成のトラフィックを、受信、伝達および送信する。混成のトラフィックを伝達するパケット150はQoS制御エンジン110に供給され、そこで、それらのトラフィッククラスの観点から識別され、トラフィッククラスカウンタ120すなわち、音声トラフィックカウンタ121、映像トラフィックカウンタ122、データトラフィックカウンタ123およびセンサトラフィックカウンタ124のうちの対応するカウンタがそれに応じて更新される。例示された実施形態では、すべてのパケット150は、ネットワーク100を通過するときQoS制御エンジン110に供給される。次いで、QoS制御エンジン110は各パケットのDSCP値を読み取る。例示された実施形態では、QoS制御エンジン110は、あらゆるアクセスインタフェースのノードに入る各パケットのDSCP値を読み取る。したがって、トラフィッククラスカウンタ120は、トラフィックミックスを示す実行中のリアルタイム統計データを維持することができる。下記でより詳細に記載するように、QoS制御エンジン110はトラフィッククラスカウンタ120を使用してトラフィックミックスを判定し、対応するQoS構成すなわち、音声中心QoS構成131、映像中心QoS構成132、データ中心QoS構成133およびセンサ中心QoS構成134をQoS構成データベース130から取り出す。あるいは、QoS制御エンジン110は、例えば、何らかの方法で情報を組み立て、修正、または、組み立ておよび修正することにより、QoS構成データベース130の中に含まれるQoS構成情報から、適切なQoS構成を動的に生成することができる。QoS制御エンジン110は、速度計算機111を使用してパケット速度の実行カウントを保持し、トラフィックミックスが経時的にどのように変化したかを判定する。図1が示すように、次いで、QoS制御エンジン110は、取り出されたQoS構成を使用してQoS160をネットワークに供給し、その中でネットワークがトラフィックミックスのその伝達に優先順位をつける方式を適応させる。一実施形態では、その中でシステムまたは方法が使用されるネットワークの例は、14個のトラフィッククラスをサポートするQoSモデルを有する。下記表1は、14個のユニークなDSCP欄3にマップされ、5つの一般トラフィックタイプ欄1に分類された、14個のトラフィッククラス欄2の一例を示す。他の実施形態が、異なるタイプおよび数の一般トラフィックタイプ、トラフィッククラスおよびDSCPへのマッピングのカテゴリおよび数を有することを、当業者は理解されよう。図1の実施形態では、QoS制御エンジン110は、あらゆるアクセスインタフェースのノードに入る各パケットのDSCP値を読み取る。一実施形態では、各ノードは6つのアクセスインタフェースを有する。下記表2はノードの例示的な実施形態を説明し、そのようなインタフェースがどのように分配することができるかを示す。上述したように、一実施形態は、4つのデフォルトのQoS構成を提供し、それぞれが異なるトラフィックモデルの、音声中心、映像中心、データ中心およびセンサ中心に対応する。したがって、トラフィッククラスカウンタ120は、各一般トラフィックタイプ用の4つの別々のカウンタすなわち、音声トラフィックカウンタ121、映像トラフィックカウンタ122、データトラフィックカウンタ123およびセンサトラフィックカウンタ124を含む。下記表3は、トラフィックミックス欄1、QoS構成欄2およびトラフィッククラスカウンタ欄3の間の対応関係を示す。表1~3を参照して、所与のネットワークノードのいずれかのアクセスインタフェースにパケットが到着すると、入力パケットのDSCPが読み取られる。入力パケットのDSCPが音声トラフィックタイプすなわち、音声-高優先度、音声-中優先度または音声-低優先度にマップする場合、音声カウンタが更新される。入力パケットのDSCPが映像トラフィックタイプすなわち、映像-高優先度、映像-中優先度または映像-低優先度のトラフィックにマップする場合、映像カウンタが更新される。入力パケットのDSCPがセンサトラフィックタイプすなわち、センサ-高優先度、センサ-中優先度またはセンサ-低優先度にマップする場合、センサカウンタが更新される。DSCPがデータトラフィックタイプすなわち、データベース同期またはベストエフォートにマップする場合、データカウンタが更新される。この例では、DSCPがネットワーク管理トラフィックタイプすなわち、ルーティングおよびネットワークの制御;遭難連絡、避難命令および重大通信、またはセッション初期化プロトコル信号にマップする場合、どのカウンタも更新されない。この理由は、ネットワークオーバヘッドを表すパケットを除いてネットワークが伝えるペイロードパケット上の適切なQoS構成の選択に基づかないという考えである。時々、および、おそらく周期的に、QoS制御エンジン110は、音声、映像、センサおよびデータのトラフィック用カウンタすなわち、音声カウンタ121、映像カウンタ122、データカウンタ123およびセンサカウンタ124を比較して、トラフィックが音声中心、映像中心、センサ中心またはデータ中心に向かったかどうかを判定する。トラフィックモデルが変化した場合、QoS制御エンジン110は、より適切なQoS構成のパラメータに従ってパラメータの値を変更する。次いで、カウンタがリセットされ、処理は間隔毎に繰り返される。図2は、リアルタイムトラフィックに基づいてQoS構成を動的に調整する方法の一実施形態の流れ図である。一般に、方法は2つの部分:トラフィック監視部分および動的QoS調整部分に分割される。図2は破線の中にこれら2つの部分を示す。方法は開始ステップ210で始まる。ステップ220では、パケットが受信される。ステップ230では、パケットが読み取られてパケットが属するトラフィッククラスが判定される。一実施形態では、DSCPが読み取られてパケットが属するトラフィッククラスが判定される。ステップ240では、パケットが属するトラフィッククラスに対応するトラフィックカウンタが更新される。さらなるパケットが受信されると、ステップ220、230、240が繰り返される。ステップ250では、カウンタ、および、カウンタの値をお互いと比較するための多くの可能な技法のうちの1つを使用することにより、ロードシナリオが決定される。ステップ260では、QoS構成情報が取り出される。QoS構成情報は、あらかじめ決定されたQoS構成、または、ステップ250で決定されたロードシナリオに適切なQoS構成を生成するために使用することができる値であり得る。ステップ270では、ネットワークのQoS構成が設定される。さまざまな実施形態では、トラフィックは監視され続け、それに従ってQoSは間断なく動的に調整される。システムおよび方法のさまざまな実施形態を記載したので、ここで実施形態の例を記載する。音声、映像、センサおよびデータのトラフィック用のトラフィッククラスカウンタが、所与のネットワーク100のために確立される。次いで、QoS制御エンジン110は、ネットワーク100の所与のノードに入るあらゆるパケットのDSCPを調査し、それに応じてカウンタのうちの対応するカウンタの値を増加させる。QoS制御エンジン110は毎秒カウンタを読み取る。QoS制御エンジン110は、カウンタを読み取った後それらをリセットする。カウンタから読み取った値は、パケット毎秒で表現される各トラフィックタイプの平均速度を示す。次いで、速度計算機111は以下の数式を使用して、トラフィックタイプ毎にパケットの指数移動平均速度を計算する。EMA_Avg_Pkt_Ratet=Current_Avg_Pkt_RateαEMA_Avg_Pkt_Ratet-Tここでα=2/1NおよびN=移動平均の期間の中に含まれる時間間隔の数である。QoS制御エンジン110の構成選択モジュールは、T時間単位毎に、トラフィックタイプ毎のEMA_Avg_Pkt_Rateを読み取る。最も高いEMA_Avg_Pkt_Rateを有するトラフィックタイプが候補として選択される。複数のトラフィックタイプが同じEMA_Avg_Pkt_Rateを有する場合、複数のトラフィックタイプのそれぞれが候補として選択される。QoS制御エンジン100は候補選択の実行記録を保持する。N回のEMA_Avg_Pkt_Rateの読取りが完了した後、例示的な実施形態は以下の技法を使用して、どのQoS構成を選択すべきかを判定する。ステップ1-N回の繰り返しで、最も多くの回数、候補として選択されたトラフィックタイプが最終候補として選択される。ステップ2-同点の場合、最も多くの回数連続して候補として選択されたトラフィックタイプが最終候補である。ステップ3-最終候補に対応するQoS構成がローディング用に選択される。ステップ1~3がMNT時間単位毎に繰り返される。ステップ1~3が繰り返される毎にロードシナリオが決定される。下記表4は、候補選択を7回N=7繰り返した結果の例を記録する。表4が示すように、上述の技法のステップ1は、音声と映像のどちらも最も多い5回回数、候補として選択されたので、音声および映像のトラフィックタイプを最終候補として選択する。次いで、技法のステップ2は、音声が最も多い回数連続して最終候補として選択されたので、音声を最終候補として選択する。次いで、技法のステップ3は、現在のロードシナリオが音声中心であると結論づけ、音声中心QoS構成すなわち、音声中心QoS構成131がロードされることを可能にする。本願が関連する当業者なら、他の、およびさらなる追加、削除、交換、および修正が、記載した実施形態に対して実施できることを理解されよう。