JP2002515217A - 予測帯域幅配分方法及び装置 - Google Patents

Abstract

(57)【要約】 電気通信システムの帯域幅の配分が予測的方法で好ましく行われる。パケットは特定のデータ・ストリームで識別され、将来の帯域幅必要量を子測するためにそのデータ・ストリームの特性が使用される。その予測は、その予測された必要量に応じてＩＳＤＮのＢチャネル等の広帯域幅チャネルを配分し、チャネルを閉じ或いは切り換えるために使われる。好ましくは、そのシステムは自己学習型であり、例えば実際の使用統計に基づいて配分決定を行うためにルール・ベースを修正することができる。

Description

【発明の詳細な説明】 予測帯域幅配分方法及び装置 発明の分野 本発明は、好ましくは通信コストに対する配分の効果を考慮して、データ・ ストリームのサイズその他の特徴の予測に基づいて、パケット又はその他の通信 メッセージへの順位付け及び／又はＩＳＤＮベアラー・チャネルの配分等の、帯 域幅の配分を可能にするものである。 発明の背景 初期の電気通信では、今ではＰＯＴＳ（plain old telephone service（簡 素な旧式電話サービス））と呼ばれているものに属する、ユーザーが利用できる サービスオプションは非常に少なくて、しばしば引き込み線の数の選択、専用回 線サービス或いは“共同加入線サービス、そして大規模ユーザー向けの構内交換 （ＰＢＸ）の選択に限られていた。対照的に、現代のユーザーは、（ＰＯＴＳの 他に）ＩＳＤＮ（Integrated Services Digital Network（サービス総合ディジ タル通信網））、Ｔ１サービス、セルラー・サービス等を含む、長所、短所及び コストを各々有する種々のサービスから選択をすることができる。電気通信の利 用が音声通話を越えて拡大して、テレファクシミリ（ファックス）、ディジタル （又は音声変調ディジタル）信号（例えばネットワーク又はインターネット通信 に使用される）等を含むようになってきて、広帯域幅電気通信の可能性を与える ＩＳＤＮ及びＴ１等のサービスが特に重要になっている。ビデオ情報、ディジタ ル・ファイル転送、静止画像、ストリーミング・オーディオ等の、或る種の情報 の通信は（しばしば時間が短いとはいえ）大量の帯 域幅を必要とする。 それにも関わらず、ＩＳＤＮ等の広帯域幅サービスは、主としてその種のサー ビスに付随するコスト（これは設備料金だけではなくて、接続料金及び関税を含 むことがある）の故に、旧来の不適当な電気通信オプションに広く取って代わっ てはいない。ＩＳＤＮ及びその他の広帯域幅オプションに付随するコストの一部 は、次のような事実から生じている、即ち、その種の多くのシステムでは大帯域 幅チャネルが各加入者に配分され、従って各加入者は、間欠的に、割合に短い時 間（例えば、割合に大きなファイルが転送されるときなど）にわたってその大帯 域幅から利益を得るに過ぎない、即ちその大帯域幅を利用できるに過ぎないのに 、長時間にわたるその帯域幅全体のコストを負担せざるを得ないという事実から 生じているのである。従って、複数のユーザーが、異なる時に、自分たちの必要 に応じて利用できるように、与えられた帯域幅が配分される“共同加入線”にお おむね（そして不完全に）似ているシステムが提案されている。 １つの提案されたシステムは（ＡＯ／ＤＩ）（Always On/Dynamic ISDN）と 呼ばれでいる。ＡＯ／ＤＩシステムでは、“Ｄ”チャネルは連続的に利用可能で ある（Always On（常時オン））。割合に帯域幅の狭いＤチャネルはユーザーに とっては“ホーム”チャネルとして役立ち、１つ以上のＢチャネルは割合に大量 の伝送のために使用され、不要になれば閉じられる。この様なシステムではコス トを複数のユーザーが共同で負担することができ、一人一人のユーザーのコスト は種々の方法で減らされる。与えられたユーザーは、大帯域幅チャネルが使われ ていない時間中や、或いはその末端ユーザーが該チャネルを必要としていない時 間中の該チャネルのコストを負担しなくても良い。ＩＳＤＮ回線は共有されるの で、与えられたユーザーのグループの必要を満たすのに必要な回線数は少なくな り、回線料金の減少及び設備利用の減少につなが る。 ＡＯ／ＤＩシステムと関連して或るプロトコルが提案されており、それらのプ ロトコルの中には、多数のチャネルの集成を可能にするマルチリンク・ポイント ツーポイント・プロトコル（ＭＬＰＰＰ）（a multi-link point-to-point prot ocol）と、ＭＬＰＰＰの“上で”動作してチャネル開閉の開始及び管理のための 、販売業者に依存しない規格を提供する帯域幅配分制御プロトコル（ＢＡＣＰ） とが含まれている。提案されたＡＯ／ＤＩ、ＭＬＰＰＰ及びＢＡＣＰについての 解説は、例えば、販売業者のＩＳＤＮ協会（Vendor's ISDN Association(VIA)。 これはカリフォルニアの非営利法人であり、その所在地は、ビショップランチ２ 、２６９４ビショップドライブ、シュート１０５、サンラモン、ＣＡ９４５８３ （Bishop Ranch 2,2694 Bishop Drive,Suite 105，San Ramon,CA 94583）である ）から入手できる“常時オン／ダイナミックＩＳＤＮ（Always On/Dynamic ISDN ）”ＲＦＣ−１９９０及びＲＦＣ２１２５でなされており、また、これをインタ ーネットのhttp://ftp.via-isdn.org/で入手することが可能であり、これを参照 により本書に取り入れたものとする。しかし、これら３つのシステムは、帯域幅 を切り換えたり配分したりする能力を与えるものではあるけれども、その様な配 分或いは配分解除を何時行うか決定するためのシステムを規定してはおらず、有 効で効率の良い決定システムを提案してはいない。 １つの実行可能なアプローチは、処理キューに蓄積されている通信パケット の数が所定閾値に到達したときに大帯域幅チャネルを配分するキュー深度システ ムである。その様なシステムは、本質的に、過去の呼数のみの考慮に基づいてい る。既に行われているトラフィックがもし与えられている時間内に所定量に達し たならば、もっと幅の広いチャネルが配分される。この様なシステムは或るレベ ルで機能するけれども、コストを減らし使いやすくするという目標 を必ずしも達成しない。実際、もし帯域幅切り換えや配分が全く行われなければ 費やされることになるコストよりも大きなコストをキュー深度システムが課す場 合もある。例えば、ファイル転送の終了直前に閾値に達した場合、たとえ末端ユ ーザーが追加の帯域幅から殆ど或いは全く利益を得られなくても（その追加の帯 域幅が配分される前或いはその直後にファイル転送が終了するから）キュー深度 システムは追加の帯域幅（及び、通常は、末端ユーザーが費やさなければならな いコスト）を配分しようとする。この閾値は前もって決められて固定されるので 、単に異なる閾値を選択するだけではこれらの問題を解決することはできない。 例えば、閾値を大きくすれば上記の例では無益なＢチャネル配分から生じる不要 な料金を払わなくて済むかも知れないけれども、他の特性（例えば、大量ではあ るが短いデータ転送を頻繁に行うなど）では、大きな閾値を持ったシステムから は何の利益も受けられない。 従って、キュー深度システムを効率的に利用するためには、与えられた末端 ユーザーのためのいろいろなトラフィックに対処するために閾値を設定しなけれ ばならない。しかし通常の末端ユーザーは最適の或いは役に立つ閾値を達成する ための技量も時間も持っていない。この様に、キュー深度システムは、多くの場 合にコスト節約という目標を達成できないだけではなくて、それを実用するにあ たって割合に多額の管理コストを要する。更に、キュー深度システムは、融通が 利かなくて、データ・トラフィックの特性の変化（例えば、一日中或いはもっと 長時間にわたるトラフィック変化）に順応することができない。キュー深度シス テムの閾値を調整するには、割合に高度の技量を持った管理者が相当の時間を費 やす必要がある。更に、キュー深度システムは、与えられたデータ・ストリーム の早い段階で帯域幅を配分することはできず（例えば、始めのほんの数個（１個 〜４個のパケット）だけの後に帯域幅を配分することはできない）、少なくとも 充分な個数のパケットが届いて所定キュー閾値に達す るまで待たなければならない。 従って、システムを確立して維持するためにやっかいな時間及び技量を要す ることなく大帯域幅電気通信のコストを下げるという目標を達成するために帯域 幅配分を実行できるシステムを提供することが有益である。時間変化するトラフ ィックや利用パターンに対処することのできるシステムを提供することも有益で ある。更に、例えば始めの少数のパケットを受け取った後など、データ・ストリ ームの早い段階で帯域幅配分について決定をすることのできるシステムを提供す ることも有益である。 広帯域幅アクセスを提供するための或るシステムは、相当の追加ハードウェ アやソフトウェアに投資することをユーザーに要求するなど、末端ユーザーに著 しい負担を強いる。従って、当該システムを動作させるために末端ユーザーの場 所（クライアント側）で相当の追加設備やソフトウェアを設けなくても電気通信 のための広帯域幅能力を費用有効的に且つ効率よく達成できるシステムを提供す ることが有益である。 また、或るシステムは、効率の良い帯域幅配分を実行するために電気通信会 社に著しい負担を課す。例えば、プロトコル・スタックを一部変更したりプロト コル・スタックに“常駐”したりするシステムを実現するためには、販売業者は そのプロトコル・スタックを認証し直す必要があり、そのことがその様なシステ ムを実現するための販売業者のコストを増加させる。電気通信システムは、多様 な販売業者からの設備及びソフトウェアを使用するので、販売業者の設備及びソ フトウェアとの一定のレベルでの対話に依存する帯域幅配分処理手順は、どの販 売業者が基本経路指定その他の電気通信設備及びソフトウェアを供給するのかに より、種々のバージョンが協同することを必要とし（即ち、販売業者依存となる ）、協同可能とするために必要な適切なバージョンを選択するのに伴うコストと 、多数のルータ販売業者の装置及びソフトウェアと関連 して動作する帯域幅配分システムの多数の異なるバージョンを供給することに付 随する開発及び実施コストとがかかることになる。 従って、再認証コストを減少させ或いは無くすると共に少なくとも部分的に は販売業者に依存しないシステムなど、電気通信会社及び開発者が負担するコス トを減少させ或いは最小限にする帯域幅配分装置及び処理手順を提供するのが有 益であろう。 発明の概要 本発明は、前述のものを含む以前の処理手順の問題の少なくとも一部分につ いての認識を包含している。本発明は、帯域幅配分が平均していっそう効率の良 い帯域幅利用を達成すると共に、好ましくは、ユーザーが負担するコストを下げ る（少なくとも平均で）こととなる可能性を高めるために、少なくとも部分的に 予測方式に基づいて、即ち、キュー深度以外の（或いはキュー深度に加えて）特 徴を用いて帯域幅配分処理手順決定を行うことを含んでいる。これと、また、開 示したその他の方法で、本発明を用いて、或るレベルのデータ及び信号通信サー ビスを提供し、管理することができる。 １実施例では、データ・パケットは特定のデータ・ストリームに属するもの として識別される。データ・ストリームの特性（例えば、ＧＩＦデータ、ストリ ーミング・ビデオ・データ、テキストＥ−メール、或いはバッチ・バイナリー・ ダウンロードなど、転送されるデータの種類に関してのデータ・ストリームの分 類）は、そのストリームの中の将来のパケットを送信するのに使うために追加の 帯域幅を配分することが効率的で且つ／又は費用有効的でありそうか否かに関す る決定に参加する。例えば、１実施例では、ＧＩＦストリームの始めの数個のパ ケットを受け取ると、（もし、例えば、そのデータ・スト リームの残りの部分で割合に大量のＧＩＦデータが到来するであろうとシステム が予測したならば）追加の帯域幅が配分される結果となることがあるが、同じ量 の、テキストＥ−メールとして分類されるデータが受信されても（即ち、前述の ＧＩＦストリームと同じキュー深度を達成しても）、もしそのテキスト・ストリ ームが割合に短いか、或いは例えば直ぐに受信されないなど、留意されないであ ろうとシステムが予測すれば、追加の帯域幅は配分されないかも知れない。 １実施例では、システムはデータ・パケットの種々の成分或いはフィールド にアクセスしてパケットを特定のストリームと関連づけることができる（出所／ 目的地／ポート情報、或いは、場合によっては、データフィールド情報など）。 システムがデータの種類に関して特定のデータ・ストリームを分類するために種 々の処理手順を使用できると好都合である。或る実施例では、データの種類に関 してのデータ・ストリームの分類を用いることに加えて（或いはその代わりに） データ・ストリームについての将来の帯域幅必要量を予測するのに役立つ他の情 報が採用される（一定の期間中に生じる特定の種類のデータ・ストリームが割合 に長く続きそうか或いは割合に短かそうかということについての、与えられたユ ーザーにとっての知識など）。本システムは好ましくは発見的方法に基づくシス テムであり、１実施例では、その様な追加の予測情報が自己学習又は人工知能シ ステムによって啓発され使用される。この様にして、システムは時間がたつに従 って変化に自動的に順応することができる。この文脈で、“自動的”という用語 は、人間のオペレータ又は管理者からの分析、決定又はその他の入力を要するこ となく目標がコンピュータ又はコンピュータシステムによって達成されることを 意味する（けれども、希望に応じて、人が入力をして自動分析を補ったり無効に したりできるようにシステムを構成しても良い）。本発明の少なくとも或る部分 をバイト・コード・システムとして設け ることは、例えばいっそう容易に自己修正又は自己学習を達成するために（後述 するように）規則を修正しやすくするのに役立つと考えられる。 本システムを実質的にモジュール化するのが好ましい。１実施例では、電気 通信回線を直接監視する或いは電気通信回線に結合されるモジュールは、実時間 で実行されなければならない品目だけを、或いは実質的にそういう品目だけを、 含むように構成され、好ましくは、例えばバイト・コード・システム（好ましく は、効率的な或いは最適化されたバイト・コード・システム）として動作するこ とによって迅速に動作するように構成される。システムの動作を分析したり（例 えば事後に）学習その他の人工知能能力を提供したりするように構成されている 本システムの他のコンポーネント（それらは通常は実時間で動作しない）は、（ 経路指定コンピュータがそれ以外にすることが無いときに限って経路指定コンピ ュータ設備を使用するために）実質的にサイクル・スチール・モードで動作する などして経路指定コンピュータの負荷を減らし或いは最小限にするように構成さ れるのが好ましい。 １実施例では、システムは、好ましくは販売業者ＡＰＩを採用することによ って実質的に販売業者に依存しない。コード・モジュール化と、販売業者に依存 するコンポーネントを例えば数個の明確な機能だけに限定することとによって、 販売業者への非依存性が好ましく促進される。 図面の簡単な説明 図１はＡＯＤＩネットワーク技術アプリケーションとの関係で役に立つ電気 通信システムのブロック図である。 図２は、キュー深度により配分されたチャネル使用例を示すタイミング図で ある。 図３は、本発明の実施例による帯域幅配分に役立つ情報の流れを示すブロッ ク図である。 図４は、本発明の実施例のモジュール方式の構成を示すブロック図である。 図５は、図４に似ているブロック図であるが、追加のクライアント側コンポ ーネントを示している。 図６Ａ及び６Ｂは、それぞれ、図４のコンポーネントを用いる処理手順を示 すブロック図及びフローチャートである。 図７Ａ及び７Ｂは、それぞれ、本発明の実施例による実時間コンポーネント と関連する処理手順を示すブロック図及びフローチャートである。 図８Ａ及び８Ｂは、それぞれ、本発明の実施例による実施コンポーネントと 関連する処理手順を示すブロック図及びフローチャートである。 図９Ａ及び９Ｂは、それぞれ、本発明の実施例による適応化コンポーネント と関連する処理手順を示すブロック図及びフローチャートである。 図１０は、本発明の実施例と関連するネットワーク・ルータのディスプレイ を示す。 図１１は、本発明の実施例と関連して役立つルータ統計のディスプレイを示 す。 図１２は、本発明の実施例と関連して役立つポリシー・オプションのディス プレイを示す。 図１３は、本発明の実施例と関連して役立つポリシー・エディターのディス プレイを示す。 図１４Ａ及び１４Ｂは、それぞれ、自己学習を図解する本発明の実施例のブ ロック図及びフローチャートである。 図１５は、データ・ストリームの分類後に帯域幅を増やすことを含む、本発 明の実施例による実例のフローチャートである。 図１６は、データ・ストリームが識別されていないときに帯域幅を増やすこ とを含む、本発明の実施例による実例のフローチャートである。 図１７は、データ量に応じて帯域幅を増やすことを含む、本発明の実施例に よる実例のフローチャートである。 図１８Ａはペグボード自己学習システムに使われるカウンターの略ブロック 図である。 図１９は、本発明の実施例に従って使うことのできる未知のタイプのデータ ・ストリームを追跡するためのテーブルの略図である。 図２０は、本発明の１実施例による開始を図解する略ブロック図である。 図２１は、本発明の実施例によるパケット転送速度制御を図解する略ブロッ ク図である。 図２２は、本発明の実施例による機密保護機構を図解する略ブロック図であ る。 図２３は、本発明の実施例による媒体経路指定を図解する略ブロック図であ る。 図２４は、本発明の実施例によるアウト・オブ・ストリーム・プロセスを図 解する略ブロック図である。 好ましい実施例の詳細な説明 本発明の特徴を説明する前に、ＡＯＤＩネットワーク技術アプリケーション の或る特徴とキュー深度制御の実例とを説明するのが有益であると考えられる。 以降の記述において、回線或いは通信リンクの種類への言及は、ＯＳＩモデルを 参照して、任意の“層１”物理媒体を含む。この開示内容を理解したならば、当 業者にとって明らかなように、電気通信回線又は通信リンクが無線リ ンクであるときに本発明の一部の又は全部の特徴を実現できる。図１に示されて いるシステムでは、データ・サーバー１１２（これは１つ以上のコンピュータを 包含することができる）及びクライアント１１４がルータ１１６に結合されてお り、図の構成ではルータ１１６の一方の側はＩＳＤＮ通信リンク１１８によって サーバー側に結合されている。代表的状態では、ルータ１１６は、ローカルエリ アネットワーク（ＬＡＮ）１３５との大帯域幅接続１３３を包含することのでき るクライアントに結合される。図に示されているＩＳＤＮリンクはＤチャネル１ ２２と、第１及び第２のＢ（ベアラー）チャネル１２４、１２６とを含んでいる 。Ｄチャネル１２２は例えば毎秒約９．６キロバイト（ＫＢＰＳ）までのデータ 転送速度に対処するための割合に狭い帯域幅を有する。各Ｂチャネル１２４、１ ２６は、６４ＫＢＰＳが可能な割合に広い帯域幅を有する（両方のＢチャネルが 使用されるときには、合計で１２８ＫＢＰＳ）。前述のように、ＡＯＤＩシステ ムでは、Ｂチャネルは回線交換される（例えば、ＢＡＣＰ及びＭＬＰＰＰプロト コルに従って）。 ＡＯ／ＤＩの１つの実施態様では、Ｄチャネル１２２は常時オン（常時オフ フック）である。ＡＯ／ＤＩの１つの実施態様では、呼は最初はＸ．２５と称さ れている処理手順（これは、例えば、ＲＦＣ−０８７４に記載されている）など のパケット化処理手順により、Ｄチャネルを介して発せられ処理される。Ｄチャ ネルは常時オンであるので、例えば“プッシュ・メール（push-mail）”を含む 常時利用可能なサービスを提供することが可能である。 追加の帯域幅を供給するべきであると確認されたときには、一方又は両方の ベアラー・チャネルがデータ転送を手伝うためにスイッチングされる。通常、ベ アラー・チャネルはＭＬＰＰＰを使用する（例えば、Ｄチャネルで使用されるＸ ．２５パケット化無しで）。その様な帯域幅の追加使用が中止されるべきである と決定されたときには、一方又は両方のＢチャネルが切断されるべきで ある。 ＡＯ／ＤＩの有用性は、帯域幅を配分する方法、即ち、Ｂチャネルを追加し 或いは撤回する決定がどのようになされるか、に関連している。ルータのキュー １２８のデータの深度が所定閾値に達しているか否かを決定の基礎とするなどし て、決定の基礎を最近のデータ・トラフィック量に置くことが可能である。図２ は、キュー深度決定の（簡略化された）実例を示すと共に、その様なシステムの 欠点のうちの１つを図解している。図２では、キュー深度２１２は始めは小さい けれども、時点Ｔ１でデータ通信が始まると割合に急速に大きくなってゆく。前 述のように、通信は始めはＤチャネル２１４で行われる。しかし、Ｄチャネルは 割合に狭帯域幅であるので、キュー深度はＴ１後には急速に大きくなって、時点 Ｔ２で所定キュー深度閾値２１６に達する。時点Ｔ２で閾値２１６に達したとい う事象が契機となって、第１Ｂチャネルを投入するという決定がなされる。この 決定の実行には或る長さの時間がかかるので、図２の図解では、第１Ｂチャネル は時点Ｔ３（２１８）で投入される。Ｂチャネルの帯域幅は割合に大きいので、 キュー深度は閾値２１６より低いレベルまで急速に低下２２２する。図２の実例 では、転送されるデータが必要とする帯域幅は割合に大きいので、時点Ｔ３後に 、キュー深度は、時点Ｔ１後の期間中よりもゆっくりとではあるけれども上昇し 続ける。図の実例では、キュー深度は時点Ｔ４で再び閾値２１６に達して、それ が契機となって第２Ｂチャネルを追加するという決定がなされる。しかし、図の 実例では、データ転送は時点Ｔ４の少し後に完了する。けれども、Ｂチャネルを 投入するまでに遅れが伴い、その後にＢチャネルを切断或いは撤回するのに遅延 が伴うので、図の実例では第２Ｂチャネルは時点Ｔ５で投入され、時点Ｔ６まで は撤回されない。従って、図２の実例では、ユーザーは第２Ｂチャネルを使用し たことから何の利益も受けていないけれども（このＢチャネルが投入される前に データ転送は完了してい るから）、時点Ｔ５及びＴ６の間の第２Ｂチャネルの使用についての料金がユー ザーに課せられる。 図３は、キュー深度以外の情報に（或いはキュー深度に加えて、それ以外の 情報にも）帯域幅配分決定の基礎を置くことのできる本発明のシステムをブロッ クの形で示している。このシステムの詳細について次に説明する。一般に、図３ に示されているように、データの特性に関連する情報は決定システム３１４に渡 される３１２。この決定システムは、帯域幅を何時配分するべきか或いはその配 分を何時解除するべきか決定し、それらの決定は、所望の帯域幅配分を達成しな がら同時にデータの流れを中断させないように、そのスイッチングを実行するた めにＭＬＰＰＰ３１８及びＢＡＣＰ３２２を使って実行３１６される。次に詳し く説明する実施例では、決定システム３１４は、決定を行うためにルール・ベー スを使用し、好ましくは、そのルール・ベースを構築するための開発環境を提供 する。１実施例では、決定システム３１４は、例えば、該システムが変化する環 境上の必要を満たすために自分自身のルール・ベースを修正できるように自己学 習能力（人工知能）を提供する。ルール・ベースの構成は、販売業者に依存しな い構成であるのが好ましく、また、例えば管理者が１つのコンソールから同時に いろいろなシステムを管理できるように、いろいろな販売業者の全てのハードウ ェアシステムで同一な管理ツールを含んでいるのが好ましい。 １実施例では、自己学習システムを達成するために、発見的分析方法が使用 される。発見的分析方法の１例は、いわゆる“ペグボード”システムである。ペ グボード型の発見的方法の１例では、（ａ）当該システムの性能を何時評価する かを決定し；（ｂ）性能をどの様に評価するかを決定し；（ｃ）性能が充分に悪 いと見なされたときにルールをどの様に修正するかを決定するシステムが設けら れる。１つのペグボード・システムでは、メッセージの総数（特定の タイプのメッセージの総数など）と、正しく処理されたメッセージ又はデータ・ ストリームの個数との別々のカウントがソフトウェア（場合によってはハードウ ェア）カウンターに蓄積される。特定のタイプの総データ・ストリームのカウン トと“正しく”処理された総数のカウントとを図１８Ａに図解されている第１及 び第２のペグボード１８１２，１８１４として視覚化することができ、この図に おいて、第１ペグボード１８１２中の黒丸は特定期間（例えば最後の性能評価以 降の期間）における特定タイプのデータ・ストリームの個数（この図では、ｅ− メール・セッションの個数）を表しており、第２ペグボード１８１４中の黒丸は 正しく処理されたｅ−メールの個数を表している。図解の目的のために、現在稼 働しているルール・ベースは、ｅ−メール・セッションが割合に小さくて、従っ てｅ−メール・セッションのための帯域幅を増大させないようなルールを規定す るという仮定に基づいて形成されていると考えて良い。従って、図１８Ａでは、 新しいｅ−メールのデータ・ストリームが処理される毎に、カウンター或いはペ グボード１８１２がインクリメントされる。ｅ−メール・セッションが正しく処 理されたか否か確認するためにｅ−メール・セッションの処理が評価され、もし 正しく処理されたと確認されたならば第２カウンター或いはペグボード１８１４ がインクリメントされる。この評価処理手順は、ｅ−メール・セッションの処理 が正しかったか否か確かめるために幾つかの方法で形成される。例えば、ｅ−メ ール・セッションのためには帯域幅を増やさないと指示するルールは、ｅ−メー ル・セッションが小さいという仮定を根拠とするので、現在のルール・ベースの もとで行われる特定のｅ−メール・セッションの処理が、その特定のｅ−メール ・セッションが実際に小さい（スレショルド量より小さい）ならば“正しい”と 見なされることとなるように、評価ソフトウェアを形成することが可能である。 他の性能評価方法も可能である。例えば、ｅ−メールの実際の処理が１つ以上の 可能な代わりのｅ −メール処理（帯域幅を増やすなど）と比較されることとなるようにソフトウェ アを形成し、もし代わりの処理手順が使用されたならば、その実際の処理が改善 され得た（例えば比較的に低コストでもっと良い性能を提供したり、或いはユー ザーが作った性能基準にもっと近い性能を提供するなどという意味で）か否か確 かめることが可能であろう。 いずれの場合にも、ペグボード１８１２，１８１４のカウントを自動的に維 持するためにソフトウェアをどの様に形成できるか以上の説明から分かる。当業 者にとっては明らかなように、他のタイプのメッセージのための一組のカウンタ ー或いはペグボード（例えば、図示されているｅ−メール・ペグボードの他に） を設けることも可能である。 機能（ｂ）を実行するために、いずれかのポイントで、ペグボードに実際に 累積された情報が評価のために充分になったと、見なされる。評価を何時行うべ きか決定するために幾つかのシステムを使用することができる。図１８Ａでは、 カウンター或いはペグボード１８１２，１８１４のどちらかが最大値に達する毎 に、即ち、いずれかのペグボード１８１２，１８１４が“満杯”１８１６となっ たときに、評価が実行される。例えば、所定時間が経過したとか、第１ペグボー ドでスレショルドに達した（しかし、第２ペグボードでは達していない）とか、 第２ペグボードでスレショルドに達した（しかし、第１ペグボードでは達してい ない）とか、システム全体としての性能、システム全体としてのコストが変化し たと認められたとか、性能を評価することを求める要求がユーザーから発せられ たとか、可変スレショルド（例えば、時刻によって変化するスレショルド）に達 したなど、評価を開始するための他の基準を使用することもできる。 図解されている実施例では、各々のｅ−メール・セッションの“正しい”処 理が個別に且つ好ましくは連続的に評価されるので、いったん評価期間に達 したならば、与えられた時間枠の中で正しく処理されたセッションの個数（１８ １４）をセッションの総数（１８１２）と比較することのみによってシステム評 価が実行され得る。例えば、その時間枠内でのｅ−メール・セッションの総数に 対する、正しく処理されたｅ−メール・セッションの割合が所定の割合よりもし 低ければ、性能を改善しようとしてシステムがルール・ベースの変更を開始する こととなるようにソフトウェアを形成することが可能である。図解されている例 では、現在のルール・ベースはｅ−メール・セッションのためには帯域幅を増や さないようになっているので、性能が許容できないほど悪いことが発見されたな らば（正しく処理されたｅ−メール・セッションのｅ−メール・セッション総数 に対する割合が比較的に低いならば）システムは、例えばｅ−メール・トラフィ ック（例えば所定最少トラフィック）に応答して帯域幅を増やすようにルール・ ベースを修正する。当業者にとっては明らかなように、性能が悪いことが分かっ たときに、例えばｅ−メール・メッセージの待ち行列作成を開始するなど、ルー ル・ベースを修正する他の方法を設けることもできる。 図１８Ａはペグボード型の発見的方法を図解しているけれども、他の自己学 習（好ましくは発見的）方法を用いることもできる。例えば、一般的な発見的方 法は、データ・ストリームの複数の種類の特性（例えば、日付、時刻、実効デー タ転送速度、ポート番号、及び現在のルール・ベースのもとでの処理など）に関 する情報を得る動作を含んでおり、その情報は、数個のデータ・ストリームに関 して、システムの性能に最も関連性が深いのはどの要因だと思われるかを確かめ るために、分析される。１例として、未知のタイプのデータ・ストリーム或いは メッセージに関する情報を得て蓄積するようにシステムを構成しても良い。前述 したように、このシステムは、通常は、未知のタイプのデータ・ストリームを処 理して、それらのデータ・ストリームのためにもっと大き な帯域幅へ切り換えるか、或いは切り換えないかを決定する何らかの処理手順を 現在のルール・ベース中に有する。一般的な発見的方法の１例では、システムは 、例えば、その様な未知のタイプのデータ・ストリームについてのポート番号を 追跡して、各ポートと関連する未知データ・タイプの頻度と、切り換えが行われ たか否かという事実とを（例えば、図１９に図解されているようなテーブル１９ １２に）蓄積する。この例では、定期的に（或いは、ユーザーが開始したときに 、或いは別様に選択された時に）現在のルール・ベースのもとでの未知データ・ ストリームの処理を評価する分析が実行される。例えば、図１９に図解されてい る情報を使って、システムに対する影響が最も大きいと思われるセッション或い はセッション・タイプ（例えば、最大多数のパケット）を選択することができる 。この例では、最も影響の大きい未知データ・ストリームの種類（最も頻繁に発 生した特定のポート・アドレスを伴う未知データ・ストリームなど）が、それら が“正しく”処理されたか否か確かめるために、分析される。“正しい”処理の 分析を、図１８の例と関連して前述した方法を含む、幾つかの方法で実行するこ とができる。例えば、（例えば、コストを所望の性能レベルと矛盾しない最低レ ベルに維持するようにシステムが構成され、或いはユーザーがコストをその様な 最低レベルに維持するように希望することを表明したならば）種々の切り換え決 定が容認できる性能をもっと低いコストでもたらすか否か確かめることができる 。１例では、割合に多数の（例えばスレショルドを上回る）未知タイプのデータ ・ストリームが正しく処理されなかったならば、性能を改善するためにルール・ ベースをどの様に修正するかに関する決定が自動的に行われる。 １実施例では、ルール・ベースをどの様に修正するかに関するこの決定は、 正しい切り換え決定及び間違っている切り換え決定を異なる数個の可能な相関（ ありそうな候補として確認された所定の可能性ある相関など）と相関させる 別の分析を根拠とする。その例は、正しい切り換え決定及び間違っている切り換 え決定をそのパケットが送られた日付及び／又は時刻と相関させようとする試み 、パケットの“バースト状／連続的”挙動、与えられた送信期間にわたる実効デ ータ転送速度などを含んでいる。 この分析に基づいて、１つ以上の相関が処理の正しさとの割合に大きな相関 関係を持っているものと確認され、その相関はルール・ベースを修正するための 根拠として使われる。例えば、間違って処理された未知タイプのデータ・ストリ ームの殆どが正午と午後３時との間の時間に、且つ／又は特定のポート番号につ いて、発生したと確認されたならば、この時間中に発生した未知データ・ストリ ームについて異なる（例えば逆の）切り換え決定を行うようにルール・ベースが 修正される。このときシステムはこの未知データ・タイプのための新しいルール を一時的に付け加えて、未知セッション・タイプのための前のルールの集合に取 って代わるものとして、この新しいルールの集合を使う。そのとき、少なくとも 変更されたルールに関連するカテゴリーについて、カウンター（図１９に示され ているものなど）がリセットされ、システムは、動作を継続し、発見的手法に基 づく後の動作分析のために情報を集積する。 帯域幅切り換えの目的でデータ・ストリーム・タイプの識別を使用するほか に、データ・タイプを他の目的にも使うことができる。１例では、データ・スト リームの待ち行列作成（重み付きフェアー・キューイング（weighted fai る。その様な待ち行列作成を上記の帯域選択或いは切り換えの代わりに、或いは それに加えて、使用することができる。図２０では、システム２０１２は、ルー タ２０１４に配置されるなどしてデータ・ストリームの中に置かれ、このルータ ２０１４は、図の実施例では、１０Ｍｂｐｓの入りＬＡＮパケット・ストリーム ２０１６を受け取り、１２８ＫｂｐｓのＷＡＮパケット・ストリーム ２０１８を出力する。図示されている実施例では、音声データ・パケット及びビ デオ・データ・パケットには最高の優先順位２０２２が与えられ、ｅ−メール及 びインターネット“ウェブ”パケットには比較的に低い優先順位２０２４が与え られる。出力ストリーム２０１８の帯域幅が完全には利用されないならば、パケ ット・ストリーム２０１６のパケットは実質的に緩衝無しに出力ライン２０１８ に置かれる。しかし、出力ストリーム２０１８の帯域幅が完全に利用されるなら ば、システムは、例えば到着するパケットをいろいろな待ち行列２０２８ａ，ｂ ，ｃに置くなどして、該パケットを待ち合わせさせる。例えば音声及びビデオに 対応する待ち行列２０２８ａには最高の優先順位２０２２が与えられるなど、異 なる待ち行列には異なる優先順位が与えられる。ルータ２０１４は、待ち行列２ ０２８ａ，ｂ，ｃからパケットを出力するけれども、必ずしもそれらのパケット が到着した順番を反映するようには出力しないし、また必ずしも種々の待ち行列 から均等な配分で出力するわけではない。むしろ、最高優先順位の待ち行列２０ ２８ａ中のパケットは、比較的に優先順位の低い待ち行列２０２８ｂ，ｃ中のパ ケットより高い周波数（入力周波数より大きい、或いは等しいか又は比例する周 波数）で出力される。入ってくるパケット・ストリーム２０１６で、音声及びビ デオは全パケットのうちの三分の一に相当するけれども、音声及びビデオ・パケ ットは比較的に頻繁に出力され、図２０の例で図解されている出力ストリーム２ ０１８においては音声及びビデオ・パケットは出力されるパケットの５０パーセ ントに相当する。 図２１は、（ルータ２１１４の中などの）データ・ストリーム中にあるシス テム２１１２を使って性能を改善し且つ／又はコストを下げる他の方法を示して いる。図２１に示されている例は、ビデオ受信装置が、例えば１０ＭｂｐｓのＬ ＡＮパケット・ストリーム２１１６を介してビデオ送信装置に（例えば１２８Ｋ ｂｐｓのＷＡＮパケット・ストリーム２１１８を介して）特定サイズ のビデオ・パケット・データを求める（肯定応答“ＡＣＫ”メッセージなどの形 の）要求を送る場合に関連している。この例では、システム２１１２はパケット 転送速度制御に使われる。例えば、ビデオ受信装置は特定の量のビデオ・データ を要求するけれども、そのデータ要求を満たすのに必要なパケットの全部を直ぐ に送信するのはあまり効率的ではないことがある。図１２の例では、パケット・ ストリーム２１１６，２１１８の実効到着データ転送速度及び実効出発データ転 送速度を確認した後、システムは、前に管理者により要求されていたデータ転送 速度など、ビデオのための“仮の”データ転送速度を考慮に入れる。例えば、管 理者は６４Ｋｂｐｓ或いは例えば８Ｋｂｐｓの転送速度のビデオ・データ転送を 要求することがある。システム２１１２は転送速度制御を維持するためにデータ の最大“チャンク”サイズを計算する。ビデオ（１２８Ｋｂｐｓである２１１８ 等のリンクでのパケット転送速度制御）については、それは毎秒２回要求される ４ＫＢチャンクにセットされることがある。このチャンク・サイズは、タイムア ウトを防止する必要に応じて調節されて良い。この場合、ビデオ・パケット・デ ータを求める要求“ＡＣＫ”が受信されたとき、信号２１１２は、要求されたデ ータ量を調整し直す。例えば、システムは、上で計算された最大チャンク・サイ ズと要求されたデータとの間に属する最小値であるサイズを選択することができ る。１例として、もしビデオ受信装置が３２ＫＢを求める要求を送ったとすると 、システム２１１２は、代わりに、４ＫＢを求める要求を送信装置へ出力する。 要求された４ＫＢが送信装置２１２６から送られて、残りの量が２８ＫＢとなっ た２１２８ことにシステム２１１２が気づくと、システム２１１２は４ＫＢを求 めるもう一つの要求を出力する。要求された３２ＫＢが受信装置に供給され終わ るまで、この処理手順が繰り返される。この様にして、システム２１１２は、特 定の要求２１２２を受け取ったことに応答して、データ転送の所望の全体として の経済的な性能と矛盾しな いようにしてパケット転送速度制御をするために該要求を一連のいろいろな要求 ２１２４，２１３２等に変換する。 図２２は、例えば、“防火壁（firewal）”機能などの、機密保護を与えるた めにデータ・ストリーム・タイプ情報を使う別の方法を示している。図２２では 、システム２２１２はデータ・ストリーム中に（ルータ２２１４の中などに）置 かれている。図２２は、所望の機密保護機能が、時刻が４ｐ．ｍ．と８ｐ．ｍ． との間の時刻ではなくて、機密保護ソフトウェア・キーがルータに送られてきて いない場合には衛星バンク内からの全てのフィル転送プロトコル（ＦＴＰ）パケ ット２２１６を拒絶する機能を含んでいる。 図２２では、時刻が４ｐ．ｍ．と８ｐ．ｍ．の間の時刻ではないか、或いは 機密保護ソフトウェア・キーがルータに送られてきていないので、１０Ｍｂｐｓ のＬＡＮパケット・ストリームのＦＴＰパケット２２１６は１２８ＫｂｐｓのＷ ＡＮパケット・ストリームで供給されない。１実施例では、ＨＱシステムが始め にルータへの機密保護接続を“アンロック”して例えば１５分間に及ぶ送信窓を 可能にした場合に限ってＨＱシステムによる衛星バンク・システムへのアクセス を許すようにシステムを構成することができる。 図２３は、種々の通信媒体でいろいろなタイプのデータ・ストリームを経路 指定するためのルータ２３１４におけるシステム２３１２の使用例を示している 。例えば、図示されている実施例では、ＬＡＮパケット・ストリーム２３１６上 のパケットは、低速で低コストのダイヤルアップＷＡＮ２３１８を介して、中速 で中コストのＩＳＤＮ ＷＡＮ２３２２，或いは高速で高コストのファイバーオ プティックＷＡＮ２３２４を介して経路指定されることができる。当業者は他の タイプの媒体にも想到するであろう。図示されている実施例では、ＬＡＮパケッ ト・ストリームは、この例ではタイミングが非常に重要で最大の性能を必要とす ると考えられる音声及びビデオ・パケット２３２６と、この例 では時間は重要ではなくてコストを最小限にするための処理を必要とするｅ−メ ール・パケット２３２８と、この例では平均的重要度のパケットであると考えら れるウェブ・パケット２３３２とを含む幾つかのタイプのパケットを含むことが できる。システム２３１２は、パケットを、パケットのタイプに応じて、例えば 各媒体に付随しているバッファー２３３４ａ，ｂ、ｃを介して、種々の媒体２３ １８，２３２２，２３２４へ経路指定する。図２３の例では、システム２３１２ のためのルール・ベースは、タイミングに敏感な或いは役目が非常に重要なパケ ットが受信されたときに（例えば２３２６）、そのパケットが利用可能な最高速 度のリンク即ちＷＡＮ２３２４を通して送られることとなるように、構成されて いる。時間の重要性が比較的に低いパケット（ウェブ・パケット２３３２や、対 話型アプリケーション用のパケットなど）が受信されたときには、該パケットは 比較的に安価な中速のリンク即ちＷＡＮ２３２２を通して送られ、ｅ−メール・ パケット及びその他の時間に鈍感なパケットが受信されたときには、該パケット は最低コストのリンク即ちＷＡＮ２３１８を通して送られる。 切り換えを包含する実例を含むシステム使用例を呈示したけれども、切り換 えと無関係なシステムの使用方法を幾つか呈示することが可能である。その様な 使用方法の多くは、図２４に示されているように、データ・ストリーム２４１６ でパケットのコピーをシステム２４１２へ供給し、且つ／又は、作成されたパケ ット２４１８をパケット・ストリームに挿入する動作を含んでいる。切り換えと は無関係のシステムの使用例は、例えば使いすぎを見つけるために回線を監視す る；トラフィックのタイプを探知して管理者に知らせる；遠くから接続するユー ザーの利用特性を探知する；現在の接続の効率及びコストを理論的接続タイプと 比較する（例えば理論的接続タイプのプロフィールが与えられたとき）；（機密 保護を分析して改善を推奨するために）強化インテリジェ ント防火壁として作用する；診断目的のためにデータをシミュレーションし且つ ／又は再生する；（例えばトラフィック呼び出し時間を短縮するために）システ ムを通して送られるデータの伝送効率を改善する；効率を改善するために意外な 方法を調査する；自動的に冗長性を与えるために他のシステムと通信する；且つ ／又は例えばウィルスを識別し防止するためにパケット内のバイト・パターンを 探知する、トンネルド・プロトコル（tunneled protocols）、機密保護プロトコ ルなどを識別して該プロトコルで作用するなどの使用方法を含んでいる。 決定システム３１４は、数個のコンポーネントを含んでおり、それらは１実 施例では分散配置されている。或るコンポーネントは販売業者の設備に常駐し、 他はシステム開発者の及び／又は管理者のワークステーションに常駐する。 該システムは、パケットを基礎とするレベルではなくてストリームを基礎と するレベルで動作するのが好ましい。当業者に知られているように、Ｘ．２５マ ルチリンク・プロトコル及び類似のシステムは、与えられたデータ・ストリーム の一部分を各々包含する複数のデータ・パケットを転送することによって該デー タ・ストリームを転送する。本システムは、各データ・パケットについて別々に 決定を行おうと試みるのではなくて、パケットが作り上げているデータ・ストリ ームを識別して、異なる各々のデータ・ストリームに関する情報に基づいて決定 を行う。決定システム３１４は、例えばＩＳＤＮインターフェースを通じてデー タ・ストリームのサイズ、開始時刻、終了時刻のいずれか又は全部を決定するこ とができる。システムは、データ・ストリームの始めの数個のパケットから情報 を得た後に、また場合によってはストリームの唯一の（例えば最初の）パケット （これは該ストリームのデータの種類を識別するのに充分なヘッダ又はその他の 情報を含むことができる）から情報を得た後に、この決定を行えるのが好ましい 。 また、決定シ又テム３１４は、ストリームの他の特徴も識別することができ る。例えばＩＳＰ（Internet Service Provider（インターネット・サービス・ プロバイダー））環境では、決定システム３１４は、特定のストリームがＦＴＰ （File Transfer Protocol（ファイル転送プロトコル）セッション、サーバーへ のＨＴＴＰ（Hypertext Transfer Protocol（ハイパーテキスト転送プロトコル ））要求、或いは他の何らかの種類の通信メッセージを表すのか否か確認するこ とができる。ストリームの種類に関するこの情報を使って、下にあるＩＳＤＮ回 線での予測ニーズに関する決定を行うことができ、従ってこの情報は何時チャネ ルを追加するか且つ／又は何時チャネルを閉じるかを決定するための基礎として 役立つ。表Ｉは、説明の目的で、選択されたデータ・ストリームの種類と、与え られた環境でそのデータ・ストリームについての将来の帯域幅ニーズを予測する のに役立つかも知れない該データ・ストリームの一定の特徴とを列挙したリスト を提供している。例えば、ＨＴＴＰ（ハイパーテキスト転送プロトコル）、ＳＭ ＴＰ、ＳＮＭＰ及びＨ．３２３などを含む他のデータ種類及び特徴が当業者に良 く知られている。 １実施例では、データ・ストリームについての将来の帯域幅ニーズに関する 予測はルール・ベースによって実行される。例えばトラフィック統計に基づいて 自動的に又は手操作でルール・ベースを修正できるのが望ましい。好ましくは、 決定システム３１４は、ルール・ベースを修正するために役立つ統計を自動的に 収集する。本発明に従って決定システム３１４を幾通りもの態様で実現すること が可能であるけれども、ルール・ベース構成による実施態様では、システム開発 者は種々のデータ・ストリームを処理するように決定システム３１４を容易に、 且つ好ましくは一連のイエス／ノー決定を通して割合に直感的に（或る決定は他 の決定のための条件を提供する）、プログラムすることが可能である。その様な システムの設計又はプログラミングは、下にあるハードウェアから独立していて 、従って多様なハードウェア構成のいずれにも用いることができるのが好ましい 。１実施例では、システムの動作を中断させることなく、例えばルータ１１６を ブートし直す必要無く、ルールの再プログラミング即ち修正を実行することがで きる。 決定システム３１４の効率的実行を達成するのに役立つように、決定システ ム３１４の少なくとも一部分はバイト・コードとして実行されるのが好ましい。 ルール・ベース・システムは、販売業者の設備にダウンロードされる前に、販売 業者に依存しないバイト・コードにコンパイルされるのが好ましい。バイト・コ ードは、パケットに対して働きかけて二元（イエス／ノー）決定を行うように具 体的に開発されるのが好ましい。最適の或いはより良い効率を求めて二元決定を 自動的に配列することによって効率を更に改善する。１実施態様では、一部又は 全部の二元決定は、実行されると、そのセッションについてのフラグが立てられ るという結果をもたらすので、決定がいったんなされたならば、必要無ければ反 復はされない。 コンパイルを行うことを必要とせずにバイト・コードを供給できるのが好 ましい（例えば、コンパイラではなくてインタープリターがバイト・コードを供 給するときなど）。このアプローチは、システム又はそのコンポーネントを中断 させたりブートし直したりする必要を伴わずに実時間コンポーネントにロードす ることのできる新しい或いは修正されたバイト・コードを供給するのに役立つ可 能性がある。 例えば図４に示されている実施例など、決定システム３１４のコンポーネン ト化或いはモジュール化された構造により、実行効率が更に促進される。図４の 実施例では、実時間コンポーネントＲＴＣ４１２は、ＩＳＤＮ１１９データ・ス トリームに（好ましくはルータ販売業者のプロトコル・スタックに）インターフ ェースして、パケットがルータ１１６を通過するときに該パケットに関する情報 を得る。好ましくは、ＲＴＣ４１２はそのスタックには常駐せず、パケットに関 する情報を販売業者アプリケーション・プログラミング・インターフェース（Ap plication Programming Interface（ＡＰＩ））から得る。プロトコル・スタッ ク自体は修正されないので、もし販売業者が必要なＡＰＩを供給するならば、本 発明が実施されるときにプロトコル・スタックを保証し直す必要はない。 好ましくは、ＲＴＣ４１２は実質的に決定システム３１４の実時間動作の全 てを包含する。図示されている実施例では、ＲＴＣ４１２は幾つかの機能を実行 する。このＲＴＣは、特定のデータ・ストリームのスタート・パケット、中間パ ケット、及びエンド・パケットを識別することができる。ＲＴＣ４１２は、バイ ト・コード・システム或いはエンジンに設けられているルールを使って、何時チ ャネルを切り換え、チャネルを開き、そしてチャネルを閉じるかを決定する。Ｒ ＴＣ４１２は、更に、データ・トラフィックに関する統計を収集する。収集され る統計の種類は、好ましくは、バイト・コード・エンジンによって決まる。 図４の実施例では、ＲＴＣによって実行されるバイト・コード・エンジンは 、適応コンポーネント（Adaptation Component（ＡＣ））４１６によってＲＴＣ ４１４に供給される。この構成は、ＲＴＣによって実行されるバイト・コード・ エンジンを修正或いは更新することを可能にする。具体的には、ＡＣ４１６は、 データ・ストリームの特性に関する統計と、ＲＴＣ４２２によって行われたチャ ネル切り換え／開く／閉じる決定に関する統計とを受け取る。受け取った統計を ＲＴＣが現在使用している既存のルール・ベースと比較することにより、ＡＣ４ １６は、ルール・ベースを現在の環境に適応させた方がよいか否か決定すること ができる。好ましくは、ＡＣ４１６は自動的に（人間の介在無しに）バイト・コ ード・エンジンの改訂或いは修正されたバージョンを作成して、その改善又は適 応されたエンジンをＲＴＣ４１２にダウンロードする。この様にして、ＡＣ４１ ６は、変動する環境の特定のニーズを満たすようにＲＴＣを修正或いは適応させ る。ＡＣにより使用される統計は好ましくは、（図示の実施例では実施コンポー ネント（ＩＣ）４２８を介して）管理者コンソール４２４に渡される。 好ましくはＡＣ４１６は実時間で動作する必要はない（換言すれば、ＡＣ４１ ６の減速或いは停止は現在のデータの流れに直接的効果を及ぼさない）。実時間 で動作しなくても良いＡＣ４１６等のコンポーネントをモジュール化或いは区分 化すれば、ルータ処理装置サイクルを利用できるときに限って動作するように（ 即ち、ルータ処理装置が遊んでいるときにルータ処理装置を使用するように）Ａ Ｃ４１６等の非実時間コンポーネントを構成することができるので、ルータ・コ ンピュータに過剰な計算負荷を課さなくても済む可能性が得られる。サイクル・ スチールを使用すれば、全体としての動作に影響を及ぼさないで且つ経路指定処 理装置やその他のハードウェアを相当追加したりアップグレードしたりすること を必要とせずに（或いは、多くの場合に、全く追加や アップグレードを必要とせずに）割合に複雑で時間のかかる分析を行うことが可 能となる。ここに記載したサイクル・スチール及びその他の効率改善手段は、必 要な計算負荷の故に電気通信ルータのためには従来は一般に不可能であると考え られていた本書記載の学習又は人工知能アプローチを採用することを可能にする 。ＡＣ４１６は、チャネルを切り換える／開く／閉じる決定（ＲＴＣにより行わ れる）４２５もＩＣ４２８に渡す。ＩＣ４２８の主な機能は、ＢＡＣＰ３２２及 びＭＬＰＰＰ３１８の販売業者のインプリメンテーションにインターフェースす ることによって、ＲＴＣによりなされた決定を実行することである。好ましくは 、ＩＣ４２８は、ＲＴＣにより決定されてＡＣ４１６を通して伝えられたとおり に、チャネルを切り換え、チャネルを開き、そしてチャネルを切断するために販 売業者のＡＰＩを使ってＢＡＣＰに電話をかける。ＩＣ４２８は、統計情報４２ ４を記憶すると共に、それを管理者コンソール４２６に渡す４３２。図１０に示 されているように、管理者コンソール４２６は、好ましくは、例えば状況１０１ ２、総数、稼働（アクティブ）ルータ及び不稼働（インアクティブ）ルータ１０ １４等の、ネットワーク中の全てのルータに関する情報を表示するように構成さ れる。図１１に示されているように、管理者コンソール４２６は、好ましくは、 例えばいろいろな時間での状況１１１２、バイト１１１４ａ及びパケット１１１ ４ｂ等の、いろいろなルータについての多数の種類の統計の詳しいカスタマイズ 可能な眺望を表示するように構成され得る。 図示されている管理アプリケーション４２６，４３４を使って管理者は新し い或いは修正されたルール・ベースを作り出すことができる。その様な新しいル ール・ベースはＩＣ４２８により（例えばインターネット・プロトコル（ＩＰ） ソケットを介して）ＡＣ４１６にダウンロード４３６され、ここでそのルール・ ベースは、ＲＴＣ４１２が使うことのできる（好ましくは最適化さ れた）バイト・コードに変換される。バイト・コードへの変換、特に効率的な或 いは最適化されたバイト・コードへの変換は、困難なタスクであるかも知れない 。１実施例では、このタスクは、主項理論に基づく処理手順により達成され或い は援助される。 好ましくは、管理者コンソール４２６は、管理者がネットワーク内のルータ上 で動作するルール・ベース（或いは、例えばルータ・ポリシー或いはユーザー・ ポリシー等の、ルール・ベースの特定の部分）のためにパラメータを設定したり 変更したりするのを補助するグラフィカル・ユーザー・インターフェース（ＧＵ Ｉ）を提供する。例えば、１実施例では、図１２に示されているように、例えば 特権を持ったユーザーのために最大帯域幅を設定したり１２１２、或るデータの 種類のためにポリシーを設定したり１２１４、ポリシーに名前を付けたりする１ ２１６ために、ドロップダウン・ボックス又はその他の選択項目を表示するなど して、或るポリシーを選択しやすいように管理者コンソール４２６を構成するこ とができる。好ましくは、管理者コンソール４２６は、統計４３２の、アクセス しやすく理解しやすい表示も提供する。図示の実施例では、ルール・ベースを作 り、それを修正するために、例えばネットワーク・エンジニアによってポリシー 設定コンポーネント４３４が使用される。図１３に示されているように、そのポ リシー設定は、好ましくは、多くのプログラマーやネットワーク・エンジニアに 良く知られている種類の“ツリー”表示１３１２を設けることによって、好まし く容易にされる。 好ましくは、管理者コンソールは、１つの場所から１つ以上の決定システム ３１４と複数のルール・ベースとの同時管理を可能にする。全ての決定システム にソケット・レベルＩＰインターフェース等のインターフェースを使用すると、 このタスクを達成しやすくなる。その様な構成では、管理者コンソール上に表示 されるインターフェースと、ルール・ベースを作ったり修正したりす るために使われる言語とは販売業者に依存しないので、与えられたＩＰネットワ ークに存在する販売業者ハードウェアに関わらず管理者には同一に見える。 図４に示されているように、末端ユーザー又はクライアント１１４のハードウ ェアやソフトウェアを修正せずに本発明を実施することが可能である。しかし、 例えば図５に示されているようにクライアント側アプリケーションを含むシステ ムを設けることも可能であり、場合によってはその様なシステムが有利である。 １実施例では、電話会社及びＩＳＰ（インターネット・サービス・プロバイダ） の両方へのユーザーのＩＳＤＮ接続を確立するのをクライアント接続コンポーネ ント５１４が援助する。末端ユーザーが（例えばユーザー・ポリシーを使用し修 正することを通して）自分のＩＳＤＮ利用を或る程度制御できるようにするため に管理コンポーネント５１６を設けることができ、それを、そのユーザーが接続 しているルータ上で動作するルール・ベースに統合することができる。例えば、 自分が必要としているものをユーザーが特に知っているということに基づいてユ ーザーがデータ通信の効率を更に改善しコストを減少させることができるように するために、これを使うことができる。ユーザーは、例えば、サービスのコスト とレベルとの特別のバランスを指示することを望むことがあり、或いは、例えば ｅ−メール・メッセージがコストに関わりなく最高の優先順位を得るように指定 することを望むことがある。サーバー側も、システムの稼働に影響を及ぼすため の何らかの可能性を持つことを望むことがある。１実施例では、末端ユーザーが 利用することのできるオプションをＩＳＰが変更したり追加したりすることを希 望するとき、そのサービス・プロバイダは、修正されたオプションをクライアン ト側に直ぐに“ホット・ロード（hot load）”することができる。 図６ａ及び６ｂは、本発明の１実施例に従ってチャネル切り換え決定を行う ことに関わるコンポーネントとプロセス・ステップとを示している。図の構 成では、データ・パーケットがルータ６１２、６１４に到達すると、ルータ６２ ４によってパケット６１６のコピーが切り換えシステム６１８、特にＲＴＣ６２ ２、に送られる。ＲＴＣは、ルール・ベース６２６を使ってパケットを解読し、 帯域幅６２８を変更するべきか否か決定する。ＲＴＣが帯域幅を変更しないなら ば、ＲＴＣはその決定を記録して、パケット６３２に関してはそれ以上は何もし ない。もしＲＴＣが帯域幅を変更するべきだと決定したならば、ＲＴＣはその決 定を記録し、ＡＣ６３８を介してＩＣ６３６にコマンド６３４を送る。ＩＣ６３ ６は、帯域幅制御方法を使ってルータ６４２に帯域幅調整を要求し、本質的に帯 域幅スイッチ６４４ａ、ｂ、ｃを開き或いは閉じる。特定のパケットが帯域幅変 更をもたらすか否かに関わらず、ＲＴＣ６２２は、自分が行った決定についてＡ Ｃ６４６に時折或いは定期的に報告をする。ＡＣ６３８は、それらの決定を評価 し、自分自身のもっと大きなルール集合を使ってＲＴＣ６４８のルール・ベース ６２６を修正することができる。 図７ａ及び７ｂは、ＲＴＣの動作をいっそう詳しく示している。パケット・ プロセッサ７１２は、新たに到着したパケットのコピーをルール・ベース・エン ジン７１６で処理できるように、そのコピーを先入れ先出し（ＦＩＦＯ）キュー ７１４等のパケット・キューに入れる。ルール・ベース・エンジン７１８は、キ ュー７１４からパケットを受け取ると、“パケット毎（per packet）”事例変数 ７２２をリセットし、ルール・ベース６２６を介して処理７２４を開始する。ル ール・ベース６２６は、例えばオプコード（opcode）リスト及び／又はパーサー ７２６によってパケットを解読し、該パケットに関連する統計とその状況とを記 録し、帯域幅の変更を行うべきか否か決定する７２８。もしルール・ベースを実 行した結果として帯域幅が変更されたならば、ＲＴＣ６２２はその決定を記録し 、（ＡＣを介して）コマンドをＩＣ６３６に送る７３４。上記のように、ＩＣ６ ３６は帯域幅制御方法を使ってルータ６１２ に帯域幅調整を要求する７３６。ＲＴＣ６２２は、前記のように、定期的に又は 時折その決定７３８と統計とをＡＣに知らせる７４２。次のパケットを処理する 前に、ＲＴＣは、ＡＣ６３８から受け取った新たな或いは修正されたルール・ベ ースがあるか否か確認する。もしあれば、ＲＴＣは、現在のパケットの（旧ルー ル・ベースによる）処理が完了するまで待ち（即ち、キュー７１４からの新しい パケットを処理しない）、旧ルール・ベースの代わりに新ルール・ベースを採用 し７４６、処理を続ける７４８。 図８ａ及び８ｂは、本発明の実施例によるＩＣ６３６の処理及びコンポーネ ントを示している。図の実施例では、ｃｏｍｍマネージャー８１２は管理アプリ ケーション４２６、５１２から例えば状況情報を受け取ることができ、ポリシー はデータ・マネージャー８１４を介して（例えば大容量記憶装置８１６に）保存 され、ｃｏｍｍマネージャー８１２はデータ・マネージャーからの最近のデータ で満たされるべき情報を要求する。大容量記憶装置８１６は、ルール・ベース、 データ辞書（DDicts）、ユーザー・パラメータ、統計などを記憶するために使わ れる。ｃｏｍｍマネージャー８１２は、新しいポリシーなどのイベントを内部コ マンド・コントローラ８２２に知らせる８２４。コマンド・コントローラ８２２ は、ＡＣ８２６から新しい統計及び状況更新を受け取り、それをデータ・マネー ジャーに保存することができる８２８。コマンド・コントローラ８２２は、帯域 幅変更コマンドなどのコマンドをＲＴＣから受け取って８３２、それを８３４で 接続マネージャー８３６に渡す８３８。接続マネージャー８３６は、例えばルー タ６１２の接続マネージャー（例えばＢＡＣＰなど）と通信８４２することによ ってスイッチ・アップ要求及びスイッチ・ダウン要求を調整し、接続要求の進行 を処理する８４４。 図９ａ及び９ｂは本発明の実施例におけるＡＣの動作及びコンポーネントを 示している。ＩＣ６３６は、一組のポリシー９１２（これは新しいルール・ ベース、データ辞書、或いはその他の形を取ることができる）を好ましくはプラ ットホーム・ニュートラル・フォーマット（即ち、システム６１８の如何なるイ ンプリメンテーションも読むことのできるフォーマット）で渡すことができる９ １４。ローダー９１６は、そのポリシーをプラットホーム固有のフォーマットに 変換する、即ち、例えば、数が１６ビットのサインド・オン・インターネット・ フォーマット（16-bit signed on Internet format）に変換されたり、オプコー ドがもっと圧縮されたフォーマットで記憶されたりする９１８。ローダーはポリ シーをＡＣＢＭ９２４に渡す９２２。ＡＣＢＭ９２４は、データ辞書９２６ａ、 パーサー９２６ｂ、オプコード・リスト９２６ｃ等を有することができて、ポリ シーからルール・ベースを導出し、それをアナライザ９３４のプライム・インプ リカント（prime implicant）９３２に渡す９２８。プライム・インプリカント ９３２は、論理のルールを使って、もっと効率が良くなるようにルール・ベース を縮小させ、再編成し、圧縮する９３６。プライム・インプリカント９３２は、 その後、ルール・ベース９３８をＲＴＣ９４２に渡す。ＩＣから受け取った情報 にルール・ベースの基礎を置くことに加えて・或いはその代わりに、ＡＣＢＭ９ ２４は、自分自身のポリシーの集合とＲＴＣから受け取った９４４統計とを使っ て新しいルール・ベースを作成し、それをプライム・インプリカントに送ること ができる９４６。 図１４ａ及び１４ｂは、本発明の実施例において自己修正或いは自己学習を容 易にする方法を示している。図の実施例では、ＩＣはデータ辞書又はルール・ベ ースをＡＣ１４１４にダウンロード１４１２する。ＡＣは、データ辞書を受け取 ると、始めに、ＲＴＣ６２２にダウンロードする前に例えばＡＣＢＭ９２４を介 してルール・ベースを抽出する１４１６。ＲＴＣ６２２は自分のルール・ベース ６２６に従って処理及び切り換えを行う。定期的に或いは時折、ＲＴＣは統計９ ４４及び／又は自分が発見した未知のパケットに関する情報 （指紋）をＡＣ６３８に渡す１４１８。ＡＣ６３８は、自分のデータ辞書９２６ ａに組み込まれているアルゴリズム又はルール・ベースを使ってルールを修正し たり、追加したり、削除したりする１４２２。データ辞書又はルール・ベースに 加えられた変更は、ＩＣに渡され１４１２、記憶される１４２４。ＡＣ６３８は ルール・ベースの新しい、最適化されていないバージョンを抽出してプライム・ インプリカント９３２に渡す１４２６。プライム・インプリカント９３２は、承 認済みルール・ベースをＲＴＣに渡す前に、縮小論理ルールを使ってその新しい ルール・ベースを最適化する１４２８。 図１５は、既知のパケットがスイッチ・アップ（即ちチャネルの追加）を生 じさせる方法の、割合に単純な１つの実例を与えている。図１５の実例では、ル ール・ベース６２６は、パケットを受け取り、そのパケットの種類をＨＴＴＰ（ ハイパーテキスト転送プロトコル）であると識別する１５１２。ルール・ベース は、このパケットが新しい接続のためのヘッダであると確認する１５１４。その 後、ルール・ベースは、そのパケットがセッションの長さを６７０Ｋバイトであ ると指定していると確認する１５１６。ルール・ベースは、このセッションの長 さは、スイッチ・アップに必要な最大バイト数より大きいと確認する１５１８。 セッション（データ・ストリーム）はログされ（情報が記憶され、データ・スト リーム識別子と関連づけられる）、データ・ストリーム即ちセッションの進行が 追跡される１５２２。ＲＴＣは、このデータ・ストリーム及び／又はパケットに 関する統計をＡＣに知らせるためにノートを作り（例えばデータを記憶したり、 フラグをセットしたりすることにより）、それはスイッチ・アップが正しかった か（所望のデータ転送効果をもたらしたか）否か且つ／又はルール・ベースを修 正するべきか否かをＡＣが決定するのに役立つ。その後、ＲＴＣはＡＣを介して ＩＣにメッセージを送ってスイッチ・アップ（帯域幅の追加）を行わせる１５２ ６。 図１６は、未知の種類のパケットが受信された結果としてスイッチ・アップ が行われることになる状態の単純な実例を与えている。図１６の実例では、デー タの種類を識別できないパケットが受信される１６１２。ルール・ベースは、デ ータ長、関連しているデータ・ストリーム、ストリーム中のパケットの数などの 、このパケットに関する情報（指紋）を入手し、前の場合と同じく、その指紋情 報をＡＣに渡すためにノートを作る１６１４。図の実例では、ルール・ベースに スイッチ・アップを要求させる原因となる２つの条件１６１６、１６１８がある 。ルール・ベースは、これらの条件１６１６、１６１８のいずれかが満たされた ときにスイッチ・アップを要求するように構成されても良く、或いは、スイッチ ・アップを要求する前に両方の条件１６１６、１６１８が満たされることを必要 とするようになっていても良い。図の実施例では、第１の条件は、新しいパケッ トを含む新しいデータ転送速度が現在の帯域幅設定についての最大データ転送速 度より大きいことである１６１６。第２の条件は、現在の帯域幅設定についての 所定時間より長い時間にわたってデータ転送速度が高すぎた（閾値より上回って いた）ことである１６１８。ルール・ベースの構成により、これらの条件のいず れか或いは両方が満たされたとき、ルール・ベースはスイッチ・アップするよう にＩＣに（ＡＣを介して）メッセージを送る１６２２。 図１７は、ストリームが集まるとスイッチ・アップが行われることになる実 例を示している。図１７の実例では、ルール・ベースは始めにｅ−メール・セッ ションの開始を意味するパケットを識別する１７１２。前の場合と同じく、ルー ル・ベースは、このセッション即ちデータ・ストリームをログして追跡し、ＡＣ に統計を知らせるためにノートを作る１７１４。ルール・ベースは、データの種 類だけを理由に、即ち単にこれがｅ−メール・セッションであることを理由に、 スイッチ・アップを要求するべきではないと決定する１７１６。或る 構成では、ｅ−メール・セッションについては時間は重要な要素ではないと考え られ、従って通常はスイッチ・アップが行われないようにルール・ベースを構成 することができる。図の実例では、新しいパケットを含む新しいデータ転送速度 が現在の帯域幅設定についての最大値より大きいこと１７１８且つ／又はデータ 転送速度がこの現在の帯域幅設定についての所定時間より長い時間にわたって高 すぎたこと１７２２が確認される。その結果として、パケットがｅ−メール・パ ケットであると識別されたとしても、ルール・ベースはスイッチ・アップするよ うにＩＣに（ＡＣを介して）メッセージを送る１７２４。帯域幅集成は、属性帯 域幅の集成（aggregation of predicate bandwidth）及び実際の帯域幅の集成の 両方との関係で使用され得る。 以上の説明を考慮すれば、本発明の幾つかの利点が分かる。本システムは、 好ましいことに、利用できる帯域幅をいっそう効率よく利用できるようにし、従 って複数のユーザーがＢチャネル又はその他の大帯域幅媒体を共有できるように する。１実施例では、本発明は、約３：１、より好ましくは約５：１、更に好ま しくは約８：１、更にいっそう好ましくは約１０：１より大きいユーザー対Ｂチ ャネル比を提供することができる。好ましいことに、本システムは、例えば可変 速度環境における現在の速度を考慮するなどして、配分がユーザーのデータ通信 料金に及ぼす効果を考慮することに基づいて帯域幅配分を決定する。本発明は、 データ・トラフィックにおける変化に対処することができ、また好ましいことに 変化する条件を自動的に学習して順応することができる。末端ユーザーに課され るコストを減少或いは最小化しながら大帯域幅サービスを必要或いは希望に応じ て提供するために現在の料金及びその他の料金を考慮して決定ルール・ベースを 構成し且つ／又は修正するように本発明を構成することができる。本発明は帯域 幅配分決定のための具体的手段を与え、実行するための、販売業者に依存しない メカニズムを提供する。同じ決定処理手順を修正 無しでいろいろな販売業者のハードウェア上で交換可能に動作させることができ る。この様に販売業者に依存しないので、本発明の決定システムに殆ど或いは全 く修正を加えずに新しいハードウェアへの移行を行うことができ、従ってハード ウェアのアップグレードが更に容易になる。この様に、本書記載の決定システム への販売業者の投資が防止され、新しいシステムが前のシステムの処理手順と両 立することになる。本発明は、直感的ＧＵＩ開発環境と、本システムにより使用 されるルール・ベースを作成し修正するための言語とを提供する。その開発環境 は、既になされている決定アルゴリズム作業を販売業者が完全に且つ容易にルー ル・ベースに統合することを可能にする。ルール・ベース自体はモジュール型で 再利用可能なものであるのが好ましい。本発明は、ルール・ベースをルータにホ ット・ロードして通常動作時に、即ちルータを立ち下げたりブートし直したりせ ずに、またデータ・ストリームを止めずに、実行することを可能にする。ホット ・ロードを行える能力により試験中に頻繁にダウンロードを行うことが可能とな るので、本発明は、アルゴリズムの開発及び試験、及び修正を容易にする。１実 施例では、広く分配されている割合に多数のルータを単一の管理者コンソールが 制御することができる。複数の管理者コンソールを使用して、特定の場所に局在 し且つ／又は遠く離れて接続されているルータの同じグループを管理することが でき（例えば、異なる交替時間の管理者が異なるコンソールを使用することがで きる）、冗長性を求めて基本コンソール、バックアップ用コンソール及び第３コ ンソールを使用することができ、或いはルータの独立した部分に責任を持つ特別 のコンソールを使用することができる。本発明は、ユーザーによる電話会社及び ＩＳＰとの接続を容易にし、ユーザーが自分のＩＳＤＮ利用を或る程度制御でき るようにすることによって、末端ユーザーに利点を直接提供する。クライアント 側アプリケーションを使用できるけれども、クライアント側設備は必要でないの で、望ましい程度の柔軟性、 開放性及び将来校正が得られる。本システムは、好ましいことに、もし充分なメ モリー及び処理資源を利用できるならば、ＢＡＣＰ及びＭＬＰＰＰを支援する遠 く離れて接続されているマシン上の如何なる販売業者ハードウェアとも両立する 。本発明は、キュー深度のみによらずに、好ましくはデータ・ストリーム特性に 基づく将来の帯域幅必要量の予測を用いて、ＩＳＤＮ等の帯域幅を配分する方法 を提供する。 本システムの幾つかの変化形及び修正形を使用することもできる。他の特徴 を使用せずに本発明の一部の特徴を使用することができる。例えば、自動学習処 理手順を使用せずに、ルール・ベースに基づく、データ・ストリーム指向の帯域 幅配分処理手順を実行することが可能である。本発明は、例えば、システムがデ ータ・ストリームのデータの種類を識別できないとき（或いはその識別を行うた めの時間又はその他の資源を欠いているとき）、“サービスのレベル”配分方法 のキュー深度を使用するなど、データ・ストリーム指向帯域幅配分を他のアプロ ーチと組み合わせることも含む。或る実施例では、２つ以上のデータ・ストリー ムに帯域幅を配分する目的で、それらのデータ・ストリームを集合させ得るよう にするのが好都合かも知れない（例えば、共存する２つ（或いはそれ以上）のデ ータ・ストリームのいずれもが帯域幅を追加する正当な理由とはならないけれど も、もし集合したデータ・ストリームに帯域幅を追加すれば全体としての効率が 良くなるような場合に）。複数のネットワーク輸送媒体があったり、或いは例え ばイーサネットやＡＤＳＬネットワークなどのようにネットワーク輸送媒体が１ つだけあるような環境で本発明を使用することができる。１実施例では、キュー を使用し、仮想チャネル或いはソフトウェア・チャネルを配分するように本発明 を実施することができる。本発明をＩＳＤＮインプリメンテーションの文脈で解 説したけれども、（例えば仮想チャネルを設けて使用することにより）Ｔ１、フ レーム・リレー、ＡＴＭ、イーサ ネット、ファイバー及びｘＤＳＬを含む他の電気通信システム又は媒体に本発明 を適用することもできる。ファイバーオプティックス、フレーム・リレー、及び イーサネットを組み合わせたネットワークと関連させて本発明を利用することが でき、また、１種類の媒体のみを有するネットワークと関連させて利用すること もできる（例えば仮想チャネル或いはソフトウェア・チャネルを使って）。例え ばモジュール化、実時間分離、バイト・コード、決定フラギング（decision fla gging）等の特徴は実行の効率化に貢献すると考えられるけれども、これらの特 徴のうちの幾つかを含まない稼働可能なシステムを実現することも可能である。 本発明の或る特徴をＩＳＰ利用の文脈で解説したけれども、本発明を他の幾つも の文脈で実施することもできる。例えば、遠隔ネットワーク・アクセスのために 、システムは（例えば、ＩＳＤＮを使って外部のユーザーをそのルータに接続す る会社によって所有されている）遠隔アクセス・ルータに常駐することができる 。本システムは、例えば法人環境で（そのデータ取り扱いが散発的でパターン化 している）電気通信に便宜を図るために帯域幅を精密に配分することができる。 ルータ同士の接続と関連させて本発明を使用することができる。例えば、衛星の ＰＯＳシステムは中央サイトへの接続を記憶する。本発明は、例えば衛星位置の ルータが、料金の漸増を招くことなく交換接続を介して、長距離輸送回線さえも 介して、絶えず本部に接続され続けることを可能にする。その様なシステムでは 、低レベル・スループット（価格チェック、クレジットカード承認等）が常時オ ン、狭帯域幅Ｄチャネルで行われることができ、価格ファイル転送、クーポン・ ダウンロード、商店取り扱い（store transactions）、要約アップロード等の高 レベル取り扱いは、要求があり次第、必要な追加の帯域幅を利用する。データ・ ストリームに優先順位を設定すること、データ・ストリーム（又はそのパケット ）を待ち行列に入れ且つ／又は保持すること、防火壁又はその他の機密保護機能 を設けること、また ポリシー・エンジンを設けることのいずれか又は全部を含む、いろいろな方法で 本発明を使用することができる。 Ｃ言語で且つ／又はプロログのもの等の公知の人工知能言語主物（artifici al intelligence language principals）を使って本発明の実施例を設けること ができるけれども、他のプログラミング言語及びアプローチを利用して本発明を 実施することも可能である。 本発明を好ましい実施例と変化形及び修正形を解説するという方法で説明し たけれども、他の変化形及び修正形を使用することもでき、本発明は下記の請求 項によって定義される。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＣＮ，ＪＰ，Ｋ Ｒ (72)発明者 デイビット スペル アメリカ合衆国 コロラド州 80293 デ ンバー 2425 サイト 17番 621 ター ンキーソリュージョンズ コープ内 (72)発明者 デイブ ローランド アメリカ合衆国 コロラド州 80293 デ ンバー 2425 サイト 17番 621 ター ンキーソリュージョンズ コープ内 (72)発明者 アジェイ ライ アメリカ合衆国 コロラド州 80293 デ ンバー 2425 サイト 17番 621 ター ンキーソリュージョンズ コープ内 (72)発明者 デイル エリス アメリカ合衆国 コロラド州 80293 デ ンバー 2425 サイト 17番 621 ター ンキーソリュージョンズ コープ内

Claims (1)

1. 【特許請求の範囲】 １． 電気通信システムにおいて少なくとも幾つかのパケットを切り換えて 電気通信ストリームを作るコンピュータで実行されるプロセスであって、このプ ロセスは： 第１帯域幅を有する媒体で伝送されている少なくとも１つのパケットを前記 ストリームの成分として識別し； 少なくとも前記パケットを用いて、少なくとも前記ストリームのありそうな データ・サイズを部分的に予測させる第１の特性を識別し； 追加のパケットを前記ストリームの成分として識別し； 少なくとも前記の第１特性に基づいて、前記の追加のパケットの少なくとも 一部を、前記第１帯域幅より大きな帯域幅を有する第２媒体に切り換えるか否か 決定するステップを有することを特徴とするプロセス。 ２． 前記の少なくとも１つのパケットを識別する前記ステップは、前記パ ケットに含まれている出所情報、目的地情報及びポート情報のうちの少なくとも １つに基づくことを特徴とする請求項１に記載のプロセス。 ３． 前記の少なくとも１つのパケットを識別する前記ステップは、前記パ ケットのデータ部分の情報に基づくことを特徴とする請求項１に記載のプロセス 。 ４． 前記第１特性はパケット・ヘッダ情報から得られることを特徴とする 請求項１、２又は３に記載のプロセス。 ５． 前記第１特性は前記ストリームのデータの種類であることを特徴とす る請求項１〜４のいずれか１つに記載のプロセッサ。 ６． 前記データの種類は： ファイル転送プロトコル； ＧＩＦ； ストリーミング・ビデオ； ストリーミング・オーディオ； ハイパーテキスト転送プロトコル； ＳＭＴＰ； ＳＮＭＰ；及び Ｈ．３２３； のうちから選択されることを特徴とする請求項５に記載のプロセス。 ７． 前記第１特性は使用特性であることを特徴とする請求項１〜４のいず れか１つに記載のプロセス。 ８． 前記使用特性は、与えられた目的地について１つ以上の期間と関連づ けられることを特徴とする請求項７に記載のプロセス。 ９． 前記使用特性は、前記電気通信システムにおける通信リンクの状況と 関連づけられることを特徴とする請求項７に記載のプロセス。 １０． 前記状況は現在のスループットを含むことを特徴とする請求項９に 記載のプロセス。 １１． 前記第１媒体はＩＳＤＮ回線のＤチャネルであり、前記第２媒体は ＩＳＤＮ回線のベアラー・チャネルであることを特徴とする請求項１〜９のいず れか１つに記載のプロセス。 １２． 前記電気通信システムは、少なくともＤチャネルとベアラー・チャ ネルとを有する媒体を包含しており、前記の決定するステップは、前記ベアラー ・チャネルの使用を開始し或いは停止するか否か決定することから成ることを特 徴とする請求項１〜９のいずれか１つに記載のプロセス。 １３． 前記媒体はＩＳＤＮサービス又はＡＯ／ＤＩサービスを提供するた めに使われることを特徴とする請求項１２に記載のプロセス。 １４． 前記媒体はＴ１サービスを提供するために使われることを特徴とす る請求項１２に記載のプロセス。 １５． 前記媒体はＴ１サービス以外のサービスを提供するために使われる ことを特徴とする請求項１４に記載のプロセス。 １６． 電気通信ストリーム中の少なくとも一部のデータを切り換えるため の、電気通信システムにおいてコンピュータで実行されるプロセスであって、こ のプロセスは： 前記ストリームの第１特性を識別するステップを有し、前記特性は少なくと も部分的に前記ストリームのありそうなデータ・サイズを予測させるものであり ； 異なるデータ伝送特性を提供するために少なくとも前記第１特性に基づいて 少なくとも何らかの追加データを切り換えるか否か決定するステップを有し、前 記の決定は、記憶されている第１ルール・ベースに基づいて実行されるようにな っており； 前記の決定するステップの有効性を自動的に評価するステップを有すること を特徴とするプロセス。 １７． 前記の評価するステップに基づいて前記ルール・ベースを修正する ステップを更に有することを特徴とする請求項１６に記載のプロセス。 １８． 前記ルール・ベースを修正する前記ステップは、コンピュータで実 行される自己学習電気通信切り換えプロセスを行うために自動的に実行されるこ とを特徴とする請求項１７に記載のプロセス。 １９． 前記の決定するステップは発見的プロセスによって実行されること を特徴とする請求項１６〜１８のいずれか１つに記載のプロセス。 ２０． 前記の評価するステップはサービスのコスト及びレベルの両方を評 価することから成ることを特徴とする請求項１６〜１９のいずれか１つに記 載のプロセス。 ２１． 前記の評価するステップは総合属性帯域幅を評価することから成る ことを特徴とする請求項１６〜１９のいずれか１つに記載のプロセス。 ２２． 前記の評価するステップは、ユーザーが特定した基準に基づいて評 価することから成ることを特徴とする請求項１６に記載のプロセス。 ２３． 前記の種々のデータ伝送特性は種々の帯域幅特性及び種々の実効デ ータ伝送速度特性から成るグループから選択されることを特徴とする請求項１６ 〜２２のいずれか１つに記載の方法。 ２４． 電気通信システムにおいてデータ・ストリームを待ち合わせさせる 、コンピュータで実行されるプロセスであって、このプロセスは： 第１及び第２の入力データ・ストリームの少なくとも第１及び第２の異 なるデータ・タイプを識別するステップを含んでおり、前記入力データ・ストリ ームは該第２データ・ストリームのパケットに関する前記第１データ・ストリー ムのデータ・パケットの第１周波数を確定し； 少なくとも前記の第１及び第２のデータ・ストリームの前記パケットを 待ち合わせさせるステップを含んでおり； 前記の第１及び第２のデータ・ストリームのうちの少なくとも一方のパ ケットを出力するステップを含んでおり、前記の一方のデータ・ストリームは、 前記第１周波数とは異なる周波数で出力されることを特徴とするプロセス。 ２５． 電気通信システムにおいてパケット転送速度を制御する、コンピュ ータで実行されるプロセスであって、このプロセスは： 少なくとも、第１データ・サイズ・インジケータを含むデータを求める 第１要求を受信し； 前記受信に応答して、前記第１データ・サイズ・インジケータとは異な る第２データ・サイズ・インジケータを有する複数のデータ要求を出力する ステップを含むことを特徴とするプロセス。 ２６． 転送速度制御を維持するために必要な計算データ・サイズを計算す るステップを更に含んでおり、前記第２データ・サイズは、前記計算データ・サ イズ及び前記第１データ・サイズのうちの小さい方であることを特徴とする請求 項２５に記載のプロセス。 ２７． 電気通信システムにおいて機密保護を与えるためにコンピュータで 実行されるプロセスであって、このプロセスは： 前記電気通信システムで伝送される実質的に全てのパケットのデータ・ ストリーム・タイプを識別し； 予め決められた基準を満たすパケットだけを回送するステップを含んで おり、前記の予め決められた基準はパケットのデータ・ストリーム・タイプに関 連する基準を含んでいることを特徴とするプロセス。 ２８． 予め決められたパスワードが受信された場合に限って少なくとも第 １データ・ストリーム・タイプについてパケットを回送するステップを更に含む ことを特徴とする請求項２７に記載のプロセス。