JP2002501251A - ユニバーサル・データ交換ゲートウエイのための方法および装置 - Google Patents

Abstract

(57)【要約】 １つまたは複数のネットワーク・プロトコルと、１つまたは複数の制御プロトコルの間でデータを転送できるようにするユニバーサル・ゲートウエイ（１０４）が記載されている。種々のプロトコルが同じ物理的ネットワーク媒体（１００）または別々のネットワーク（１００、１３０）に存在できる。ゲートウエイ（１０４）を用いることによって、エンドユーザーは従来の自立した、互換性のないネットワークを一緒に結合して、ユニバーサルにアクセスできる、中央管理された「スーパーネットワーク」にできる。ゲートウエイ（１０４）は集中化されたノード・データベースと、レガシイ・プロトコルのサポートと、規則エンジンと、オブジェクト指向クラス・ライブラリ・インタフェースとを提供する。集中化されたノード・データベースに対する高信頼性のアクセスが、待機サーバ・ノードによって提供されるシステム障害耐性により強化される。また、ゲートウエイ（１０４）は各種のデータストリームを電源線を通じて分配する能力をもたらす。ゲートウエイ（１０４）によって提供された経路選択ハンドラによりＴＣＰ／ＩＰなどの、ほとんどいかなるレガシイ・データ・ネットワーク化サービスを電源線を通じて送ることができる。

Description

【発明の詳細な説明】

【０００１】

【技術分野】発明の背景 発明の分野 本発明はコンピュータ・ネットワーク・プロトコル・ゲートウエイに関し、特
に、電源線ネットワーキング・システムに適合させられるゲートウエイに関する
。

【０００２】

【従来の技術】関連技術についての説明 コンピュータ、特にパーソナルコンピュータの広範囲な可用性によってコンピ
ュータ・ネットワークの数が急速に増加した。２台または３台以上のコンピュー
タを一緒にネットワーク化することによってコンピュータが情報、ファイル資源
、プリンタを等を共用できる。２台または３台以上のパーソナル・コンピュータ
およびプリンタを一緒に接続してネットワークを構成することは簡単な作業であ
る。コンピュータとプリンタはケーブルを用いて一緒に簡単に接続され、必要な
ソフトウエアがコンピュータにインストールされる。ネットワークの用語では、
ケーブルはネットワーク媒体であり、コンピュータとプリンタはネットワーク・
ノードである。ネットワーク・ノードは、伝送制御プロトコル、インターネット
・プロトコル（ＴＣＰ／ＩＰ）などのプロトコルを１つまたは複数個用いて相互
に「話しあう」。

【０００３】 ゲートウエイは１つのプロトコルから別のプロトコルへのプロトコル翻訳を実
行するために用いられるので、種々のプロトコルを使用する２つのネットワーク
を相互に接続できる。たとえば、Ｐｒｏｄｉｇｙネットワーク・サービスは、そ
の内部に所有する電子メ−ル・フォーマットとインターネット電子メ−ルフォー
マットとの間で翻訳するゲートウエイを有する。

【０００４】 標準的なネットワーク・プロトコルは通常、各ネットワーク・ノードが、十分
な処理性能と十分な記憶性能を持つ「スマート（ｓｍａｒｔ）」な装置であると
の仮定の下に作られている。たとえば、典型的なパーソナル・コンピュータ（Ｐ
Ｃ）はほとんどいかなるネットワーク・プロトコルも取り扱う十分以上の処理性
能と記憶性能を有する。しかし、プリンタは必要な処理性能と記憶性能を有しな
い「ダム（ｄｕｍｂ）」装置である。プリンタをネットワークに接続できるよう
にするネットワーク・プリンタ・アダプタを提供する製造業者もいる。プリンタ
・アダプタは、完全に構成されたＰＣの処理性能と記憶性能に類似する処理性能
と記憶性能を提供する単一のボードコンピュータである。したがって、ネットワ
ーク・プリンタ・アダプタは「ダム」プリンタを「スマート」装置に変換する。
ネットワーク・プリンタ・アダプタは実際に動作するが、比較的高価であるので
多くの家庭や小規模の事務所の環境には向いていない。さらに、プリンタ・アダ
プタはその他の非ＰＣ装置をネットワークに接続するのにはあまり良く適してい
ない。たとえば、ユーザーは、屋外灯、警報器、電話装置等などのダム装置をユ
ーザーのコンピュータ・ネットワークに接続することをしばしば希望する。それ
らの各ダム装置をスマート装置の変えるネットワーク・アダプタ・カードを購入
することは、それを断念させるほど高価につく。

【０００５】 スマート装置のために使用されるプロトコルは「ネットワーク・プロトコル」
と通常呼ばれている。ダム装置のために用いられるプロトコルは「制御プロトコ
ル」としばしば呼ばれる。ネットワーク・プロトコルは、性能と複雑さとにおい
て、制御プロトコルとは全く異なる。それらの違いのために、ネットワーク・プ
ロトコルの間でデータを転送するように構成されているゲートウエイは、制御プ
ロトコルの間でデータを転送するという作業には通常あまり適さない。より困難
なことはネットワーク・プロトコルと制御プロトコルの間でデータを転送する作
業である。

【０００６】 既存の家庭用制御／オートメーション製品は、集中化されたクライアント／サ
ーバ・モデルではなくて同列間モエルを基にしている制御プロトコルを使用する
傾向がある。これは、各ノードが状態情報と諸規則をローカルに記憶することが
要求されるために、これらの製品の可用性を制限する。使用が容易な、集中化さ
れたユーザー・インタフェース部品がないために、ネットワークの構成はしばし
ば困難である。さらに、競合する製品（たとえば、Ｘ−１０とＣＥＢｕｓ）の間
の相互使用可能性がほとんど不可能である。発明の概要 本発明は、１つまたは複数のネットワーク・プロトコルと１つまたは複数の制
御プロトコルの間でのデータ転送可能にする、安価で、使用が容易であり、融通
性があり、信頼性が高く、かつ拡張性があるゲートウエイ・アーキテクチャを提
供することによって、それらの問題およびその他の問題を解決する。種々のプロ
トコルが同じ物理的ネットワーク媒体上に共存できる。このゲートウエイは、選
択されたプロトコルの中にネットワーク・プロトコルを通り抜けさせ（ｔｕｎｎ
ｅｌｉｎｇ）、かつ集中化された制御も行う。

【０００７】 したがって、このゲートウエイはデータおよび制御ネットワークのエンドユー
ザー、特に家庭および小規模事務所の環境における利用者に極めて大きな利益を
もたらす。このゲートウエイによって、エンドユーザーは、他のネットワークと
非互換の従来の自立したネットワークを容易かつ好都合に組み合わせて、コンピ
ュータ、プリンタ、警報装置、家庭用機器、照明装置、電話等を接続する普遍的
にアクセスできる、集中管理される「スーパーネットワーク」にできる。

【０００８】 このゲートウエイは集中化されたノード・データベースと、ＴＣＰ／ＩＰなど
のレガシイ（ｌｅｇａｃｙ）プロトコルの支持、規則エンジン、およびオブジェ
クト指向のクラス・ライブラリ・インタフェースを提供する。このゲートウエイ
は、インターネット・ブラウザなどの使用が容易で、共通のグラフィカル・ユー
ザー・インタフェースを用いて家庭用／小規模事務所のオートーメーションおよ
び制御の広域な可能性を提供する。自動装置の発見によって構成が簡単にされる
。集中化されたノード・データベースに対するアクセスは、待機サーバによって
提供されるシステム障害耐性によって高められる。

【０００９】 このゲートウエイは、電源線ネットワークと共に使用されると、各種のデータ
ストリームを電源線を通じて分配する能力を有する。たとえば、ケーブルモデム
またはその他の種類の高速インターネット接続器を有するネットワーク・ユーザ
ーは、既に設置されている電気配線以外の追加の配線の必要なしに家庭／事務所
内のどこにでもインターネット・トラフィックを送ることができる。音声データ
も電源線を通じて家庭／事務所全体に容易に送られる。このゲートウエイにより
提供されるハンドラによって、今日一般に用いられているほとんど全てのレガシ
イ・データネットワーク化サービスおよびプロトコルを、電源線を通じて送るこ
とができる。

【００１０】 開示されている発明の諸利点および諸特徴は、当業者は下記の図面とともに以
下の詳細な説明を読んだ時に容易に理解されるであろう。

【００１１】 図面において、任意の３桁の番号の最初の数字は、要素が最初に現れた図の番
号を一般に示している。４桁の参照番号が用いられた時は、初めの２桁が図面番
号を示す。好適な実施形態の詳細な説明 図１はユニバーサル・ゲートウエイとともに使用されるのに適したコンピュー
タ・ネットワーク・システムを示す。第１の物理的ネットワークはネットワーク
媒体１００（ケーブルとして示されている）を用いている。スマート・ノード（
パーソナル・コンピュータ１０３として示されている）はコネクタ１０２によっ
てネットワーク媒体１００に接続されている。プリンタ１１０と、コンピュータ
１０４と、安全照明装置１１８もネットワーク媒体１００に接続されている。照
明装置１１８は、比較的低い計算能力と比較的小さい記憶を持つ「ダム」ノード
の例である。コンピュータ１０４は、公衆交換電話回線（ＰＳＴＮ）として示さ
れている第２のネットワーク１３０にも接続されている。

【００１２】 典型的なネットワーク環境においては、ネットワーク媒体１００は各種のデー
タ・プロトコルのためのデータ・トラフィックを伝えるように構成されている。
したがって、図１における例により示されているように、コンピュータ１０３は
ＴＣＰ／ＩＰを用いてコンピュータ１０４と通信でき、コンピュータ１０４は、
たとえば、この開示された出願の、付録Ａとして表示されている部分に記載され
ている電源線交換（ＰＬＸ）プロトコルなどの制御プロトコルを用いて照明装置
１１８と通信する。付録Ａは「電源線交換プロトコル方法および装置（ＭＥＴＨ
ＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＰＯＷＥＲ ＬＩＭＥ ＥＸＣＨ
ＡＮＧＥＰＲＯＴＯＣＯＬ）」という名称の米国特許出願０９／２１１９５０の
部分を含む。この米国特許出願の開示は参照することによりここに含まれる。

【００１３】 ユニバーサル・ゲートウエイは、コンピュータ１０４などのコンピュータでソ
フトウエア・プログラムとして実行される。このユニバーサル・ゲートウエイは
種々のネットワーク・プロトコルの間、および種々の物理的ネットワークの間の
接続を行う。たとえば、図１に示すように、コンピュータ１０４においてソフト
ウエア・プログラムとして実行されているこのユニバーサル・ゲートウエイはＴ
ＣＰ／ＩＰプロトコルをＰＬＸプロトコルに接続することにより、コンピュータ
１０３が照明装置１１８と通信できるようにする。

【００１４】 コンピュータ１０４においてソフトウエア・プログラムとして実行されている
このユニバーサル・ゲートウエイは別々の物理的ネットワークの間のデータ転送
も行うことにより、別々の物理的ネットワークにおける装置が相互に通信できる
ようにする。図１において、このユニバーサル・ゲートウエイはネットワーク１
３０と照明装置１１８との間のデータ転送を行う。

【００１５】 このユニバーサル・ゲートウエイは階層状のネットワーク・プロトコルに適合
する。スマート・ノード（コンピュータ１０３および１０４など）用に構成され
たほとんどのネットワークは、オープン・システム・インタフェース（ＯＳＩ）
委員会により開発されたネットワーク・アーキテクチャ・モデルを基にしている
。ＯＳＩアーキテクチャは、通信システム内の個々の各ハードウェア層およびソ
フトウエア層と、層の間の相互依存性と、各層が実行する独自の機能とについて
の概要を示すネットワーク・モデルを定める。

【００１６】 図２は、１番下の層から１番上の層まで、物理層２０１、データ・リンク層２
０２、ネットワーク層２０３、トランスポート層２０４、セッション層２０５、
プレゼンテーション層２０６、およびアプリケーション層２０７の７つの層とし
てＯＳＩアーキテクチャが編成されていることを示す。各層はそれのすぐ下の層
を用いてすぐ上の層のサービスを行う。ある実現例では、ある層は副層により自
身で構成できる。ある層は、特定のネットワーク・プロトコルが動作する２つま
たは３つ以上の通信装置またはコンピュータの、ソフトウエア環境および／また
はハードウェア環境である。ネットワーク接続は、おのおの異なる層またはレベ
ルにある、多少とも独立している１組のプロトコルであるとして考えることがで
きる。１番下の層は、種々のノードにおけるハードウェアの間の直接ノード間通
信を支配し、１番上はユーザー・アプリケーション・プログラムで構成されてい
る。各層はそれの下の層を用いて上の層に対するサービスを行う。１つのホスト
における各ネットワーク化コンポーネント・ハードウェアまたはソフトウエアは
それの層に適切なプロトコルを用いて、他のノードにおける対応するコンポーネ
ント（それの「同等なコンポーネント」）と通信する。そのような階層状のプロ
トコルは同列間プロトコルとして知られていることがある。

【００１７】 階層状にされたプロトコルの利点は、１つの層から別の層へ情報を送る方法が
プロトコルの部分として明らかに指定され、かつ１つのプロトコル層内での変化
が他のプロトコル層に影響を及ぼすことが阻止されることにある。これによって
通信システムの設計および維持が簡単になる。

【００１８】 物理層２０１はＯＳＩ階層化モデル内の１番下の層である。それは媒体アクセ
ス制御（ＭＡＣ）を含むネットワークの電気的接続と機械的接続を含む。媒体ア
クセス制御とは、データ伝送媒体１００（たとえば、ネットワーク・ケーブル）
の制御、およびそれに対するアクセスを指す。物理層２０１はデータ・リンク層
２０２により用いられる。

【００１９】 データ・リンク層２０２はＯＳＩ層モデル内の１番下から２番目の層である。
データ・リンク層２０２はデータを（物理層２０１で送られる）フレームに分割
し、確認応答フレームを受信する。データ・リンク層２０２は誤り検査を行い、
正しく受信されなかったフレームを再送する。データ・リンク層２０２は誤りの
ない仮想チャネルをネットワーク層２０３に提供する。データ・リンク層２０２
は上側の副層、すなわち、論理リンク制御（ＬＬＣ）と、媒体アクセス制御（Ｍ
ＡＣ）の部分を含む下側の副層とに通常分割される。

【００２０】 ネットワーク層２０３はＯＳＩの７層モデル内の１番下から３番目の層である
。ネットワーク層２０３は、送り手からデータ・リンク層２０２を経由する受け
手までのデータ・パケットの経路を決定し、かつトランスポート層２０４によっ
て用いられる。最も一般的なネットワーク層プロトコルはＩＰである。

【００２１】 トランスポート層（または「ホスト−ホスト層」）２０４はＯＳＩモデル内の
中間層である。トランスポート層２０４は、最初のノードがメッセージを第２の
ノードへ送ることができ、それらのメッセージが変更されないで、正しい順序で
到達するように、誤りのない点間の仮想接続を行うためにネットワーク層２０３
をどのように使用するかを決定する。トランスポート層２０４はノードの間の接
続を行い、かつ解消する。

【００２２】 セッション層２０５はＯＳＩモデル内の１番上から３番目のプロトコル層であ
る。セッション層２０５はトランスポート層２０４を用いて種々のノードにおけ
るプロセス間の接続を確立する。セッション層２０５はセッションの安全と作成
を取り扱う。

【００２３】 プレゼンテーション層２０６はＯＳＩモデル内の１番上から２番目のプロトコ
ル層である。プレゼンテーション層２０６はノードの間の違いをならそうとして
テキスト圧縮、コードまたはフォーマットの変換などの機能を実行する。プレゼ
ンテーション層２０６によってアプリケーション層内の適合しないプロセスがセ
ッション層を介して通信できるようにされる。

【００２４】 アプリケーション層２０７はＯＳＩモデル内の１番上の層である。アプリケー
ション層２０７はネットワークについてユーザーが見るもの（たとえば、電子メ
ール・メッセージのフォーマット）に関するものである。プレゼンテーション層
２０６はアプリケーション層２０７に、ネットワークで使用されているフォーマ
ットとは独立したデータのなじみのローカル表現を提供する。アプリケーション
層プロトコル例にはＴｅｌｎｅｔ、ファイル転送プロトコル（ＦＩＰ）、シンプ
ル・ネットワーク・マネージメント・プロトコル（ＳＮＭＰ）、シンプル・メー
ル転送プロトコル（ＳＭＴＰ）、インターネット制御メッセージ・プロトコル（
ＩＣＭＰ）、ネットウエア・コア・プロトコル（ＮＣＰ）、経路指定情報プロト
コル（ＲＩＰ）、サービス・アドバータイジング・プロトコル（ＳＡＰ）、単純
ファイル転送プロトコル（ＴＦＴＰ）、およびシステムフォールトトレランスプ
ロトコル（ＳＦＴＰ）が含まれる。

【００２５】 図３はユニバーサル・ゲートウエイ３００のアーキテクチャと、ゲートウエイ
３００が、アプリケーション・プログラム、ハードウェア・ドライバなどの他の
ソフトウエア・コンポーネントとどのようにしてやり取りするかを示す。アプリ
ケーション・プログラム３０２は１組のゲートウエイ・ファウンデーション・ク
ラス３０４を用いてゲートウエイ３００と通信する。ゲートウエイ・ファウンデ
ーション・クラス３０４はデータベース・アクセス・モジュール３０６と、事象
ハンドラ３１０と、ディスパッチャ３２０と、ルーティンオペレーティングシス
テム・サービス（ＲＴＯＳ）３１１と通信する。データベース・アクセス・モジ
ュール３０６は、（ノード・データベース）と呼ばれている情報保存部３０８を
含む。ノード・データベース３０８はデータベース、リンクされたリスト、表、
マップ、コンテナ等として編成できる。データベース・アクセス・モジュール３
０６は事象ハンドラ３１０と、ペイロード／プロトコル・プロセッサ３１２とも
通信する。ペイロード／プロトコル・プロセッサ３１２は、生データ・ハンドラ
３１６、ストリーミング・データ・ハンドラ３１７、およびＣＡＬ制御ハンドラ
３１８などのペイロード／プロトコル・ハンドラを１つまたは複数個含む。事象
ハンドラ３１０は規則エンジン３１４およびディスパッチャ３２０とも通信する
。ディスパッチャ３２０はＲＴＯＳ３１１と、規則エンジン３１４と、ＰＬＸ装
置ドライバ３２２と、レガシイデバイスドライバ３２６とも通信する。ＰＬＸデ
バイスドライバ３２２はＰＬＸ制御装置ドライバ３２３（ダム装置のため）とＰ
ＬＸデータ装置ドライバ３２４（スマート装置のため）を含む。

【００２６】 ゲートウエイ３００は１つのプロトコルから別のプロトコルへのプロトコル翻
訳を行うので、異なるプロトコルを使用している２つのネットワークを相互に接
続できる。それらのネットワークは実在の物理的ネットワークとすることもでき
れば、ネットワークを仮想ネットワーク（すなわち、ソフトウエア内にのみ存在
する）とすることができる。ゲートウエイ３００はレガシイ・プロトコルと主（
すなわち、所望の）プロトコル（たとえば、電源線プロトコル）との間のインタ
フェースを行う。レガシイ・プロトコルという用語は既存のプロトコルに限定さ
れるものではない。それよりも、レガシイ・プロトコルという用語は主プロトコ
ル以外の任意のプロトコルを指すことを意図するものである。レガシイデバイス
ドライバは、たとえば、Ｘ−１０ドライバ３２９とＣＥＢｕｓドライバ３３２を
含む。各レガシイ装置ドライバは、レガシイ装置ドライバをゲートウエイに適合
させるシムを含むことを選択もできる。一実施形態では、主プロトコルは電源線
プロトコルであるが、ゲートウエイ３００はそのようには限定されない。したが
って、主プロトコルは、たとえば、ＴＣＰ／ＩＰ、ＩＰＸ、ＡＤＳＬ、およびこ
の開示の他の箇所に掲記されているか、この技術で知られているその他のプロト
コルのいずれかを含めた任意のプロトコルとすることができる。

【００２７】 イーサネット・ドライバ３６２およびＡＤＳＬドライバ３６４などのレガシイ
装置ドライバ３６２をストリーミングするために、ゲートウエイはレガシイ・ス
タック３５２を提供する。レガシイ・スタック３５２はＴＣＰ／ＩＰスタック３
５２およびＳＰＸ／ＩＰＸスタック３５４などのＯＳＩプロトコル・スタックを
サポートする。レガシイ・スタック３５２はストリーミング・レガシイ装置ドラ
イバ３６２および経路選択ハンドラ３５５と通信する。経路選択ハンドラ３５５
はストリーミング・レガシイ装置ドライバ３６２と、レガシイ・スタック３５２
と、ペイロード／プロトコル・プロセッサ３１２と通信する。レガシイ・スタッ
ク３５２はレガシイ・アプリケーション３５０とも通信する。

【００２８】 ゲートウエイ３００は各種のネットワークの間の接続点として機能して、イー
サネット、デジタル交換線（ＤＳＬおよびＡＤＳＬ）、電源線交換機（ＰＬＸ）
、Ｘ−１０、およびＣＥＢｕｓを含むが、それには限定されない、制御ネットワ
ークおよびデータ・ネットワークのサポートを行う。

【００２９】 ゲートウエイ３００は、ノード管理およびデータ経路選択の２つの主機能を有
する。ノード・マネジャーとして、ゲートウエイ３００はネットワーク・ノード
状態情報の発見と、列挙と、検索と、保存と、処理との責任を負う。その状態情
報はノード・データベース３０８に保存される。ノード・データベース３０８は
汎用共通アプリケーション言語（ＣＡＬ）仕様を基にしている。ＥＩＡ−６００
で定められたＣＥＢｕｓはバス装置を制御するための工業規格制御言語である。
ＥＩＡ−６００は家庭ＬＡＮ内で使用するための共通アプリケーション言語用の
骨格を提供する。汎用ＣＡＬはＥＩＡ−７２１シリーズの規格（ＥＩＡ−７２１
．１、ＥＩＡ−７２１．２、ＥＩＡ−７２１．３、ＥＩＡ−７２１．４を含む）
で定められる。ＣＥＢｕｓ工業協議会（ＣＩＣ）は、汎用ＣＡＬを使用するため
の「文法」規則を定めることによってその骨格に肉付けするホーム・プラグ＆プ
レイ（ＨＰＰ）を定めている。

【００３０】 ＨＰＰ仕様は、家庭内の製品およびシステムが家庭の状態に応じた動作を行え
るようにする、それらの製品やシステムのための１組のハードウェア特性の詳細
を定めている。たとえば、その仕様は、「住人が居ない」または「住人は在宅し
ているが寝ている」などの家庭内の種々の状況を識別して、安全装置を作動状態
にする、屋内灯を消す、または温度設定に類似する適切な動作を家庭システムが
行えるようにする。ＨＰＰ仕様は家庭制御用のウインドウズ９５ＰＣベース・ア
プリケーションを開発するための情報も含む。

【００３１】 ＥＩＡ−６００内で定められた共通アプリケーション言語は、種々の産業分野
（たとえば、娯楽、コンピュータ、暖冷房、台所用品、等）で製造された家庭Ｌ
ＡＮ製品の間の通信のための枠組を提供する。各産業分野は、それの製品がその
言語を使用する基準を成す「アプリケーション・コンテキスト」（すなわち、文
法規則）を定める。ＣＩＣは、種々の産業分野が「調和の取れた」アプリケーシ
ョン・コンテキストを開発することを支援する支持組織として活動するために設
立された。ＣＩＣのＨＰＰは、相互に運用できるＣＡＬをベースとする製品で家
庭ＬＡＮ市場を求めているそれらの産業分野のための調和の取れたアプリケーシ
ョン・コンテキストの概要である。

【００３２】 ＣＥＢｕｓ／汎用ＣＡＬ仕様の全体を参照することによりその仕様はここに含
まれる。

【００３３】 ゲートウエイ３００は、ノード状態変化を監視し、ユニバーサル規則定義言語
（ＲＤＬ）シンタックスを用いて定義された規則に従ってそれらの状態変化に対
して動作する規則エンジン３１４を提供もする。

【００３４】 ゲートウエイ３００は、ディスパッチ制御ブロック（ＤＣＢｓ）を用いること
によってデータ・ストリーミング・タスクと経路選択タスクの取扱いもする。経
路選択ハンドラ３５５はＰＬＸを通じるＴＣＰ／ＩＰトンネリング、プロキシ・
サーバ、およびネットワーク・アドレス翻訳のような機能を行う。シム（３２８
、３３０）は、非ＰＬＸ電源線をベースとするノードをＰＬＸネットワークに継
目なしに挿入できるようにするために設けられる。ゲートウエイ・ファウンデー
ション・クラス３０４は、ユーザー・インタフェースおよびシステム管理アプリ
ケーション３０２が使用するオブジェクト指向ＡＰＩライブラリイを提供する。
ゲートウエイ３００は、レガシイ、非ユニバーサル・ネットワークＡＰＩｓ（Ｍ
ＦＣ、ＴＬＩ、ソケット、家庭ＡＰＩ、等）を使用するアプリケーションがネッ
トワーク・ノードと通信できるようにするサポートを提供する。これによりネッ
トワークを通じてのレガシイ・ネットワーク・データの透明なデータ・ストリー
ミングを行うことができるようにされる（イーサネット、ＡＤＳＬ、等）。それ
には、ジャバおよびウエブブラウザを用いてゲートウエイ３００により管理され
るノードを制御する能力が含まれる。

【００３５】 オペランド・データベース３０８はゲートウエイ３００により保存されている
ノード・データの保存場所である。ノード・データは各クライアント・ノード、
事象待ち行列、クライアント・ノード・バインディングス（ｂｉｎｄｉｎｇｓ）
および規則から得られたノード構成輪郭を含む。ゲートウエイ３００のその他の
が１組のアクセス規則３０６によってノード・データベース３０８をアクセスす
る。

【００３６】 事象ハンドラ３１０と規則エンジン３１４はクライアント・ノードで起きる状
態変化の結果として起きる行動の責任を負う。規則エンジン３１４は状態変化に
関連する規則を解釈し、かつ規則評価の結果としてトリガされることがあるスケ
ジューリング通知要求またはＣＡＬ送り要求の責任を負う。規則エンジン３１４
はノード・データベース３０８および事象ハンドラ３１０と一緒に動作する。事
象ハンドラ３１０は事象待ち行列を処理し、事象通知を実行する。それらの事象
通知はゲートウエイ３００の他のコンポーネントへの内部通知と、事象通知を受
信することを登録したアプリケーション３０２への外部通知とを含む。ゲートウ
エイ３００とアプリケーション３０２との間の相互作用はゲートウエイ・ファウ
ンデーション・クラス３０４を介して行われる。

【００３７】 ディスパッチャ３２０は、送／受待ち行列の取扱いと、スレッド（ｔｈｒｅａ
ｄ）初期化と、管理等を含む、ゲートウエイ３００の実行時間オペレーションを
指示する責任を負う。管理を要求するゲートウエイ活動はアプリケーションＣＡ
Ｌ送り要求タスクと、生ストリーミング・データ要求スクと、事象受信タスクと
、バックグラウンド・ハウスキーピング・タスクとを含む。ディスパッチャ３１
４は汎用インタフェースをネットワーク装置ドライバ３２２、３２６に提供して
、ドライバ３２２、３２６によりサービスされる下部のネットワーク制御器ハー
ドウェアについての詳細な知識を必要とすることなく各種のネットワーク・ノー
ドのサポートを行えるようにする。

【００３８】 デバイスドライバ３２２、３２５はネットワーク通信ハードウェア（ＵＳＢま
たは並列ポートＰＬＸノード、Ｘ−１０シム、ＣＥＢｕｓシム等）と直接通信し
、かつデータ・リンク層２０の機能（たとえば、ＭＡＣヘッダーの発生／解釈、
低レベル・タイミング等）を取り扱う。ドライバ３２２、３２６のうち、下部ハ
ードウェアと直接話し合う部分は、ドライバとハードウェアとの間に存在し得る
種々の接続（たとえば、ユニバーサル直列バス（ＵＳＢ）、並列ポート、ファイ
ヤ（Ｆｉｒｅ）ワイヤ・ポート、ＰＣＩスロット、ＩＳＡスロット、直列ポート
等）をサポートするために独自のプラットフォームであるのが普通である。ゲー
トウエイ３００は、レガシイＸ−１０およびＣＥＢｕｓノードから受けとった制
御データの、ゲートウエイ３００により用いられるフォーマットへの変換を取り
扱うためにシム・コンポーネント３２８、３３０を提供する。

【００３９】 ペイロード／プロトコル・プロセッサ３１２内のペイロード／プロトコル・ハ
ンドラ３１６−３１８は受信されたパケット・データの構文解析および処理の責
任を負う。データ・ハンドラ３１６−３１７は経路選択ハンドラ３５５と一緒に
動作する。経路選択ハンドラ３５５は生データ・パケット・ヘッダを構文解析す
る。ルー・ハンドラ３５５は、種々のレガシイ・プロトコル・スタック３５２と
レガシイ・ストリーミング・ドライバ３６２の間のデータの流れの指示を助ける
アドレス表および経路選択表を調べもする。

【００４０】 種々のプラットフォームおよび種々のオペレーティングシステムを横切るコー
ド移植性（ｐｏｒｔａｂｉｌｉｔｙ）を維持するために、プラットフォームに特
有のコードが、ＲＴＯＳ ３１１により提供されるプラットフォーム分離（ａｂ
ｓｔｒａｃｔｉｏｎ）層内で分離される。典型的な実行時間サービスはスレッド
・スケジューリングと、メモリ管理と、割込み処理と、クロックと、同期化と、
優先順位スケジューリングと、初期化等を含む。

【００４１】 ゲートウエイ３００内のコンポーネントの多くは、ノード・データベース３０
８と直接にまたは間接に相互作用する。データベースを最初に構築し、維持する
タスクはディスパッチャ３２０と、ドライバ３２２、３２６と、ペイロード／パ
ケット・ハンドラ３１２とによって主として取り扱われる。ユーザー・インタフ
ェースおよび管理アプリケーションがゲートウエイ・ファウンデーション・クラ
ス３０４を介してノード・データベース３０８をアクセスおよび／または変更す
る。

【００４２】 ノード・データベース３０８は、実時間アクセスが速くて効率的であるように
構成されている。速さ／メモリ使用の間の妥協が用いられ、アクセス速度よりも
効率的なメモリ使用に優先順位が通常与えられる。ある実施形態では、ノード・
データベース３０８の部分が不揮発性記憶装置に保存される。

【００４３】 ノード・データベース３０８はクライアント・ノード構成とノード状態情報を
含む。これはコンテキストと、オブジェクトと、各クライアント・ノードに関連
するインスタンス変数（ＩＶ）情報を含む。この情報はノード発見中にネットワ
ーク・コマンドとネットワーク要求を用いて得られる。この情報のうち、ダイナ
ミックＩＶｓが固定記憶装置に保存される。ほとんどのオブジェクト（ノード制
御またはコンテキスト制御は含んでいない）に対して、これはノードの状態を定
める現在の値ＩＶｓを含む。

【００４４】 ノード・データベース３０８はゲートウエイに特有のある情報をも含む。各ノ
ードに対して存在するノード・コンテキスト以外に、ノード・データベース３０
８は、ノード管理のために必要とされるオブジェクトを含んでいるデータベース
・サーバ・コンテキストを含む。このデータベース・サーバ・コンテキストは、
ゲートウエイ３００によって知られているクライアント・ノード・アドレスのア
レイを含むネットワーク・ノード・リスト・オブジェクトを含む。

【００４５】 ノード・データベース３０８はアクセス法の汎用セットを通じてアクセスされ
る。ほとんどのアクセスはネットワーク・メッセージを通じて直接または間接に
来るので、データベース・アクセス法３０６は典型的なネットワーク獲得および
セット法を用いて変数値を獲得およびセットする責任を負う。それらの方法には
ＧｅｔＶａｌｕｅ、ＧｅｔＡｒｒａｙ、ＳｅｔＶａｌｕｅ、ＳｅｔＡｒｒａｙ、
ＳｅｔＯｎ、ＳｅｔＯｆｆが含まれる。どの方法が適切であるかは取り扱われて
いるインスタト変数のタイプに依存する。たとえば、ＣＡＬネットワークは、ブ
ーリアン（ＧｅｔＶａｌｕｅ、ＳｅｔＶａｌｕｅ、ＳｅｔＯｎ、ＳｅｔＯｆｆ）
、数値（ＧｅｔＶａｌｕｅ、ＳｅｔＶａｌｕｅ）、キャラクタ・ストリング（Ｇ
ｅｔＶａｌｕｅ、ＳｅｔＶａｌｕｅ）、およびデータ（ＧｅｔＡｒｒａｙ、Ｓｅ
ｔＡｒｒａｙ）の４つのＩＶデータ・タイプを定める。

【００４６】 ほとんどの部分に対して、それらの方法は入力キーの類似のセットを取り、そ
れらは取り扱われているデータと、任意の数の入力引数を識別する。その後で各
方法は求められた情報（もしあれば）と状態を戻す。たとえば、ＣＡＬ ＩＶｓ
を取り扱う方法の汎用プロトタイプは下記のものに類似する。 ENUM STATUS<method>(NodeID,Context,ObjectID,IVID,args,.... ★returnVal) この場合には、ＮｏｄｅＩＤ、ＣｏｎｔｅｘｔＩＤ、ＯｂｊｅｃｔＩＤ、およ
びＩＶＩＤはキーである。非ＣＡＬオブジェクトに対しては異なるキーセットが
用いられる。

【００４７】 インスタンス変数にセット操作が起きると、事象通知が事象ハンドラ３１０を
通じて規則エンジン３１４に対して行われて、状態変化事象が起きたことを通知
する。その後で規則エンジン３１４は、変化したインスタンス変数に属する規則
状態／報告状態を解釈し、行動が保証されているならば、事象ハンドラ３１０に
よって事象のスケジュールを定める。この結果としてディスパッチャ３２０を辻
てネットワーク送り要求が発生し、またはファウンデーション・クラス３０４を
通じてより高いレベルのアプリケーション３０２に通知されることになる。

【００４８】 上記のように、ノードＩＶを獲得またはセットするためにアクセス呼び出しが
行われると、４つの情報（またはキー）が通常提供される。それらにはＮｏｄｅ
ＩＤと、ＣｏｎｔｅｘｔＩＤと、ＯｂｊｅｃｔＩＤと、ＩＶＩＤとが含まれる。

【００４９】 ＮｏｄｅＩＤは構成中に割り当てられた（これは製造時に、または実行時間中
に動的に、生ずることがある）ノード・アドレスである。ＰＬＸネットワークの
場合には、これは４バイト・フィールドであって、０ｘ０００００００１と０ｆ
ｆｆｆｆｆｅｆの間の値を取ることができ、この範囲より上のアドレスは放送ま
たはその他のＰＬＸに独自の使用のために取って置かれる。非ＰＬＸネットワー
クの場合には、同じアドレス・マッピング／翻訳が通常求められる。経路選択ハ
ンドラ３５５はアドレス翻訳問題に気を付ける。

【００５０】 ＣｏｎｔｅｘｔＩＤは２バイト長であって、大きなバイトは選択可能なコンテ
キスト数で、それの値は０ｘＡ０・０ｘＤＥの範囲であるが、使用されなければ
０である。小さいバイトは０ｘ００・０ｘ９Ｅの範囲内のコンテキスト・クラス
値である（それらは汎用ＣＡＬ仕様で定められる）。

【００５１】 ＯｂｊｅｃｔＩＤは０ｘＤ１・０ｘ３Ｅの範囲の１バイトオブジェクト番号で
ある。

【００５２】 ＩＶＩＤは所与のコンテキストおよびオブジェクト・タイプ内のインスタンス
変数を特定するａｓｃｉｉキャラクタ（または複数のキャラクタ）である。

【００５３】 ノードはコンテキストのグループにより記述される。各コンテキストはオブジ
ェクトのグループにより構成されている。各オブジェクトはＩＶｓのグループに
より構成されている。データベースは、ちょうど論じている４つの情報について
、ＩＶに対するアクセスが下記のルックアップ・アルゴリズムを含むように構成
されている。

【００５４】 １） ＮｏｄｅＩＤは各ノードはコンテキスト・レコードのアレイを示す。ノ
ード・リスト・エントリにマップする（通常はハッシング・アルゴリズムを用い
て）。ＣｏｎｔｅｘｔＩＤは、所望のコンテキスト・レコードを獲得するための
直接インデックスとして使用できるようには構成されていないので、ここでは直
線的なルックアップが起きる。ノードはほんの少し（２または３）のコンテキス
トを通常有する。各コンテキスト・レコードはオブジェクト・レコードのアレイ
（またはリンクされたリスト）に対するポインタを含む。

【００５５】 ２） ＯｂｊｅｃｔＩＤは、所望のオブジェクト・レコードを獲得するための
直接インデックスとして使用できるようなフォーマットのものである。各オブジ
ェクト・レコードはＩＶレコードのアレイに対するポインタを含む。

【００５６】 ３） ＩＶＩＤを基にして動作する所望のＩＶを探すために直線サーチが用い
られる。これは、ほとんどのクライアント・ノードに対してほんの僅かなＩＶｓ
がノード・データベース３０８に保存されるから効率的である。ほとんどのＧＥ
Ｔ要求／ＳＥＴ要求はＩＶの現在の値に関する。現在の値がＩＶリストに常に保
存されていると、集中的な直線サーチが必要とされることはまれである。

【００５７】 ネットワーク・ノード・リストを住まわせる（ｔｏ ｐｏｐｕｌａｔｅ）ため
にゲートウエイ３００により用いられる発見プロセスは、ノードのタイプに依存
して変化する。ＣＡＬを用いる典型的なＰＬＸに対しては、下記のアルゴリズム
が用いられる。

【００５８】 １） ＣＡＬ「Ｐｉｎｇ」要求がネットワーク上で放送される（これは初期化
中に通常行われるが、定期的にも同様に行うことができる）。この要求のフォー
マットは他の任意のＣＡＬコマンド／要求のフォーマットに類似し、下記のパラ
メータを用いる。

【００５９】

【数１】 この要求は、ノードへ直接送ることができる点、または全てのノードへ放送で
きる点で、標準ＣＡＬ要求とは異なる。

【００６０】 ２） ＣＡＬ Ｐｉｎｇ要求を受信するノードは送り出しノードへＣＡＬ Ｐ
ｉｎｇ要求を送り返す。このパケットは「応答」と呼ばれているが、パケットの
シンタックスは従来のＣＡＬ要求パケットとは異なる。その応答は、ｐｉｎｇ要
求を放送として送ることができるようにするために異なるのである。その応答パ
ケットのフォーマット（実際にはＣＡＬ応答ではなくてＣＡＬコマンド／要求に
類似する）は、方法コードが５０ｈの代わりに５１ｈであることを除き、ｐｉｎ
ｇ要求に類似する。

【００６１】 ３） ゲートウエイ３００が、ネットワーク・ノード・リストに掲載されてい
ないノードからｐｉｎｇ要求を受けると、ゲートウエイ３００はそのノードをリ
ストに加え、ノードのＩＶｓ情報をノード・データベース３０８に付加する。

【００６２】 ４） 希望によっては、ゲートウエイ３００は、ある長さの時間聞かれなかっ
たノード・リスト内の任意のノードにＣＡＬ要求を送る。そのノードが応答しな
ければ、それはそのノードから除去される。

【００６３】 ５） ｐｉｎｇ応答パケットは、クライアント・ノードに電源が投入された時
またはリセットされた時にも送られる。

【００６４】 レガシイ制御ノード（Ｘ−１０ノードまたはＣＥＢｕｓノードなど）では、ノ
ード発見プロセスは、レガシイ・アプリケーションに従って変化する。ゲートウ
エイ３００はシム３２８、３３０の支援でそれらのノードを処理する。シム３２
８、３３０は、上記ＣＡＬノード発見法と、非ＰＬＸドライバにより使用される
レガシイ法を知っている。ｐｉｎｇ要求に応答して、シムはｐｉｎｇ要求を、レ
ガシイ制御ネットワークでノード発見を実行するために求められる同等の要求（
または要求セット）に変換する。ノードが発見されると、シム３２８、３３０は
ｐｉｎｇ応答パケットを発生して、それらをゲートウエイ３００の上側の層へ送
る。ゲートウエイ３００の残りに関する限りは、それらのレガシイ制御ノードは
ＰＬＸノードである。シム３２８、３３０については以下でさらに説明する。

【００６５】 ゲートウエイ３００によってユーザー・インタフェースおよび管理アプリケー
ション３０２がファウンデーション・クラス３０４を通じてノード・データベー
ス３０８をアクセスできる。アプリケーション３０２によるノード・データベー
ス３０８のアクセス性を高めるために、ゲートウエイ３００は多数のアプリケー
ション・サーバの存在をサポートする。ここに、１つのサーバがアクティブアプ
リケーション・サーバとして動作し、他のサーバが待機アプリケーション・サー
バとして動作する。

【００６６】 各サーバは同じノード・データベース３０８を保存し、ネットワーク・トラフ
ィックを聴取し、ネットワーク・ノード状態変化を監視し、かつそれに従ってそ
れのノード・データベース３０８を更新することにより、他のノードと同じ日（
同期させられる）まで、それのノード・データベース３０８情報を保持する。し
かし、アクティブアプリケーション・サーバは、状態変化に関連している諸規則
を実際に評価し、求められている事象通知を実行するノードのみである。アクテ
ィブサーバがなんらかの理由で動作しなくなったとすると、待機サーバがこれを
検出して「アクティブにされる」ことになる。アプリケーション・サーバ・ノー
ド４０２に対するアクティブプロセスが、同期化ブロック４０４で始まる、図４
に示されている。その同期化ブロックではノード４０２はそれのノード・データ
ベース３０８を更新する。ノード・データベース３０８を更新した後で、プロセ
スは判定ブロック４０６へ進む。この判定ブロック４０６で、ノードがアクティ
ブサーバ状態にあると、プロセスはアクティブサーバ・ブロック４０８へ進み、
さもなければ、プロセスは待機サーバ・ブロック４２０へ進む。アクティブサー
バ・ブロック４０８が終了すると、プロセスは判定ブロック４１２へ進む。この
判定ブロック４１２で、サーバ睡眠要求が検出されると、プロセスはセット待機
ブロック４１０へ進み、さもなければプロセスは判定ブロック４１４へ進む。こ
の判定ブロック４１４で、クライアント要求が検出されると、プロセスは応答ブ
ロック４１８へ進み、さもなければプロセスは同期化ブロック４０４へ戻る。セ
ット待機ブロック４１０または応答ブロック４１８が終了すると、プロセスは同
期化ブロック４０４へ戻る。

【００６７】 待機サーバ・ブロック４２０が終了すると、プロセスは判定ブロック４２２へ
進む。この判定ブロック４２２で、確認応答されなかったクライアントが検出さ
れると、プロセスはアクティブセット・ブロック４２４へ進み、さもなければプ
ロセスは同期化ブロック４０４へ戻る。アクティブセット・ブロック４２４が終
了すると、プロセスは通知ブロック４２６へ進む。このブロックでは、現在のサ
ーバ・ノードがアクティブ状態になりつつあることを他のアプリケーション・サ
ーバ可能ノードに通知する。ブロック４２６が終了すると、プロセスは同期化ブ
ロック４０４へ戻る。

【００６８】 クライアント・ノードで状態変化が起きた時に、規則エンジン３１４と事象ハ
ンドラ３１０が含まれることになる。ＳＥＴ方法が実行された時にそのような状
態変化が起きるので、各ＳＥＴ方法はその変化を事象ハンドラ３１０を介して規
則エンジン３１４に通知する。その後で規則エンジン３１４は、変化したＩＶに
関連している任意のノードの存在を調べ、なんらかの事象通知が必要とされてい
るかどうかをそれは判定する。ユーザーが、ファウンデーション・クラス３０４
を用いてユーザー・インタフェースを介して種々のノードを結び付けると、ユー
ザーは規則を作成できる。あるノードと、明示のユーザー定義を必要としない従
来のオペレーションに対してデフォールト・ノードは存在することもできる。

【００６９】 規則は簡単にもできれば、複雑にもできる。簡単な規則は、クライアント・ノ
ードの間の１対１または１対多数の結合関係を特徴するものである。簡単な１対
１規則の例は、「灯火スイッチＡがオンにされると、電球Ｂが点灯する」という
ことに類似するようなものと読めるであろう。１対多数規則の例は「灯火スイッ
チＡがオンにされると、電球Ａ、Ｂ、Ｃ、Ｄが点灯する」と読めるであろう。複
雑な規則は多数対１または多数対多数の結び付きを取り扱う（たとえば、「灯火
スイッチＡがオンにされ、かつユーザーが安全クリアランス（ｃｌｅａｒａｎｃ
ｅ）有すならば、電球Ａ、Ｂ、Ｃ、Ｄが点灯する」）。

【００７０】 ゲートウエイ３０８は、ユニバーサル規則制定言語（ＲＤＬ）として知られて
いる規則制定のための多用途シンタックスを提供する。図５は規則の構成要素と
、アプリケーション５０２と規則５０４との間の相互作用とを示す構造図である
。図５に示すように、アプリケーション５０２は、規則５０４を含めた、１つま
たは複数の規則を制定する。規則５０４は、条件付き表現５０６を含む「ｉｆ」
文を含むことができる。条件付き表現５０６は１つまたは複数の定数５０８と、
１つまたは複数の演算子５１２と、１つまたは複数のＩｖｓとを含むことができ
る。規則５０４内の「ｔｈｅｎ」クローズはアプリケーション５０２に返される
通知５１４を特定する。各定数は値を含む。各演算子は演算子識別名（ＩＤ）を
含む。各ＩＶはＩＤと、値と、トリガ状態とを含む。トリガ状態は縁部をトリガ
されたものと、非縁部をトリガされたものとを含む。各通知は通知ＩＤとメッセ
ージＩＤを含む。

【００７１】 規則は事象と行動を含む。行動は、アプリケーションに特有であるストリング
のアレイである。事象は、所与の状態がネットワークに存在しているか否を記述
するブール表現である。事象ストリングは下記の文法を用いて指定される。その
文法は定義されていないターミナル記号ｉｎｔｅｇｅｒ ｃｏｎｓｔａｎｔ、ｃ
ｈａｒａｃｔｅｒ ｃｏｎｓｔａｎｔ、ｆｌｏａｔｉｎｇ ｃｏｎｓｔａｎｔ、
およびｓｔｒｉｎｇを有する。識別子ターミナルは特定のフォーマットを有する
ことに注目されたい。脱字記号「 」ポンド符号「＃」の後の最初のｉｎｔｅｇ
ｅｒ ｃｏｎｓｔａｎｔは１６進法で指定されたノード・アドレスである。２番
目（任意選択）のｉｎｔｅｇｅｒ ｃｏｎｓｔａｎｔは１６進法でのＣＡＬコン
テキスト数である。３番目のｉｎｔｅｇｅｒ ｃｏｎｓｔａｎｔは１６進法での
ＣＡＬコンテキスト・クラスである。４番目のｉｎｔｅｇｅｒ ｃｏｎｓｔａｎ
ｔは１６進法でのＣＡＬオブジェクト数である。ｃｈａｒａｃｔｅｒ ｃｏｎｓ
ｔａｎｔはＣＡＬインスタンス変数（ＩＶ）である。識別子の前の脱字記号は「
縁部をトリガされた」ｉｖと「非縁部をトリガされた」ｉｖを指定する。ポンド
符号は、ｉｖが「レベル」または「既存値」であることを意味する。規則は１つ
の「縁部をトリガされた」識別子を有するのみである。

【００７２】 規則文法

【００７３】

【数２】 あるレガシイ・シンタックス（たとえば、ＲＤＬ以外のシンタックス）を用い
る規則が埋め込まれている非ＰＬＸノードに対しては、規則エンジン３１４は（
シム３２８、３３０からの助けで）レガシイ・シンタックスをＲＤＬシンタック
スに変換する。

【００７４】 データベース３２０は、ゲートウエイ３００の内部で起きるオペレーションの
順序および流れを指令する責任を負う。初期化中は、ディスパッチャ３２０はＲ
ＴＯＳ３１１を呼び出して、実行時間オペレーションを管理する種々のハンドラ
・スレッドをつくる。ハンドラ・スレッドは、１）受信ペイロード・スレッド、
２）生データ（ストリーミング）送信スレッド、３）ＣＡＬ送信スレッド、およ
び４）低い優先順位のアイドル・スレッド（任意）、を含む。それらのスレッド
は優先順位の順に記載した。

【００７５】 上記ハンドラ・スレッドのほとんどはパケットをクライアント・ノードへ送る
。デバイスドライバ送りルーチンの呼び出しを行う前に、それらのスレッドはド
ライバが送り要求を取り扱えることを示すＴｘＦｒｅｅＣｏｕｎｔセマフォでま
ず待つ（睡眠）。また、ＣＡＬ送信スレッドは、「遅延された」モードにあるク
ライアントへはＣＡＬパケットが送られないようにする。遅延されたノードにつ
いては以下で説明する。

【００７６】 ディスパッチャ３２０は、ハンドラ・スレッドが働き掛ける待ち行列の管理も
行う。ハンドラ・スレッドおよびゲートウエイ３００のその他の構成要素はディ
スパッチャ３２０を呼び出してパケットをその待ち行列に加え、かつその待ち行
列からパケットを除去する。ディスパッチャ３２０はディスパッチ制御ブロック
（ＤＣＢｓ）を用いてＣＡＬ要求パケット／ＣＡＬ応答パケットおよび生データ
流部分を記述する。

【００７７】 ＤＣＢ構造が（Ｃ／Ｃ＋＋シンタックス）で下記のように定められる。

【００７８】

【数３】 ｌｉｎｋフィールドはどのような目的に対してもＤＣＢの所有者により使用で
きる。ｂｕｆｆｅｒフィールドおよびｂｕｆｆｅｒＳｉｚｅフィールドは、ＤＣ
Ｂにより記述されているパケット／断片データを指し、それのサイズを定める。
ｄｅｓｔＤｅｖＡｄｄｒｅｓｓおよびｓｔｃＤｅｖＡｄｄｒｅｓｓは、ＤＣＢに
関連する宛先ノードと送り手ノードを特定する。ｄｅｓｔＳｏｃｋｅｔおよびｓ
ｒｃＳｏｃｋｅｔはノード内の宛先アプリケーション／送り手アプリケーション
をさらに特定するために使用することもできる。ｔｉｍｅＳｔａｍｐフィールド
は、種々の時間切れ条件の処理を支援するためにゲートウエイ３００により使用
される。ｓｅｑｕｅｃｅＮｏは、主として生データ・パケットストリームのため
のパケットに命令するために用いられる。ｃｏｎｔｒｏｌＩｎｆフィールドは、
ＤＣＢおよび関連するデータ・パケットの求められた特殊な特徴／処理を指示す
るために用いられる種々のビット・フィールドおよびフラッグを保存するために
用いられる。それらのビットはデータ暗号化、認証、およびデータ・ストリーミ
ングのような諸特徴を制御する。ｒｅｓｅｒｖｅｄ１フィールドおよびｒｅｓｅ
ｒｖｅｄ２フィールドはゲートウエイ３００により内部で用いられ、かつ外部ア
プリケーションにより用いられる。

【００７９】 受信ペイロード・スレッドは通常、ディスパッチャ３２０によりスタートさせ
られた最高優先順位のスレッドであって、デバイスドライバ３２２、３２５が受
信パケットを行列にした時に常に実行する。デバイスドライバ３２２、３２５に
おける割り込み／ポール・サービス・ルーチンはこのスレッドを提供できる。こ
のスレッドはパケットを受信待ち行列から除去し、それらのパケットを更に処理
するためにペイロード／プロトコル・ハンドラ３１２にそれらのパケットを渡す
。このスレッドは受信待ち行列に何も残らなくなるまで実行する（またはおそら
くあるしきい値に達するまで）実行し、その後でより多くの受信が行列にされる
まで休止する。

【００８０】 生データ送信スレッドは２つの条件が真である、すなわち１）生データ／スト
リーミング送信要求がアプリケーションによって待ち行列にされた、および２）
任意のより高い優先順位のスレッド／割り込みハンドラが実行を終了した時に実
行する。生送信スレッドは送り待ち行列中の次のエントリを獲得し、それを適切
なデバイスドライバ送りルーチンに渡す。これは、送り待ち行列内にもう報告が
残っていなくなるまで、またはあるしきい値に達するまで、繰り返される。その
後で生データ送信スレッドは新しい送信の予定が組まれるまで休止する。

【００８１】 ＣＡＬ送信スレッドは生データスレッドに類似する。その２つの間の主な違い
は、ＣＡＬ送信スレッドが種々の送り待ち行列を取り扱うことである。ＣＡＬ送
信スレッドはＣＡＬ要求事象に対して働き掛ける。ＣＡＬ要求事象はアプリケー
ション３０４から来る要求の結果として予定が通常組まれる。それらのアプリケ
ーション要求はディスパッチャ３２０によりＣＡＬ送り待ち行列に置かれる。遠
方のノードまたはノード・データベース３０８に保存されている状態情報を読出
し（獲得）および書込む（セット）するためにＣＡＬ送信を使用できる。規則エ
ンジン３１４により解釈される規則中に定められている事象をトリガする内部状
態変化および外部状態変化によってＣＡＬ送信を発生することもできる。

【００８２】 システム内で低い優先順位でアイドル・スレッドが実行するが、それを行うか
どうかは任意できる。もし使用されると、アイドル・スレッドは、より高い優先
順位のスレッドが実行している間に安全に無期限に延期できる低い優先順位のタ
スクを取り扱う。低い優先順位のタスクは次の行動をすなわち。１）メモリ管理
タスクおよびがらくた収集タスク、２）非応答ノードを検出および古びさせるた
めに見張りパケット／ｐｉｎｇパケットを送り出す、３）キャッシュされたデー
タベース情報を非キャッシュされた（持続する）予備保存コピーに同期させる。
アイドル・スレッドが支持されると、アイドル・スレッドにより呼び出されるべ
き低い優先順位のタスクを他のモジュールがスケジュールできるように、ディス
パッチャ３２０は他のモジュールにインタフェースを提供する。

【００８３】 デバイスドライバ３２２、３２６はディスパッチャ３２０（ディスパッチャ制
御ブロックすなわちＤＣＢにより記述されている）から汎用要求を受け取り、そ
れらの要求を基礎をなすネットワーク・ノードに適切なＩ／Ｏ要求に変換する。

【００８４】 デバイスドライバ３２２、３２６はネットワーク・ハードウェアから受取った
パケットも処理し、以後の処理のためにその後で送られるＤＣＢｓを組み立てる
。ディスパッチャ・スレッドはゲートウエイ３００のうち、デバイスドライバ３
２２、３２６にインタフェースする唯一のコンポーネントである。デバイスドラ
イバ３２２、３２６によりディスパッチャ３２０に与えられたインタフェースは
ＤＣＢを通されるＤｒｉｖｅｒＳｅｎｄインタフェースを含む。媒体アブストラ
クション・コンポーネント（ＭＡＣ）モジュールはＭＡＣヘッダを組み立て、ネ
ットワーク制御器ハードウェアへの実際のパケット送りを開始する。ドライバ割
り込み／ポーリング・ルーチン待ち行列はペイロード受信待ち行列における事象
を受け取り、その後の時刻にその待ち行列は受信ペイロード・スレッドによって
処理される。

【００８５】 以下の説明のほとんどは、デバイスドライバがＰＬＸをベースとするノードを
ドライブしていると仮定している。しかし、上側の層に提供されるインタフェー
スは、他のドライバがゲートウエイによりサポートされるように汎用である。シ
ム３２８、３３０は、Ｘ−１０ノードおよびネイティブＣＥＢｕｓノードなどの
非ＰＬＸベースとするノードが、ゲートウエイ３００により継ぎ目なしにサポー
トされるようにするために設けられている。

【００８６】 たとえば、ＰＬＸ制御ドライバ３２３などのドライバがロードされると、ドラ
イバ初期化モジュールが、そのドライバによりサービスされるネットワーク・イ
ンタフェース・ハードウェアを機能的な状態に置く。初期化が終わると、ドライ
バ３２３とハードウェアがパケットの送受信できる状態にある。ドライバ初期化
の一部が、受信−ハンドラＩＳＲ／ポール−ルーチンの設定と、ハードウェア資
源の決定／保留と、任意のハウスキーピング・スレッドのスタートとを通常含む
。通常、送信時間切れと死んだ装置ドライバ問題／死んだハードウェア問題を調
べるためにタイマ・スレッドが用いられる。

【００８７】 送り時には、ディスパッチャ３２０はパケット／断片データ・アドレスと、制
御情報をＤＣＢを用いてドライバ３２２に供給する。その後で、ドライバ３２０
は適切なＭＡＣヘッダをつくり、送信を開始する。同時に取り扱える送信の数は
、初期化中に読出すことができるハードウェア／ファームウエアに依存する値（
ＴｘＦｒｅｅＣｏｕｎｔと呼ばれている）である。

【００８８】 送信データをネットワーク制御器にコピーした後で、ＤｒｉｖｅｒＳｅｎｄル
ーチンが送り時間切れタイマを開始する。この点で、送信終了を示す応答が同期
して受信されないと（ＤｒｉｖｅｒＳｅｎｄルーチンが戻る前の送りに続く）、
ネットワーク・ハードウェアが送信終了状態を示すまで送信は「係属」状態にあ
る。送信が係属状態にある間は、ネットワーク制御器が利用できるバッファスペ
ースを有する限り、ＴｘＦｒｅｅＣｏｕｎｔにより定められるように、より多く
の送りが起きることができる。係属している送りの数がＴｘＦｒｅｅＣｏｕｎｔ
にひとたび等しいと、ＤｒｉｖｅｒＳｅｎｄルーチンはロックされ（それ以上の
送りは起きないことを意味する）、ＩＳＲ／ポール・ルーチンが送信成功状態ま
たは送信時間切れ状態の受取りに続いてそれのロックを解除するまでロックされ
たままである。

【００８９】 ドライバ割り込み／ポール・サービス・ルーチン（またはＩＳＲハンドラ）ル
ーチンはシステム内で最高の優先順位で実行し（割り込みコンテキストが好まし
い）、受け取られたパケットのＭＡＣヘッダの解釈／除去の責任を負い、後で適
切なペイロード・ハンドラにより処理するためにディスパッチャ３２０でパケッ
トを待ち行列化する。受信パケットは次の部類、１）内部（またはローカル）制
御／状態パケット、２）ＣＡＬコマンド／要求、３）ＣＡＬ迅速応答、４）ＣＡ
Ｌ遅延応答、または５）生ストリーム・データの１つに入る。

【００９０】 内部制御／状態パケットは、送信終了または誤り状態を示すために主として用
いられる。ＩＳＲハンドラにおける送信状態パケットの処理は、状態が適用され
る送信パケットのタイプ（たとえば、ＣＡＬ／生、ローカル／遠隔）にいくらか
依存して通常変化する。

【００９１】 生断片ＣＡＬパケットとＣＡＬパケットの両方に対して、送信が成功裡に終了
させられたことを状態が示すと、ＩＳＲルーチンはＴｘＦｒｅｅＣｏｕｎｔを調
整して次の送りが起きることを可能とする。時間切れ誤りの場合には、ＣＡＬ送
信は、送りが成功するまで適切な何回か再試行するか、ある最大再試行回数に達
した後で放棄することが好ましい。

【００９２】 生データ断片の送信時間切れは、ある場合に（生データストリームの性質と、
受信側で予測されるものとに依存する）、追加の再試行処理を要求することがで
きることを除き、ＣＡＬ送信に類似するやり方で取り扱われる。生ストリーム断
片は、データストリームの管理の支援のためにパケット・シーケンシングを通常
用いる。生ストリーム受信アプリケーションの要件に依存して、時間切れ取扱い
コードが、その時間切れを送信するばかりでなく、係属中の追加の生送信（より
大きい一連番号を盛っているもの）が成功に終わるか否かとは無関係に、それら
の係属中の送信のいずれも再試行することが望ましいことがある。これは受信ア
プリケーションまたは経路選択ハンドラが昇順の順序でパケットを確実に受け取
ることを支援する。受信ａｐｐ／経路選択装置はそれらを落とすことにより狂っ
た順序を取り扱う必要がある。

【００９３】 ＣＡＬ要求／応答および生ストリームパケットはＩＳＲハンドラにより待ち行
列にされ、受信ペイロード・スレッドおよび適切なペイロード・ハンドラにより
後で処理される。

【００９４】 ＣＡＬ応答が係属中であるような遠隔ノードへ新しいＣＡＬ要求が送られない
ことを検査するために、特殊な取扱いもＣＡＬパケットで用いられる。また、Ｃ
ＡＬ要求が遠隔のノードから受け取られるとすると、通常は、適切なＣＡＬ応答
が送られるまで新しいＣＡＬパケットはそのノードに送られることを許されない
。

【００９５】 レガシイ制御ネットワーク装置ドライバ（Ｘ−１０ドライバ３２８およびＣＥ
Ｂｕｓドライバ３３２など）に対しては、シム３２３、３３０は、それらの非Ｐ
ＬＸドライバがゲートウエイ３００と動作できるようにするインタフェースを提
供する。送信時には、シム３２３、３３０はディスパッチャ３２０により送られ
るＣＡＬパケットを調べ、それらのパケットを、基礎を成しているレガシイ・ド
ライバ／装置により認識される同等のフォーマットに変換する。受信時には、シ
ム３２３、３３０は受けたレガシイ・データをＣＡＬフォーマットに変換し、Ｄ
ＣＢを組み立て、そのＤＣＢをディスパッチャ３２０まで送る。

【００９６】 パケットの送受信中はシム３２３、３３０は、４バイトＤＣＢアドレスを、基
礎を成すレガシイ・ドライバにより用いられているアドレス・フォーマットに変
換することにより、あるアドレス変換を通常実行する。

【００９７】 受け取られたパケットはＣＡＬ制御メッセージまたは生ストリームデータ（そ
れはプリンタ・データ、トンネルを通るのように送られた（ｔｕｎｎｅｌｅｄ）
イーサネット／ＡＤＳＬデータ等を含むかもしれない）を制御する。それらのペ
イロードの各々は、ペイロード／プロトコル・プロセッサ３１２により提供され
る適切なペイロード／プロトコル・ハンドラにより取り扱われる。ＣＡＬハンド
ラ３１８は、制御ネットワーク・ノードから受け取られたＣＡＬ要求／応答制御
パケットを構文解析および処理するＣＡＬインタプリタを含む。ペイロード・ハ
ンドラ・スレッドはＣＡＬパケットを更に処理するためにクライアントからＣＡ
Ｌハンドラへ送る。ＣＡＬインタプリタはある基本ＣＡＬ構文解析ルーチンを、
ＣＡＬメッセージを取り扱う他のゲートウエイ・コンポーネントにも提供する。

【００９８】 ディスパッチャ３２０がＣＡＬハンドラ３１８を呼び出すと、それは、特に、
ＣＡＬメッセージに対するポインタと、そのパケットを生じたクライアントのア
ドレスと、働き掛けるべきクライアントのアドレスとを送る。それら２つのアド
レスは、アプリケーション３０２からパケットが生じた場合を除き、通常は同じ
である。

【００９９】 そのＣＡＬメッセージはコマンド（要求とも一般に呼ばれる）または応答メッ
セージである。クライアント・ノードからのＣＡＬコマンドは通常は、「私の状
態変数をある新しい値にセットする」の作用についてゲートウエイ３００に何事
か告げる状態変化通知である。アプリケーション３０４により制御されているよ
うなものなどの、特殊機能クライアントもＣＡＬコンポーネントを送り、ユーザ
ーの要求を基にして、他のクライアントの状態（インスタンス）変数を獲得、ま
たはセットする。それらのパケットは次の節で説明する特殊取扱いを通常要する
。

【０１００】 単一コマンドＣＡＬパケットは次のようなフォーマットのものである。 ＜ｃｏｎｔｅｘｔＩＤ＞＜ｏｂｊｅｃｔ＃＞＜ｍｅｔｈｏｄ／ｍａｃｒｏＩＤ＞ ［＜ＩＶ＞［＜ａｒｇｕｍｅｎｔｓ＞］］ ＣＡＬインタープリタはメッセージをそれのコンポーネントに分解し、方法識
別子を、後でＩＤおよび引数パラメータで呼び出される適切なデータベースアク
セス法にマップする。データベース・アクセス法３０６は求められたオペレーシ
ョンを実行し、ＩＶが変化すると、規則エンジン３１４に通知される。規則エン
ジン３１４は変化させられたＩＶに適用されるどのような規則も評価し、保証さ
れるならば、上記のように事象ハンドラ３１０により事象通知の計画が立てられ
る。

【０１０１】 ＣＡＬコマンドに応答するためにＣＡＬ応答パケットはクライアント・ノード
によって用いられる。ＣＡＬ応答は＜ｓｔａｔｕｓ ｔｏｋｅｎ＞［＜ｒｅｔｕ
ｒｎｅｄ ｄａｔａ＞］の形のものである。ここに、＜ｓｔａｔｕｓ ｔｏｋｅ
ｎ＞は応答（ＣＯＭＰＬＥＴＥＤ，ＦＡＬＳＥ，ｏｒＥＲＲＯＲ）のタイプの１
バイト標識であり、＜ｒｅｔｕｒｎｅｄ＞データはコマンド・メッセージの結果
として戻された任意のデータである。

【０１０２】 それらのパケットの１つが受け取られると、それは元のＣＡＬコマンド／要求
に関連させられる。クライアントが要求に直ちに応答する時はその関連付けは比
較的容易である。応答が遅れた時は関連付けは一層複雑である。関連付を可能に
するものは、あるクライアントが以前の要求に対する応答を送るまで、クライア
ントがＣＡＬ要求パケットをネットワークへ送らないかもしれない、という事実
である。「遅延させられた」モードにあるクライアントへはゲートウエイ３００
は要求を送らない。これによってゲートウエイ３００はクライアントに最後に送
られた要求（またはコマンド）をクライアント毎に保存できるようにされる。ク
ライアント応答が受け取られると、この情報によってＣＡＬハンドラ３１８は、
戻された情報ではすべきことを決定できる。

【０１０３】 生データ・ハンドラ３１６は非ＣＡＬ受信データを処理する。ゲートウエイ３
００は、種々のアプリケーションで生ずることができる多数の、同時データスト
リームをサポートする。生データ・ハンドラ３１６が生データストリームの間で
識別するやり方はソケット・フィールドを含む。そこでは独自のソケット番号が
各生データストリームタイプに関連させられる。生データストリーム例にはイー
サネット／ＡＤＳＬネットワークく・パケットと、プリンタ・データと、音声ス
トリーム等が含まれる。生データ・ハンドラ３１６はソケット番号を調べるため
以外の生データの構文解析はほとんど行わない。パケット・データと、関連付け
られたＤＣＢはその後で、そのソケット番号に責任を負う経路選択ハンドラ３５
５へ送られる。

【０１０４】 経路選択ハンドラ３５５は、ゲートウエイ３００がレガシイ・データ・ネット
ワーク（イーサネット、ＡＤＳＬ、トークンリング等）からのネットワーク・デ
ータ・トラフィックを所望のネットワークへ向け直すことを可能にする機能を提
供する。たとえば、レガシイ・ネットワークからのネットワーク・データ・トラ
フィックを、ＰＬＸ電源線ネットワークへ向け直すためにゲートウエイ３００を
用いると、１）追加のイーサネット・ケーブル配線の必要なしに、電源線を基に
したノードを含むように従来のイーサネット・ネットワークを拡張できること、
２）広帯域データを電源線を通じて送ることができること、３）電源線をベース
とするネットワーク・クライアントのために代用サーバ性能を可能にすること、
４）レガシイ・プロトコル・スタック（ＴＣＰ／ＩＰ、ＰＸ／ＩＰＸ、ＮｅｔＢ
ＥＵＩ等）を電源線を通じてトンネルを通るように送ることができるようにする
こと、を含むが、それらに限定されるものではない。

【０１０５】 経路選択ハンドラ３５５により実行される重要なタスクはアドレス翻訳である
。初期化中は、経路選択ハンドラ３５５は、ゲートウエイ３００から発生された
ＤＣＢｓを送信する際に、ｓｒｃＤｅｖＡｄｄｒｅｓｓとして用いられている４
バイト・アドレスを得る。経路選択ハンドラ３５５はこのアドレスを、レガシイ
・スタックとドライバの少なくとも一方に適切な形に翻訳するので、ハンドラは
通信する。

【０１０６】 以下の節は、ＤＣＢｓを用いて異なるプロトコル（たとえば、ＰＬＸプロトコ
ル）によってレガシイ・ネットワーク・データ・パケットをトンネルを通るよう
にして送るために、経路選択ハンドラ３５５により用いられる方法を説明するも
のである。トンネルを通るようにして送ることは第１のプロトコルからのパケッ
トを第２のプロトコルい対するパケット内側に封じ込めるすなわち包み込むこと
である。包まれたパケットはその後で第２のプロトコルを介してネットワークを
通じて送られる。それの宛先に到達すると、包まれたパケットはほどかれて第１
のプロトコルからの最初のパケットを現す。

【０１０７】 初期化中には、経路選択ハンドラ３５５は前記したようにアドレス・マッピン
グ表／翻訳表を設定する。経路選択ハンドラ３５５は、ＤＣＢごとにサポートさ
れる最大パケット／断片サイズに気付いてもいる。経路選択ハンドラ３５５はこ
の情報をディスパッチャ３２０から得る。種々の経路選択ハンドラ３５５はソケ
ット番号を用いることによって特定される。初期化中に独占的に使用またはダイ
ナミックに得るために周知のソケット・アドレスを保留できる。

【０１０８】 電源線装置のために設計されているレガシイ・スタックまたはドライバからの
送り要求を経路選択ハンドラ３５５が得ると、経路選択ハンドラ３５５は送りデ
ータをサポートされているＤＣＢデータサイズより大きくない断片にばらばらに
する。その後でＤＣＢが作成され、各断片に一連番号が割り当てられる。最初の
断片は常に一連番号０で、最後の断片は一連番号セットの高位のセットが割り当
てられる。任意に、別のレベルで機能が適切に提供されなければ、経路選択ハン
ドラ３５５はチェックサムをパケットに付加できる。その後でそれらのＤＣＢｓ
は、生送り待ち行列で待ち行列化するためにディスパッチャ３２０に渡される。
これは生送りスレッドを覚醒させ、電源線へ送信するためにそれはＤＣＢｓを適
切な装置ドライバに渡す。

【０１０９】 装置ドライバによって各送信が終了させられると、Ｔｘ状態がＤＣＢにマーク
され、そのＤＣＢは経路選択ハンドラ３５５に戻される。全てのＤＣＢが戻され
た後で、経路選択ハンドラ３５５はレガシイ・プロトコルによって求められた送
り終了動作を実行する。時間切れ／再試行の問題がディスパッチャ３２０と、装
置ドライバと、多くの場合にはレガシイ・スタックによっても同様に取り扱われ
ているので、経路選択ハンドラ３５５は追加の再試行動作を実行しないことを選
択できる。

【０１１０】 受信取扱いはより複雑にされたビットである。その理由は、経路選択ハンドラ
３５５が多数の送り手から断片を同時に受けることが可能だからである。また。
、ある場合には、断片を順序なしで受けることがあり、または断片が脱落するこ
とがある。経路選択ハンドラ３５５はそれらの可能性の全てを取り扱うことがで
きる受信モジュールを有する。通常は、初めにＤＣＢ／断片が、ペイロード／プ
ロトコル・ハンドラ３１６により経路選択ハンドラ３５５の１つ渡されるので、
送りアドレスのために留保されている受信待ち行列に置かれる。各ＤＣＢが受け
られると、受け手は最後の断片列または受信時間切れを調べる。

【０１１１】 全ての断片が受けられて、完全性検査に合格したら、経路選択ハンドラ３５５
は、受信事象を示すためにレガシイ・プロトコル／ドライバにより求められてい
るステップを実行する。これにはパケットの再組み立てと、おそらくは関連する
受信データの、レガシイ・モジュール３５２により提供されたバッファへのコピ
ーが通常含まれる。各受信ＤＣＢにより記述された物が処理された後で、ＤＣＢ
はフリーＤＣＢリストに戻される。

【０１１２】 ゲートウエイ・ファウンデーション・クラス３０４がオブジェクト指向概念（
たとえば、Ｊａｖａ、Ｃ＋＋、ｓｍａｌｌｔａｌｋ等）を基にしており、各種の
アプリケーションがノード・データベース３０６、規則エンジン３１４、事象ハ
ンドラ３１０、およびゲートウエイ３００により提供されるその他のサービスに
保存されているノード情報をアクセスおよび管理する方法を提供する。これによ
ってエンドユーザー・アプリケーション３０２は広範囲の有用な諸特徴をエンド
ユーザーに提供できる。たとえば、ゲートウエイ・ファウンデーション・クラス
３０４は自立アプリケーションとＪａｖａ ｂｒａｗｓｅｒ ａｐｐｌｅｔが、
ノード・データベース３０８において記述されているノードの列挙と、監視と、
制御とを可能にする。それらのアプリケーション／ａｐｐｌｅｔｓは、規則定義
言語を用いて簡単な規則または複雑な規則を定めることによりノードの間の種々
の結合を行うことができる。アプリケーション３０２は、事象通知ターゲットと
してそれ自身を登録することによりデータベースの変化をそれが起きた時に気付
くようにされることもできる。

【０１１３】 以上、本発明の特定の実施形態について説明し、示したが、種々の変更および
修正を、付録Ａに続く特許請求の範囲によって定められる本発明の範囲及び要旨
を逸脱することなく、当業者により行うことができる。

【０１１４】 付録Ａ ＰＬＸプロトコルは安価で、使用が容易であり、融通性に富み、信頼性があり
、かつキーボードを変更でき、多数のスマート・ノードとダム・ノードを共通の
データ・チャネル／制御チャネルを通じて通信できるようにするネットワークア
ーキテクチャ／プロトコルである。ネットワーク化プロトコルによってこのネッ
トワークにおけるどのようなノードもアクティブなネットワーク・サーバとして
自身を割り当てることができるようにする。アクティブなネットワーク・サーバ
はラインアップ・カードを基にしてクライアント・ノードをポールする。インア
クティブなノードはラインアップ・カードから自動的に除去され、したがって、
不必要なポーリング・トラフィックを減少する。このアーキテクチャは衝突を減
少させ、しかも実際のデータ伝送のための帯域幅を維持する。制御およびデータ
のネットワーク化要求のサポートがプロトコルによって行われる。ストリーミン
グ・データまたは非同期データのためのサポートが、タイムスロットをネットワ
ークに割り当て、かつ２つの知能ノードが、アクティブなネットワーク・サーバ
により仲裁されて相互に直接通信することができるようにする。アクティブなネ
ットワーク・サーバは、主ネットワークの動作とは独立に大量のデータ・トラフ
ィックが流れることができるように、別々のデータ・チャネルを割り当てること
もできる。アクティブなネットワーク・サーバとして動作するネットワーク・ノ
ードはダイナミックに変更でき、かつ通常は、睡眠中のネットワークへの要求の
送信を開始する第１のノードにより決定される。クライアント・ノードは、アド
レス分離スキームを用いてダイナミック・ポーリングによりアドレスされる。

【０１１５】 ＰＬＸプロトコルを含んでいるＰＬＸアーキテクチャは、建物内部の既存の電
力線（電源線）をネットワーク媒体として使用するネットワークに良く適する。
データの伝送に既存の電源線を使用することは、ユーザーがネットワーク・ケー
ブルを設置する必要がないことを意味する。

【０１１６】 ＰＬＸアーキテクチャはネットワーク・ノードのために頑丈で、決定的な媒体
アクセス可能性を提供する。ノードはアドレス分離スキームを用いるダイナミッ
ク・ポーリングによってアドレスされる。実行可能なデータ・チャネルが診断、
議論のやりとり、および汎用データやり取りアプリケーションに使用するために
提供される。

【０１１７】 一実施形態では、ＰＬＸプロトコルは大局的に独自の識別コードと、ノード輪
郭と、３２ビット仮想アドレス可能性とを提供する。それによってＰＬＸプロト
コルはプラグ−ｎ−プレイ・タイプのネットワークに適合できる。

【０１１８】 一実施形態では、ＰＬＸアーキテクチャ・プロトコルはピヤリング（ｐｅｅｒ
ｉｎｇ）、多数サーバ、簡単な構成、安全、データグラム検出、多数のデータ・
フォーマット、および優先順位決定のスキームなどの諸機能を提供する。ＣＲＣ
およびチェックサムなどの誤り検出、およびデータ完全性性能はＰＬＸのある実
施形態の部分である。ＰＬＸアーキテクチャはスマート・ノードとダム・ノード
を提供し、かつこのアーキテクチャは簡単な制御から複雑なデータ・ストリーミ
ングまでの範囲のデータ・トラザクションを提供する。

【０１１９】 一実施形態では、ＰＬＸは状態マシン論理またはマイクロ制御によって実現さ
れる。流線形の低い端部のノード（ダムノード）を、フルＰＬＸ性能のサブセッ
トを使用するために実現できる。機器などの、中間範囲のノードはここで開示さ
れているプロトコルに適合する。ＰＣまたはＰＳＸ、インターコム／調査装置、
プリンタ、マウス、およびその他のデータ集中ノードなどのより高い端部のノー
ド（スマートノード）はＰＬＸアーキテクチャにおいてまた応用性を見出す。

【０１２０】 ＰＬＸプロトコルはデータ・リンク層、ネットワーク層、およびトランスポー
ト層のための動作規則を定める。一実施形態では、ＰＬＸはデータ・リンク層の
媒体アクセス制御（ＭＡＣ）部を含む。ＭＡＣプロトコルは、物理的媒体を各ノ
ードがいつ、どのようにしてアクセスできるかを支配する規則の集まりである。
一実施形態では、ＭＡＣプロトコルは、電源線における衝突を減少させる、集中
して分布されているダイナミック・トークン・パッシング・アーキテクチャを使
用する。

【０１２１】 ＰＬＸアーキテクチャによって、ネットワークにおけるどのようなノードもア
クティブなネットワーク・サーバとしてそれ自身に割り当てることができるよう
にされている。それはトークンのための要求を仲裁する。ノードがインアクティ
ブであると、それらのノードは「睡眠」モードに入り、したがって、不必要な任
意の「ポーリング」トラフィックを無くす。このアーキテクチャは衝突を減少さ
せ、しかも実際のデータ伝送のための貴重な帯域幅を維持する。

【０１２２】 ＰＬＸアーキテクチャは、多くの面で、クライアント／サーバネットワーク化
アーキテクチャであって、制御ネットワーク化およびデータネットワーク化の需
要のためのパケットをサポートする。ストリーミング・データまたは非同期デー
タのためのサポートは、ワイヤにタイムスロットを割り当て、２つの知能ノード
がアクティブなネットワーク・サーバによる仲裁で相互に直接話し合えるように
することにより、サポートできる。アクティブなネットワーク・サーバは、大量
のデータ・トラフィックを主ネットワークの動作とは独立に流れることができる
ように、別々のデータ・チャネルを割り当てることもできる。アクティブなネッ
トワーク・サーバとして機能しているネットワーク・ノードはダイナミックに変
更でき、かつ睡眠中のネットワークで送信要求を開始する第１のノードによって
通常決定される。また、アクティブなネットワーク・サーバはアプリケーション
・サーバとは独立に選択される。アプリケーション・サーバは通常は固定ノード
場所である。アクティブなネットワーク・サーバはノードになり得る任意のサー
バとすることができる。

【０１２３】 一実施形態では、ＰＬＸは、インアクティブな（睡眠中）ネットワーク媒体を
最初にアクセスするためのデータグラム検出アルゴリズムと、その後に続く、ア
クティブなネットワークに挿入するための集中化されたトークン・パッシングを
含む、組合わされた媒体アクセス性能を提供する。これは多数のアクセスを衝突
のない、トークン・パッシング・タイプの環境に実効的に結合する。これは決定
論の付加された利点である。一実施形態では、ＰＬＸは最初の媒体アクセス可能
性を決定するデータグラムの存在を用いる。データグラムは指定された前文／長
さシーケンス組合わせを一致させることによって特に決定される。

【０１２４】 一実施形態では、ＰＬＸは、システムのアクティブなノードへトークンを通す
だけである集中化されたダイナミック・ポーリング・アルゴリズムを用いること
によってネットワークにおけるトラフィックを減少させる。オペランドがひとた
びインアクティブになると、そのノードはポーリング・リストから除去される。
この選択的なポーリング・プロセスは、それら自身を「バスの分割」として知ら
れているプロセスによってポーリング・リストに挿入できるノードの性能を基に
している。

【０１２５】 この分割プロセスはポーリング・リストへの実時間で実行中の挿入を可能にす
る。この分割プロセスは複数のノード応答が単一のシステム応答として見られる
ようにする。このシステム応答は、アクティブなノード（ポーリングを行ってる
ノード）が特定のノード要求挿入をポーリングリスト内にさらに分割することを
可能にする。

【０１２６】 ポーリング・リストからの実時間、実行中の除去が時間が経過したプロセスに
より行われる。インアクティブなノードは、所定の時点の後でそれらがトークン
を使用しなければ、最終的にはポーリング・リストから除去される（挿入を解除
される）。一実施形態では、時間の経過したプロセスは、ノードがトークン要求
に応答し損なったならば、更に促進される。

【０１２７】 一実施形態では、ポーリング・リストは媒体の帯域幅性能を基にして固定サイ
ズ（オペランドの数）に設定される。低い優先順位のデータ（照明装置の制御デ
ータなどの）を伝えるノードが、より高い優先順位のデータ（ストリーミング・
オーディオ／ビデオ・データなどの）を持つノードのためにリストに余地を設け
るために、ポーリング・リストから除去される。

【０１２８】 一実施形態では、ＰＬＸアーキテクチャ内の媒体アクセス制御（ＭＡＣ）層は
、予備の受信バイポーラ・トランジスタ、使用中応答ハンドシェイクを用いるこ
とによって自己スロットリング機構を提供する。一実施形態では、各ノードにＭ
ＡＣヘッダのコピーを保持するために十分大きい受け面積を設けることによって
、自己スロットリングが完成される。以前のパケット要求によりノードが完全に
忙殺されているとしても、その忙殺されているノードは、使用中応答を発生する
ことにより、いぜんとして要求に応答できる。使用中応答は、伝送しているノー
ドにそれのパケットにバーストまたはシーケンスを近寄らせなくしなければなら
ないことを知らせて、各受信ノードの性能に従ってシステムのペースをとる。

【０１２９】 電源投入時のノード自動アアウンス機能が遠隔のデータベース・サーバの再同
期化を行う。新しいノードの電源投入時には、その新しいノードはそれが媒体に
新たに到達したことをアナウンスする。

【０１３０】 一実施形態では、ＰＬＸは好適なサーバ選択を行い、キックスタート・アルゴ
リズムを提供する。ＰＬＸはクライアント／サーバ型アーキテクチャであるので
、媒体アクセスを仲裁するために１つのノードが通常選択される。典型的な電源
線ネットワークでは、全てのノードが必ずしも等しく作られているわけではない
。したがって、ＰＬＸの一実施形態によって、最も中央に（すなわち、ブレーカ
ーパネルの近く）配置されているノードをユーザーが選択できるようにされて、
好適な「アクティブなネットワーク・サーバ」として動作できるようにする。好
適なサーバがインアクティブであるとすると、遠隔のノードがその好適なサーバ
をアクティブにことができる。簡単な覚醒アルゴリズムによってインアクティブ
な好適なサーバが再び活動するようにできる。

【０１３１】 最初に、クライアント／サーバ・モデルにおける媒体をアクセスするためにノ
ードがトークンを獲得する。ひとたびクライアント・ノードにそのトークンが与
えられると、それは媒体を指定された時間だけ使用する。この時間の期間中は、
それはシステム内のどのノードとも、サーバの環境とは独立に、直接通信できる
。この期間が切れると、媒体アクセス制御がサーバ・ノードに戻される。したが
って、媒体仲裁がクライアント／サーバのようにしてまず行われ、それに同列間
タイムスロットが続く。

【０１３２】 一実施形態では、ＰＬＸはダイナミック媒体仲裁サーバを含む。媒体アクセス
を仲裁するサーバは活動を基にしてダイナミックに割り当てられる。そのダイナ
ミックな割り当ては、送信すべきパケットを有する最初のノードが、システムが
「インアクティブである」ことを認識し、好適なサーバ（存在するならば）を覚
醒させようとする数回の試みの後で、アクティブなネットワーク・サーバの役割
を行う。ＰＬＸネットワークでノードになることができるどのようなサーバもア
クティブなネットワーク・サーバになることができる。

【０１３３】 一実施形態では、このネットワーク・プロトコルはストリーミング・データを
電源線媒体を通じて送受信させる。一実施形態では、ストリーミング・データは
デジタル音声データを含む。一実施形態では、ストリーミング・データはデジタ
ル・ビデオ・データを含む。

【０１３４】 一実施形態では、電源線媒体を通じて、デジタルＰＢＸ型機能および／または
、デジタル・インターコム機能を提供するためにこのネットワーク・プロトコル
は用いられる。このネットワーク・プロトコルは広帯域デジタルネットワーク化
サービス（たとえば、ＤＳＬ、ケーブル、ＩＳＤＮ等）を家庭内の既存の電源線
を通じて家庭全体に拡張するために用いられる。

【０１３５】 ネットワーク・プロトコルは３種類または４種類以上のネットワーク・トラフ
ィック、すなわち、制御トラフィック、データ・トラフィック、ストリーミング
・データ・トラフィック（ストリーミング・マルチメディア・データ）、を同時
に取り扱うことができ、かつ管理できる。このネットワーク・プロトコルは所与
のノード（音声装置のための決定の要求などの）のネットワーク化要求に依存し
て保証されたアクセス回数を許すために優先化スキームを提供する。ＰＬＸ ＯＳＩモデル 上から５番目までのＯＳＩ層２０３〜２０７の各々は大きなオーバーヘッドを
ネットワーク・アプリケーションに加える。図３に示すように、ＰＬＸは、共通
アプリケーション言語（ＣＡＬ）と呼ばれている比較的薄いアプリケーション層
６０７と、比較的薄いトランスポート／ネットワーク層６０３を用いて、下側の
データ・リンク層６０２と物理層６０１を補足する。層６０１〜６０３と６０７
のおのおのはＰＬＸコンプライアント・ノードに通常存在する。図３に示すよう
に、ＰＬＸデータ・ネットワーク化ノード（スマート・ノード）は、アプリケー
ション層２０７と、ネットワーク層２０３と、トランスポート層２０４とに通常
のＯＳＩネットワーク性能（たとえば、ＴＣＰ／ＩＰ、ＩＰＸ、ウインドウズ、
ネットウェア、等）を含むこともできる。ＰＬＸコンプライアント・ノードは減
少させられた量の制御情報を通常含む。それは、層６０１〜６０３と６０７にお
いて具体化されるように、ＰＬＸスタックのみを用いてＰＬＸノードの間で送ら
れる。ＰＬＸ物理層 ＰＬＸ物理層６０１はネットワーク・ハードウェアと、ネットワーク・ケーブ
ルとに物理的にインタフェースするハードウェアの詳細を取り扱い、および、通
常は、実際のハードウェア自身を含む。物理層は変調技術、使用される周波数、
電力出力、等などの属性を含む。一実施形態では、ＰＬＸは下記のようにデジタ
ル電源線（ＤＰＬ）技術を用いる。ＰＬＸデータ・リンク層 ＰＬＸデータ・リンク層６０２は、アドレス指定機能、媒体仲裁スキーム、間
隔の間の間隔決定、バック・オフ・アルゴリズム、などの、媒体１００とのイン
タフェーシングの詳細を取り扱う。データ・リンク層６０２は、発信元アドレス
／宛先アドレスと、長さと、巡回冗長検査（ＣＲＣ）またはチェックサム・デー
タなどの誤り検出／訂正データとを含むヘッダを含んでいる。ＰＬＸネットワーク層 インターネット層と呼ばれることもあるネットワーク／トランスポート層６０
３、はネットワーク上の１つの場所から別の場所へのデータのパケットの経路選
択を行う責任を負っている。ＰＬＸ内では、ネットワーク層６０３はシステム、
個々のノード、ソケット、およびＭＡＣヘッダ・フィールド内のネットワーク・
アドレス・フィールドを用いて通常取り扱われる。ＰＬＸトランスポート層 ＰＬＸネットワーク／トランスポート層６０３は、上に存在するアプリケーシ
ョン層６０７のための２つのホストの間でデータの流れを行う。トランスポート
層６０３は、一連番号および／または要求／応答型確認応答情報も含む。ＰＬＸ
内では、アプリケーション制御を行えるようにするために、トランスポート層６
０３は、ＯＳＩトランスポート層２０３と比べて小さくされている。トランスポ
ート層６０３は要求／応答接続手順アルゴリズム、再試行アルゴリズム、時間切
れアルゴリズム、等を提供する。ＰＬＸはＭＡＣヘッダの制御フィールド内でネ
ットワーク／トランスポート層６０３をほとんど完全に実現する。ＰＬＸアプリケーション層 ＰＬＸアプリケーション層６０７はアプリケーションの詳細を取り扱い、パケ
ット配信を確実に扱うために、どのトランスポートが用いられているかに依存し
て、アプリケーション層６０７は接続手順プロトコルおよび／または要求／応答
プロトコルとを使用できる。フィールドのかなりの量の重複がＯＳＩ層のプロト
コル内に存在する。この重複はより多くのオーバーヘッドに変わり、より多くの
スペースを使用し、追加の処理パワーを要する。ＰＬＸプロトコル内では、ＯＳ
Ｉフィールドの多くが必要とされず、したがって通常省かれる。

【０１３６】 種々のＯＳＩプロトコル内に含まれている種々のコンポーネントを調べること
により、データ・リンク層６０２が上の３つの層なしに瀘波の多くを行えること
が明らかにされる。この瀘波は、同じ通信チャネルを競合している多数のノード
（たとえば、同じネットワークワイヤを競合している多数のネットワーク・カー
ド）などの、ハードウェアの問題点に留意もするハードウェア論理にデータ・リ
ンク層６０２が通常しばしば限られるため、有利である。一実施形態では、特定
のネットワーク・ノードのためのネットワーク・ハードウェアが、その特定のネ
ットワーク・ノードに宛てられたデータ・パケットを除く全てを除去する。その
ようなシステムの下では、ノードはデータ・パケットのデータ部分を解析するだ
けである。ＤＰＩのための２つプロトコル デジタル電源線（ＤＰＬ）で使用される２つのプロトコル、すなわち、低レベ
ル・プロトコルと高レベル・プロトコル、をＰＬＸで定めることが好ましい。低
レベル・プロトコルの定義。低レベル・プロトコルはデータ・リンク層６０２の
定義を与え、パケットが、比較的少数のネットワーク化機能およびトランスポー
ト機能を持つ同じ媒体１００からどのようにして瀘波され、送られ、かつ受信さ
れるかの定義を行う。

【０１３７】 高レベル・プロトコルの定義。ＰＬＸノードは少ない量の情報を含む。各ＰＬ
Ｘノードは特定のノード属性を制御する共通アプリケーション層６０７を使用す
る。これにより、ノードの種類とは無関係にＰＬＸシステムを特徴付けることが
できるようにされる。アプリケーション層６０７はハードウェア・ヘッダが除去
された後で制御情報を解読すなわち構文解析する。物理層：デジタル電源線（ＤＰＬ）仕様 ＰＬＸプロトコルは、光伝送、光ファイバ伝送、無線周波数伝送装置、ツイス
ト・ペア伝送装置、同軸伝送装置、衛星システム、デジタル電源線（ＤＰＬ）装
置、等を含めた、多くの種類のネットワーク媒体（すなわち、データ伝送装置）
に使用できる多用途プロトコルである。

【０１３８】 電源線搬送装置としても知られているＤＰＬ装置はデジタル・データを伝送 するために電源配線（たとえば、建物内の標準１１０ボルト交流（ＶＡＣ）回路
を使用する。一実施形態では、ＰＬＸプロトコルは、単一の低速チャネル（３５
０〜１０００ｋｂｐｓ）、約５．６ＭＨｚの低速搬送周波数、約８０ｄＢまたは
それより良いダイナミックレンジ、狭い帯域幅使用（速さに依存するが、１ＭＨ
ｚ位）のＤＰＬに関連して使用される。

【０１３９】 一実施形態では、ＰＬＸプロトコルは、多数の高速チャネル（合計で４〜８ｍ
ｂｐｓ）、３０ＭＨｚまたはそれより上までの高速搬送周波数、約８０ｄＢまた
はそれより広いダイナミックレンジのＤＰＬに関連して使用される。

【０１４０】 通常のＤＰＬ装置では、送信搬送波はデータの少なくとも２０マイクロ秒前に
イネンブル状態にされ、受信器が搬送波を検出しなくなるまで、送信器を動作不
能にする間の時間は１５マイクロ秒またはそれより長くできる。低レベルプロトコル層：ＰＬＸの 仕様 ＰＬＸプロトコルは、簡単な制御から複雑なデータ・ストリーミング・ネット
ワークまでの範囲に及ぶアプリケーションのために加減できる。一実施形態では
、ＰＬＸプロトコルは一般的なＣＡＬ仕様の諸特徴のほとんどに影響を与えるよ
うになっている。ＥＩＡ−６００において定められているＣＥＢｕｓはバス装置
を制御するための産業標準制御言語である。ＥＩＡ−６００は家庭ＬＡＮ内で使
用するための共通アプリケーション言語の骨組みを提供する。一般的なＣＡＬは
ＥＩＡ−７２１規格シリーズ（ＥＩＡ−７２１．１、ＥＩＡ−７２１．２、ＥＩ
Ａ−７２１．３、およびＥＩＡ−７２１．４を含む）で定められている。ＣＥＢ
ｕｓ産業協議会（ＣＩＣ）は、その言語を使用するための「文法」規則を制定す
ることによって、その骨組みに肉付けする家庭プラグ・アンド・プレイ（Ｈｏｍ
ｅＰｌｕｇ＆ｐｌａｙ）（ＨＰＰ）仕様を制定している。

【０１４１】 ＨＰＰ仕様は、家庭内の製品およびシステムが家庭の状態を基にして動作を行
えることができるようにする、それらの製品およびシステムの挙動特徴の集まり
の詳細を定めている。たとえば、その仕様は、「住人が不在」または「住人が帰
宅して睡眠中」などの家庭内の種々の状態を識別して、安全システムの起動、屋
内灯の消灯、または温度設定などの適切な操作を家庭システムが行えるようにす
る。ＨＰＰ仕様は家庭制御用ウィンドウズ’９５ＰＣベース・アプリケーション
を開発するための情報も含む。

【０１４２】 ＥＩＡ−６００において定められている共通アプリケーション言語は、種々の
産業部門（たとえば、娯楽、コンピュータ、冷暖房、台所設備、等）で製造され
た家庭ＬＡＮ製品の間の通信のための枠組みを提供する。

【０１４３】 各産業部門は、それの製品がその言語を使用するための基礎として役立つ、「
アプリケーション・コンテキスト」（すなわち、文法規則）を定める。ＣＩＣは
種々の産業部門が「調和のとれた」アプリケーション・コンテキストを開発する
ことを支援するサポート組織として機能するために作成された。ＣＩＣのＨＰＰ
は、ＣＡＬをベースとする相互に動作できる製品で家庭ＬＡＮ市場を求めている
それらの産業部門のための、調和のとれたアプリケーション・コンテキストの要
約である。

【０１４４】 ＣＥＢｕｓ／一般的ＣＡＬアプリケーションの全体を参照することによりここ
にその仕様が包含される。媒体アクセスの概観 ＰＬＸは、集中されたトークン・パッシング・スキーム、またはＤＳＭＡ／Ｃ
ＴＰを持つデータグラム検出多重アクセス・プロトコルとして特徴付けることが
できる。多数の同等のノードが同じ物理的媒体１００をアクセスすることを許さ
れているために、ＰＬＸは、データを媒体１００に置くことを試みた時に各ノー
ドを使用するための共通規則群を述べる。

【０１４５】 ＰＬＸは、種々の数のプロトコルからのいくつかの機能を統合して単一の効率
的な決定論的環境を生成する。ＰＬＸはデータグラム検出を行う。各ＰＬＸノー
ドはトラフィックのための媒体１００を「検出」でき、媒体１００が現在優勢で
あるならばそれ自身を主張する。構成されたトークン・バッシング型機構を介し
て衝突回避が行われる。ＰＬＸは媒体に対するアクセスを取り扱うために単一の
中央仲裁ノードを選択する方法を含む。その中央ノード（アクティブなサーバ）
はアクティブなシステムにトークンが確実に存在するための責任を負う。ＰＬＸ
は、設計の簡素化と、実現の容易さと、衝突なしのアクセスと、系統的な受容と
、トークンのその後の放棄と、データを確実に配信するため確認応答シーケンス
（要求／応答）とを行うために選択的な動的ポーリングを行うために選択的かつ
動的ポーリングを用いる。

【０１４６】 ＰＬＸはノードが「アクティブの」時に「静止した」媒体１００を持つ能力を
提供する。通常は、ＰＬＸにおいては、「アクティブな」ノードのみが媒体１０
０で通信する。ＰＬＸはプラグ−ｎ−プレイ性能のための全体的アドレス指定方
式と、媒体１００のための複数ノード競合を分離するためのアルゴリズムを提供
もする。

【０１４７】 ＰＬＸは、ストリーミング・アプリケーションのための時間決定論、または保
証されたタイム・スロット、と、ターンアラウンド時間を短くするために短縮さ
れたセル長さ（パケット長さ）とをも提供する。

【０１４８】 ＰＬＸは多重レート・サポート・パケットと、ホット・スワッピング・パケッ
トと、真正証明および安全パケットと、制御および管理パケットとを提供する。

【０１４９】 また、ＰＬＸはより高い層プロトコル内に多くの制御ネットワーク化機能を提
供する。その結果、媒体アクセス方法が種々のトポロジーの多くの有利な機能を
利用する高度に洗練されたものになった。媒体アクセス方法論 媒体アクセス方法論は媒体１００をアクセスする際に含まれる諸規則の概要を
示すものである。媒体１００をアクセスするＰＬＸ法は３つの事象、 １．データグラム検出または「聴取」； ２．バスの分割； ３．集中化されたトークン・パッシング を通常含んでいる。

【０１５０】 ノードはシステムに存在するトークンに関して、アクティブネットワーク・サ
ーバ・ノードとして、またはクライアント・サーバとして特徴付けられる。ＰＬ
Ｘシステムでは、媒体１００に対する最初のアクセスは、活動を聴取し、その後
でアクティブなネットワーク・サーバとして自己表明し、最後に、活動している
ネットワーク・サーバによる系統的な、集中化されたトークン・パッシングをす
ることにより行われる。

【０１５１】 図５は、どのノードが媒体１００で「話す」ことを許されるかを仲裁するため
にＰＬＸにより用いられる媒体アクセス・アルゴリズムを示す流れ図である。図
５に置ける流れ図は電源投入および告知処理ブロック８０１で始まる。そうする
と各ノードは、電源を投入されると、媒体１００に置けるそれの存在を告知され
る。告知が終わると、プロセスは判定ブロック８０２へ進む。ノードは、送信（
Ｔｘ）準備完了コマンドが受け取られるまで、判定ブロック８０２内でループ（
アイドル）し、そのコマンドが受け取られると、プロセスは判定ブロック８０３
へ進む。この判定ブロック８０３において、ノードがラインアップ・カード上に
ないか、またはアクティブサーバでなければ、プロセスはデータグラム検出ブロ
ック８０４へ進み、さもなければプロセスは判定ブロック８１６へ進む。判定ブ
ロック８１６では、ノードがトークンを受け取っていたならば、プロセッサはパ
ケット送りブロック８１４へ進み、さもなければ、プロセッサは時間切れ判定ブ
ロック８１０へ進む。判定ブロック８１０では、時間切れが起きていなかった場
合、プロセスは判定ブロック８１６へ戻る。さもなければ、プロセスはデータグ
ラム検出ブロック８０４へ進む。パケット送りブロック８１４では、プロセスは
送信パケットを送って、ポーリング・ブロック８１５へ進む。ポーリング・ブロ
ック８１５では。図７を参照して説明するように、アクティブなネットワーク・
サーバがアクティブなノードをポールし、またはそのノードがクライアントであ
れば戻る。ポーリング・ブロック８１５が終了すると、プロセスは判定ブロック
８０２へ進む。

【０１５２】 データグラム検出ブロック８０４では、ノードは媒体１００を特定の時間聴取
し、その後で判定ブロック８０５へ進む。処理ブロック８０４の聴取期間中に媒
体が覚醒しているならば、プロセスはＬＩＰ要求判定ブロック８０６へ進み、さ
もなければ、プロセスは処理ブロック８１２へ進む。処理ブロック８１２では、
そのノードは「覚醒」パケットを送り、判定ブロック８１４へ進む。判定ブロッ
ク８１４では、３つの覚醒パケットが送られたがそれに対する応答がなかったと
すると、プロセスは自己表明ブロック８１３へ進む。さもなければデータグラム
検出ブロック８０４へ戻る。自己表明ブロック８１３では、ノードはアクティブ
なサーバ・ノードとして自己表明し、プロセッサはパケット送りブロック８１４
へ進む。

【０１５３】 ＬＩＰ要求判定ブロック８０６では、プロセスはＬＩＰ要求の存在を調べる。
ＬＩＰ要求が存在しなければ、プロセスは時間切れ判定ブロック８０９へ進み、
さもなけれぱ、プロセスは処理ブロック８０７へ進む。時間切れ判定ブロック８
０９では、プロセスは指定されたパケット時間切れ期間が経過したかどうかを調
べる。その期間が経過したならば、プロセスは判定ブロック８０２へ進み、さも
なければプロセスはＬＩＰ要求判定ブロック８０６へ戻る。

【０１５４】 処理ブロック８０７では、ノードはバスにスピット・オンし、その後で判定ブ
ロック８０８へ進む。判定ブロック８０８では、ノードがドラフトされたかどう
かをプロセスは調べる。ノードがドラフトされたとすると、プロセスはトークン
受信判定ブロック８１６へ戻り、さもなければ、プロセスはＬＩＰ要求判定ブロ
ック８０６へ戻る。

【０１５５】 ブロック８０２、８０３、８１０、および８１４〜８１６は集中化されたトー
クン・パッシング・アルゴリズムの一部である。ブロック８０４、８０５、およ
び８１１〜８１３はデータグラム検出（聴取）アルゴリズムの一部である。ブロ
ック８０６〜８０９はスピッティング・オン・ザ・バス・アルゴリズムの一部で
ある。

【０１５６】 図５に示すように、媒体１００に対する最初のアクセスは、媒体１００が「睡
眠中」であるか「覚醒している」かに依存して２つの異なるやり方の１つで行わ
れる。媒体１００が睡眠中であれば、アクセスを望んでいるノードはアクティブ
サーバとして自身を自己表明する。媒体１００がアクティブ（すなわち、アクテ
ィブネットワーク・サーバにより用いられている）と、アクセスを望んでいるク
ライアント・ノードがアクティブなネットワーク・サーバにアクセスを求める。
アクティブなネットワーク・サーバはアクセスを求めたクライアント・ノードの
ラインアップ・カードを保持している。クライアント・ノードは「スピッティン
グ・オン・ザ・バス」として知られているプロセスによってラインアップ・カー
ドに記入されることを求める。

【０１５７】 通常は、サーバになることができるどのようなノードもアクティブなネットワ
ーク・サーバとして自身を表明できるが、所与のノード内にサーバになることが
できる属性を含むという要求ではない。

【０１５８】 アクティブなネットワーク・サーバがひとたび選択されると、それは、ポール
すべきアクティブなサーバ・ノードのリストを含む「ラインアップ・カード」を
作成および保持することができなければならない。アクティブなネットワーク・
サーバの全てがインアクティブになり（エージング・プロセスによって）と、ア
クティブなネットワーク・サーバはアクティブなサーバとしてのそれの現在の状
態を放棄し、媒体１００は再び眠る（睡眠）ことになる。通常、アクティブなネ
ットワーク・サーバは、媒体１００へ送り出す何かを有するノードにより自己指
名される。

【０１５９】 アクティブノードがある時間沈黙しているとそのノードはラインアップ・カー
ドから除去される。アクティブノードは、高い優先順位のデータを持つノードが
ラインアップ・カードに対するアクセスを必要とする時にもラインアップ・カー
ドから除去される。ラインアップ・カードは通常は最大数のスロットを有する。
いいかえると、ラインアップ・カードはラインアップ・カードに載せることがで
きる最大数のノードを有する。スロットの数は媒体１００で利用できる帯域幅と
、種々のネットワーク・ノードにより必要とされている帯域幅とにより通常決定
される。Ｎがラインアップ・カード中のスロットの最大数、ｔが特定のアクティ
ブなノードがトークンを保持することを許される最も長い時間（ミリ秒）とする
と、そのアクティブなノードはＮ×ｔミリ秒ごとに少なくともおよそ１回トーク
ンを獲得する。したがって、ラインアップ・カードは、アクティブなノードが定
期的な、予測できるベースでポールされることになる、という決定を行う。 た
とえば、ストリーミング・ビデオ・データはストリーミング・オーディオよりも
高い優先順位を持つ。そうすると、Ｎ個のストリーミング・ビデオ・ノードがラ
インアップ・カードに既に載せられていると、ラインアップ・カードに載せられ
ることを求めているストリーミング・オーディオ・ノードは拒絶される。しかし
、ストリーミング・オーディオ・ノードには、ラインアップ・カードに載せられ
ることを求めるたびに、トークンが与えられる。ラインアップ・カードに載せら
れているノードは自動的にポールされ、したがって、トークンを求める必要なし
にトークンを定期的に獲得する。ラインアップ・カードに載せられていないノー
ドは、トークンに対する要求、またはラインアップ・カードに載せられる要求、
を行った後でのみトークンを受け取る。

【０１６０】 特定のネットワーク・ノードにより提供されるデータの優先順位は、以下に説
名するノード・プロフィル・オブジェクトに関連して記載されたｎｅｔｗｏｒｋ
−ｃｌａｓｓフィールドにより決定される。特定のノードに対するｎｅｔｗｏｒ
ｋ ｃｌａｓｓはノード・アドレスの上位４ビット（ｄｅｖｉｃｅ ｔｙｐｅフ
ィールド）中にも見出される。

【０１６１】 ノード・セマフォ 各ＰＬＸノードは、システムの現在の状態と、システム内におけるノードの関
わり合いとを反映する２つのローカル・セマフォを管理する。それらのセマフォ
は聴取プロセスを開始すべきか否かをノードが決定することを支援する。通常は
、それら２つのセマフォは媒体１００に対するアクセスを行うために用いられる
ので（ノードが送信するものを有しているとき）、ノードはそれらのセマフォを
管理する。

【０１６２】 最初のセマフォは「システム状態」を反映する。システム状態は、媒体１００
がアクティブか否か（すなわち、パケットが媒体１００上で見られるか）に応じ
て、「覚醒している」か「睡眠中」であるかである。

【０１６３】 第２のセマフォは「ローカル・ノード状態」と名付けられている。ローカル・
ノード状態はノードの取り得る次のような３つの状態、すなわち、（１）ノード
はアクティブなネットワーク・サーバ・ノードである、（２）ノードはアクティ
ブなクライアント・ノードである、（３）ノードはノンアクティブなクライアン
ト・ノードである、の１つを反映する。ローカル・ノード状態は、ノードが聴取
アルゴリズムを開始すべきかどうか、ノードが現在ラインアップ・カードに載せ
られている（ポールされている）かどうか、またはノードが現在アクティブなサ
ーバであるかどうかを判定する。

【０１６４】 「システム状態」腕木信号 各ノードは、システムが覚醒しているか、睡眠中であるかについて個々に判定
する。この判定は媒体１００におけるラインアップ挿入要求パケット（ＬＩＰ）
の存在を基にしている。ノードがＬＩＰパケットを見ると、システム状態腕木信
号は覚醒することになる。ある時間の後で、ＬＩＰパケットが見られないとする
と、ノードはシステム状態を睡眠へトグルする。これは、アクティブネットワー
ク・サーバが存在するものとすると、それはクライアント・ノードを覚醒状態に
維持するためにＬＩＰパケットを周期的に送らなければならないことを意味する
。

【０１６５】 ノードが媒体１００を聴取せねばならないか否かを決定するために、ノードは
この腕木信号を使用する。システム状態が睡眠である時のみ、ノードは聴取プロ
セスを通じて媒体１００を争う必要がある。

【０１６６】 「ローカル・ノード状態」腕木信号 アクティブなネットワーク・サーバは、それのラインアップ・カードに現在載
せられているクライアント・ノードにトークン（ポール）を、そのクライアント
・ノードによる最後の送信の後で１ないし１０秒間配信する。この時点で、アク
ティブなネットワーク・サーバは、ノードが送信を続け、ラインアップ・カード
からクライアント・ノードを「古びさせる」ことを決定する。クライアント・ノ
ードはこれを検出できなければならない。クライアント・ノードがトークンを現
在受信していると、それはアクティブとみなされる。クライアント・ノードがト
ークンを現在受信していないと、それはインアクティブとみなされる。インアク
ティブなクライアントは、アクティブなネットワーク・サーバによりラインアッ
プ・カードに載せられた後で、「スピッティング・オン・ザ・バス」と名付けら
れたプロセスにより、媒体１００に送信することができるだけである。下の表Ａ
１には可能なノード腕木信号状態と、各状態が媒体への送信に関して意味するも
のを示す。

【０１６７】 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ システム状態 ノード状態 次の送信動作 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 覚醒 アクティブ ラインアップ・カードで：トークンを待つ ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 覚醒 インアクティブ ラインアップ・カード外で：スッピト・オン ・ザ・バス ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 睡眠 アクティブ 悪い状態：聴取し、その後サーバであると表明 する ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 睡眠 インアクティブ 聴取し、その後サーバであると表明する ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ 表Ａ１．新たな送信の用意ができているノードに対する次の動作。

【０１６８】 データグラム検出または「聴取」 上記システム状態腕木信号は、ノードが聴取を開始すべきか否かを決定する際
の主な要因である。それは、ノードがアクティブネットワーク・サーバであると
自身で表明すべきか否か、またはそれがクライアントとしての服従的な役割を演
ずるか否かを決定する際の主な要因でもある。通常は、聴取は、睡眠中のシステ
ムへの最初の送信に先立って行われるだけである。いずれかのノードが媒体１０
０へ送信していると、アクティブネットワーク・サーバはＬＩＰパケットを送る
ため、およびトークン配信を仲裁するために、アクティブネットワーク・サーバ
は既に選択されており、システムは覚醒している。システムが覚醒しているなら
ばノードはクライアントとして行動すべきである。

【０１６９】 媒体１００へ送る準備が整っているパケットをあるノードが有していること、
およびシステム状態腕木信号が睡眠中であることをそのノードが判定すると、ノ
ードは聴取プロセスを行ってそれの次のステップを決定し、この最初のプロセス
中の衝突を最少にする。これは、２つのノードが媒体１００を求めて争うことが
あり、かつ考えられる見えていない衝突が起こり得る、ＰＬＸネットワーク上の
時間のみでなければならない。このようにして、堅実なバックオフ・アルゴリズ
ムが提供される。

【０１７０】 聴取においてアドレスするために次のような２つの可能なケースがある。（１
）ノードに電源が投入されたばかりで、現在のシステムに加えたことを告知する
ために、それの「告知」パケットまたは「ＣＡＬ−ピン（ｐｉｎｇ）」パケット
を送る必要がある。（２）ノードはインアクティブで、システムを覚醒させよう
と試みている。いずれのケースでも、聴取中にあるサーバが検出されると、その
ノードはＬＩＰパケットのサーチを直ちに開始すべきである。ＬＩＰパケットは
ノードがラインアップ・カードをアクティブネットワーク・サーバに挿入するこ
と、およびその後でのトークン・パッシングおよびノード送信を可能にする。

【０１７１】 最初の「聴取／ピン（Ｐｉｎｇ）」告知 ノードに電源が投入されると、そのノードはシステムにおけるそれの存在を放
送ＣＡＬ−ピン・パケットを送信することにより直ちに告知する。これによって
、情報を「引く」ことを常に試みる代わりにそれを「押す」ことによって、自動
発見機構を一層堅実なものにすることができるようにされる。電源を投入された
ばかりのノードはシステムに関する履歴を持っていないので、聴取アルゴリズム
は正常な覚醒プロセスとは僅かに異なる。

【０１７２】 最初の聴取はＣＡＬ−ピン・パケットを放送するまでに５００ｍｓも要するこ
とがある。これは、指定された時間だけトラフィックを実際に聴取し、その後で
その時間中無作為に聴取し、放送覚醒パケットを３回送信して好適なサーバに、
このノードが存在するならば、それをポーリングをする機会を与えることによっ
て行われる。この動作は３回繰り返され、それが終わると、ＣＡＬ−ピン・パケ
ットが全てのノードへ放送されて、システムへのエントリが成功したことを知ら
せる。聴取／ピンのための一連の動作が擬似コードで次のように与えられている
。

【０１７３】 １） ａ）１２５ｍｓより短い任意の長さの時間媒体１００を聴取する（ＬＩ
Ｐパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）聴取を続けて全部で１２５ｍｓの時間を終了する。 ２） ａ）１２５ｍｓより短い任意の長さの時間媒体１００を聴取する（ＬＩ
Ｐパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）聴取を続けて全部で１２５ｍｓの時間を終了する。 ３） ａ）１２５ｍｓより短い任意の長さの時間媒体１００を「聴取する」（
ＬＩＰパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）「聴取」を続けて全部で１２５ｍｓの時間を終了する。 ４）アクティブネットワーク・サーバとして表明し、放送「ＣＡＬ−ピン」
パケットを送信して存在を示す。 ５）アクティブネットワーク・サーバとしての表明を取消す。

【０１７４】 上記聴取／ピン・プロセスはノードに電源が投入された後で１回行われ、そこ
からこのプロセスが要する待ち時間は通常は長くない。以下に説明する実行時間
覚醒プロセスはもっとしばしば実行されるので、待ち時間はもっと短いことが望
ましい。

【０１７５】 実行時間「聴取／覚醒」シーケンス ノードに電源がひとたび投入され、それがシステムに存在することが告知され
ると、それは実行時間モードで動作を開始する。それの実行時間動作モード中に
、ノードがパケットを睡眠中のシステムへ送る必要があると、それは同様な一連
の事象を進んで、好適なサーバを覚醒させようと試みる。好適なサーバが存在せ
ず、かつアクティブネットワーク・サーバが存在しないとすると、ノードはアク
ティブネットワーク・サーバと自身を表明し、クライアント・ノードのポーリン
グを開始する。聴取／覚醒アルゴリズムのための疑似コードの表が下に与えられ
ている。下に与えられているアルゴリズムに加えて、応答時間をより短くするた
めに、システムの状態を反映させるためにノードは媒体１００の監視と、ローカ
ル・ノードセマフォの使用とを交互に行うことができる。このプロセスに関連す
る待ち時間を一層短縮するために、ローカル・ノードセマフォは覚醒パケットに
関連して用いられる。

【０１７６】 １） ａ）１２５ｍｓより通常短い任意の長さの時間媒体１００を聴取する（
ＬＩＰパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）「聴取」を続けて全部で１２５ｍｓの時間を終了する。 ２） ａ）１２５ｍｓより通常短い任意の長さの時間媒体１００を聴取する（
ＬＩＰパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）聴取を続けて全部で１２５ｍｓの時間を終了する。 ３） ａ）１２５ｍｓより短い任意の長さの時間媒体１００を「聴取する」（
ＬＩＰパケットを求める）。 ｂ）覚醒パケットを間隙間に３００μｓの間隔をおいて３回放送する。 ｃ）聴取を続けて全部で１２５ｍｓの時間を終了する。 ４）アクティブネットワーク・サーバとして表明し、それに応じて次のパケ
ットを送信する。 ５）アクティブネットワーク・サーバとしての表明を取消す。

【０１７７】 スピッティング・オン・ザ・バス システム上のノードが送信準備の整ったパケットを有し、かつシステムが覚醒
している（アクティブネットワーク・サーバが存在し、かつそれが現在トークン
を配信している）時に「スピッティング」プロセスは起きる。アクティブネット
ワーク・サーバは媒体１００をアクセスすることを許可されている唯一のノード
である。アクティブネットワーク・サーバのラインアップ・カードは、インアク
ティブのクライアント・ノードが媒体１００をアクセスできるようにする機構の
ことである。

【０１７８】 典型的な実行時間動作中は、ネットワークは２つの状態、すなわち、睡眠中ま
たは覚醒中、のいすれか１つで現れる。スピッティング・プロセスはネットワー
クが現在どの状態にあるかに応じて僅かに異なる。

【０１７９】 睡眠および覚醒状態 サービスを現在求めているノードがないと、アクティブネットワーク・サーバ
が判定した時にネットワークは睡眠状態に入り、その結果、トークンの送信を停
止する。ネットワークの動作停止の前に、アクティブネットワーク・サーバは一
連のマスクされた群ＬＩＰ（ＬＩＰＧ）要求パケットを指定された時間送る。一
連のＬＩＰＧ要求パケットがどのクライアント・ノードからも応答を引き出さな
いと、アクティブネットワーク・サーバは活動しなくなり、ネットワークは睡眠
状態に入る。送信を求めているノードによるネットワークへのその後のエントリ
は、その後で上記正常な競合取扱い、聴取アルゴリズムを介して行われる。

【０１８０】 覚醒状態は、指定されたネットワークにおける、１つまたは複数の遠隔ノード
と情報を能動的に交換しているノードを象徴する。覚醒状態では、媒体アクセス
はアクティブネットワーク・サーバおよびそれのラインアップ・カードにより制
御される。ラインアップ・カードに現在載せられているノードに対するトークン
・パッシングを用い、かつラインアップ・カードに載せられようと試みているノ
ードに対するスピッティングによって衝突は減少させられる。

【０１８１】 「スピッティング・オン・ザ・バス」シーケンス スピッティング・オン・ザ・バスのためのシーケンスによって、アクティブネ
ットワーク・サーバがＬＩＰＧパケットを周期的に送ることができるようにされ
る。睡眠中のクライアント・ノードはＬＩＰＧパケットに応答することを許され
る。応答がひとたび見られると、アクティブネットワーク・サーバはマスクされ
ていないＬＩＰＤ要求を全てのノードへ送って、トークンを望んでいるノードの
アドレスを持つ単一の応答を希望する。２つ以上のノードがトークンを求めて競
合しているとすると、応答は見られず、アクティブネットワーク・サーバはノー
ド分離シーケンスに入る。

【０１８２】 図６Ａおよび図６Ｂは、それぞれアクティブネットワーク・サーバおよびクラ
イアント・ノードのためのスピッティング・オン・ザ・バスのプロセスを示す図
６Ａでは、アクティブネットワーク・サーバのためのスピッティング・オン・ザ
・バスのプロセスは、ノードがアクティブネットワーク・サーバになった時にス
タート・ブロック９０１で始まる。プロセスはスタート・ブロック９０１からポ
ーリング・ブロック９０２へ進む。ポーリング・ブロック９０２では、アクティ
ブサーバは現在ラインアップ・カードに載せられているクライアント・ノードの
全てをポールする。ポーリングがひとたび終了すると、プロセスは送信ブロック
９０３へ進む。送信ブロック９０３では、アクティブサーバ・ノードはマスクさ
れていないＬＩＰＧ要求を送り、その後で判定ブロック９０４へ進む。判定ブロ
ック９０４では、アクティブサーバはＬｏＧＩ応答を探す。ＬｏＧＩ応答が受け
られたとすると、プロセスはプロセス・ブロック９０５へ進み、さもなければ、
プロセスはポーリング・ブロック９０２に戻る。

【０１８３】 プロセス・ブロック９０５では、アクティブサーバはマスクされていないＬＩ
ＰＤ要求を送り、その後で判定ブロック９０６へ進む。判定ブロック９０６では
、アクティブサーバが直接ＡＣＫ（ＤＡＣＫ）応答を探す。１つのＤＡＣＫ応答
が受信されると、プロセスはプロセス・ブロック９０７へ進む。多数のＤＡＣＫ
応答が受信されるか、ＤＡＣＫ応答が受信されないと、プロセスはノード分離ブ
ロック９１０へ進む。プロセス・ブロック９０７では、ＤＡＣＫ応答を送ったク
ライアント・ノードがラインアップ・カードに加えられ、その後でプロセスはポ
ーリング・ブロック９０２に戻る。

【０１８４】 プロセス・ブロック９１０（ノード分離アルゴリズムを開始している）では、
プロセスはＬＩＰＧマスクを初期化し、プロセス・ブロック９１１へ進む。プロ
セス・ブロック９１１では、マスクが更新され（たとえば、マスク中の次のビッ
トがトグルされる）、プロセスは送信ブロック９１２へ進む。送信ブロック９１
２では、マスクされたＬＩＰＧ要求が送られ、プロセスは判定ブロック９１３へ
進む。判定ブロック９１３では、プロセスはＬｏＧＩ応答を探す。ＬｏＧＩ応答
が受信されると、プロセスは判定ブロック９１５へ進み、さもなければ、プロセ
スはプロセス・ブロック９１４へ進む。プロセス・ブロック９１４では、プロセ
ス・ブロック９１１で最近にトグルされたマスク・ビットがトグルを解除され、
プロセスは判定ブロック９１５へ進む。

【０１８５】 判定ブロック９１５では、マスク中の全てのビットがトグルされると、プロセ
スはプロセス・ブロック９１６へ進み、さもなければ、プロセスはプロセス・ブ
ロック９１１に戻る。プロセス・ブロック９１６では、アクティブネットワーク
・サーバはマスクされたＬＩＰＧ要求を送り、判定ブロック９１７へ進む。判定
ブロック９１７では、ＤＡＣＫ応答が受信されると、プロセスはプロセス・ブロ
ック９０７へ進み、さもなければ、プロセスはポーリング・ブロック９０２に戻
る。

【０１８６】 プロセス・ブロック９０３〜９０７は最初のシーケンスをスピッティングして
いるサーバの一部である。プロセス・ブロック９１０〜９１７はノード分離シー
ケンスをスピッティングしているサーバの一部である。

【０１８７】 図６Ｂはクライアント・スピッティング・アルゴリズムを示す流れ図であって
、アクティブネットワーク上のクライアントのためのスタート・ブロック９３１
で始まる。スタート・ブロック９３１から、プロセスは判定ブロック９８２へ進
み、そこで送信状態が調べられる。送信状態が「準備完了」であれば、プロセス
は判定ブロック９８３へ進み、さもなければプロセスはアイドル・ブロック９８
８へ進む（アイドル・ブロックは判定ブロック９８２に戻る）。

【０１８８】 判定ブロック９８３では、ノードがシステム・トークンを受信すると、プロセ
スは送信ブロック９８９へ進み、さもなければ、プロセスは判定ブロック９８４
へ進む。送信ブロック９８９では、ノードはデータのパケットを送り、プロセス
は判定ブロック９８２に戻る。判定ブロック９８４では、ノードがＬＩＰＤ要求
を受信すると、プロセスはプロセス・ブロック９９０へ進み、さもなければプロ
セスは判定ブロック９８６へ進む。判定ブロック９８６では、プロセスは時間切
れまたはシステム睡眠状態を調べる。プロセスが時間切れまたは睡眠を検出する
と、プロセスはプロセス・ブロック９８７へ進み、そこで現在のノードが実施例
をアクティブサーバであるとして表明する。

【０１８９】 プロセス・ブロック９９０では、ＬＩＰＤからのマスクが現在のノードのノー
ド・アドレスと比較され、プロセスは判定ブロック９９１へ進む。判定ブロック
９９１では、マスクがノードに一致すると、プロセスは応答ブロック９９２へ進
実、さもなければ、プロセスは判定ブロック９８２に戻る。応答ブロック９９２
では、ノードはネットワーク・サーバに応答し（適切なＬｏＰＧまたはＤＡＣＫ
で）、プロセスは判定ブロック６８２に戻る。

【０１９０】 群ＬＩＰ（ＬＩＰＧ）質問 ネットワークが覚醒している間、アクティブネットワーク・サーバは群ＬＩＰ
質問を周期的に放送する。群ＬＩＰ（ＬＩＰＧ）質問は論理群分離（ＬｏＧＩ）
応答を任意の数のノードから求める。この機構は、衝突のない機構において使用
中ネットワーク内にラインアップ・カードに挿入する機会をクライアント・ノー
ドに与える。ＬｏＧＩパケットの利点は、多数の同時ノードがこの種のパケット
を送信できること（それらが同じ時間内にあると仮定して）、および結果が単一
のＬｏＧＩパケットである、ということである。したがって、多数のＬｏＧＩ応
答によって単一のＬｏＧＩパケットが受信ノードにより見られることになる。

【０１９１】 最初のＬＩＰシーケンス・パケットは、ネットワークにおけるいずれか１つの
ノードがＬＩＰシーケンスをラインアップ・カードに挿入することを開始するこ
とを望んでいるかどうかを判定するために送られる、マスクされていない群ＬＩ
Ｐ（ＬＩＰＧ）質問である。ＬｏＧＩシーケンスが見られたとすると、おそらく
単一のノードのみが挿入することを望み、したがって、マスクされていない直接
ＬＩＰ（ＬＩＰＧ）パケットが次に送られる。直接応答が見られないと、その後
のＬＩＰＧパケットがマスクされたアドレスを持つ群パケットとして送られる。
これは、ラインアップ・カードに挿入される特定のノードを分離するために用い
られる、骨の折れる、効率の低い分離機構である。これはビットマスクを系統的
に送ることによって行われる。それは遠隔ノードの３２ビットアドレスの単一の
ビットを同時に分離する。２つまたは３つ以上の衝突したノードがトークンを同
時に要求したときに、この分離機構は実行されなければならない。

【０１９２】 直接ＬＩＰ（ＬＩＰＤ）質問 直接ＬＩＰ（ＬＩＰＤ）質問はＬＩＰＧ質問の結果として送られる。ＬＩＰＤ
質問の目的は、単一のノードのみが応答することを希望して（それは時間のほと
んどのケースでなければならない）マスクされていないＬＩＰＤ要求を全てのノ
ードへ送ることによりＬＩＰプロセスを促進することである。ＬＩＰＤパケット
は応答するノードのアドレスを含む通常のＤＡＣＫ応答で応答される。単一のノ
ードが応答すると、応答が見られ、ノード・アドレスがラインアップ・カードに
適切に加えられる。しかし、ＬＩＰＤ要求が見られないと、（多数のノードが同
時に応答するために）アクティブネットワーク・サーバは、ＬＩＰＧパケットを
用いて、正常な分離アルゴリズムによって分離を続け、「ラインアップ・カード
」に挿入される競合しているノードのうちのただ１つを選択する。

【０１９３】 したがって、単一のノードだけが要求に応答することを望んで、ＬＩＰＤパケ
ットは分離プロセスを促進するために用いられるだけである。

【０１９４】 ノード分離シーケンス ノードが最初のＬＩＰＧに応答したが、なんらかの理由で単一の応答がＬＩＰ
Ｄ質問からは見られないと、アクティブネットワーク・サーバはノード分離に自
動的に進む。分離シーケンスは、ＬｏＧＩ応答を要求するＬＩＰＧパケットを使
用する。これによって多数の同時応答をアクティブネットワーク・サーバによっ
て見られるようになる。

【０１９５】 「アクティブネットワーク・サーバ」は、第１のアドレス（最下位）ビットが
セットされたパケットを送ることによってこのシーケンスを開始する。送信を望
んでいるノードは、この特定のアドレス・ビットがそれら自身に一致し、かつ一
致した時のみ、このパケットに応答する。このアルゴリズムは、元のマスクとの
比較が後に続く簡単な「ＡＮＤ」である。２つの値が一致すると、パケットはＬ
ｏＧＩにより応答される。

【０１９６】 アクティブネットワーク・サーバはその後以前に一致したマスクをそのまま持
ち、次のビットがセットされている次のパケットを送る。再び、ビット・シーケ
ンスが一致したならばノードは応答する。どのノードも応答しないと、アクティ
ブネットワーク・サーバは現在のビットをクリヤし、そのパケットを再び試行す
る。これは、３２ビットの全てが識別されて一致が見出されるまで続行される。
この時点で、唯一に識別されたノードがアクティブネットワーク・サーバのライ
ンアップ・カードに加えられる。

【０１９７】 集中化されたトークン・パッシング（ポーリング） システムが覚醒していると、ラインアップ・カードに含まれている各ノードに
（スピッティング・プロセスにより）、媒体１００をアクセスできる時間である
決定論的タイムスロットを与えることが望ましい。各ノードに使用中の媒体１０
０を介して送信する同じ機会を与えることも望ましい。イーサネットは上記利点
のいずれも欠いているが、トークン・リングは両方とも有する。

【０１９８】 トークン・リングは、各ノードにそれの上流側および下流側の近くのノードの
アドレス、およびトークンが常に存在／回転することを知ることを要求する点が
欠点である。従来のトークン・リング・ネットワークのオーバーヘッド要件は、
ＰＬＸにより意図されているダム・ノードとは適合しない。さらに、電源線ネッ
トワークの特別なネットワーク化要件はそのような厳密なトークン回転には寄与
しない。したがって、ＰＬＸはダイナミック・ラインアップ・カードを有する集
中化されたトークン・パッシング（ＣＴＰ）機構を導入する。

【０１９９】 ＣＴＰでは、アクティブネットワーク・サーバ・ノードは、トークンが存在す
ること、トークンを必要としている全てのノードがそれを得ること、睡眠中のノ
ードが覚醒できかつトークンを受信することができること、およびトークンが決
定論的なやり方で公平に分配されることを確実に行う責任を負っている。ＣＴＰ
の下では、アクティブサーバ以外のノードはクライアントと呼ばれている。アク
ティブネットワーク・サーバの役割は上記データグラム検出または聴取プロセス
を通じて自己指名される。アクティブネットワーク・サーバの役割は媒体１００
での所定の時間の動作の後で破棄される。一実施形態では、アクティブサーバの
役割は約５秒の動作しなかった後で放棄される。システムの動作中は、アクティ
ブネットワーク・サーバはラインアップ・カード中の各クライアント・ノードを
ポーリングするとともに、新しいノードに、それら自身をラインアップ・カード
にスピッティング・プロセスを通じて挿入できる機会を与える役目をする。

【０２００】 図７はネットワーク・サーバ・ポーリング・アルゴリズムを示す流れ図であっ
て、ノードがアクティブサーバになるスタート・ブロック１００１で始まる。プ
ロセスはスタート・ブロック１００１から判定ブロック１００２へ進み、その判
定ブロックで周期的ＬＩＰパケットを送信の必要性を判定する。ＬＩＰパケット
が必要とされると、プロセスはプロセス・ブロック１０１０へ進み、さもなけれ
ば、プロセスはプロセス・ブロック１００３へ進む。プロセス・ブロック１０１
０では、ノードは図６Ａに関連して説明したアクティブサーバ・スピッティング
・プロセスを実行する。プロセス・ブロック１０１０が終了すると、プロセスは
プロセス・ブロック１００３へ進む。

【０２０１】 プロセス・ブロック１００３では、プロセスはラインアップ・カード中の次の
エントリを獲得して判定ブロック１００４へ進む。プロセス・ブロック１００４
では、ラインアップ・カード中の全てのエントリが処理されると（すなわち、全
てのクライアント・ノードが話す機会を持っていると）、プロセスはプロセス・
ブロック１０１１へ進み、さもなければ、プロセスはプロセス・ブロック１００
５へ進む。プロセス・ブロック１０１１では、トークンはアクティブサーバに与
えられ（したがって、アクティブサーバが話すことを許される）、プロセスはプ
ロセス・ブロック１００５へ進む。

【０２０２】 プロセス・ブロック１００５では、トークンがラインアップ・カードから得ら
れた次のノードに与えられ、プロセスは判定ブロック１００７へ進む。判定ブロ
ック１００７では、応答時間切れが起きると、プロセスはプロセス・ブロック１
０１２へ進み、さもなければ、プロセスは判定ブロック１００７へ進む。判定ブ
ロック１００７では、クライアント・ノードがそのトークンを使用しなかった場
合、プロセスはプロセス・ブロック１０１２へ進む。プロセス・ブロック１０１
２では、アクティブノードの数のカウントがデクリメントされ、プロセスは判定
ブロック７０８へ進む。

【０２０３】 判定ブロック１００８では、全てのノードがインアクティブであると、プロセ
スはプロセス・ブロック１００９へ進み、さもなければ、プロセスは判定ブロッ
ク１００２に戻る。プロセス・ブロック１００９では、アクティブサーバは活動
してい無いクライアント・ノードへ戻る。

【０２０４】パケットの型およびフォーマット ＰＬＸネットワークにおけるパケットはパケットの目的に応じて種々のフォー
マットをとることができる。種々のフォーマットは３つの別々の部類にグループ
化するのが好都合である。

【０２０５】 １つのフォーマットによって、多数のノードが、干渉問題や復調問題なしに、
同じ応答パケットを同時に送信／受信できる。それらは論理的グループ分離（Ｌ
ｏＧＩ）パケットと呼ばれており、放送／再放送および確認応答のために主とし
て用いられる。

【０２０６】 生データ・ペイロード・パケットおよびコマンド・ペイロード・パケットと呼
ばれている、他の２つの型のパケットは、単一のノードが任意の所与の時点でワ
イヤにより通信する時に用いられる。新しい生データ・ペイロード・パケットは
、それのアプリケーションに属する情報の送信／受信を望んでいるアプリケーシ
ョンにより用いられる。ホスト・ノードから来るパケットは生データ・ペイロー
ド・パケットおよび任意のＣＡＬパケットである。

【０２０７】 ＰＬＸコマンド・ペイロード・パケットが媒体のアクセスおよび流れを管理す
るために用いられる。ＰＬＸコマンド・パケットはアダプタのファームウエア内
およびハードウェア内で発生し、かつ終息して、ホスト・ノードは通らない。Ｐ
ＬＸコマンド・パケットはトークン、確認応答、ラインアップ挿入等の円滑な流
れを容易にするものであって、全てのＰＬＸネットワークに固有のものである。

【０２０８】 論理グループ分離（ＬｏＧＩ）応答パケット ノードがグループ要求（多数の同時応答の可能性を持つ要求）をネットワーク
へ送り出す時に第１の形式が用いられる。ＰＬＸは衝突が減少した、またはある
場合には衝突がない環境が望ましいので、衝突を検出することは困難である。し
たがって、同時応答が可能である。図８に示されている、ＬｏＧＩパケット１１
００は２バイト０フィールドと、それの後に続く多数の２バイトオール「１」フ
ィールドと、それの後の２バイト０フィールドとを含む。この種のパケット内に
存在するデータは非常に秘密であるが、群応答を単一のノードに分離することを
助けるその目的を果たす。

【０２０９】 マスクされたＬＩＰＧ要求がＬｏＧＩパケットに先行する。２つ以上のノード
のマスク手段はマスクされたアドレスに一致でき、したがって、多数の同時応答
が生ずることができる。ＬＩＰＧパケットについては後で説明する。

【０２１０】 ＬｏＧＩパケットは、特定のパケット中に存在する１の列を長くすることによ
ってある非常に単純化されたデータも含む。長くされたパケットは、異なる型の
応答を示すために、時間変位（ｔｉｍｅ ｄｉｓｐｌａｃｅｍｅｎｔ）と共に用
いなければならない。放送パケットはこの特徴を用いて、使用中の応答を１つま
たは複数のノードにより同時に示すことができるようにする。

【０２１１】 ペイロード・パケット 第２の形式はネットワークの周囲でペイロードを運ぶために用いられる。これ
はネットワーク上で最も一般的に用いられている形式であって、有用なデータ情
報を送信および受信するために有効な形式である。

【０２１２】 ペイロード・パケットは、受信側の範囲と、それらが受信することを期待して
いる応答の型とを示す２つの形式もとる。それらはグループアドレスされる（通
常は放送パケット）パケット型および直接にアドレスされるパケット型である。
群アドレスされるパケットはＬｏＧＩ応答を受信することのみができ、一方、直
接アドレスされるパケットは、単一の応答が期待されているために、直接確認応
答パケットすなわちＤＡＣＫパケットを受信する。

【０２１３】 ペイロード・パケットは、パケット内でのペイロードの使用を決定する２つの
別々の部類にさらに分割される。それらは生データ・パケットとＰＬＸコマンド
・パケットである。

【０２１４】 生データ・パケット 生データ・パケット１２００のフォーマットが図９に示されている。それはプ
リアンブル・フィールド１２０１と、長さフィールド１２０２と、長さフィール
ド１２０３と、ｃｔｒｌフィールド１２０４と、宛先アドレス・フィールド１２
０５と、発信元アドレス・フィールド１２０６と、シーケンス・フィールド１２
０７と、認証フィールド１２０８と、ＤＳｋフィールド１２０９と、ＳＳｋフィ
ールド１２１０と、ペイロード・フィールド１２１１と、ＣＲＣフィールド１２
１２とを含む。生データ・パケット１２００はアクティブサーバ・ノードまたは
クライアント・ノードによって送られる。長さフィールド１２０２と、長さフィ
ールド１２０３と、ｃｔｒｌフィールド１２０４と、宛先アドレス・フィールド
１２０５と、発信元アドレス・フィールド１２０６と、シーケンス・フィールド
１２０７と、それから認証フィールド１２０８と、ＤＳｋフィールド１２０９と
、ＳＳｋフィールド１２１０はＭＡＣヘッダ１２１５の構成要素である。ペイロ
ード・フィールド１２１１は適切なペイロード・ハンドラにより調べられるべき
アプリケーション層情報を含む。ホストＰＣおよびＣＡＬインタープリータはペ
イロード・ハンドラの例である。一実施形態では、生データ・パケット１２００
は３バイトのプリアンブル１２０１と、１３〜１５バイトのＭＡＣハンドラ１２
１５と、２５５バイトまでのペイロード部１２１１と、２バイトのＣＲＣ１２１
２とを有する。

【０２１５】 ＰＬＸ（外部）コマンド・パケット ＰＬＸコマンド・パケットは、２つのノードが短いパケット・シーケンスによ
って通信するための手段を提供することにより、媒体１００を介するデータの流
れを容易にするために用いられる。ＰＬＸコマンド・パケットの変形についての
説明を以下に行う。

【０２１６】 トークン・パケット：ＰＬＸトークン・パケット１３００のフォーマットが図
１０に示されており、それはプリアンブル・フィールド１２０１と、長さフィー
ルド１２０２と、長さフィールド１２０３と、ｃｔｒｌフィールド１２０４と、
宛先アドレス・フィールド１２０５と、発信元アドレス・フィールド１２０６と
、ＣＲＣフィールド１２１２とを含む。長さフィールド１２０２と、長さフィー
ルド１２０３と、ｃｔｒｌフィールド１２０４は（１６進）値０_x０５、０_x０５
、および０_x１７をそれぞれ有する。

【０２１７】 トークン・パケット１３００は直接にアドレスされたノードへ送られ、いずれ
のペイロード型パケットも求める。注意を必要としないノードは単にＤＡＣＫす
べきであり（状態フィールドが０ｘ０３にセットされている）、これは、それら
のノードが話すべきなにものも持たず、トークンを使用しないことを意味する。

【０２１８】 クライアント・ノードはアクティブネットワークへ送信する前にトークンを呼
び出すべきである（ＬＩＰプロセスによって）。ノードがこのトークンを用い続
けている限り、アクティブネットワーク・サーバはそれにトークンを送り続ける
。しかし、クライアント・ノードが「使用されていないトークン」応答で繰り返
し応答すると、アクティブネットワーク・サーバはノードを老化させ、それはラ
インアップから外される。

【０２１９】 トークン・パケットは通常のＭＡＣヘッダ（発信元アドレスを差し引いている
）とＣＲＣを含んでいるが、データ・フィールドは用いられない（データ・フィ
ールドのサイズは零である）。トークンは、アドレスを０ｘｆｆｆｆｆｆｆｅに
固定すべきである「アクティブネットワーク・サーバ」から来ることができるの
みである。

【０２２０】 直接確認応答（ＤＡＣＫ）パケット：ＰＬＸトークン・パケット１４００のフ
ォーマットが図１１に示されており、それはプリアンブル・フィールド１２０１
と、長さフィールド１２０２と、長さフィールド１２０３と、ｃｔｒｌフィール
ド１２０４と、宛先アドレス・フィールド１２０５と、状態フィールド１４０１
と、ＣＲＣフィールド１２１２とを含む。長さフィールド１２０２と、長さフィ
ールド１２０３と、ｃｔｒｌフィールド１２０４は（１６進）値０ｘ０６、０ｘ
０６、および０ｘ０７をそれぞれ有する。

【０２２１】 ＤＡＣＫパケットはパケットまたはパケット列の有効な受信に対して確認応答
するために受信ノードにより送られる。ＤＡＣＫパケットは直接にアドレスされ
たメッセージ・パケット（ＬＩＰＤパケットを除き）から戻されるだけである。

【０２２２】 ＤＡＣＫパケットはネットワークにおける２つのノードの間の典型的なハンド
シェイキング・シーケンスを終了させるために用いられ、その結果３つのノード
．．．１）アクティブネットワーク・サーバ、２）要求するノード、３）応答す
るノード、を含む。（要求するノード／応答するノードは、「アクティブネット
ワーク・サーバ」が現在の要求の宛先であるならば、「アクティブネットワーク
・サーバ」とすることもできる）。ＤＡＣＫ状態フィールドはパケットを受信す
るノードの型（アクティブネットワーク・サーバまたはクライアント）に応じて
変化する。要求するノードへ（応答するノードによって）送り返されたＤＡＣＫ
パケットは、要求しているノードへ制御を戻してパケットの流れを継続し、（要
求するノードにより）「アクティブネットワーク・サーバ」へ送り返されたＤＡ
ＣＫパケットは「アクティブネットワーク・サーバ」へ制御を戻して、パケット
の流れの終りを知らせる。要求するノードは、シーケンスまたはＤＡＣＫパケッ
トが受信されていないと、パケットを再度要求する役目を有する。

【０２２３】 ＤＡＣＫパケットは通常のＭＡＣハンドラおよびＣＲＣと、１バイト・ペイロ
ードとを含む。状態フィールドは受信したパケットに関する情報を含み、それは
このフィールド内に戻される。状態フィールド１１０１の値を表Ａ２に示す。

【０２２４】ＤＡＣＫ ノード 摘要 ０ｘ０ 全部 バッファ・フル受信（障害） ０ｘ１ 全部 障害（多チャネル応答） ０ｘ２ サーバ ノードによって用いられるトークン ０ｘ３ サーバ ノードによって使用されないトークン ０ｘ４ サーバ 「覚醒している」要求に応答するトークン ０ｘ９ 全部 プリンタ・シーケンス番号付けエラー ０ｘａ 全部 プリンタ・プラグを抜かれたエラー ０ｘｂ 全部 プリンタ・オフラインエラー ０ｘｃ 全部 プリンタ一般的なエラー ０ｘｄ 全部 紙エラーのプリンタ ０ｘｅ 全部 プリンタの未知のエラー ０ｘｆ 全部 成功 表Ａ２．ＤＡＣＫ状態フィールド１１０１の値

【０２２５】 この情報は実際の媒体１００自体へ送られること、およびホスト・ノードにま
で送られる状態ではないかもしれないことに注目すべきである。ホストに送られ
る状態情報に関するより多くの情報については内部ＰＬＸパケット、Ｔｘ状態に
ついての節を参照されたい。

【０２２６】 ラインアップ挿入パケット（ＬＩＰＤおよびＬＩＰＧ）：図１２はＰＬＸパケ
ット１５００のフォーマットを示すものであって、それはプリアンブル・フィー
ルド１２０１と、長さフィールド１２０２と、長さフィールド１２０３と、ｃｔ
ｒｌフィールド１２０４と、宛先アドレス・フィールド１２０５と、マスク・フ
ィールド１５０１と、ＣＲＣフィールド１２１２とを含む。長さフィールド１２
０２と、長さフィールド１２０３と、ｃｔｒｌフィールド１２０４は（１６進）
値０ｘ０９、０ｘ０９、および０ｘ２３をそれぞれ有する。

【０２２７】 図１３はＰＬＸ ＬＩＰＤパケット１６００のフォーマットを示すものであっ
て、それはプリアンブル・フィールド１２０１と、長さフィールド１２０２と、
長さフィールド１２０３と、ｃｔｒｌフィールド１２０４と、宛先アドレス・フ
ィールド１２０５と、零フィールド１６０１と、ＣＲＣフィールド１２１２とを
含む。長さフィールド１２０２と、長さフィールド１２０３と、ｃｔｒｌフィー
ルド１２０４は（１６進）値０ｘ０９、０ｘ０９、および０ｘ２３をそれぞれ有
する。

【０２２８】 ラインアップ挿入パケット（ＬＩＰ）は「アクティブネットワーク・サーバ」
によって送られて、新規の物が既存のラインアップ・カードに入ることができる
ようにする。これは２つの別々のパケットで行われ、それらのパケットは両方と
も全ての聴取しているノードへ放送される。第１のパケット、すなわちＬＩＰＧ
パケット１５００、はＬＩＰマスク・フィールド１５０１を含む。マスク１５０
１はＬｏＧＩシーケンスで応答する前に遠方のもののアドレスに一致しなければ
ならない。第２のパケット、すなわちＬＩＰＤパケット１６０１は、応答するノ
ードを、それの発信元アドレス（ラインアップ・カードに挿入すべき）を含んで
いるＤＡＣＫパケットで応答させることによって、挿入プロセスを促進するため
に用いられる。

【０２２９】 したがって、ＬＩＰＧパケットはマスクされ、かつＬＩＰマスク・フィールド
内に対応するビット・シーケンスを有する。ノードはＬｏＧＩパケットでＬＩＰ
Ｇパケットに応答しなければならない。同様に、ＬＩＰＤパケットはマスクされ
ておらず、これは、ラインアップ・カードに入ることを望んでいる全てのノード
（これはノードがラインアップ・カードに既に無いことを意味している）もＤＡ
ＣＫで応答すべきであることを意味する。

【０２３０】 ペイロード・パケット・フレーム・フォーマット 下記は、ペイロード型パケット内に存在できる各フィールドについての説明で
ある。これは、生データ・パケット型とＰＬＸコマンド・パケット型の両方につ
いてあてはまる。

【０２３１】 プリアンブル／スタート・シーケンスはパケット・フォーマットの一部ではな
いが、ハードウェアを入来パケットに同期させるキャリヤを検出するため、およ
び現在のパケット内の以後のバイトのビット時間すなわちライン速さを決定する
ために用いられる所定のビット・パターンである。プリアンブルの長さは、ライ
ン上に有効なキャリヤおよび同期化を存在させるために必要な最小量のビット時
間によって決定される。そのプリアンブル１２０１のビット・パターンは 値 シーケンス ０ｘａａ 第１の同期バイト ０ｘ３１ 第２の同期バイト ０ｘｎｎ 速さ／第３の同期バイト である。

【０２３２】 速さ（すなわち第３の同期）バイトは入来するデータ（長さバイト１２０２で
スタートする）の速さを決定するものであって、次のように要約される。

【０２３３】 値 速さ ０ｘ５５ 低速−３５０ｋ ０ｘｄｄ 中速−７００ｋ ０ｘ９９ 高速−１．１９ｍ ０ｘ１１ 予備 最後に、プリアンブルの後に、パケットの長さを記述する２つの重複長さバイ
ト１２０２〜１２０３が続く。それらのバイトは新な速さで来る。

【０２３４】 長さフィールド 長さフィールド１２０２〜１２０３は入来パケットのサイズを示すために用い
られる。長さフィールド１２０２〜１２０３は、有効なパケット受信を決定する
ためにハードウェアにより使用される（キャリヤ検出信号が存在しない中で）。
パケットの長さにひとたび達すると、ＣＲＣフィールド１２１２の妥当性が検査
される。したがって、ＰＬＸパケットの長さは全部で２５６バイト（プリアンブ
ル・フィールド１２０１とＣＲＣフィールド１２１２を含めて）に制限すること
が好ましい。その長さはＭＡＣヘッダ１２１５（制御、アドレス等）と、オプシ
ョンのフィールドと、ペイロード・フィールド１２１１とを含む。

【０２３５】 入来データストリーム（それはプリアンブルの延長として機能する）の有当性
を確実にするために長さフィールドは２つの時間（１２０２、１２０３）に重複
される。長さフィールド１２０２〜１２０３はパケット受信の開始前に相互に（
およびプリアンブル一致）一致しなければならない。

【０２３６】 制御フィールド 上で示したように、ペイロード・パケットは次の２つの主な型：ＰＬＸコマン
ド・パケットまたは生データ・パケット、の１つとすることができる。

【０２３７】 ＰＬＸコマンド・パケットの型は２つの下位型、すなわち外部ＰＬＸ・コマン
ドおよび内部ＰＬＸコマンドにさらに分類される。内部ＰＬＸコマンド・パケッ
トは、ローカル接続（ＵＳＢ、１２３４、直列等）を介するハードウェアとホス
ト・ノード・ドライバとの間のハンドシェイクを指す。外部ＰＬＸ・コマンド・
パケットは、媒体１００アクセスを調整する電源線媒体１００自体上のハンドシ
ェイク・パケットを指す。

【０２３８】 制御フィールド１２０４は図示のようにパケットの型に応じて変化し、各ビッ
トは表Ａ３に示されているように特定の定義のための専用である。

【０２３９】 ビット ＰＬＸ（ＥＸＴ） ＰＬＸ（ＩＮＴ） ＲＡＷ（ＮＯＮ−ＰＬＸ） 0: PACKET＿TYPE(1) PACKET＿TYPE(1) PACKET＿TYPE(0) 1: PLX＿SUBTYPE(1) PLX＿SUBTYPE(0) RAW＿ACK＿TYPE0 2: PLX＿ACK＿TYPE 予備（０） RAM ACK TYPE1 3: 予備（０） 予備（０） 暗号 4: EXT＿SUBTYPE INT＿SUBTYPE ソケット 5: EXT＿SUBTYPE INT＿SUBTYPE 予備（０） 6: EXT＿SUBTYPE INT＿SUBTYPE PID 7: EXT＿SUBTYPE INT＿SUBTYPE 予備（０） 表Ａ３．制御フィールド１２０４内のビット。

【０２４０】 パケット型 パケット型ビットは、所与のパケットがＰＬＸの型か生データの型か、または
非ＰＬＸの型かを示すために用いられる。ＰＬＸプロトコル要求は異なって取り
扱われ、かつほとんどの場合にマイクロコントローラファームウエアによって取
り扱われ、生データ・パケットは別々のアプリケーション・ソフトウエアすなわ
ちホスト・ソフトウエアにより通常取り扱われるので、制御フィールド内で区別
を行うと都合が良かった。生データ・パケットは、適切なアプリケーション・ソ
フトウエアに渡すべき生ペイロード情報を通常含んでいる。この場合の例外は、
マイクロコントローラ内のインタープリータの一部と、ホスト・マシン内の一部
を含んでいるＣＡＬパケットである。

【０２４１】 ビット パケット型 １ ＰＬＸコマンド・パケット＝１ ０ 生データ・パケット＝０ ＰＬＸ副パケット型 ＰＬＸコマンドは２つの形式の１つで通常来る。第１の形式は他のノードによ
るワイヤからの要求であり、第２の形式はワイヤへは進まないホストからの要求
である。マイクロコントローラファームウエアはそれら２つの型に対する応答を
弁別し、かつ２つの型は相互に完全に別個なので、このビットが作成されたもの
である。

【０２４２】 ビット１ ＰＬＸ副パケット型 １ 外部ＰＬＸコマンド・パケット＝１ ０ 内部ＰＬＸコマンド・パケット＝０ ＰＬＸ ＡＣＫ型 トークン・コマンド・パケットおよびＤＡＣＫコマンド・パケットはアクセス
権を媒体１００へ転送するために用いられ、「アクティブネットワーク・サーバ
」が媒体１００の制御を他のノードへ一時的に放す場合にシーケンスを終了する
。他の２つのＰＬＸコマンド・パケット、ＬＩＰＧとＬＩＰＤ、は応答パケット
を求める。応答型は型ＬｏＧＩまたは型ＤＡＣＫのいずれかである。このビット
はどの型の応答をノードが利用すべきであるかを決定する。

【０２４３】 ビット２ ＰＬＸ ＡＣＫ型 １ ＤＡＣＫ＝１での応答 ０ ＬｏＧＩ＝０での応答 ＰＬＸ副パケット外部型 ＰＬＸの仕様は、集中化された（サーバが仲裁されたトークン）トークン・パ
ッシング・システム内の２つのノードの間の接続なしの、確認応答されたデータ
転送指すおよび確認応答されなかったデータ転送サービスを提供する。それらの
ビットによってこの通信が行われることが可能になる。

【０２４４】 アクティブネットワーク・サーバは、クライアントが送信を開始できる前に指
令されたトークンを媒体１００に置く。クライアント・ノードが媒体１００に対
するアクセス権を、ＤＡＣＫ応答パケットがアクティブネットワーク・サーバ・
ノードへ戻ることを指令された状態で終了する。アクティブネットワーク・サー
バは、クライアント・ノードをポーリングする時にアクティブノードのラインア
ップ・カードを維持する。ラインアップ・カードに載せるために、クライアント
・ノードは指令されたＬＩＰ要求（ＬＩＰＤ）または群ＬＩＰ要求（ＬＩＰＧ）
のいずれかに適切に応答する。

【０２４５】 ラインアップ・カードにおいて１旦、ノードがポールされ、かつペイロード情
報を、確認応答された形式または確認応答されない形式で持っているパケットを
それらのノードは送受信できる。下記は媒体１００において許された有効なＰＬ
Ｘ副パケット外部型の表である。

【０２４６】 ビット（７、６、５、４） バイト値 パケット副型 ０ ０ ０ ０ ０ｘ０７ ＤＡＣＫ ０ ０ ０ １ ０ｘ１７ トークン ０ ０ １ ０ ０ｘ２７ ＬＩＰＤ ０ｘ２３ ＬＩＰＧ その他 予備 注：ＤＡＣＫ／ＧＡＣＫが所定の間隙間間隔要件内の要求しているノードによ
り受信されない場合、送信（要求または応答している）ノードがその要求（応答
）を再試行する責を負う。

【０２４７】 ＰＬＸ副パケット内部型 ＰＬＸ仕様によってプロトコルの一部分が、ＰＣなどのホスト・ノードに存在
できる。ホスト・ノードは、それが物理的に接続されている、取り付けられたノ
ードに関する情報をアクセスすることを周期的に必要とする。これは、取り付け
られているノード上のためであり、かつ遠方のノードへ送られるように通常はワ
イヤに置くべきでないため、内部ＰＬＸ要求として知られている。下記は可能な
内部ＰＬＸ副型についての記述である。

【０２４８】 ビット（７、６、５、４） バイト値 パケット副型 １ １ １ １ ０ｘｆ１ エラーハンドシェイク ０ ０ ０ １ ０ｘ１１ ＣＡＬ要求 ０ ０ １ ０ ０ｘ２１ ＣＡＬ応答 ０ ０ １ １ ０ｘ３１ Ｔｘ状態 １ １ ｘ ｘ 予備 内部副型はホストから送られ、ハードウェアによって消費され、それから適切
な応答がホスト・ノードへ送り返される。内部パケットは媒体１００へ決して送
られない。したがって、このパケット型はペイロード・パケット節では定められ
ておらず、ＰＬＸ（内部）ホスト・パケットの下で定められた節にある。

【０２４９】 生ＡＣＫ型 生ＡＣＫ型はどの型の応答が現在の生データ・パケットにに続かなければなら
ないかを指定する。応答型は４つの形式、すなわち、バースト（応答なし）、二
重ＬｏＧＩ、ＬｏＧＩ、およびＤＡＣＫ、のうちの１つをとる。

【０２５０】 バースト型は説明を必要とせず、パケットは次々に送られる。バースト・シー
ケンスの最後のパケットには異なる確認応答型が割り当てられる（バースト・シ
ーケンスを終了するために、応答が用いられる）。

【０２５１】 二重ＬｏＧＩシーケンスによってグループ要求すなわち放送要求を送ることが
可能になる。ノードがパケットをバッファできない場合、それは最初の間隙間間
隔内で応答し、それがパケット正しく受信さしてパケットを解析すると、遅延さ
れた間隙間間隔中にそれは応答する。

【０２５２】 ＬｏＧＩ応答は単一のノードへ向けられ、それは応答のための最も効率的な機
構である。ＬｏＧＩパケットの長さは帯域幅に関して最も効果的であるが、応答
についての非常に多くの情報を含むことはできない。

【０２５３】 ＤＡＣＫ応答は特定のノードへ向けられるが、応答内に、ＬｏＧＩ型よりもは
るかに多くの情報を含むことができる。

【０２５４】 ビット（２、１） パケット副型 ０ ０ バースト ０ １ 二重ＬｏＧＩ １ ０ ＬｏＧＩ １ １ ＤＡＣＫ

【０２５５】 暗号 暗号ビットによってパケットの内容を、認証バイトからスタートして、暗号化
できる。１つの暗号化法が２５６ビットＤｉｆｆｉｅ−Ｈｅｌｌｍａｎハンドシ
ェイクを用いて鍵の変更をこなうことができ、その後で、秘密の３２バイト・ア
レイが媒体１００を通じて確実に送られる。その後のトランザクションは確実な
通信のために暗号化アレイを使用できる。

【０２５６】 ビット ３： 暗号 現在のパケットが暗号化される＝１ 現在のパケットが暗号化されない＝０

【０２５７】 ソケット 通常ＰＬＸ生データ・ペイロード・パケットが下記のフィールド・サイズで構
成される。

【０２５８】 フィールド 長さ プリアンブル １２０１ ３バイト 長さ １２０２、１２０３ ２バイト 重複している 制御 １２０６ １バイト 宛先アドレス １２０５ ４バイト 発信元アドレス １２０６ ４バイト ペイロード １２１１ ０〜２５５バイト ＣＲＣ １２１２ ２バイト 同じノードに多数のアプリケーションが存在している場合、特定のノード・ア
ドレス内の適切なアプリケーションへパケットを送れるようにする機構が用いら
れる。それらの型のアプリケーションはソケット・フィールドを使用する。第１
のバイトは宛先ソケット・アドレスであり、第２のバイトは発信元ソケット・ア
ドレスである。したがって、このビットを設定することにより、ＭＡＣヘッダの
サイズが２倍になる。このフィールドは、実施された時は、認証バイトの直後に
あり、下記のビットがセットされると含まれる。

【０２５９】 ビット ４ ソケット １ ソケット・フィールドを含む ０ ソケット・フィールドを含まない

【０２６０】 プロトコルＩＤ（ＰＩＤ） 各パケットは、ＩＰＸ、ＴＣＰ／ＩＰ、またはＣＡＬなどのより高いレベルの
プロトコルによって解析できる情報を含む。ＰＬＸは、ネットワークを横切って
送信／受信すべきそれらの型のパケットを入れるトランスポートとして単に用い
られる。通常は、より高いレベルの解析ルーチンがホスト・システムに存在する
が、最小セットのハードウェアはＣＡＬ解析機能を含むことが要求される。した
がって、ハードウェアはＣＡＬ要求を解析し、適切なペイロード取扱いルーチン
までの他の全ての要求を送る。プロトコル情報の中にはハードウェア（たとえば
、ＲＯＭ、フラッシュメモリ等）内に配置できるものがあり、他のプロトコル情
報はホスト・ノードにより解析される。このビットは、ハードウェア・プロトコ
ル・ハンドラがこのパケットの解析を開始することを要求されているか否かを決
定する。

【０２６１】 ビット ６ プロトコル ＩＤ（ＰＩＤ） １ プロトコルＩＤが存在する（マイクロ解析） ０ プロトコルＩＤが存在しない（生−ホスト解析） 生パケットは、データの最初のバイトがその型のプロトコルのバイト−コード
ではなく、その代わりにプロトコル・ヘッダ自身の最初のバイトであることを意
味する。ＰＩＤ解析可能なパケットは最初のバイト−コードを復号してどのプロ
トコルがそのパケットを解析すべきかを決定する。

【０２６２】 下記はＰＩＤビットがセットされた時に利用できるオプションである。１番目
のデータバイトは現在のパケットを解析するのに必要なプロトコルの型を表して
いる。バイト値 定義 型 ０ｘｆｆ 予備 ｎ／ａ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ０ｘｆｅ 完成されたパケット ｃｅｂｕｓＲｅｓｐ ０ｘｆｄ 正しくないパケット ｃｅｂｕｓＲｅｓｐ ０ｘｆｃ エラーパケット ｃｅｂｕｓＲｅｓｐ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ０ｘｄｆ〜０ｘｆｂ 予備 ｎ／ａ −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− ０ｘａ０〜０ｘｄｅ コンテキスト番号（ＣＡＬ） ｃｅｂｕｓＣｍｄ ０ｘ９ｆ 予備（ＣＡＬ） ｃｅｂｕｓＣｍｄ ０ｘ００〜０ｘ９ｅ コンテキスト・クラス（ＣＡＬ）ｃｅｂｕｓＣｍｄ

【０２６３】 宛先アドレス・フィールド 宛先アドレス１２０５は現在のパケットの宛先ノードを含む。

【０２６４】 あるノードがある要求を持っているか、他のノード要求に対して応答している
とき、それは、応答パケットの宛先のノードのアドレスを宛先アドレス・フィー
ルド１２０５内に置く。そのノードがアクティブネットワーク・サーバまたはデ
ータベース・サーバと通信できるだけであるならば、それはそのアドレスを宛先
アドレス・フィールド１２０５内に置く。さもなければ、宛先アドレスは要求し
ているパケットの発信元アドレス・フィールド１２０６から通常得られる。

【０２６５】 あるＰＬＸアドレスは周知である。それら周知のＰＬＸアドレスのリストが以
下に示す。アドレス 摘要 0x00000000〜0xffffffef 有効で独自のノード・アドレス 0xfffffff0〜0xfffffffc 予備 0xfffffffd アプリケーション・サーバ・ノード・アドレス 0xfffffffe アクティブネットワーク・サーバ・ノード・アドレス 0xffffffff ノード・アドレス放送

【０２６６】 発信元アドレス・フィールド 発信元アドレス１２０６は現在のパケットのノードのアドレスを含んでいる。
ノードが要求を持っているか、他のノード要求に対して応答していると、それは
それ自身のノード・アドレスを発信元アドレス・フィールド１２０６内に置く。
ノード・アドレスはノードの型と組合された８バイトＧＵＩＤの一部を用いて、
４バイトのノード・アドレスを作成する。ＧＵＩＤからの最下位から７桁目のニ
ブル（Nibble）が用いられ、ノード型がノード・アドレスの最上位のニブル（８
番目のニブル）に重ね書きする。

【０２６７】 例： Ｉｆ．．． ＧＵＩＤ＝０ｘ０１２３４５６７８９ＡＢＣＤＥＦ Ａｎｄ Ｎｏｄｅ Ｔｙｐｅ＝０ｘ０３ Ｔｈｅｎ．．． Ｓｏｕｒｃｅ Ａｄｒｅｓｓ＝０ｘ３９ＡＢＣＤＥＦ Ｅｎｄ Ｉｆ

【０２６８】 シーケンス番号フィールド シーケンス・フィールド１２０７は、媒体１００で伝送されるより小さいパケ
ットに分けられたデータ・パケットまたはデータ・シーケンスを再構成すなわち
再組立てする能力をホスト・アプリケーションに与える。二重シーケンス番号は
捨て去ることができ、受信されなかったシーケンス番号は再び送ることができる
。シーケンシングによってより大きいデータ流に対してデータを完全なものにす
る。シーケンス・フィールド１２０７内に置かれた値はアプリケーションに依存
し、所望により他の目的に使用できる。

【０２６９】 認証フィールド 認証フィールド１２０８によって、各パケットの受信完了前に各パケットの有
効性を確認できる。認証フィールド１２０８は、暗号化アレイの初めの２バイト
に対して排他的オア操作を行うことによって通常シード（ｓｅｅｄ）される．し
たがって、安全システム内の全てのノードには同じ認証値がシードされ、それら
の全てはこの検証手続きを受けなければならない。完全性を高めるために認証フ
ィールドはさらに暗号化される。

【０２７０】 ペイロード・フィールド データ・ペイロード・フィールド１２１１は受信ノードに情報を提供するため
に用いられる。ペイロード・データの第１のバイトは内容をどのようにして解析
するかを決定するバイト・コードを含むことができる。データのこの最初のバイ
トは初めに説明した生ビットとともに用いられる。

【０２７１】 周期的冗長検査（ＣＲＣ）フィールド 周期的冗長検査（ＣＲＣ）フィールド１２１２は、送信されたパケット内に信
頼性のある誤り検出技術を用意するために用いられる。終了した時にそれは再評
価され、認証のために比較される。この検査を通らなかったパケットは捨てられ
る。

【０２７２】 ＣＲＣアルゴリズムは、不当なオーバーヘッド（ソフトウエアおよびハードウ
ェアにおける）なしに、所望の信頼度レベルを得るように、十分効率的かつ簡単
であるように選択される。送信されたパケットと受信されたパケットとに対する
実行中のＣＲＣ計算を行えるに十分速いＣＲＣアルゴリズムを提供することが望
ましい。

【０２７３】 実行中計算（ビットまたはバイトが受信されたときに、全部のパケットが来る
ことを待っている代わりに、ＣＲＣが更新される。同じことが送信についてもあ
てはまる）は強制的ではないが、システムの全体のスループットおよび性能を高
めるのに役立つ。

【０２７４】 一実施形態では、Ｇ（ｘ）＝ｘ16＋ｘ15＋ｘ11＋ｘ8＋ｘ6＋ｘ5＋ｘ4＋3＋ｘ ＋１によってＧ（ｘ）が与えられる。

【０２７５】 ＰＬＸ（内部）ホスト・パケット ＰＬＸ内部ホスト・パケットは媒体１００には決して到達しないので、パケッ
トについての説明ははるかに簡単にみえる。プリアンブル１２０１は必要とされ
ず、また重複長さフィールド１２０２、１２０３と、アドレッシング・フィール
ド１２０５、１２０６も必要とされず、かつＣＲＣフィールド１２１２も必要と
されない。図１４は、長さフィールド１７０１と、制御フィールド１７０２と、
データ・フィールド１７０３とを含むＰＬＸ内部ホスト・パケットのフォーマッ
トを示す。データ・フィールド１７０３は制御フィールドが指定したいかなるも
のも含む。制御フィールドの以前の定義（それはＰＬＸ内部ホスト・パケットに
も同様に適用される）に示されているように、ハードウェアとホスト・ノードの
間を通り、トラフィックの流れを容易にするいくつかのパケットが存在する。以
下は各型のパケットの定義である。

【０２７６】 ＣＡＬ要求パケット 図１５はＣＡＬ要求パケット１８００のフォーマットを示す。それは長さフィ
ールド１７０１と、制御フィールド１７０２と、ＣＡＬデータ・フィールド１８
０３とを含む。制御フィールド１７０２は値０ｘ１１を有する。

【０２７７】 ＣＡＬ要求パケット１８００は、ハードウェア上に存在するＣＡＬ情報を取っ
てくるために、ホストによってハードウェア・ノードへ送られる。ＰＬＸノード
はアプリケーション・コードを有することができ、またはホスト・プロセッサが
ハードウェア／ＡＳＩＣから分離されているために、ＣＡＬ情報はそれら２つの
別々のプロセッサを越えて拡がることもできる。したがって、ホスト・プロセッ
サはＣＡＬ情報を取り付けられているノードから周期的に集める。

【０２７８】 ＣＡＬ応答パケット 図１６はＣＡＬ応答パケット１９００のフォーマットを示すものであって、長
さフィールド１７０１と、制御フィールド１７０２と、ＣＡＬ応答フィールド１
９０３とを含む。制御フィールド１７０２は値０ｘ２１を有する。

【０２７９】 上で述べた理由と同じ理由から、ＣＡＬ応答パケットはハードウェア・ノード
から取り付けられているノードへ送られる。この応答パケット１９００は先行す
るＣＡＬ要求パケット１５００に応答して送られる。

【０２８０】 Ｔｘ状態パケット（単一チャネル、スピード） 図１７は単一チャネルＣＡＬ応答パケット２０００のフォーマットを示すもの
であって、長さフィールド１７０１と、制御フィールド１７０２と、データフィ
ールド１９０３とを含む。制御フィールド１７０２は値０ｘ２１を有する。図１
８は多チャネルＣＡＬ応答パケット２１００のフォーマットを示すものであって
、長さフィールド１７０１と、制御フィールド１７０２と、データフィールド２
１０３とを含む。制御フィールド１７０２は値０ｘ３１を有する。

【０２８１】 Ｔｘ状態パケットの形式は２つある。１つの形式は単一チャネル、単一スピー
ド・アプリケーションのためのものであって、制御バイト値０ｘ２１を用いる第
２の形式は多チャネル、多スピード解決のためのものであって、０ｘ３１の制御
バイトを使用する。

【０２８２】 単一チャネル、単一スピード解決は使用できるただ２つのＴｘバッファを有し
、それら２つのＴｘバッファの状態は内部ＰＬＸハンドシェイクによってホスト
・ノードへ周期的に送り返される。それらのＴｘ状態パケットの目的は、ホスト
・ノードからハードウェアに渡された未解決の送信事象に関するループを閉じる
ことである。しばしば、ＤＡＣＫパケット内の戻された同じ値が、この送信事象
に関する情報のためにホストに渡されるが、多くの時にはＤＡＣＫは外部ＰＬＸ
事象に渡され、その場合には、ＤＡＣＫ値はホスト・ノードに渡してはならない
。ホスト・ノードが送信要求を生じた時にＤＡＣＫ値はホスト・ノードに送り返
される。

【０２８３】 したがって、ＰＬＸは下に示す複製されたＤＡＣＫ状態値を使用する。

【０２８４】 媒体上で見られるＤＡＣＫ状態フィールド値 ０ｘ０＝バッファ・フル受信（失敗） ０ｘ２＝ノードにより用いられるトークン（ホストへ送られない） ０ｘ３＝ノードにより用いられないトークン（ホストへ送られない） ０ｘ４＝「覚醒」要求に応答するトークン（ホストへ送られない） ０ｘ９＝プリンタ・シーケンス番号付けエラー ０ｘａ＝プリンタ・プラグを引き抜かれたエラー ０ｘｂ＝プリンタ・オフラインエラー ０ｘｃ＝プリンタ一般的なエラー ０ｘｄ＝プリンタ紙エラーなし ０ｘｅ＝プリンタ不明エラー ０ｘｆ＝成功 ０ｘ９から０ｘｅまでの値はプリンタ・ノードからのＤＡＣＫ応答である。プ
リンタ応答値はホスト・ノードへ修正されずに返される。

【０２８５】 値０ｘｆはうまくいったＤＡＣＫ応答であって、ホストが要求を出ると、この
値もホスト・ノードへ修正されずに返される。

【０２８６】 値０ｘ２から０ｘ４は外部ＰＬＸコマンド・パケットへのＤＡＣＫ応答値であ
って、ホスト・ノードまで渡してはならない。

【０２８７】 唯一の奇妙な状態値は０ｘ０であり、これはワイヤ上で受信中のノードがビジ
ーであり、パケットを受取ることができないことを意味する。ハードウェアはこ
の状況を認識し、指定された（それがビジーでない時よりもしばしば）このパケ
ットを再び試みる。受信するノードが異常に長い時間ビジー状態に留まっている
と、パケットは最後に中断され、「失敗−０ｘｆ」応答状態がホスト・ノードへ
送り返される。ホスト・ノードへ送り返された０ｘ０の値は何も意味しない。そ
れは完了しなかった送信事象のデフォールト値であり、ホストは非零状態がその
フィールド内に置かれるまで待つ。０ｘ１の値はワイヤに決して戻されない。ノ
ードが間違ったデータを持つパケットをノードが受信すると、ノードは単にその
パケットに応答せず、送信ノードはそれを再送信することを要求される。送信パ
ケットが時間切れとなりそれの最大再試行数になったとき０ｘ１の値がホストに
戻されるだけである。

【０２８８】 下記は、ホスト・ノードへ通常戻されるＴｘ状態値を示す表である（値はあら
ゆる場合にＤＡＣＫ応答値と同一でないことに注意されたい）。

【０２８９】 Ｔｘ状態データ・フィールド値 ０ｘ０＝このＴｘバッファのためのＴｘ状態なし ０ｘ１＝失敗（Ｔｘ時間切れまたは受信バッファ一杯） ０ｘ９＝プリンタ・シーケンス番号付けエラー ０ｘａ＝プリンタ・プラグを引き抜かれたエラー ０ｘｂ＝プリンタ・オフラインエラー ０ｘｃ＝プリンタ一般的なエラー ０ｘｄ＝プリンタ紙エラーなし ０ｘｅ＝プリンタの未知のエラー ０ｘｆ＝成功 これは続くＤＡＣＫ情報が内部Ｔｘ状態パケットを介してホスト・ノードまで
渡されないことを意味する。

【０２９０】 ホストに与えられていない追加のＴｘ状態Ｉｎｆｏ ０ｘ０＝受信バッファ一杯（失敗） ０ｘ２＝ノードによって用いられるトークン（ホストへ送られない） ０ｘ３＝ノードによって用いられないトークン（ホストへ送られない） ０ｘ４＝覚醒要求に応答するトークン（ホストへ送られない） Ｔｘ状態バイトは各部分がニブル幅である２つの部分にさらに分けられ、２つ
のＴｘバッファ状態を現す。Ｔｘ状態フィールド中の値をそれぞれの意味と共に
以下に示す。

【０２９１】 Ｔｘ状態値の例 ０ｘ０ｆ＝送られることに成功した最初のＴｘバッファ ０ｘ０ｆ＝送られることに成功した２且目のＴｘバッファ ０ｘｆｆ＝両方のＴｘバッファが送られることに成功した ０ｘ１ｆ＝２番目のＴｘバッファは失敗し、最初のＴｘバッファは成功 等．．．

【０２９２】 Ｔｘ状態パケット（多チャネル、スピード） Ｔｘ状態パケットの第２の形式は多チャネル、多スピードの解決策のためのも
のである。単一チャネルＴｘ状態パケットに関する以前の説明の全体と、それが
ＤＡＣＫ値にどのように関連するかは、いぜんとしてあてはまる。違いは、多チ
ャネル／スピードＴｘ状態パケット内に含まれているデータ情報の量である。そ
のパケットは存在する各チャネルに対して以前に定められた単一の状態バイトを
基本的に含む。結果は各バイトが２つの別々のＴｘバッファを有する単一のチャ
ネルを表している多数のデータ・バイトである。

【０２９３】 パケット・タイミング、間隔取りおよび再試行 媒体１００上で送信のために提示された全てのパケットは厳密なタイミング要
件を守らなければならない。それらのタイミング要件は、システムが円滑かつ衝
突なしに動作できるようにする諸規則である。それらの規則を守ることは正しい
動作のために厳密に実行されねばならない。

【０２９４】 正常な動作の下では、「アクティブネットワーク・サーバ」がシステム上に存
在し、媒体１００をアクセスするためにアクティブノードの全てを調停しなけれ
ばならない。以下の仮定は媒体１００に存在するそのようなアクティブ状態に適
用される。媒体１００上でのインアクティブは、各ノードが睡眠状態にあり、し
たがって、「アクティブネットワーク・サーバ」として主張する前に正常な「聴
取」プロセスを通らなければならない。

【０２９５】 さらに、ＰＬＸシステムは確認応答されるハンドシェイク・シーケンスを特徴
とする。確認応答パケットは指定された時間間隔内に戻されるようになっている
。確認応答（ＤＡＣＫ、ＬｏＧＩ、または二重ＬｏＧＩ）パケット以外のいかな
るものでも送信する前にトークン・パケットは要求される。アクティブネットワ
ーク・サーバはトークン、またはＬＩＰパケットを送信する権利を有するノード
のみである。クライアント・ノードはペイロード・パケットおよび確認応答パケ
ットを送信するのみである。

【０２９６】 典型的なパケット・タイミング 図１９はパケット・タイミングと間隔決定を示すタイミング図である。パケッ
ト時刻は第１の基準時刻２２０２および第２の基準時刻２２０４に関連して定め
られる。第２の基準時刻は、５０μｓ（マイクロ秒）の平均パケット間間隙（Ｉ
／Ｇａｐ）だけ第１の基準時刻に遅れている。

【０２９７】 上で示した図は６５０ｋｂｐｓで動作するシステムのためのタイミングをとっ
ている。間隙間タイミング以外の全ての値は表Ａ４に与えられているようにして
調整すべきである。表Ａ４では上付き数字１は第１の基準２２０２を基準にした
時間を示し、上付き数字２は第２の基準２２０４を基準にした時間を示す。

【０２９８】 ３５０kbps ７００kbps １．２mbps １．４mbps Min Ｉ/Gap1 １５μｓ １５μｓ １５μｓ １５μｓ AvgI/Gap1 ５０μｓ ５０μｓ ５０μｓ ５０μｓ プリアンブル １３０μｓ ６５μｓ ３８μｓ ３３μｓ loGI Packet2 １４０μｓ ７０μｓ ４０μｓ ３５μｓ DLogI Packet2 １８５μｓ ９２μｓ ５４μｓ ４６μｓ DACK Packet2 ３３５μｓ １６８μｓ ９８μｓ ８４μｓ TxRetry LoGI1 ２０５μｓ １０３μｓ ６１μｓ ５２μｓ TxRetry DACK1 ４００μｓ ２００μｓ １１７μｓ １００μｓ TxRetry LoGI1 ３２０μｓ １６０μｓ ９４μｓ ８０μｓ インタートークン1 ３＋ｍｓ ３＋ｍｓ ３＋ｍｓ ３＋ｍｓ 表Ａ４．パケット・タイミング

【０２９９】 正常な条件の下では、典型的なパケット・タイミングは、パケットを受信して
いるノードを所定の長さの時間内に応答することを必要とする。この応答時間は
、ＬｏＧＩ／二重ＬｏＧＩ確認応答パケットを除く全てのパケットで同じである
。したがって、パケット・タイミングの２つのケースは１）ＬｏＧＩ／二重Ｌｏ
ＧＩシーケンスと２）他の全ての応答である。

【０３００】 他のパケット・タイミング ノードは、応答パケットを要しないバースト・パケットおよび確認応答パケッ
トを除くパケットを、ペイロード・パケットを生じたノードへ、ある時間内に、
送り返す。応答パケットは型：ＤＡＣＫパケット、ＬｏＧＩパケット、またはペ
イロード・パケットにできる。

【０３０１】 応答パケットは上で図１９に示されている間隙間間隔要求に追従する。最短応
答時間は通常５マイクロ秒より長く、最長応答時間は通常５０マイクロ秒を超え
てはならない。

【０３０２】 送信ノードが前回の送信の確認応答を受信しないと、配信信頼度を高くするた
めに再試行プロセスを開始しなければならない。この再試行プロセスは最長の可
能な確認応答シーケンスまたはＤＡＣＫパケットの長さプラス最も広い可能な間
隙間間隔の後で、または３５０ｋｂｐｓで約４００マイクロ秒の後で通常始まる
。

【０３０３】ノードに特有の情報 各ノードはその特定のノードを特徴付けるある量の情報でもって構成されるよ
うになる。ＰＬＸノードはシステムで完全に機能するためにこの最少量の情報を
要する。

【０３０４】 固有の識別、アドレス指定可能性、および大域的に固有な識別（ＧＵＩＤ） ＰＬＸノードが電気装置に差し込まれると、そのノードはただちに動作できる
状態になる。各ノードは一連番号が焼き付けられて来る。その一連番号のうちの
下位の２８ビットはそのノードの実行時間アドレスとして使用される。これは大
域的な固有性を確保せず、衝突するアドレスを有する２つのノードを見付ける貴
方の機会は２億６千８百万に１回であるので、それは衝突の可能性を制限する。
このより大きい実行時間アドレスはスループットを僅かに減少させるが、システ
ムを簡単にして（ノードは工場から予め組み立てられて出荷されるためである）
、プラグ−アンド−プレイ性能を高くし、かつ使用を容易にする。

【０３０５】 ユニバーサル・コンテキストおよびノード輪郭オブジェクト ＣＥＢｕｓ／一般的ＣＡＬコンプライアント・ノードは、最低限、ユニバーサ
ル・コンテキストおよびノード制御オブジェクトを有し、それに変数例（ＩＶｓ
）が組合わされている。ＰＬＸはＣＥＢｕｓ／一般的ＣＡＬが定めた報告条件お
よびアドレス指定からそれる（両方とも、ＣＥＢｕｓ／一般的ＣＡＬピアツーピ
アアーキテクチャとは異なって、ＰＬＸクライアント／サーバ・アーキテクチャ
に関連している）。したがって、ＰＬＸはユニバーサル・コンテキスト／ノード
制御オブジェクトを、ＩＶ記述が僅かに異なるノード輪郭オブジェクトとして再
構成する。また、各ＰＬＸコンプライアント・ノードはノード制御オブジェクト
に組合わされた変数例を含む。

【０３０６】 各ノードは、識別する所定の属性セットを含む責任を負い、一般に知られてい
る属性を持つノード型群内にノードを置く。各ノードに対するノード輪郭オブジ
ェクト情報はノード内の不揮発性メモリにハードコードされる（ｈａｒｄ−ｃｏ
ｄｅｄ）ことが好ましい。ノード輪郭オブジェクトは変数例のリストで構成され
ている。各ＰＬＸノードは、下の表Ａ５に示されているユニバーサル・コンテキ
スト（０ｘ００）と、ノード輪郭オブジェクト（０ｘ０１）と、指定された変数
例（ＩＶ）とを少なくとも含む（ここにＲ／Ｗは読出し／書込みを示す）。

【０３０７】

【表１】

【０３０８】

【表２】 下の表Ａ６は記憶されて、管理され、「アプリケーション・サーバ」により保
持されて、アプリケーション・サーバ内のデータベースに存在するクライアント
ＩＶｓを示すものである。したがって、クライアントはそれらのＩＶｓに関する
情報の蓄積および提供に関わる必要はない。

【０３０９】 また、マスタ・ケースのみに対するユニバーサル・コンテキストの部分は、Ｃ
ＡＬにより定められたデータ・メモリ・オブジェクトを使用する規則オブジェク
ト（０ｘ０３）、および我々の目的のために定められたある固有のＩＶｓである
。下記はこの特定のオブジェクトの記述である。

【０３１０】

【表３】 規則オブジェクトによって遠隔ノードを、加え（跡継ぎ）、削除（跡継ぎしな
い）、および規則リスト内の規則を見る（アレイを獲得する）ことができるよう
にされる。

【０３１１】 ユニバーサル・コンテキストを提供することにより、ネットワークはノード・
リストを含むことができる。ノードはコンテキスト・リストを含むことができる
。ノードは各コンテキストごとにオブジェクト・リストを有することができる。
オブジェクト・リストが与えられると、ノードは特定の例変数を含むこともでき
る。それらのリストの多くは一般的なＣＡＬ仕様（ネットワーク・リストおよび
ノード・リスト以外）内で指定される。

【０３１２】 要求されると、ノードは、ノードの特定の構成について上で示したノード輪郭
の特定の部分で応答する。ノード輪郭によって、当該ネットワーク内で固有であ
る特定のノードを自動構成する手段を得ることができる。重複ノードが、一意に
特定されるようにするために、他のレベルの構成を行うことができる。

【０３１３】 安全 安全は２段階法により実現される。最初に、ネットワーク上で電源を投入され
た各ノードが公衆ネットワーク内に直ちに置かれる。公衆ネットワークは全ての
ノードに対するデフォールト・ネットワーク割り当てであって、他の全ての公衆
ノードが利用でき、それの認証ＩＤがＮＵＬＬに割り当てられる。下記の鍵交換
プロセスによってノードが安全になったら、それの認証ＩＤは暗号化アレイによ
り指示された値に変化する。各ノードがこの私用／安全ネットワークに割り当て
られると、それらに３２バイトの暗号化アレイが与えられ、それから以後のパケ
ットを暗号化し、または解読する。これはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎとして
知られている鍵交換技術で行われる。効率的な指数関数的アルゴリズムを用いる
と、鍵交換に用いられている値の計算に必要な時間が減る。暗号化アレイがネッ
トワークの各ノードのメモリ内にひとたび記憶されると、暗号化と解読とが行わ
れる。一実施形態では、暗号化と解読は、帰還を含む排他的論理和を基にした流
れ暗号化技術を使用する。たとえば、ＤＥＳ、ＲＣ４、ＭＤ５等を含む他のアル
ゴリズムを使用できる。

【０３１４】追加の諸特徴 報告条件仕様 ＰＬＸの下では報告条件はそれがＣＡＬの下におけるものとは異なったやり方
で取り扱われるので、規則を取り扱うＰＬＸ法をここで示すことにする。それら
の交換は、厳密なＣＡＬ報告条件方法内で固有の制約の多くをアドレスするため
に実行された。違いを下の表Ａ７で示す。

【０３１５】 ＣＥｂｕｓ ＣＡＬ ＰＬＸ １ オブジェクト当りの規則 オブジェクト当りの多くの規則 １ オブジェクト当りのアクティブＩＶ オブジェクト当りのアクティブな 多数のＩＶＳ 簡単な規則のみ 簡単な規則および複雑な規則 堅い規則 融通性のある規則 表Ａ７．一般的なＣＡＬに対するＰＬＸの諸利点

【０３１６】 一般的なＣＡＬの下における分布された規則とは逆に、ＰＬＸ規則はサーバに
存在しているので、ＰＬＸの単一の強力なエンジンによってＰＬＸはそれが諸規
則をどのように取り扱うかにおいてより強力である。これはどのようなＩＶ変更
でもその通りである。サーバがＩＶ変更を見ると、サーバは変更された特定のオ
ブジェクト／ＩＶ組合わせを調べ、サーバはそれの規則リストを調べ、そしてサ
ーバは各規則の有効性を試験する。したがって、下記の２つのＩＶｓを含むよう
に各オブジェクトは構成され、それは作成された各規則を、指定されたオブジェ
クトおよび下に掲げた関連するＩＶに対して取り扱う。

【０３１７】 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ ＩＶ Ｒ／Ｗ 型 名称 コンテキスト機能 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿ Ｒ Ｒ／Ｗ ｄ ｒｕｌｅｓ＿ａｒｒａｙ マスターズ規則リスト（規則 オブジェクト）内にインデック スのポインタのアレイを含む。 各エントリは、このオブジェク ト内のＩＶが変更された時に 完全な規則を試験することを 意味する。 Ｐ Ｒ／Ｗ ｎ ｎｕｍｂｅｒ ｏｆ ｒｕｌｅｓ規則アレイ内の規則 の数を含む。 ＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

【０３１８】 実際のｒｅｐｏｒｔ＿ｈｅａｄｅｒ、およびｒｅｐｏｒｔ＿ａｄｄｒｅｓｓ，
ｒｅｐｏｒｔ＿ｃｏｎｄｉｔｉｏｎ、およびｐｒｅｖｉｕｓ＿ｖａｌｕｅ変数は
、アレイにより指された規則内におのおの保持される。読出しルーチンはこのポ
インタ（またはインデックス）を単に規則エンジンへ送り、規則エンジンはそれ
が必要とする適切な情報をマスタ規則リストから分析する。

【０３１９】 不揮発性メモリの取扱い 各ノードはＲＯＭなどの静的メモリ場所にノードプロファイル情報を含む。ま
た、ノードは認証鍵などのその他の情報を不揮発性メモリに記憶できるが、これ
は任意のものであって、いずれのＰＬＸコンプライアント・ノードでも要求され
るものではない。他の任意のメモリ要求は経路指定情報とその他のダイナミック
な表を含む。

【０３２０】 クライアント変更通知 クライアント・ノードは状態変化条件をアプリケーション・サーバに通常知ら
せる。これは、アプリケーション・サーバがそれの状態を変更することをクライ
アントに知らせるとしても、クライアントはアプリケーション・サーバにそれの
状態が変化したことを逆に知らせることを意味する。これによってアプリケーシ
ョン・サーバのデータベースが実際のクライアント・ノードの変数に同期されて
いないというような問題が起きる機会が減少する。

【０３２１】 これは、アプリケーション・サーバが通知条件およびクライアント変数変化に
関連する規則を含んでいるために望ましい。クライアントはこれに関しては知能
的ではないので、クライアントはアプリケーション・サーバに適切な変更を通知
すべきである。

【０３２２】 アプリケーション・サーバは、クライアントが状態を変更したことを「アプリ
ケーション・サーバ」に通知する、そのクライアント・ノードから確証を受けと
った後まで、特定のクライアント・ノードに属するそれのデータベース変数を通
常更新しない。

【図面の簡単な説明】

【図１】 パーソナル・コンピュータなどのスマートなノードと、外部保安灯などのダム
なノードを有するネットワークのブロック図である。

【図２】 ７層ＯＳＩネットワーク・モデルのブロック図である。

【図３】 ユニバーサル・ゲットウェイ構造のブロック図である。

【図４】 サーバアクティブ アルゴリズムの流れ図である。

【図５】 規則コンポーネントを示すデータ図である。

【図６】 スマート装置用のＰＬＸネットワークモデルのブロック図である。

【図７】 ダム装置用のＰＬＸネットワークモデルのブロック図である。

【図８】 媒体アクセスのアルゴリズムを示す流れ図である。

【図９Ａ】 アクティブネットワーク・サーバ・スピッティング・アルゴリズムを示す流れ
図である。

【図９Ｂ】 クライアントスピッティング・アルゴリズムを示す流れ図である。

【図１０】 アクティブネットワーク・サーバ・ポーリング・アルゴリズムを示す流れ図で
ある。

【図１１】 ＰＬＸ論理群分離（ＬｏＧＩ）パケットのフィールドを示すブロック図である
。

【図１２】 ＰＬＸ生データ・パケットのフィールドを示すブロック図である。

【図１３】 ＰＬＸトークン・パケットのフィールドを示すブロック図である。

【図１４】 ＰＬＸ直接確認応答（ＤＡＣＫ）パケットのフィールドを示すブロック図であ
る。

【図１５】 ＰＬＸマスクされたラインアップ挿入（ＬＩＰＧ）パケットのフィールドを示
すブロック図である。

【図１６】 ＰＬＸ直接ラインアップ挿入（ＬＩＰＤ）パケットのフィールドを示すブロッ
ク図である。

【図１７】 ＰＬＸ内部ホスト・パケットのフィールドを示すブロック図である。

【図１８】 ＰＬＸ共通アプリケーション言語（ＣＡＬ）要求パケットを示すブロック図で
ある。

【図１９】 ＰＬＸ ＣＡＬ応答パケットを示すブロック図である。

【図２０】 ＰＬＸ単一チャネル送信状態パケットを示すブロック図である。

【図２１】 ＰＬＸ多チャネル送信状態パケットを示すブロック図である。

【図２２】 ＰＬＸパケット・タイミングを示すブロック図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ， ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，Ｄ Ｋ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ， ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，Ｌ Ｔ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ， ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，Ｕ Ａ，ＵＧ，ＵＺ，ＶＮ，ＹＵ，ＺＷ Ｆターム(参考） 5B089 GA31 GB02 GB04 JA35 KA11 KA13 KF05 KF06 5K033 AA09 BA04 CB01 CB02 CB08 CB14 CC01 DA05 DB12 DB18 DB23 EC03 5K046 PS00 PS23 PS36 【要約の続き】 ほとんどいかなるレガシイ・データ・ネットワーク化サ ービスを電源線を通じて送ることができる。

Claims (33)

【特許請求の範囲】
1. 【請求項１】 媒体プロトコルを用いてネットワーク媒体上を伝送させられ
   る１つまたは複数のデータ・プロトコルを用いてコンピュータ・ネットワーク上
   の多数のノードが通信できるように構成され、前記多数のノードと通信するため
   にアプリケーション・プログラミング・インタフェースをさらに提供するゲート
   ウエイであって、 ネットワーク上ノードについての情報を含む内部ノード・データベースと、 前記内部ノード・データベースを維持して、前記ノード・データベースをアク
   セスするように構成されているアクティブモードと、前記内部ノード・データベ
   ースを外部ノード・データベースの鏡像コピーとして維持するように構成されて
   いる待機モードとを提供するように構成されているソフトウエア・モジュールと
   を有するゲートウエイ。
2. 【請求項２】 前記内部ノード・データベースが、クライアント・ノードの
   状態変化時にとるべき行動を指定する規則をさらに含む、請求項１に記載のゲー
   トウエイ。
3. 【請求項３】 前記規則が簡単な規則である、請求項２に記載のゲートウエ
   イ。
4. 【請求項４】 前記規則が複雑な規則である、請求項２に記載のゲートウエ
   イ。
5. 【請求項５】 前記規則を解釈するように構成された規則エンジンをさらに
   備える、請求項２に記載のゲートウエイ。
6. 【請求項６】 シムをさらに備え、前記シムは規則を規則定義言語に変換す
   るように構成されている、請求項２に記載のゲートウエイ。
7. 【請求項７】 前記状態変化が前記クライアント・ノードのインスタンス変
   数の変化を含む、請求項２に記載のゲートウエイ。
8. 【請求項８】 ピン要求を発することによって前記内部ノード・データベー
   スが更新される、請求項１に記載のゲートウエイ。
9. 【請求項９】 前記ソフトウエア・モジュールが、確認されていないクライ
   アント要求が検出された時に、前記アクティブモードへ移行するように構成され
   ている、請求項１に記載のゲートウエイ。
10. 【請求項１０】 第１のプロトコルを第２のプロトコル内を通りぬけさせる
    ようにさらに構成されている、請求項１に記載のゲートウエイ。
11. 【請求項１１】 前記媒体が電源線であり、前記媒体プロトコルが電源線プ
    ロトコルである、請求項１０に記載のゲートウエイ。
12. 【請求項１２】 前記媒体が電源線であり、前記媒体プロトコルがＰＬＸプ
    ロトコルである、請求項１に記載のゲートウエイ。
13. 【請求項１３】 前記クライアント・ノードのインスタンス変数に変化が起
    きた時にユーザー・アプリケーションに通知するように構成されている事象ハン
    ドラをさらに備える、請求項７に記載のゲートウエイ。
14. 【請求項１４】 オブジェクト指向アプリケーション・プログラミング・イ
    ンタフェースをさらに備える、請求項１に記載のゲートウエイ。
15. 【請求項１５】 ユーザー・インタフェースに前記内部ノード・データベー
    ス中の情報を提供するように構成されているインターネット・ブラウザをさらに
    備える、請求項１４に記載のゲートウエイ。
16. 【請求項１６】 ユーザーが電源線ネットワーク上のノードを制御できるよ
    うにするように前記ユーザー・インタフェースが構成されている、請求項１５に
    記載のゲートウエイ。
17. 【請求項１７】 電源線ネットワーク媒体と、 ディスパッチ制御ブロックを使用することによって生のデータ情報を、前記電
    源線ネットワーク媒体からユーザー・アプリケーションへ送るゲートウエイ手段
    とを有するコンピュータ・ネットワーク。
18. 【請求項１８】 ノード・データベースと、 ディスパッチ制御ブロックを作成して解釈するディスパッチャ手段と、 ネットワーク・インタフェース・アダプタを制御するデバイス・ドライバ手段
    と、 前記デバイス制御ブロックを前記デバイス・ドライバ手段に適合させるシム手
    段とを有するゲートウエイ。
19. 【請求項１９】 ネットワーク上のノードについての情報を含んでいるノー
    ド・データベースを作成することと、 前記ノード・データベースをアクセスする１つまたは複数のアクセス法を提供
    し、前記ノード・データベースを維持するゲートウエイを指定することと、 前記ノード・データベースを１つまたは複数の待機サーバ・ノード内にするこ
    とと、 を有する、ネットワーク上のノード間で通信するために所望のプロトコルを使用
    する方法。
20. 【請求項２０】 クライアント・ノードにおいて状態変化が起きた時に取る
    べき行動を指定する諸規則を解釈し、かつ実行することをさらに備える請求項１
    ９に記載の方法。
21. 【請求項２１】 前記諸規則が規則エンジンによって解釈される、請求項２
    ０に記載の方法。
22. 【請求項２２】 前記状態変化が起きた時に事象通知を発生するステップを
    さらに有する、請求項２０に記載の方法。
23. 【請求項２３】 前記通知がディスパッチャに与えられる、請求項２２に記
    載の方法。
24. 【請求項２４】 受けとったデータを規則定義言語に変換するステップをさ
    らに有する、請求項２０に記載の方法。
25. 【請求項２５】 前記状態変化が前記クライアント・ノードのインスタンス
    変数の変化を含む、請求項２０に記載の方法。
26. 【請求項２６】 ピン要求を発し、前記ピン要求に対する応答が聞こえるか
    と耳を澄ますステップをさらに有し、前記応答は前記ノード・データベースを更
    新するために用いられる、請求項１９に記載の方法。
27. 【請求項２７】 前記アクティブサーバがインアクティブになった後に前記
    待機サーバの１つをアクティブ状態にするステップをさらに有する、請求項１９
    に記載の方法。
28. 【請求項２８】 第１のプロトコルの生のパケットを前記所望のプロトコル
    での包みパケット内に入れ、前記生のパケットを前記所望のプロトコル内に通り
    ぬけさせるステップとをさらに有する、請求項１９に記載の方法。
29. 【請求項２９】 前記媒体が電源線であり、前記媒体プロトコルが電源線プ
    ロトコルである、請求項１９に記載の方法。
30. 【請求項３０】 前記媒体が電源線であり、前記媒体プロトコルがＰＬＸプ
    ロトコルである、請求項１９に記載の方法。
31. 【請求項３１】 前記クライアント・ノードのインスタンス変数が変化した
    時にユーザー・アプリケーションに通知するステップをさらに有する、請求項１
    ９に記載の方法。
32. 【請求項３２】 前記ノード・データベース内の情報を見るためにインター
    ネット・ブラウザを用いるステップをさらに有する、請求項１９に記載の方法。
33. 【請求項３３】 電源線ネットワーク上のノードを制御するためにインター
    ネット・ブラウザを用いるステップを更に備える請求項１９に記載の方法。