JP2002520950A

JP2002520950A - ミドルウェアベース・リアルタイム通信システム

Info

Publication number: JP2002520950A
Application number: JP2000559677A
Authority: JP
Inventors: ファン，ジャンドン; チェン，ドンフィ
Original assignee: ハネウエル・インコーポレーテッド
Priority date: 1998-07-10
Filing date: 1999-06-22
Publication date: 2002-07-09
Also published as: DE69931052T2; WO2000003521A1; DE69931052D1; EP1097551A1; US6483846B1; CA2336829A1; EP1097551B1

Abstract

(57)【要約】従来のイーサネット・ネットワークを介して決定性の、すなわち予測可能な通信サービスを提供するリアルタイム・イーサネットを実施するためのミドルウェア手法が記述される。本発明は、ネットワーク・インターフェース・デバイスおよびデバイス・ドライバの上方にあり、しかしシステム移送サービスおよび／またはユーザ・アプリケーションの下方にある。ミドルウェアは、ネットワーク上へのデータ・パケットの認可をスケジュールして制御し、データ・パケットのリアルタイム制約を、それらが認可されたときに保証する。本発明は、リアルタイム・データの伝送中のデータ・ストリームの衝突を妨げ、それでも、帯域幅の利用を改良するためのソフトまたは非リアルタイム・データの伝送中の衝突を許すことができる。本発明はさらに、スケジューリング決定にサービス品質定義を組み込むことによって帯域幅利用を最適化することができる。

Description

【発明の詳細な説明】

【０００１】本特許文書の開示の一部は、著作権保護を受けている素材を含む。著作権所有
者は、特許開示の任意の１つによるそのままの複写に対し、それが米国特許商標
庁特許ファイルまたは記録に現れるときには異議をもたず、しかしその他の場合
にはいかなる無断転載も禁ずる。

【０００２】（発明の分野）本発明は、ネットワーク・データ通信に関し、特に、リアルタイム・イーサネ
ットを実施するためのミドルウェア手法に関する。

【０００３】（発明の背景）コンピュータ・ネットワークは、ビジネスおよび産業を通じて広く普及してい
る。それらは、一箇所で、または複数の場所にわたって複数のコンピュータをリ
ンクするために使用されている。

【０００４】ネットワークは、あるコンピュータから別のコンピュータへデータを伝送する
ため、すなわちトラフィックのための通信チャネルを提供する。ネットワークの
用途は無限にあり、単一データまたはファイル転送、遠隔オーディオまたはビデ
オ、マルチメディア会議、工業用制御などが挙げられる。

【０００５】おそらく、最も普及しているネットワーク・プロトコルはイーサネット、すな
わちコンピュータ通信またはコンピュータ間ファイル転送に対する高速端末用の
ローカル・エリア・ネットワーク仕様である。イーサネット通信プロトコルは、
データ通信チャネルまたはバス、典型的にはツイスト・ペアまたは同軸ケーブル
にわたるデータ転送を可能にし、かつそれに対処する。

【０００６】イーサネット通信プロトコルは、ローカル・エリア・ネットワーク（ＬＡＮ）
を介する通信に関するＩＥＥＥ８０２．３標準として標準化された。このプロト
コルは、１持続性、キャリア検知多重アクセス／衝突検出（ＣＳＭＡ／ＣＤ）プ
ロトコルを組み込み、これは、共有ネットワークの１つまたは複数のノードが、
もしそれらが伝送するデータ・パケットを有すると、チャネルを監視し、チャネ
ルがアイドル状態であることを検出するとすぐにそのパケットを伝送することが
できることを意味する。

【０００７】データ・パケットの「衝突」は、２つ以上のノードがネットワーク上で同時に
伝送し始める場合に生じる。衝突しているノードは、そのようなデータの衝突を
検出して、伝送するのを止め、ランダムに決定された時間枠だけ待機してから、
再び伝送を試みる。現行標準下では、ノードが、そのデータ・パケットを衝突を
起こさずに伝送することを試みて、１６回不成功になった後に、障害が生成され
ることになる。

【０００８】軽い負荷の条件のもとでは、衝突はあまり頻繁ではなく、解決が早い。しかし
、負荷が重いと、アクセス時間が不確定になる可能性がある。あるアプリケーシ
ョンがデータ転送時の衝突およびその結果生じる遅延を比較的受けにくい一方、
あるアプリケーションは、時間感受性があり、そのためデータ・パケットの衝突
が望ましくない、さらには受け入れることができない。そのような時間感受性ま
たはリアルタイム適用分野の例としては、遠隔ビデオや、工業プロセス機器の制
御が挙げられる。いくつかの適用分野で、衝突を回避し、正常な送信および受信
を保証することを必要とされることが、イーサネットに様々な改良をもたらして
きた。

【０００９】１つのイーサネット改良は、ＩＥＥＥ８０２．４（トークン・バス）または８
０２．５（トークン・リング）の下で標準化されているトークンベース・プロト
コルである。これら２つの標準の基本的な相違点は、それぞれがアドレス指定す
るように設計されているネットワーク・トポロジにある。トークン・バスは、ノ
ードが論理的リングを形成するネットワークをアドレス指定する。トークン・リ
ングは、ノードが物理的リングを形成するネットワークをアドレス指定する。

【００１０】トークンベース・プロトコルは、ネットワークをたどってあらゆるノードに渡
される「トークン」を生成する。これらのプロトコルは、ノードがトークンを所
持している状態にあるときにのみデータ伝送を可能にし、各ノードが、データを
伝送するために、固定された時間を与えられる。この伝送時間はさらに、様々な
優先順位レベルに関係する複数のセグメントまたはタイマに分割される。これら
の優先順位レベルは、様々なデータ・ストリームに対し、その重要度および時間
感受性に応じて割り当てることができる。ノードは、所与の優先順位レベルのデ
ータのみを、その当該のタイマ中に伝送することができる。この手法の下では、
リアルタイム・データに、衝突の起こらない帯域幅の一部分を保証することがで
きる。しかし、このトークンベース・プロトコルのいくつかは、他のノードがそ
れらの帯域幅を完全に、さらには任意に使用するかどうかにかかわらず、所与の
ノードに帯域幅のその固定された割当分のみを与えることがある。

【００１１】これらのトークンベース・プロトコルに対する改良も提案されてきた。一例と
して、トークンベース・プロトコルを利用するＵＮＩＸプラットフォームで実施
されるソフトウェア指向リアルタイム・イーサネットに関するアカデミック・プ
ロトタイプが提案されている（ＣｈｉｔｒａＶｅｎｋａｔｒａｍａｎｉ「Ｔｈ
ｅＤｅｓｉｇｎ，ＩｍｐｌｅｍｅｎｔａｔｉｏｎａｎｄＥｖａｌｕａｔｉ
ｏｎｏｆＲＥＴＨＥＲ：ＡＲｅａｌ−ＴｉｍｅＥｔｈｅｒｎｅｔＰｒ
ｏｔｏｃｏｌ」Ｐｈ．Ｄ．Ｄｉｓｓｅｒｔａｔｉｏｎ，ＳｔａｔｅＵｎｉｖｅ
ｒｓｉｔｙｏｆＮｅｗＹｏｒｋ，Ｊａｎｕａｒｙ１９９７参照のこと）
。しかし、ＲＥＴＨＥＲは単に、任意のノードによって送信すべきリアル・タイ
ム・トラフィックがそれ以上存在しないときに、非リアル・タイム・トラフィッ
クを行いうるにすぎない。ネットワーク上のトラフィックのタイプによっては、
これが、非リアル・タイム・トラフィックに関するオーバーヘッドを渡すトーク
ンによる低いネットワーク・スループットおよび利用をもたらし、激しいリアル
・タイム・トラフィックをサポートしなかった。

【００１２】別の従来の解決策は、ハードウェア・ベースのものである。この手法の下では
、データ・パケット衝突はハードウェアによって回避される。このハードウェア
ベースの解決策は、厳しい性能および信頼性要件に見合うように、航空機産業な
どのいくつかの重要なリアルタイム適用分野に必要である。しかし、そのような
解決策は、メーカ独自の、ベンダ依存のものであり、それがこの解決策を実施す
ることを困難にし、費用のかかるものにしている。ハードウェアベースの解決策
は、多くの既存のイーサネット・ネットワークに不適合である可能性があり、コ
ストのかかる複雑な変更を必要とする。さらに、これらのハードウェア解決策は
衝突を防止するが、システム全体のリアルタイム・トラフィックのスケジューリ
ングを提供しない。どちらの解決策も、既存のハードウェアまたはソフトウェア
の変更を必要とする。

【００１３】したがって、衝突を防止するため、および既存のイーサネット・ネットワーク
で実施することができ、各種のＣＯＴＳ（ｃｏｍｍｅｒｃｉａｌ−ｏｆｆ−ｔｈ
ｅ−ｓｈｅｌｆ）ハードウェアおよびアプリケーションに適合するイーサネット
を介するリアルタイム・トラフィックを保証するための効率の良い決定性サービ
スが求められている。そのような解決策は、プロセス制御ネットワーク、時間感
受性マルチメディア、およびインターネット・アプリケーションに必要とされる
。

【００１４】（発明の概要）リアルタイム・イーサネットを実施するためのミドルウェア手法は、データの
パケットを伝送することを望む複数のノードを有する従来のイーサネット・ネッ
トワークを介するリアル・タイム・トラフィックと非リアル・タイム・トラフィ
ックの両方に関する決定性の、すなわち予測可能な通信サービスを提供する。ミ
ドルウェアは、ネットワーク・インターフェース・デバイスおよびデバイス・ド
ライバの上方にあり、しかしシステム転送サービスおよび／またはユーザ・アプ
リケーションの下方にあるコンピュータ・ソフトウェアを備える。本発明は、イ
ーサネットを実施する既存のハードウェアに対する変更を必要としないミドルウ
ェア・リアルタイム・イーサネット、すなわちＭＲＴＥを提供する。

【００１５】一実施態様では、イーサネット帯域幅が複数のサイクルに分割される。各サイ
クル中、衝突が生じる可能性がないように、例えばトークンを渡すことによって
決定性スケジューリング・プロトコルを使用して、リアル・タイム・データ・パ
ケット・トラフィックに関する第１の時間間隔が用意される。第２の時間間隔中
、標準キャリア検知、多重アクセス、衝突検出イーサネット・プロトコルが、非
リアル・タイム・トラフィックに使用される。これら２つの時間間隔を使用する
ことによって、リアル・タイム・トラフィックと非リアル・タイム・トラフィッ
クの間で帯域幅が共用され、両方が所望の帯域幅を受け取ることを保証する。

【００１６】一実施形態では、別々の待ち行列が決定性スケジューリングに使用されて、（
１）サービスを伝送することを認可されたときにリアルタイム・トラフィックを
保証することができるように、（２）非リアルタイム・トラフィックを提供する
ことができるように、かつ（３）イーサネット帯域幅利用を最適化することがで
きるように、各ノードでのパケット待ち行列化および伝送の順序を決定する。

【００１７】サービス品質、ＱｏＳ、により、ネットワーク帯域幅利用可能性とネットワー
ク伝送品質の間のオンライン・トレードオフを行うことが可能になる。ＱｏＳの
例としては、（１）あるタイム・スロット中にソフトまたは非リアルタイム・ト
ラフィックによってイーサネットが共用されるときのパケット衝突の程度、（２
）終端間パケット伝送待ち時間が挙げられる。

【００１８】ＱｏＳが用いられるとき、毎秒３０フレームのビデオなどの周期性データに、
優先順位または重要度を与えることができ、例えば１行で最大４フレームの累積
損失ファクタを廃棄することができる。より高い優先順位のタスクまたはデータ
・ストリームが処理された後に帯域幅が十分に残っている場合、ビデオがリアル
・タイム待ち行列に受け入れられることになり、少なくとも毎秒５フレームが送
信される。他のタスクが削除される、または減少される場合、このフレーム率は
増大する。

【００１９】ソフトウェア構造化が、イーサネット・ネットワーク・デバイスおよびデバイ
ス・ドライバの上方にあり、システム転送ソフトウェアおよび／またはユーザ・
アプリケーションの下方にあるリアルタイム・イーサネット・ミドルウェアのホ
スティングを可能にする。そのようなソフトウェア・ホストの具体的な例は、Ｍ
ｉｃｒｏｓｏｆｔ（登録商標）ＮＴ（登録商標）ベースのパーソナル・コンピュ
ータ・プラットフォーム上でデバイス・ドライバ・キット（ＤＤＫ）を備えるＭ
ｉｃｒｏｓｏｆｔ（登録商標）ネットワーク・デバイス・インターフェース仕様
（ＮＤＩＳ）である。選択される特定のハードウェアに応じて、多くの他のソフ
トウェア・ホストが利用可能である。

【００２０】衝突回避モジュールは、伝送がトラフィック衝突を生じないことを保証する。
衝突回避モジュールは、イーサネット・トラフィックが衝突するのを防止する能
力を与える衝突回避プロトコルを実装している。これは非決定性イーサネット挙
動の問題の１つの解決策である。そのようなプロトコルの具体的な例は、トーク
ンベース・プロトコルであり、これによってイーサネット・ノード間で循環する
トークンが、任意の時点でどのノードがパケットを伝送するかを決定する。時分
割多重接続（ＴＤＭＡ）、時分割多重化（ＴＤＭ）を使用する技法の様々な例な
ど他の衝突回避プロトコルを本発明と共に使用することができる。プロトコルま
たは標準は、任意の所与の時間での２つ以上のノードによるデータ伝送間の競合
を回避するための機構を提供する。

【００２１】一実施形態では、衝突回避プロトコルは、望みに応じて、決定性スケジューリ
ング・モジュールによってイネーブルする、またはディスエーブルするように切
換え可能である。これにより、本発明は、リアルタイム・トラフィックの衝突が
ないことを保証し、それでもソフトおよび非リアルタイム・トラフィックの衝突
を許すことができるようになる。そのような混合モード操作は、ソフトおよび非
リアルタイム・トラフィックに割り振られた時間枠中の負荷に応じて、より大き
な帯域幅の利用をもたらすことができる。軽い負荷のＣＳＭＡ／ＣＤシステムは
、衝突回避プロトコルで動作するシステムよりも効率が良くなる場合がある。

【００２２】衝突回避プロトコルはアクティブであるが、伝送するノードの完全な回転に関
して設定される時間に制限がある。トークンベース・プロトコルの場合には、ト
ークンは、この制限された時間、またはトークン回転時間中に戻らなければなら
ない。

【００２３】各衝突回避プロトコル（トークン・ベースまたはＴＤＭＡ）ごとに、決定性ス
ケジューリング・モジュールが、トラフィックをスケジュールするためにあるア
ルゴリズムを使用し、デッドラインが終了する前に伝送が行われることを保証す
る。

【００２４】本発明のさらなる実施態様では、個々のブリッジまたはノードに対する帯域幅
の割振りが、ネットワーク中の他のブリッジまたはノードによる帯域幅の活用が
不十分なことに基づいて増大する。

【００２５】本発明の利点は、ＩＥＥＥ８０２．３標準に適合したままであることである。
そのような適合により、本発明を、ハードウェアの変更を必要とせずに、したが
って開放型システムを維持したままで多数の標準イーサネット・ネットワークで
実施することができるようになる。

【００２６】本発明のさらなる利点は、性質上、モジュラ方式であることである。したがっ
て、本発明は、様々な衝突回避プロトコルと、決定性スケジューリング・アルゴ
リズムと、ＱｏＳ折衝および適合方針およびアルゴリズムとを使用して実施する
ことができる。

【００２７】ソフトウェア手法と同様、本発明はまた、リアルタイム・イーサネット用の任
意のＣＯＴＳイーサネット・カードおよびドライバの使用を可能にする。特定の
ベンダ・イーサネット・カードおよびドライバの使用は、アプリケーションにト
ランスペアレントであり、そのため本発明をベンダ相互操作性があり、システム
構成柔軟性があり、ネットワーク・ユーザに対して低コストなものにする。

【００２８】（実施形態の説明）下記の詳細な説明では、本明細書の一部分を成し、本発明が実施され得る特定
の実施形態を例示するために示されている、付随の図面への参照が行われる。こ
れらの実施形態は、当技術分野の専門家が本発明を実施できるようにするのに十
分な程度の詳細で説明される。また、本発明の趣旨および範囲を逸脱することな
く、他の実施形態を利用することができ、構造上、論理上、電気上の変更を行い
得ることを理解されたい。したがって、下記の詳細な説明は、限定として理解さ
れるべきものではなく、本発明の範囲は、添付の請求項の範囲によって定義され
ている。図中の同じの番号は、同じコンポーネントを指し、このことは、使用の
コンテキストから明白となる。

【００２９】図１は、本発明を組み込んだイーサネット・ネットワークの概念図を示してい
る。イーサネット・ネットワーク１００はイーサネット・チャネル１１０を備え
ている。イーサネット・ネットワーク１００はさらに、イーサーネット・チャネ
ル１１０を通じてデータを受信および送信するため、ドロップ１３０を介してイ
ーサネット・チャネル１１０に接続された２つまたはそれより多くのノード１２
０を含んでいる。ノード１２０は、アプリケーション層１４０、ミドルウェア・
リアルタイム・イーサネット（ＭＲＴＥ）層１５０、およびイーサネット・プロ
トコル層１６０を含んでいる。アプリケーション層１４０とＭＲＴＥ層１５０は
直接通信を行い、ＭＲＴＥ層１５０とイーサネット・プロトコル層１６０は直接
通信を行うが、アプリケーション層１４０とイーサネット・プロトコル層１６０
は、ＭＲＴＥ層１５０を介してのみ通信を行う。

【００３０】図２Ａは、ノード１２０の層のより詳細を示している。詳細には、ＭＲＴＥ層
１５０は論理的に、他のノードに送信するためにアプリケーション層１４０内で
生成されたデータ・トラフィックまたはパケットのための、一対の待ち行列を含
んでいる。第１待ち行列は、リアルタイムでの送信のために受け入れらた情報パ
ケットを待ち行列に入れるためのリアルタイム待ち行列１５２からなる。言い換
えれば、この待ち行列内のパケットは、ネットワーク障害がない限り、衝突なし
に送信されることが保証されている。リアルタイム待ち行列１５２は、トラフィ
ックを重要度に基づいてソートしている。第２待ち行列は、受信ノードにとって
価値をもつのにリアルタイムで宛先に着信する必要のないデータ・パケットに対
する非リアルタイム待ち行列を含んでいる。第２待ち行列１５４は、先入れ先出
し法によってソートされている。待ち行列は、適切なソフトウェアと物理的に別
個であることも、組み合わされていることも可能である。これらの待ち行列は両
方とも、先入れ先出し法スケジューリング・アルゴリズムをもった標準イーサネ
ット衝突待ち行列１６２に入る。アプリケーション層１４０内のアプリケーショ
ンは、望みに応じて、これらの待ち行列のいずれかにデータを割り振る。

【００３１】任意の反復時間サイクルごとに、第１時間枠の間にネットワーク上での衝突が
回避されたリアルタイム待ち行列内のパケットに対する決定性スケジュールを実
施し、第２時間枠の間に非リアルタイム待ち行列１５４から得られた非リアルタ
イム・パケットを標準イーサネット・プロトコルに送信させるように、ＭＲＴＥ
層１５０は帯域幅パーティション・スキームが実装されている。

【００３２】図２Ｂでは、ＭＲＴＥ層１５０をより詳細に表わしたノードが示され、詳細に
は、リアルタイム待ち行列が、衝突回避を提供するのにどのように管理されてい
るかを示している。アプリケーション層１４０では、アプリケーション２０５が
サービス・プロバイダ２１０と連結されている。実際には、アプリケーション２
０５は、データ・パケットの最終的ソース（送信者）または宛先（受信者）とし
て動作する。サービス・プロバイダ２１０は、アプリケーション２０５とＭＲＴ
Ｅ層１５０の間のインターフェースとしての役割を果たす。

【００３３】ＭＲＴＥ層１５０はさらに、ＱｏＳ適応サービス２１５と決定性スケジューリ
ング・サービス２２０に分割されており、一実施形態では、この両方が、ソフト
ウェア・モジュールまたはオブジェクト内に実装される。ＱｏＳ適応サービス２
１５は、ＱｏＳマネージャ２２５およびＱｏＳ適応アルゴリズム２３０を含む。
ＱｏＳマネージャ２２５およびそれに関連するＱｏＳ適応アルゴリズム２３０は
、非リアルタイム・データ・トラフィックの所用時間を変更したり、非リアルタ
イム・トラフィックのための帯域幅とのバランスで、優先度の高いリアルタイム
・トラフィックに対して衝突の起きない十分な帯域幅の提供を確実に行うために
、低重要度のトラフィックをサスペンドするなどの、ＱｏＳに基づいた交渉およ
び適応を行う。

【００３４】決定性スケジューリング・サービス２５０は、衝突解決プロトコル２３５、Ｍ
ＲＴＥプロトコル２４０、ならびにＭＲＴＥスケジューラ２４５およびそれに関
連する決定性スケジューリング・アルゴリズム２５０およびＭＲＴＥリポジトリ
２２５を含む。決定性スケジューリング・サービス２２０はさらに、イーサネッ
ト・プロトコル層１６０に対してＭＲＴＥ層をホストまたはインターフェースす
るソフトウェア構造化２６０を含む。ＭＲＴＥプロトコル２４０は、衝突解決プ
ロトコル２３５の助けを借りて、データ・パケットの衝突を回避する仲裁を実施
する。データ・パケット送信の役割を果たしているイーサネット構成ごとに１つ
のプロトコルが存在する。ＭＲＴＥスケジューラ２４５は、決定性スケジューリ
ング・アルゴリズム２５０の助けを借りて、スケジューリング分析を提供して、
個々のノード間での分散スケジューリングを調整する。イーサネット構成ごとに
１つのスケジューリング・アルゴリズムが存在する。ＭＲＴＥスケジューラ２４
５は、大域的なスケジューリング情報のローカル・イメージを格納するために、
ＭＲＴＥリポジトリ２５５を使用する。

【００３５】イーサネット・プロトコル層１６０は、イーサネット・チャネル１１０への物
理的接続および通信のためのイーサネット・カード（図示せず）をサポートする
、イーサネット・ドライバ２６５を含む。図２Ｂは、サービス・プロバイダ２１
０をＭＲＴＥプロトコル２４０へ、次にソフトウェア構造化２６０へ、次にイー
サネット・ドライバ２６５へと接続する、両方向データ・フローを描いている。
図２Ｂはさらに、ＭＲＴＥプロトコル２４０を衝突解決プロトコル２３５および
ＭＲＴＥスケジューラ２４５に接続する制御フローを描いている。ＭＲＴＥスケ
ジューラはさらに、アプリケーション２０５、ＱｏＳマネージャ２２５、および
決定性スケジューリング・アルゴリズム２５０とのフロー通信を制御する。決定
性スケジューリング・アルゴリズムは、ＱｏＳマネージャ２２５との通信のフロ
ーを制御する。ＱｏＳマネージャはさらに、アプリケーション２０５およびＱｏ
Ｓ適応アルゴリズム２３０との通信のフローを制御する。

【００３６】図２Ｂに描かれる様々なコンポーネントはさらに、表１に示されるとおり、ソ
フトウェア・オブジェクトとして表わすことができる。個々のソフトウェア・オ
ブジェクトは、アプリケーション・プログラミング・インターフェース（ＡＰＩ
）コールを介して通信を行う。各オブジェクトと関連付けられたコールが、図１
でリストされている。

【表１】

【００３７】ネットワークへのアドミッション制御は、２つの方法のうちの１つで開始する
ことができる。アドミッションは、アプリケーションによって要求され得る、ま
たはスケジューラ割り込みによって開始され得る。図３および４は、アドミッシ
ョンを制御する上での様々なコンポーネントの動作を描いている。

【００３８】図３は、アプリケーション要求に応答する動作を描いている。アプリケーショ
ン２０５は、ネットワークを介してデータを送信する要望を示すため、ＭＲＴＥ
サービス・プロバイダにＡｄｍｉｔ（）コールを行う。ＭＲＴＥサービス・プロ
バイダ２１０の方は、ＭＲＴＥスケジューラ２４５にＡｄｍｉｔ（）コールを転
送する。次にＭＲＴＥスケジュールが、アドミッションの要求が保留中であるこ
とを示すために、ＭＲＴＥプロトコル２４０にＧｅｔＰｅｒｍｉｓｓｉｏｎ（）
コールを呼び出す。

【００３９】図４は、スケジューラ割り込みに応答する動作を描いている。割り込みは、選
択された衝突回避プロトコルによって指示される形式で、最初にＭＲＴＥプロト
コル２４０によって受信される。トークンに基づくプロトコルの場合は、割り込
みはソフトウェア構造化２６０から受信されて、個々のノードによるトークンの
受信を示す。ＴＤＭＡに基づくプロトコルの場合は、割り込みはＴＤＭＡタイマ
（図示せず）によって生成されて、タイムスロットが個々のノードによるデータ
送信に対して適切であることを示す。割り込みを受信すると、ＭＲＴＥプロトコ
ル２４０は、ＭＲＴＥスケジューラ２４５にＩｎｄｉｃａｔｅＰｅｒｍｉｓｓｉ
ｏｎ（）コールを行う。ＭＲＴＥスケジューラは次に、ネットワーク状況情報を
得るためにＭＲＴＥリポジトリ２５５にＧｅｔ（）コールを行う。ＭＲＴＥスケ
ジューラ２４５は次に、決定性スケジューリング・アルゴリズムにＳｃｈｅｄｕ
ｌｅ（）コールを行う。ＭＲＴＥリポジトリ２５５は、ネットワーク状況をＭＲ
ＴＥスケジューラ２４５に提供するために、Ｕｐｄａｔｅ（）コールを発行し、
これが次にＭＲＴＥスケジューラ２４５によって発行されたＵｐｄａｔｅ（）コ
ールを介してＭＲＴＥプロトコル２４０に転送される。

【００４０】ネットワーク状況情報でＭＲＴＥプロトコル２４０を更新すると、ＭＲＴＥス
ケジューラ２４５は、ネットワークへのアドミッションが可能になったことを合
図するため、ＭＲＴＥサービス・プロバイダ２１０にＩｎｄｉｃａｔｅＡｄｍｉ
ｔ（）コールを行う。ＭＲＴＥサービス・プロバイダ２１０は次に、Ｉｎｄｉｃ
ａｔｅＡｄｍｉｔ（）コールをアプリケーション２０５に転送する。

【００４１】図５は、ＱｏＳマネージャ２２５の一般的動作を表わす流れ図である。一実施
形態は、この動作はソフトウェア内にＣ＋＋言語で実装され、その動作を記述す
るのに使用される論理ブロックと正確に一致することも、一致していないことも
可能な複数のオブジェクトを含む。当技術分野で周知のとおり、他の実施形態で
は、別の言語ならびに異なるプログラミング・スタイルおよびハードウェアまた
はファームウェアを使用することができる。ＱｏＳマネージャは、開始ブロック
またはボックス５１０、動作ボックス５１５、５２５、５３５、５５０、５５５
、５６５、および判断ボックス５２０、５３０、５４０、５４５、５６０によっ
て表わされている。ＱｏＳマネージャ２２５の初期化は、開始ボックス５１０で
の新しいトラフィック・セッションの着信によって示されている。他のノードに
送信されるべき既知の数または周波数およびサイズのパケットを含んだ着信セッ
ションは、動作ボックス５１５で、ＱｏＳ領域内でスケジュールされる。セッシ
ョンがスケジュール可能であるかどうかについて、判断ボックス５２０で決定さ
れる。セッションがスケジュール可能な場合、フローは、そのセッションのアド
ミッションのために動作ボックス５５０に移る。

【００４２】この時点でセッションがスケジュール可能ではない場合、動作ボックス５２５
で他のセッションのＱｏＳが削減され得る。この処理は、サービスを受けている
特定のアプリケーションに高度に依存している。当技術分野で周知のとおり、通
常、どのアプリケーションでもそれに関連して、容易にＱｏＳに適応可能な、多
数の異なるレベルの重要度をもったデータが存在する。アドミッションの判断は
判断ボックス５３０で行われることになる。セッションがスケジュール可能であ
る場合、そのセッションのアドミッションのために、フローが動作ボックス５５
０に移る。スケジュール可能性処理およびアドミッション処理に関するさらなる
詳細を下記に提供する

【００４３】この時点でセッションがスケジュール可能でない場合、ＱｏＳマネージャ２２
５は、重要度のより低いセッションをサスペンドすることができる。次にアドミ
ッション判断が、判断ボックス５４０で行われる。セッションがスケジュール可
能な場合、そのセッションのアドミッションのために、フローは動作ボックス５
５０に移る。

【００４４】この時点でセッションがスケジュール可能な場合、そのセッションのために、
より高いＱｏＳを使用してスケジューリングが再交渉されるべきかどうかについ
て、判断ボックス５４５で決定されなければならない。再交渉が必要な場合、ス
ケジューリング分析を繰り返すために、フローは動作ボックス５１５に移る。再
交渉が必要ではない場合、待ち行列に入れるために、フローは判断ボックス５６
０に移る。

【００４５】動作ボックス５５０でトラフィック・セッションのアドミッションが行われる
と、このセッションは動作ボックス５５５によって送信される。動作ボックス５
５５によってセッションが送信されると、判断ボックス５６０が、アドミッショ
ンが行われていない、または待ちセッションが存在するかどうか評価することに
なる。待ちセッションが存在する場合、フローは動作ボックス５６５に転送され
て、そこで最も重要度の高い待ちセッションが選択される。フローは次に、動作
ボックス５１５に転送され、スケジューリング分析を繰り返す。待ちセッション
が存在しない場合、この処理は新しいセッションが着信するまで終了となる。

【００４６】図６は、ＭＲＴＥスケジューラ２４５の一般的動作を表わす流れ図である。Ｍ
ＲＴＥスケジューラは、開始ボックス６１０、動作ボックス６１５、６２５、６
３０、６３５、および判断ボックス６２０によって表わされている。要求は、動
作ボックス６１５で決定性スケジューリング・アルゴリズム２５０にしたがって
分析される。動作ボックス６１５でスケジュール可能性の決定を行うと、ＭＲＴ
Ｅスケジューラ２４５は、すでにアドミッションの行われたトラフィックに悪影
響を及ぼすことなしに、その要求を保証できるかどうか判断しなければならない
。

【００４７】悪影響なしにその要求を認可することができる場合、ＭＲＴＥスケジューラ２
４５は、そのトラフィックがどのようにフラグメント化しているか、動作ボック
ス６３０でＭＲＴＥプロトコル２４０に知らせる。次にＭＲＴＥスケジューラ２
４５は、動作ボックス６３５で要求を認可する。悪影響なしに、その要求が認可
できない場合、ＭＲＴＥスケジューラ２４５は、動作ボックス６２５でその要求
を拒否することになる。要求が認可される、あるいは拒否されると、この処理は
終了する。

【００４８】図７は、ＭＲＴＥプロトコル２４０の一般的動作を表わしている流れ図である
。ＭＲＴＥプロトコルは、開始ボックス７１０、動作ボックス７１５、７２０、
７３０、７３５、７５０、７５５、および判断ボックス７２５、７４０、７４５
、７６０によって表わされている。ＭＲＴＥプロトコル２４０は、開始ボックス
７１０で初期化によって示されるとおり、ネットワーク・アドミッションの処理
を開始する。ＭＲＴＥプロトコル２４０が初期化されると、動作ボックス７１５
で示されるとおり、衝突解決プロトコル２３５からシステム構成情報が収集され
る。ＭＲＴＥプロトコル２４０は次に、動作ボックス７２０でユーザ要求および
システム割り込みを待つ。判断ボックス７２５で、１つまたは両方の待ち状態が
満たされているかどうかについて、判断が行われる。両方が満たされている場合
、フローは動作ボックス７３０に転送されて、ネットワーク占有を認可する。

【００４９】動作ボックス７２０の両方の待ち状態が満たされていない場合、ＭＲＴＥプロ
トコル２４０は、ユーザ要求が受信されているか、判断ボックス７４５で判断す
る。受信されていない場合、フローは動作ボックス７２０に戻って、待ち続ける
。ユーザ要求が受信されている場合、ＭＲＴＥプロトコル２４０は次に、動作ボ
ックス７５０で送信およびアドミッション要求を事前処理する。次にそれは、動
作ボックス７５５でシステム割り込みを待つ。システム割り込みが受信されると
、フローは動作ボックス７３０に転送されて、ネットワーク占有を認可する。

【００５０】動作ボックス７３０でいずれかの経路でのネットワーク占有が認可されると、
ＭＲＴＥプロトコル２４０は、動作ボックス７３５でデータを送信し、アドミッ
ション要求を処理して、ネットワーク占有を解放する。次にそれは、他の送信要
求が保留中であるか、判断ボックス７４０で判断することになる。送信要求が保
留中である場合、フローは事前処理のために動作ボックス７５０に移る。保留中
の送信要求がない場合、フローは動作ボックス７２０に転送されて、さらなる要
求およびシステム割り込みを待つ。

【００５１】図８は、ＭＲＴＥプロトコル２４０の割り込み取り扱いの流れ図である。ＭＲ
ＴＥプロトコル２４０は、開始ボックス８１０、動作ボックス８３０、８４０、
８５０、８５５、８６０、８６５、８７５、８８０、および判断ボックス８１５
、８２０、８２５、８３５、８４５、８７０で表わされている。この処理は、開
始ボックス８１０で割り込みの受信とともに開始され、ＭＲＴＥプロトコルは次
に、その割り込みがトークン・パケットまたは衝突解決プロトコル２３５からの
ＴＤＭＡ割り込みのいずれであるかを判断ボックス８１５で判断する。衝突解決
プロトコル２３５からの割り込みである場合、ＭＲＴＥプロトコル２４０は、ア
ドミッション要求が現在、判断ボックス８２０で保留中であるかどうかを判断す
る。

【００５２】割り込みが衝突解決プロトコル２３５からではない場合、ＭＲＴＥプロトコル
２４０は、その割り込みが、ＭＲＴＥシステム状況情報を含んだＭＲＴＥプライ
ベート・データ・パケットであるかどうか、判断ボックス８４５で判断する。そ
れがＭＲＴＥプライベート・データである場合、ＭＲＴＥプロトコル２４０は、
そのシステム状況を更新する。ＭＲＴＥプライベート・データではない場合、Ｍ
ＲＴＥプロトコル２４０は、それが妥当な着信ＭＲＴＥデータ・パケットである
かどうか判断する。それが妥当なデータ・パケットである場合、ＭＲＴＥプロト
コル２４０は、動作ボックス８７５で、そのパケットをＭＲＴＥサービス・プロ
バイダ２１０上に渡す。その割り込みが妥当なＭＲＴＥデータ・パケットでない
場合、ＭＲＴＥプロトコル２４０は、本発明によっては定義されていない、関与
した上部層のプロトコルにそのパケットを渡す。

【００５３】判断ボックス８２０で保留中のアドミッション要求が存在する場合、ＭＲＴＥ
プロトコル２４０は、ＩｎｄｉｃａｔｅＰｅｒｍｉｓｓｉｏｎ（）ＡＰＩコール
を行って、ＭＲＴＥスケジューラ２４５を動作ボックス８５５で呼び出すことに
なる。ＭＲＴＥスケジューラ２４５を呼び出した後、または保留中のアドミッシ
ョン要求が存在しない場合、フローは、保留中のＭＲＴＥ送信要求が存在するか
どうか判断するために判断ボックス８２５に移る。送信要求が保留中である場合
、ＭＲＴＥプロトコルは、動作ボックス８６０でＭＲＴＥ同期メッセージ・パケ
ットを送信する。同期パケットを送信した後、保留中の送信要求が存在しない場
合、フローは動作ボックス８３０に移る。

【００５４】動作ボックス８３０で、ＭＲＴＥプロトコル２４０は、タイマおよび非同期メ
ッセージ待ち行列をチェックする。使用可能な時間および非同期メッセージ待ち
行列に基づいて、ＭＲＴＥプロトコル２４０は、送信時間が使用可能であるかど
うか、また非同期メッセージの準備ができているか、判断ボックス８３５で判断
する。時間が使用可能で、非同期データ・パケットの送信準備ができている場合
、ＭＲＴＥプロトコル２４０は、動作ボックス８６５で非同期データ・パケット
を送信し、次に動作ボックス８４０でイーサネット占有を解放する。時間が使用
可能ではなく、送信準備のできた非同期データ・パケットが存在しない場合、Ｍ
ＲＴＥプロトコル２４０は単に、動作ボックス８４０でイーサネット占有を解放
する。

【００５５】図９は、ＭＲＴＥスケジューラ２４５のアドミッション制御処理の流れ図であ
り、開始ボックス９１０、動作ボックス９１５、９２５、９３０、９３５、９４
０、および判断ボックス９２０を含んでいる。この処理は、ＭＲＴＥプロトコル
２４０からのＩｎｄｉｃａｔｅＰｅｒｍｉｓｓｉｏｎ（）コールの受信によって
開始される。初期化が行われると、ＭＲＴＥスケジューラ２４５は、動作ボック
ス９１５で、Ｇｅｔ（）コールを使用してＭＲＴＥリポジトリ２５５からネット
ワーク状況情報を得る。ＭＲＴＥスケジューラ２４５は次に、９２０で決定性ス
ケジューリング・アルゴリズム２５０に対してＳｃｈｅｄｕｌｅ（）コールを行
うことによって、送信要求をスケジュールすることができるかどうか判断する。
その要求をスケジュールすることができない場合、ＭＲＴＥスケジューラ２４５
は動作ボックス９４０で、ＭＲＴＥサービス・プロバイダ２１０に、９４０でＩ
ｎｄｉｃａｔｅＲｅｃｅｉｖｅ（）コールを使用することによってアドミッショ
ン障害を示して報告を行う。スケジューリングおよびアドミッション制御アルゴ
リズムは、トークンに基づくものまたはＴＤＭＡなどの異なるプロトコルに基づ
いて、決定性スケジューリング・ポリシー・クラス内にカプセル化されている。

【００５６】決定性スケジューリング・アルゴリズム２５０が送信要求をスケジュールでき
ると判断した場合、ＭＲＴＥスケジューラ２４５は、Ｕｐｄａｔｅ（）コールを
使用して動作ボックス９２５でＭＲＴＥリポジトリ２５５を更新する。ＭＲＴＥ
スケジューラ２４５は次に、動作ボックス９３０で、Ｕｐｄａｔｅ（）コールを
使用して動作状況情報でＭＲＴＥプロトコル２４０を更新する。最後に、ＭＲＴ
Ｅスケジューラ２４５は、動作ボックス９３５で、ＩｎｄｉｃａｔｅＲｅｃｅｉ
ｖｅ（）コールを使用してアドミッション成功を示して、ＭＲＴＥサービス・プ
ロバイダ２１０に報告を行う。

【００５７】考慮すべき２つのトラフィック・モデルが存在する。第１は、周期的または同
期メッセージ・ストリームである。各ノード１２０ごとに、このトラフィック・
モデルに含まれるファクタは、その周期（Ｐｊ）、メッセージ長または送信時間
（Ｍｊ）、期限（Ｄｊ）、ＱｏＳ（Ｑｊ）、および重要度または重要性のレベル
（Ｃｊ）であり、ここで「ｊ」は個々のメッセージ・ストリームを表わすものと
する。第２のトラフィック・モデルは、非周期的または非同期メッセージ・スト
リームである。各ノード１２０ごとに、このトラフィック・モデルに含まれるフ
ァクタは、周期（Ｐｊ）を除外して、周期的モデルの場合と同じである。

【００５８】一実施形態では、決定性スケジューリング・アルゴリズム２５０は、一実施形
態で要求がスケジュール可能であるかどうか判断するのに、一組の方定式を使用
する。関係のある方程式は下記のとおりである。

【数３】ただし、下記の追加の定義が適用される：ＴＴＲＴ：目標トークン・ローテーション・タイムＴ_RT：リアルタイム・トラフィックを送信するためのタイム・インターバルＴ_NRT：ソフト・トラフィックまたは非リアルタイム・トラフィックを送信する
ためのタイム・インターバルＩ：ノード数Ｊ：データ・ストリーム数Ｈ_i：個別ノードＩのトークン保持タイムＯ_j：データ・ストリームｊ送信のソフトウェア・オーバーヘッドｎ：ノードの総数ｍ_i：Ｈ_i内での送信のためのリアルタイム・パケットの総数方程式１、２、３を前提として、方程式４が真である場合、新しい要求はスケジ
ュール可能である。

【００５９】（結論）データのパケットを送信することを要望している複数のノードをもった従来の
イーサネット・ネットワークを介して、リアルタイムおよび非リアルタイムの両
方に対して、決定性、すなわち予測可能な、通信サービスを提供するリアルタイ
ム・イーサネットを実施するためのミドルウェア手法を説明してきた。このミド
ルウェアは、ネットワーク・インターフェース・デバイスおよびデバイス・ドラ
イバの上層で、ただしシステム伝送サービスおよび／またはユーザ・アプリケー
ションより下層に常駐するコンピュータ・ソフトウェアを含む。本発明は、イー
サネットを実施する既存のハードウェアに対する変更を必要としないミドルウェ
ア・リアルタイム・イーサネットまたはＭＲＴＥを提供する。各ノード上でのパ
ケット待ち行列入れおよび送信の順序を決定する決定性スケジューリングのため
に、別個の待ち行列が使用されて、（１）送信サービスのためにアドミッション
が行われると、リアルタイム・トラフィックを保証することが可能で、（２）非
リアルタイム・トラフィックに対するサービスを行うことが可能で、（３）イー
サネット帯域幅の使用が最適化できるようにする。クオリティ・オブ・サービス
またはＱｏＳが、ネットワーク帯域幅の使用可能度とネットワーク送信の質の間
でのオンライン・トレードオフを行うことを可能にする。ＱｏＳの例は、（１）
あるタイム・スロットの間でのソフト・トラフィックまたは非リアルタイム・ト
ラフィックによってイーサネットが共有されるときの、パケット衝突の程度、お
よび（２）終端間パケット送信待ち時間の量を含む。

【００６０】ＱｏＳが使用されるとき、毎秒３０フレームでのビデオなどの周期的データに
、優先順位または重要度、ならびに、例えば最高で連続４フレームまで廃棄する
などの、累積的ロス・ファクタを与えることができる。より高い優先順位のタス
クまたはデータ・ストリームが取り扱われた後に、十分な帯域幅が残っている場
合、少なくとも毎秒５フレームを送信する形で、ビデオがリアルタイム待ち行列
に受け入れられる。他のタスクが削除または削減された場合、このフレーム・レ
ートは増加する。

【００６１】ソフトウェア構造化が、イーサネット・ネットワーク・デバイスおよびデバイ
ス・ドライバより上層で、システム・トランスポート・ソフトウェアおよび／ま
たはアプリケーションよりも下層に、リアルタイム・ミドルウェアをホストする
ことを可能にする。こうしたソフトウェア・ホストの特定の例は、マイクロソフ
ト（登録商標）ＮＴ（登録商標）に基づくパーソナル・コンピュータ上の、デバ
イス・ドライバ・キット（ＤＤＫ）を備えたマイクロソフト⁽（登録商標）ネッ
トワーク・デバイス・インターフェース・スペシフィケーション（ＮＤＩＳ）で
ある。選択された特定のハードウェアにより、他の多くのソフトウェア・ホスト
が使用可能である。

【００６２】リアルタイム・イーサネット・ミドルウェアは、２つの主要機能モジュール、
衝突回避モジュールおよび決定性スケジューリング・モジュールを含む。衝突回
避モジュールは、非決定性イーサネット動作の問題の一原因であるイーサネット
・トラフィックの衝突を防ぐための機能を与える衝突回避プロトコルを実装して
いる。こうしたプロトコルの特定の例はトークンに基づくプロトコルである。そ
れによって、イーサネット・ノード間を回っているトークンが、任意の時点でど
のノードがパケットを送信すべきかを決定する。時間分割多重を使用する技術で
ある時間分割多重アクセス（ＴＤＭＡ）の様々な実装など、他の衝突回避プロト
コルを本発明とともに使用することができる。プロトコルまたは規格は、任意の
時点で複数のノードによるデータ送信間の競合を回避するメカニズムを提供する
だけでよい。どちらの実施形態も、リアルタイム処理制御、マルチメディアおよ
びインターネット・アプリケーション、ならびにリアルタイム・トラフィックの
着信に依存する可能性のある他のアプリケーションのために役立つ。

【００６３】決定性スケジューリング・モジュールは、分散システム全体の中で、一組のリ
アルタイム・トラフィックが、終端間送信待ち時間など、そのタイミング制約に
関して保証され得るかどうかを判断する。

【００６４】一実施形態では、衝突回避プロトコルは、決定性スケジューリング・モジュー
ルによる要望に応じて、使用可能または使用不可となるように切り替え可能であ
る。これは、本発明がリアルタイム・トラフィックの衝突が起きないことを保証
しながらも、ソフト・トラフィックおよび非リアルタイム・トラフィックの衝突
を許すことを可能にする。こうした混合モードの動作は、ソフト・トラフィック
および非リアルタイム・トラフィックに割り当てられた時間枠の間でのロードに
より、より大きな帯域幅の使用されることになる可能性がある。軽くロードされ
たＣＳＭＡ／ＣＤシステムは、衝突回避プロトコル上で動作しているシステムよ
り効率的であり得る。

【００６５】衝突回避プロトコルが活動している間、送信を行うノードの完全なローテーシ
ョンのために設定された時間は制約されている。トークンに基づくプロトコルの
場合、トークンは、この制約された時間、つまりトークン・ローテーション時間
内に戻らなければならない。

【００６６】本発明の別の実施形態では、個々のブリッジまたはノードに対する帯域幅の割
り当ては、ネットワーク内の他のブリッジまたはノードが帯域幅を十分に使用し
ていないことに基づいて増加される。

【００６７】本発明を様々な実施形態との関係で説明したが、その意図は、本発明をそうし
た実施形態の１つに限定することではない。前述の説明を検討するれば、当技術
分野の専門家には、他の多くの実施形態が明らかになる。本発明の一実施形態で
は、ＱｏＳモジュールが除外される。本発明のモジュール性のため、システムは
、それをユーザが要望するなら、ある程度後になってからＱｏＳモジュールを受
け入れることができる。

【００６８】本発明の別の実施形態では、複数のローカル・イーサネット・ネットワークを
一緒にブリッジすることができる。ネットワーク間の各ブリッジが、メッセージ
またはデータのストリームを受け入れ、スケジュールを行うことになる。個々の
ブリッジによって保持されるデータ・ストリームは、ブリッジがトークンに基づ
くプロトコルでトークンを所有しているときなど、ブリッジが送信を指定された
ときに送信されることになる。ブリッジがすべてのより優先順位の高いメッセー
ジを送信した後に、データを送信するのに十分な帯域幅があるかどうかに基づい
て、新しいデータ・ストリームは拒否され得る。任意の時間枠で衝突が起きない
ことを保証するため、すべてのブリッジは、その時間枠の間、衝突回避プロトコ
ルのモードで動作していなければならない。

【図面の簡単な説明】

【図１】本発明を組み込む複数のノードを有するイーサネット・ネットワークのブロッ
ク図である。

【図２Ａ】図１のイーサネット・ノードのソフトウェア・アーキテクチャのブロック図で
ある。

【図２Ｂ】いくつかの部分をより詳細に提供する図２のソフトウェア・アーキテクチャの
ブロック図である。

【図３】ネットワークに入る認可を求めるアプリケーション要求に応答するノードの振
舞いを示す図である。

【図４】ネットワークに入る認可を付与するスケジューラ割込みに応答するノードの振
舞いを示す図である。

【図５】本発明の一実施形態のＱｏＳ管理機能の振舞いを示す流れ図である。

【図６】本発明のスケジューラの振舞いを示す流れ図である。

【図７】本発明のＭＲＴＥプロトコルの振舞いを示す流れ図である。

【図８】本発明のＭＲＴＥプロトコルの割込みハンドラを示す流れ図である。

【図９】本発明のスケジューラの認可制御プロセスを示す流れ図である。

───────────────────────────────────────────────────── フロントページの続きＦターム(参考） 5K030 GA03 HA08 HB01 HB19 KX13 5K032 AA01 BA04 CA17 CC12 DA07 DB20

Claims

【特許請求の範囲】

【請求項１】衝突検出ベースの通信ネットワークでリアル・タイム・トラ
フィックを通信するにあたって、非リアル・タイム・トラフィックとは別にリアル・タイム・トラフィックを待
ち行列化するステップと、決定性スケジューリング・プロトコルを使用しながら、通信サイクルの第１の
時間間隔中にリアル・タイム・トラフィックを送信するステップと、通信サイクルの第２の時間間隔中に非リアル・タイム・トラフィックを送信す
るステップとを含む衝突検出ベースの通信ネットワークでリアル・タイム・トラフィックを通
信する方法。
【請求項２】コンピュータに請求項１の諸ステップを実施させるための命
令を格納している機械可読媒体。
【請求項３】衝突検出ベースの通信ネットワークでリアル・タイム・トラ
フィックを通信するにあたって、送信するためのリアル・タイム・トラフィックを有することを示す通信ネット
ワークに結合されたノードでの要求を受信するステップと、リアル・タイム・トラフィックに関して所与のサービス品質を提供することが
できるかどうか判定するステップと、前記サービス品質を提供することができない場合に、非リアル・タイム・トラ
フィックに付与された通信サイクル当たりの第１の時間を調節するステップと、リアル・タイム・トラフィック要求を受け入れるステップとを含む衝突検出ベースの通信ネットワークでリアル・タイム・トラフィックを通
信する方法。
【請求項４】コンピュータに請求項３の諸ステップを実施させるための命
令を格納している機械可読媒体。
【請求項５】さらに、非リアル・タイム・トラフィックとは別にリアル・タイム・トラフィックを待
ち行列化するステップと、決定性スケジューリング・プロトコルを使用しながら、通信サイクルの第１の
時間中にリアル・タイム・トラフィックを送信するステップと、通信サイクルの第２の時間中に非リアル・タイム・トラフィックを送信するス
テップとを含む請求項３に記載の方法。
【請求項６】コンピュータに請求項５の諸ステップを実施させるための命
令を格納している機械可読媒体。
【請求項７】リアル・タイム・トラフィックを待ち行列化する第１の待ち
行列と、非リアル・タイム・トラフィックを待ち行列化する第２の待ち行列と、決定性プロトコルを使用して、通信サイクル当たりの第１の時間枠中に通信ネ
ットワークを介して送信するためにリアル・タイム・トラフィックをスケジュー
ルし、通信サイクル当たりの第２の時間枠中に通信ネットワークを介して送信す
るために非リアル・タイム・トラフィックを提供するスケジューラとを備える衝突検出ベースの通信ネットワークに結合されたノード。
【請求項８】さらに、ノードによって生成されたトラフィックのタイプに
基づいて第１および第２の時間枠を変更するサービス品質管理機能を備える請求
項７に記載のノード。
【請求項９】衝突検出ベースの通信ネットワークがイーサネットを備え、
衝突回避プロトコルが、トークンリングまたは時分割プロトコルを備える請求項
７に記載のノード。
【請求項１０】イーサネット実施ハードウェアによって結合された複数の
ノードを備える通信ネットワークであって、各ノードが、ハードウェアに対して決定性プロトコルを使用して、通信サイクルの第１の期
間中にリアル・タイム・トラフィックを提供し、通常のイーサネット伝送に関し
て、ハードウェアに対して通信サイクルの第２の期間中に非リアル・タイム・ト
ラフィックを提供するソフトウェア・モジュールのミドルウェア・セットを備え
、それにより全てのノードが、各期間中に同じプロトコルを使用して動作する通
信ネットワーク。
【請求項１１】ネットワーク・デバイスと、デバイス・ドライバと、シス
テム・ネットワーク移送ソフトウェアと、ユーザ・アプリケーションとを含むイ
ーサネット・ネットワークで、リアルタイムおよび非リアルタイム・データ・パ
ケットを伝送するための通信プロトコルであって、ネットワーク・デバイスおよびデバイス・ドライバの上方にあり、システム・
ネットワーク移送ソフトウェアまたはユーザ・アプリケーションの下方にある通
信プロトコルをホスティングするためのソフトウェア構造化モジュールと、イーサネット・ネットワークで伝送するためのデータ・パケットの認可のスケ
ジュール可能性および順序を決定するための決定性スケジューリング・モジュー
ルと、決定性スケジューリング・モジュールによって必要とされるイーサネット・デ
ータ・パケット間での衝突を防止する衝突回避プロトコル・モジュールとを備える通信プロトコル。
【請求項１２】衝突回避プロトコル・モジュールがトークン・ベースのも
のである請求項１１に記載の通信プロトコル。
【請求項１３】衝突回避プロトコル・モジュールが、時分割多重接続ベー
スのものである請求項１１に記載の通信プロトコル。
【請求項１４】決定性スケジューリング・モジュールが、リアルタイム・
データ・パケットの衝突を妨げ、非リアルタイム・データ・パケットの衝突を許
す請求項１１に記載の通信プロトコル。
【請求項１５】さらに、イーサネット・ネットワーク利用可能性とイーサネット・ネットワーク伝送品
質の間のオンライン・トレードオフを行うためのサービス品質モジュールを備え
る請求項１１に記載の通信プロトコル。
【請求項１６】ＴＴＲＴをターゲット・トークン回転時間とし、Ｔ_kTを、リアルタイム・トラフィックを伝送するための時間間隔とし、Ｔ_NRTを、ソフトまたは非リアルタイム・トラフィックを伝送するための時間
間隔とし、Ｉをノード数とし、ｊをデータ・ストリーム数とし、Ｈ_iを、個々のノードＩのトークン保持時間とし、Ｏ_jを、データ・ストリームｊを伝送するソフトウェア・オーバーヘッドとし
、ｎをノードの総数とし、ｍ_iを、Ｈ_i中に伝送するためのリアルタイム・パケットの総数とし、リアルタ
イム・データ・パケットは、式４が所与の式１、２、および３を調整するように
評価する場合にスケジュール可能であるとして、式【数１】に従って、決定性スケジューリング・モジュールが、リアルタイム・データ・パ
ケットのスケジュール可能性を決定する請求項１１に記載の通信プロトコル。
【請求項１７】決定性スケジューリング・アルゴリズムを備えるリアルタ
イムおよび非リアルタイム・データ・パケットを伝送するためのイーサネット・
ネットワーク用の通信プロトコルであって、決定性スケジューリング・アルゴリ
ズムが、リアルタイム・パケットと非リアルタイム・データ・パケットのどちらの伝送
も保証し、リアルタイム・データ・パケットの伝送を、そのようなパケットが他のデータ
・パケットの伝送と競合しない場合にのみ可能にし、イーサネット・ネットワークの利用を最適化する通信プロトコル。
【請求項１８】決定性スケジューリング・アルゴリズムが、式【数２】を備え、ここで、ＴＴＲＴをターゲット・トークン回転時間とし、Ｔ_kTを、リアルタイム・トラフィックを伝送するための時間間隔とし、Ｔ_NRTを、ソフトまたは非リアルタイム・トラフィックを伝送するための時間
間隔とし、Ｉをノード数とし、ｊをデータ・ストリーム数とし、Ｈ_iを、個別のノードＩのトークン保持時間とし、Ｏ_jを、データ・ストリームｊを伝送するソフトウェア・オーバーヘッドとし
、ｎをノードの総数とし、ｍ_iを、Ｈ_i中に伝送するためのリアルタイム・パケットの総数とし、それによ
りリアルタイム・データ・パケットは、式４が所与の式１、２、および３を調整
するように評価する場合にのみ伝送を許される請求項１７に記載の通信プロトコ
ル。
【請求項１９】リアルタイムおよび非リアルタイム・データ・パケットを
伝送するためのイーサネット・ネットワーク用の通信プロトコルであって、前記
イーサネット・ネットワークが、ネットワーク・デバイスと、デバイス・ドライ
バと、システム移送ソフトウェアと、ユーザ・アプリケーションとを含み、ネットワーク・デバイスおよびデバイス・ドライバの上方にあり、システム移
送ソフトウェアおよびユーザ・アプリケーションの下方にある通信プロトコルを
ホスティングするためのソフトウェア構造化手段と、イーサネット・ネットワークにわたって伝送するためのデータ・パケットの認
可をスケジュールするための決定性スケジューリング手段と、決定性スケジューリング手段によって必要とされるイーサネット・データ・パ
ケット間の衝突を防止するための衝突回避プロトコル手段とを備える通信プロト
コル。
【請求項２０】決定性スケジューリング手段が、リアルタイム・データ・
パケットの衝突を妨げ、非リアルタイム・データ・パケットの衝突を許す請求項
１９に記載の通信プロトコル。
【請求項２１】さらに、イーサネット・ネットワーク利用可能性とイーサネット・ネットワーク伝送品
質の間のオンライン・トレードオフを行うためのサービス品質手段を備える請求
項１９に記載の通信プロトコル。