JP2005535247A - ネットワーク確立及び管理プロトコル - Google Patents

Abstract

本発明は、ネットワーク装置間の通信用のプロトコルに関係する。装置は、他の装置形式が付随しないコントローラ装置形式と、複数の他の装置形式が付随する基本装置形式とを有する装置形式の階層として論理的に構成される。装置は、固定長のシンプル装置記述メッセージと装置形式を有するフォーマットを実装し、いくつかの装置は、追加情報を有する拡張装置記述メッセージを更に実装する。

Description

本発明は、ネットワークプロトコルに関するものであり、特にプロトコルの実装に関するものである。

ネットワーク管理用の従来技術のプロトコルは、ユニバーサル・プラグ・アンド・プレイであり、そのユニバーサル・プラグ・アンド・プレイは、帯域とバッテリー消費とある程度のコストが問題とならないインターネットアプリケーションで非常に有用である。家庭用電化製品(CE:consumer electronics)へのプロトコルの実装は存在するが、プロトコルの限界のため、このような実装は、その実装がなければ最小の処理能力しか必要としない特に最も単純な装置に大きい負荷をかける。

従って、ライトやサーモスタットやCE装置(TVやDVDやPVRのリモコン)のような簡単な装置に組み込むのに適したプロトコルに対する必要性が存在する。そのプロトコルは実装が簡単であり、コスト効率の良いものであり、最小の帯域を必要とするが、可変の機能により広範囲の装置を通じてスケーラブルである。

この必要性は、無線アプリケーションに限定されず、有線アプリケーションに拡張する。

本発明の第１の態様によると、それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置と、他の装置にシンプル装置クエリメッセージを送信し、シンプル装置記述メッセージを受信し、他の装置から受信した後にシンプル装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置と、他の装置に拡張装置クエリメッセージを送信し、拡張装置記述メッセージを受信し、他の装置から受信した後に拡張装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置とを有するシステムが提供され、各ネットワーク装置は、装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを送信することにより、その他の装置からの入力シンプル装置クエリメッセージに応答するように構成され、少なくとも１つのネットワーク装置は、拡張装置記述メッセージを送信することにより、その他の装置からの入力拡張装置クエリメッセージに応答するように構成される。

このようなシステムは、この特許出願の対象であるプロトコルを実装する。プロトコル自体は、ホーム・ユニフォーム・コントロール言語(HUCL:home uniform control language)と呼ばれる。

相対的に、発明者が認識している従来技術のシステムは、単一の装置記述メッセージ及び応答のみを実装する。定められた長さのシンプル装置記述と可変長の拡張装置記述とを提供することにより、本発明は、HUCLプロトコルを使用して、簡単なメッセージのみを使用して動作する簡単な装置と、可変長の拡張装置記述から利用可能になる大きい機能を利用する複雑な装置とを結合することが可能になる。簡単な装置は、拡張装置記述クエリを単に無視してもよい。

シンプル装置記述は少数又は適度な数の所定のフィールドを有し、各フィールドは固定長である。一般的に、各メッセージに同じフィールドが使用されが、ある程度の変動が存在することがある。例えば、複合装置は、以下に説明するサブ装置の数を含む追加の整数フィールドを有してもよい。

シンプル装置記述メッセージは、人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージ(token-compressed message)の形式であることが好ましく、メッセージは他の装置の形式を表す装置形式値を有する。装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される。

HUCLプロトコルの好ましい実装によると、基礎となるメッセージフォーマットは、XMLのような人間に解読可能なフォーマットである。しかし、帯域を確保するために、メッセージは圧縮形式でネットワーク装置間を通過する。それにもかかわらず、使用される圧縮方法が、共通ストリングをトークンと交換するトークン圧縮であるため、ネットワーク装置はこのような圧縮メッセージを処理することができる。従って、ネットワーク装置は、シンプル装置記述の応答を要求するクエリを認識するのに少なくとも十分な程度で、解凍せずに圧縮されたトークンを認識することができ、シンプル装置記述で応答することができる。このように、ネットワーク装置は、ほとんどオーバーヘッドなしに実装され得る。

トークン符号化(token coding)の適切な形式は、http://www.w3.org/TR/wbxmlで入手可能な1999年6月24日の“wap binary XML content format”に記載されている。

基本装置形式に付随する少なくとも１つの階層(すなわち被制御装置の階層)が存在するが、コントローラ装置の対応する階層が存在しないことに留意すべきである。これは、シンプル装置記述メッセージをできる限り短く且つ簡単に保持するためである。ユニバーサル・リモコンのような多くのコントローラが多数の異なる装置形式を制御することが可能になる。

複数のネットワーク装置は、メッセージを解凍する機能を備えず、そのため圧縮メッセージを直接解釈する少なくとも１つの簡単な装置と、メッセージを解凍するメッセージ解凍構成と解凍されたメッセージを解釈するメッセージ解釈器とを有する少なくとも１つの複雑な装置とを有することが好ましい。

その他の態様では、本発明は、シンプル装置記述クエリメッセージと拡張装置記述クエリメッセージの双方に応答可能な個々のネットワーク装置に関係する。

従って、第２の態様では、
メッセージを送受信するトランシーバと、
他の装置のうちの１つからシンプル装置記述クエリメッセージを受信すると、ネットワーク装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを他の装置に送信するステップと、
その他の装置から拡張装置記述クエリメッセージを受信すると、可変長の拡張装置記述を他の装置に送信するステップと
を実行するように構成されたメッセージハンドラと
を有するネットワーク装置が提供される。

このような装置クエリメッセージに応答可能なネットワーク装置と同様に、本発明はまた、装置クエリメッセージを生成し、その結果を処理する装置に関係する。

従って、第３の態様では、
メッセージを送受信するトランシーバと、
少なくとも１つの他の装置のアドレスを定めるステップと、
シンプル装置記述を要求するその他の装置にシンプル装置記述クエリを送信するステップと、
他の装置の形式を表す装置形式値と、拡張装置記述が利用可能であるか否かを示すフィールドとを有する固定長のシンプル装置記述メッセージを他の装置から受信するステップと、
を実行するように構成され、
シンプル装置記述メッセージをテストし、拡張装置記述が利用可能であるか否かを決定するステップと、
他の装置から拡張装置記述を要求する他の装置に拡張装置記述クエリメッセージを送信するステップと、
可変長の拡張装置記述を他の装置から受信するステップと
を任意選択で実行するように更に構成されたメッセージハンドラと
を有するネットワーク装置が提供される。

本発明はまた、第２及び第３の態様の装置の動作方法に関係する。

従って、第４の態様では、本発明はネットワーク装置の動作方法に関係し、シンプル装置記述を要求する他の装置のうちの１つにシンプル装置記述クエリメッセージを送信し、他の装置の形式を表す装置形式値と、拡張装置記述が利用可能であるか否かを示すフィールドとを有する定められた長さのシンプル装置記述メッセージを他の装置から受信し、シンプル装置記述メッセージをテストし、拡張装置記述が利用可能であるか否かを決定し、そうである場合には、他の装置からの拡張装置記述を要求する他の装置に拡張装置記述クエリメッセージを送信し、可変長の拡張装置記述を他の装置から受信することを有する。

第５の態様では、本発明は、ネットワーク装置の動作方法に関係し、
シンプル装置記述を要求する他の装置のうちの１つからシンプル装置記述クエリメッセージを受信し、
ネットワーク装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを他の装置に送信し、
ネットワーク装置からの拡張装置記述を要求する他の装置から拡張装置記述クエリメッセージを受信し、
可変長の拡張装置記述を他の装置に送信することを有する。

前述のように、装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される。

本発明によるコントローラ装置は、制御入力を有し、制御入力で受信した信号に基づいて他の装置を制御することが好ましい。更に、コントローラ装置は、どの装置をコントローラが制御可能であるかを決定する１つ以上の方法を実装してもよい。

装置がコントローラ装置である場合の情報の欠如に対処する１つの手法は、コントローラ装置が、所定の装置形式又は所定の装置形式が付随する上位レベルの装置形式であるネットワーク装置により制御され得る装置形式のリストにおける最下位レベルの装置形式で応答することにより、コントローラが所定の装置形式を制御可能であるか否かを尋ねる入力コントローラクエリメッセージに応答する機能を有することである。コントローラ装置は、制御入力で受信した信号に従って、制御信号の所定のリストから選択された制御信号を他の装置に送信することができる。

コントローラ装置の代わりに、装置は、基本装置形式又は基本装置形式に付随する装置形式を有する被制御装置でもよい。ネットワーク装置は、コントローラにより送信された基本装置の命令に応答する機能を有し、その命令は、所定の基本セットの命令を少なくとも有する。

多機能装置に対処するために、所定の最上位レベルの要素は、所定の数の他の装置形式の機能を備え、複合装置としての装置形式と即時数の他の装置形式を有するシンプル装置記述を送信することにより、シンプル装置記述を要求する入力装置クエリメッセージに応答するように構成された複合装置形式を有してもよい。

ネットワーク装置は、所定のシンプル装置記述メッセージを格納するメモリを有してもよく、その記述メッセージは、装置形式と、送信装置が利用可能な拡張装置記述を有するか否かを示すフラグと、所定の数の追加状態設定を特定する所定の数の追加フラグとを有する人間に解読可能な形式のメッセージから事前に圧縮されたメッセージである。従って、内部でシンプル装置記述メッセージを生成するのではなく、適切なメッセージが事前に格納されており、必要な時に送信される。

本発明はまた、ネットワーク装置を制御するコンピュータプログラムに関係する。

そのシステムは、簡単な機能を備えておりメッセージを解凍する機能を備えていない複数の簡単な装置と、更なるオーバーヘッドとプロセッサ能力の要件を犠牲にして、メッセージを解凍してそれを解釈してそのメッセージで動作する更に複雑な装置とを有しても良い。

その他の態様では、本発明は、電子装置を制御するネットワーク確立及び管理プロトコルに関係し、そのプロトコルは記録媒体に記録され、そのプロトコルは、前記メッセージの圧縮機構を定める圧縮アルゴリズムと、XML準拠のメッセージである一般メッセージフォーマットの定義と、メッセージシーケンス要件(message sequencing requirement)とを有する。

そのプロトコルは、コントローラ装置を定めてもよく、コントローラ装置の発見は、コントロール装置を発見し、将来の動作時にそのコントロール装置を命令する機構を有するように定められてもよい。

そのプロトコルは、装置記述メッセージが、固定長及び固定内容の第１のメッセージと、定められていない長さ及び内容の第２のメッセージとのうちの１つになるように定めてもよい。

そのプロトコルは、第２の装置記述メッセージの断片的な発見を可能にするように、装置記述メッセージの発見を定めてもよい。

そのプロトコルは、複合装置を定めてもよく、複合装置の装置記述メッセージは、複合に複数のサブ装置を含めるように定められる。

複合装置の装置記述メッセージの発見は、順にサブ装置の発見を可能にするように定められてもよい。

本発明の更なる理解のため、添付図面を参照して単に一例として実施例について説明が行われる。

プロトコルHUCLは、主に無線システム用に設計された軽量の小帯域の制御プロトコルである。メッセージフォーマットはXMLに基づき、メッセージは送信前に圧縮される。XMLの使用は、送信されるデータを低減する圧縮を備えた拡張可能且つスケーラブルな解決策を提供し、送信機がオンになっている時間の量を低減し、消費電力を低減する。

HUCLプロトコルの一般原理と、それが装置で動作する方法について、簡単な例を参照して説明する。

図１を参照すると、照明スイッチ2と、照明設備4が備えられている。照明スイッチ2は、ユーザにより操作される物理的なロッカースイッチ6と、RFトランシーバ8と、バッテリー10と、制御回路12と、メモリ14とを有する。照明設備もまた、RFトランシーバ8と、メモリ14を有するが、主電源付きであり、電球22に電力を加える制御回路20を有する。従って、照明スイッチ2は、制御入力6(スイッチ)を有するコントローラの例であり、照明設備は被制御装置4の例である。コントローラのメモリ14は、コントローラが制御可能な装置形式と装置形式に属する制御機能のリスト24を有する。被制御装置4とコントローラ装置2の双方のメモリ14はまた、以下に詳細に説明される方法を制御回路に実行させるコード26を有する。

図２は、各装置のメモリ14に存在するソフトウェアの表示を示したものである。制御アプリケーション30は、特定のイベントが生じたときにHUCLソフトウェアスタック32と通信する。

同様に、HUCLソフトウェアスタック32は、RFソフトウェアスタック34と通信し、RFソフトウェアスタック34は、特定のイベントが生じたとき(例えばデータの受信時)にHUCLソフトウェアスタック32と通信する。

メッセージ36が送受信される。メッセージは、シンプル装置記述クエリメッセージを含む複数の形式でもよく、また何らかの複数の他のメッセージ形式でもよい。

装置の動作について、図３を参照して説明する。この一対の装置の動作の第１段階は、スイッチが設備のアドレスを発見することである。これは装置発見として知られており、装置発見処理が(RFソフトウェアスタックで)提供されること、又はトランスポートスタックの上位で(HUCLソフトウェアスタックの下位レイヤで)装置発見が実装可能であることは、基礎のRFトランスポートスタックの要件である。

発見処理は、HUCLソフトウェアスタックに呼び出しを行い、まず既知の装置の数を要求し、次にその装置のネットワークアドレスを要求することで、(場合によってはあるユーザ相互作用の結果として)制御アプリケーションにより開始される100。これらの装置のアドレスが返信される。

基礎のRFプロトコルに応じて、他の方法でネットワークアドレスが定められてもよい。

装置発見段階の最終結果は、制御アプリケーションがRFスタックにより認識された全ての装置のアドレスのリストを受ける102。処理のこの時点では、制御アプリケーションはそのアドレス以外にそれぞれの他の装置について認識しない。

対になる処理の第２段階は、制御アプリケーションが、アドレスを有する装置について情報を収集することである。この情報は装置記述と呼ばれる。制御装置は、HUCLソフトウェアスタックに呼び出しを行い、装置記述を要求する装置のアドレスを渡すことにより、このことを行う。

シンプル装置記述の要求は、RFリンクを通じて宛先装置に渡され104、前述のスイッチ／設備の例では、要求がスイッチから設備に送信される。要求を受信すると、宛先装置のHUCLソフトウェアスタックは、制御アプリケーションに呼び出しを行い、装置記述を要求する。記述のフォーマットは定められている。圧縮形式でない場合には、要求の送信者に返信される前に記述が圧縮される。

要求装置のHUCLソフトウェアスタックが装置記述を受信すると106、制御アプリケーションに渡される。この時点で、アプリケーションは装置についてある程度の基本情報を有しており、この装置と更に通信したいか否かについて決定を行うことができる。

HUCLの設計目標は、非常に簡単な装置で動作するのに適することであるが、装置を十分に記述するために必要な情報は潜在的には非常に複雑である。以下のリストは、装置の記述の一部として装置が提供しようとする情報の種類を示している。

装置形式(例えばDVD)
ベンダ名(例えばPhilips)
モデル番号(例えばDVD1010/002)
シリアル番号(例えばAH06848032345)
ベンダURL(例えばwww.philips.com)
このセクションを通じた例で使用されるスイッチのように、最も簡単な制御装置の場合には、この情報のほとんどが場合によっては冗長的である。しかし、このような情報がユーザ向けに表示可能なスクリーンを有するハイエンドの‘PDA’形式のリモコンでは有用である。

完全なメッセージを受信したときにキャッシュする記憶装置(RAM)が潜在的に必要となるため、ローエンドの装置でのこのような記述の処理は問題を提示する。前述の記述データの全体のサイズは不確定であり、その情報のほとんどは‘自由記載(free text)’であるため(ベンダ名は非常に長くなることがあり、URLは場合によってはパラメータで正確なページを特定することがある(例えばhttp://www.consumer.philips.com/global/b2c/ce/catalog/subcategory.jhtml?groupId=VIDEO&dvdId=0&catId=DVD&subCatId=DVDPLAYER))、その問題は当初に思われるものより悪くなる。

HUCLで克服する方法は、装置記述を２層の情報に分割することである。第１層は、装置の簡単すぎる記述であるが、更なる情報が利用可能であるか否かを特定する。これは自由記載(free text)フィールドを含まないため、全体の長さが決定的になる。第２層の拡張情報は任意選択であるが、追加情報を提供する。

図１２を参照すると、シンプル装置記述メッセージ230は、フィールドとして、装置形式232と、拡張装置記述が利用可能であるか否かを示すフィールド238と、キー情報を特定する他のフィールド236(例えばイベント申込みが利用可能であるか否かを示すフラグ)とを有する。任意選択の整数のフィールド234は、複合装置のサブ装置の数を表す。メッセージ230がヘッダとフッタをも有してよく、それらが簡潔性のために省略されていることを当業者は認識するであろう。メッセージは、同様に簡潔性のために省略されている圧縮XMLトークンを有する。シンプル装置記述のフィールドは全て固定長であり、それにより解凍することなく容易に処理され得る。

シンプル装置記述230を受信した後106(図３)、シンプル装置記述230はHUCLスタックに戻される。

拡張装置記述が利用可能であり、コントローラ装置がそれを要求した場合には、コントローラ装置の制御アプリケーションは“GetExtendedDescription”要求をその装置に返信してもよい108。

この要求を受信した装置のHUCLスタックは、拡張装置記述を要求する制御アプリケーションにGet Extended Descriptionの呼び出しを行う。

拡張装置記述はHUCLスタックに戻され、それを要求した装置の制御アプリケーションに戻される。その後、拡張記述は要求装置に戻される110。

GetEtendedDescriptionクエリが拡張装置記述を提供しない装置で受信されると、その要求は単に無視される。

このセクションを通じて使用されるスイッチ／設備の例に再び戻ると、スイッチが設備のアドレスのみを認識した時点から、スイッチは設備からそのシンプル装置記述を要求する。これを受信すると、標準の設備コマンドセットに準拠する照明設備と通信していることをスイッチが認識し、更に(例えば)設備が拡張装置記述を提供できないことを認識するのに十分な情報を提供する。

要求時に装置アプリケーションがシンプル装置記述をHUCLスタックに提供することは必須である。拡張装置記述を提供しない装置は、このような情報について受信した如何なる情報も無視することができる。

装置の形式(例えばTV、DVD、照明設備等)を特定する装置形式のフィールド232 が、(要求時に)装置により戻されるシンプル装置記述に含まれる。装置形式のフィールド232は、(シンプル装置記述を要求する)コントローラに対して装置が準拠する命令セットを特定する。HUCL装置は、単にその形式の識別子により自分を特定し、それが制御される方法を記述するメッセージを送信し続けない。HUCLには‘ランタイム’サービス記述の概念が存在しない。装置が照明設備として自分を特定した場合には、その装置で呼び出されるコマンドセットは、照明設備の形式の装置用のHUCL仕様で特定される。

図４を参照すると、全ての装置形式は基本装置形式50に付随する。最上位の要素58は、この例では、コントローラ装置形式52と、被制御装置用の基本装置形式54と、アラーム装置形式56とを有する。

従属装置形式68は、基本装置形式に付随する。この例では、TV装置形式64と、調光可能照明装置形式62と、PVR装置60が含まれる。

装置形式の分類は、コントローラの機能の範囲まで装置を制御することができるか否かを簡単なコントローラが特定することを可能にする目的のシステムを作ることである。

簡単なスイッチは照明設備と対になり、照明をオン及びオフすることができるが、スイッチの制御機能(すなわち、装置をオン又はオフする機能)は、オン／オフの概念を受け入れることができる如何なる装置(例えば、TV、ヒーター、プリンタ)にも適用可能であるべきである。

これが実装され得る１つの方法は、制御方法(オン又はオフすること)を認識する全ての装置のリストをスイッチが有することである。装置のシンプル装置記述を要求すると、返信された記述の装置形式のフィールドを調べて、制御方法を認識している装置形式のリスト内に存在するか否かを決定することができる。

この手法の２つの著しい欠点が存在する。第１に、スイッチは非常に簡単な装置であり、その内部のアプリケーションが、制御可能な全ての見込まれる装置のリストを保持することは望ましくない。そのリストは非常に大きくなる可能性がある。第２に、スイッチが作られた後に新しい形式の装置が作られると(その新しい形式の装置は簡単なオン・オフ機能を受け入れることができる)、スイッチはこの新しい装置形式をそのリストに有しておらず、制御可能であるかがわからない(すなわち、拡張可能でない)。

図４に示すように、HUCLは階層的に装置を分類する。装置形式のフィールド232(図１５)は、階層内の装置を特定するため、新しい装置が作られても、階層内の適当なポイントに由来する限りは、依然として簡単なスイッチは、ある程度それを制御することができるということを認識する。

ツリーの下にある装置は、その上の装置形式の機能を引き継ぐ。ツリーの下の装置に適用されると、コマンドに対してある程度の解釈を追加する必要があることがある。例えば、オン／オフのコマンドが照明に送信されると、完全に明確にオンとオフをするが、同じコマンドがTVに送信されると、スタンバイモードへの出入りをする。

装置形式の階層の主な利点は、コントローラが特有の装置形式自体について認識していなくても、由来するものから装置を決定することができ、その装置についてある程度の認識をすることができ、それにより、(装置の観点から)ある程度少ない範囲で装置を制御することができる。

例えば、照明スイッチが装置のアドレスを取得し、その装置からシンプル装置記述を要求した場合について検討する。装置形式のフィールドは装置をTVとして特定するが、スイッチは認識している装置としてこの装置を認知しない。しかし、スイッチはまた、認識している‘基本装置’の派生であるという記述から定めることができる。最終結果として、スイッチは装置自体について何も認識していないにも関わらず、コントローラの機能(すなわちオンとオフ)の範囲までTVを制御することができる。装置は、スイッチがある程度まで依然として制御することができる基本装置に由来する限り、スイッチが製造されたずっと後に発明された‘XYZ’という真新しい分類の装置でもよい。

装置形式の階層は、２層だけ(最上位レベルの要素にコントローラと基本装置)を有してもよいが、少なくとも１つの更なる層及び／又は最上位レベルの要素が望ましい。これは、前述の基本装置の機能に準拠しない装置、すなわち基本的な‘オン’‘オフ’機能を有さない装置(例えばアラーム)に応じる。例示目的で、‘アラーム’形式の装置56が図４に示されており、当然のことながら、この‘アラーム’装置は、基本装置に由来する装置が有している必要がある通常のオン／オフ機能を実装しようとしない。従って、それは基本装置54自体と同じ階層のレベル58に位置する。

階層に対する第２の拡張も図４に示されている。すなわち、通常のTV装置64の下の拡張TV装置66である。ここで、拡張TV装置は基本装置54とTV装置64の双方の機能の全てを引き継ぐが、通常のTVに存在しないある程度の機能も有する。通常のTV装置を操作するように設計された通常のTVリモコンは、通常のTV装置の機能のレベルまで拡張TV装置を操作することができるが、拡張機能を制御することができない。

従って、HUCLプロトコルは、装置形式と機能を引き継いだ上位の装置を記述する拡張可能な機構を提供する。多レイヤの階層の概念は魅力的に思えるが、３又は４のレベルを超えて拡張すると、シンプル装置記述の大きさに影響を与え始めることになる。

HUCL内で、コントローラと制御可能な装置から装置記述を要求することができる。ある装置が“Get Simple Description”をコントローラ装置(例えばスイッチ)に送信すると、“コントローラ”の装置形式を含むシンプル装置記述を戻す。コントローラ装置はまた、製造者やモデル番号等のような更なる情報を提供する拡張装置記述を利用可能にしてもよい。

コントローラ装置により戻される装置形式が、装置形式のツリーに定められた異なるコントローラ形式の装置の階層が存在しない単に“コントローラ”52であることに特に留意すべきである。この理由は、前述のように、プロトコルとメッセージを小さく簡単に保持しようとするためである。スイッチ、TVリモコン、PVRリモコン等のように基本コントローラに由来する異なるコントローラ形式を有することができると考えられ得る。しかし、広範囲の装置を制御可能なユニバーサル・リモコンのようなインテリジェントコントローラで問題が生じる。全ての可能なコントローラ形式を単一の装置記述に含めることにより、潜在的に長いメッセージを生じることになり、初期のシンプル装置記述を簡単にしようとする理念に反する。コントローラ装置の正確な機能を決定するために、異なる機構が使用される。

コントローラ装置の機能を決定する第１の手段は、コントローラ装置で許可されており、装置名(例えば“ユニバーサル・リモコン”)のような情報を含んでもよい拡張装置記述によるものであり、これはテキスト情報でありアプリケーションソフトウェアにより直接解釈可能ではないが、それはユーザに提示され、コントローラについて情報に基づく選択を行う際に助けになり得る。

装置がコントローラについて更に決定する第２の手段は、それにクエリを行うことによるものである。

クエリの使用は、装置についての情報をゆっくりと供給する強力な機構であり、それがない場合には、全体で提供されると要求者に過負荷をかける。

コントローラ形式の各装置は、他の装置が特定の装置形式を制御可能であるか否かを尋ねる手段を提供する120(図５)。クエリで渡された装置形式は、シンプル装置記述で使用されるもの(すなわち装置形式の階層で定義されたもの)と同じフィールドである。コントローラは、クエリで渡された装置形式又はその装置形式が付随する装置形式であるコントローラのメモリ14に格納されたリストにおける最下位の装置形式を返信することにより、装置を制御できるレベルを返信する122。例えば、簡単なスイッチは、拡張TV装置を制御することができるか否かについて尋ねられる。前述の図４に示される階層に基づいて、応答は、基本装置のレベルまで制御できるということになる。スイッチは、一般的に拡張TV装置の装置形式については何も認識していないが、その装置形式は引き継いだ装置も有するため、基本装置を特定することができ、制御可能な最下位の階層的に上位の装置形式としてそれを戻す。

コントローラはまた、シンプル装置記述で戻された装置形式をスイッチが制御できるか否かを決定するアルゴリズムを実装する(図６)。スイッチが装置のアドレスを発見すると、そのシンプル装置記述を装置に要求し124、その情報を受信すると126、スイッチがこの形式の装置をある程度まで制御できるか否かをテストする128。これは、クエリ処理120の結果と同じ応答を要する問題である。その結果、２つのクエリ処理120、122、124、126、128は簡単なスイッチ装置の複雑性をあまり追加しない。同じことがその他の簡単な装置にも当てはまる。

装置が、同じ物理アドレスを介して全てアクセスされる(例えば単一のRFトランシーバで共に検出される)複数の別個の装置の複合でもよい場合が存在することが予想され得る。

この形式の装置の例は、単一のRFトランシーバを通じて制御される個別に切り替え可能な一式の照明であり、又は統合したアラームクロックを備えたTV(その双方の構成要素が同じトランシーバでリモートから制御可能である)である。

図７は発見処理を示している。最初にスイッチは基礎のトランスポート媒体により認識された全ての装置のアドレスを取得する。これは４つの個々に制御可能な照明の単一のアドレスを有する。スイッチは照明一式にGet Simple Descriptionコマンドを発行する140。生じる問題は、応答が何になるかである。４つの装置の記述が戻されると、スイッチが受信することを予期しているデータの４倍になる。複数のシンプル装置記述を戻すことはあまりスケーラブルではなく、例えば照明一式に20個の照明が存在する場合には問題を生じる。

HUCLにより提供されるこの解決策は、複合装置用の特定の装置形式である。

複合装置は、装置形式のフィールド232に“複合装置”としてその装置形式を含んだシンプル装置記述を戻す142。シンプル装置記述はまた、フィールド234で、この例ではこの単一の装置に４つの組み込まれた装置が存在することを特定する。

コントローラが複合装置と通信していることを特定すると、次の段階は、何の装置がその中に組み込まれているかをそれが定めることである。コントローラは、複合装置にGet Simple Descriptionの要求を更に行うが144、特定の組み込まれた装置にその要求をアドレス指定する。組み込まれた装置はその装置記述を戻す146。

コントローラが組み込まれた装置のうちの１つを制御することを決定すると、各コマンドに組み込まれた装置IDを含めることにより、その特定の組み込まれた装置に全ての制御コマンドが向けられる。複合装置の概念が定められると、利益になる複数の関心ある装置の組み合わせの可能性が広がる。そのいくつかが後述される。

一例は、一体のスイッチを備えたランプで構成される単一の装置であり、スイッチの機能は他の装置を制御できるように公開されている。この装置は、シンプル装置記述について尋ねられると複合装置として提示するが、更に尋ねられると一方の組み込まれた装置はコントローラであり、他方は制御可能なもの(すなわち照明装置)であることがわかる。複数のこのような装置は、いずれか１つの装置のスイッチを動作すると全ての装置でライトがオン／オフされる(例えば、ラウンジのいずれか１つのテーブルランプをオンにすると、ラウンジの全てのテーブルランプがオンになる)ように構成され得る。

CEドメイン内の複合装置の他の可能な組み合わせには、例えば、TV+ビデオカセットレコーダ(VCR)、又はDVDとVCRが含まれる。そのそれぞれは、必要に応じて２つの装置の複合として自分を記述することができる。

理論的には、装置は、コア装置と０以上のサブ構成要素で構成される。例えば、TV装置60はTV装置60自体と、チューナ64、オーディオ66及びディスプレイ68のサブ構成要素で構成される(図８参照)。

単一の装置が１つより多いインスタンスを有してもよいことも考えられる。例えば、TV/VCRのコンビ装置は、２つのチューナ62と64(一方はTV用でもう一方はVCR用)と、オーディオ66及びディスプレイ68の構成要素を有してもよい(図９参照)。

XMLの使用と、最も簡単な装置でのその圧縮及び解凍はほとんど負荷にならないと考えられ得る。プロトコルを記述するためにXMLを使用することは、将来の拡張に対して容易に拡張可能であり、記述と理解が比較的容易であり、構造化された情報を容易に処理することができ、‘インターネットドメイン’とすぐに適合する解決策を提供する。

(HUCL内で定められた)XMLでのタグ圧縮技術(tagged compression technique)を使用することにより、内容の構造を保持するためのある程度の追加のオーバーヘッドを用いて、従来の純粋のバイナリベースのプロトコルのサイズまで比較的冗長なプロトコルスタックを減少する。

圧縮形式のコマンドが提示されると、コマンド構造の情報とデータ値の記述用のテーブルを使用して、その他のバイナリベースのプロトコルを読み取るのと同じ方法で読み取られることができる。バイナリデータがXMLベースの表記から生じた可能性があるという唯一のヒントは、構造を表すデータの存在である。

HUCL仕様は、常にメッセージが圧縮形式でトランスポート媒体を通じて伝送されることを定める。しかし、簡単な装置では、アプリケーションは圧縮メッセージで直接動作してもよいため、HUCLソフトウェアスタック内の圧縮／解凍ソフトウェアの存在に対するその装置での必要性を除去する。この場合、アプリケーションは、(ROMのアプリケーションイメージの一部として)事前に圧縮された形式でシンプル装置記述を格納し、その他のバイナリプロトコルのパーサ(parser)と本質的に類似する、受信した圧縮プロトコルメッセージ用のパーサ(parser)を有する。如何なる応答メッセージもまた、圧縮形式で格納される必要がある。

この手法を用いて、このセクションを通じて使用される照明スイッチと照明設備の例のような最も簡単な装置は、減少したソフトウェアスタックで実施されることが可能になり、単一の装置が理解及び送信に必要とするコマンドの数が比較的少なくなる(照明をオンにする、照明をオフにする、トグルする(toggle)、現在の状態を取得する、装置記述を取得する等)と考えられ、アプリケーションソフトウェアのオーバーヘッドが最小になる。

このことは、装置に対してスケーラブルな解決策を提示し、実行され得る圧縮データで動作するアプリケーションを実装することが現実的になる。しかし、装置が複雑になると、スタックに圧縮／解凍機能を含めて、全XML表記でプロトコルメッセージをアプリケーションに使用させることが容易になるポイントが存在する。この分割ポイントは装置設計者に完全に依存しており、HUCLで定義又は記載されていない。

図１０は、HUCLを構成する構成要素が組み合わさる方法を示している。構成要素はメモリに記録されるソフトウェアコンポーネントであることがわかる。

以下のセクションでは、HUCLソフトウェアスタック32を形成するレイヤと、それが提供する機能について更に詳細に説明する。

前述のように、(例えばTCP/IPとは異なり)HUCLは特定のトランスポートプロトコルに依存しないが、その代わりに、トランスポートプロトコル34の上位に直接位置する。異なるトランスポートスタック34は、異なるAPIを通じて、アプリケーションに本質的に異なるサービスを提供する。HUCLトランスポート適応レイヤ180は、特有のトランスポートレイヤに対するバッファとして機能する。

トランスポート適応レイヤ180は、サービスのセットに関係なく、HUCLスタックの上位レイヤに一貫したトランスポートを提供する。このレイヤの要件は、プロトコル仕様に詳細に定められている。

メッセージングレイヤ182は、HUCLソフトウェアスタックの大部分の機能を提供する。アプリケーションはHUCL APIを通じてこのレイヤと通信し、必要なときに(例えばデータを受信したときに)アプリケーションにコールバックを実行する。

メッセージングレイヤ182はまた、何らかの初期エラー報告を処理し、必要に応じて承認を処理する。紛失メッセージの検査とメッセージを応答に結合する検査に使用されるメッセージIDとトランザクションIDもまた、このレイヤにより完全に処理される。

メッセージングレイヤ182はまた、メッセージを圧縮又は解凍するときに、圧縮／解凍サービス184を利用する。前述のように、アプリケーションは圧縮形式でメッセージを排他的に処理するため、そのサービスに呼び出しは行われず、それがランタイムスタックから除去され得る。

簡単に言えば、圧縮及び解凍サービスは、圧縮形式と解凍形式との間でHUCLメッセージを変換する手段をメッセージレイヤに提供する。システムのこの構成要素がローエンドの装置に存在せず、アプリケーションとの全てのデータ交換が圧縮されたメッセージで行なわれることも可能である。

アプリケーションプログラミングインタフェースAPI186は、全てのアプリケーションがHUCLソフトウェアスタックと通信するインタフェースである。特定のイベントが下位のレイヤで生じた結果として(例えばトランスポートスタックを介してメッセージが受信された結果として)HUCLスタックがアプリケーションに非同期のコールバックを行うという点で、通信は双方向である。

HUCLは、独立のトランスポートスタック34であり、これは、HUCLメッセージングプロトコルが有線と無線の双方の多様なトランスポートスタックの上位に構成され得ることを意味する。

HUCLは軽量プロトコルとして設計されているため、新興のZigbee(802.15.4)規格のような軽量のトランスポートスタックにも最適であるが、有線(例えばイーサーネット)と無線(例えば802.11b)の双方の広範囲の他のプロトコルに広まるTCP&UDP/IPの上位にも同様に位置することができる。

HUCLがトランスポートスタック34に実装されるためには、HUCLスタックのメッセージングレイヤに複数のサービスを提供できなければならない。このことは、これらの装置がトランスポートスタック自体に存在し得るか、又はHUCLスタックのトランスポート抽象レイヤの何らかの欠いたサービス(missing service)を実装可能でなければならないことを意味する。これらのサービスは、アドレス指定やメッセージ配信や装置発見(例えばネットワークの他の装置のアドレスを発見すること)のような側面をカバーしてもよい。

プロトコル自体は、媒体214に記録されたドキュメントであり、図１１に示すように以下の情報を有する。

全てのHUCLメッセージが準拠するフォーマットを定めた一般HUCLメッセージフォーマット200
制御プロトコルを形成する特有のメッセージを定めたメッセージ定義202
どのメッセージがいつ送信されたかと、メッセージ受信時のアプリケーションの要件を定めたメッセージシーケンス要件(message sequencing requirement)204
HUCLとそれを使用するアプリケーションの間の双方向インタフェースを定めたHUCL API定義206
HUCLソフトウェアスタックのメッセージングシステム要件及び機能208
HUCLメッセージの圧縮機構を定めた圧縮アルゴリズム210
HUCLソフトウェアスタックがトランスポートシステム(例えばRFスタック)とインタフェース接続する方法を定めたトランスポート適応レイヤ定義212
従って、HUCLは単にメッセージフォーマットの定義だけではなく、メッセージ交換及び圧縮を包含する。前述のリストの後の４つの項目は、装置に存在するHUCLソフトウェアスタックを形成し、最初の３つの項目はスタックとアプリケーションが準拠しなければならない要件を定める。

この開示を読むことにより、他の変更形態と変形形態が当業者に明らかになる。そのような変更形態と変形形態は、ネットワークの設計と製造と使用の際に既に既知であり、ここに記載された機能に加えて又はその代わりに使用され得る相当物及び他の機能を有してもよい。この出願では、特許請求の範囲は特定の組み合わせの機能に対して策定されているが、当然のことながら、本発明と同じ技術的な課題の一部又は全てを緩和しようとしまいと、開示の範囲は明示的又は暗示的にここに開示されている如何なる新規な機能若しくは如何なる新規な機能の組み合わせ又はその一般化を含む。この結果、この出願は、この出願又はそれから導かれる如何なる出願の遂行の間に、そのような機能及び／又はそのような機能の組み合わせに対して新しい特許請求の範囲が策定され得るという予告を提示する。

特に、例で使用される特有のサブルーチン名は容易に変更され得る。装置を制御するコンピュータプログラムは、メモリ14に記録されたものとして示されているが、CDやフロッピー（登録商標）ディスク等のようなその他の多数の形式の記録媒体に記録され得ることを当業者は認識するであろう。

更に、照明設備と照明スイッチの非常に簡単な例が広く前述されたことに留意すべきである。更に多数の複雑な制御シナリオも可能であることを当業者は認識するであろう。

本発明による実施例を使用して通信する一対の装置を示したものである。 １つの装置のソフトウェアの概要を示したものである。 装置発見処理のフローチャートである。 装置形式の階層の概要である。 被制御装置の制御機能を被制御装置に通知するためにコントローラが実行するステップを示したものである。 被制御装置の制御機能を決定するためにコントローラが実行するステップを示したものである。 複合装置の装置発見処理のフローチャートである。 複合装置の実施例を示したものである。 複合装置のその他の実施例を示したものである。 ソフトウェアの構造を示したものである。 HUCLプロトコルを示したものである。 シンプル装置記述メッセージを示したものである。

Claims (22)

1. 少なくとも１つの他の装置を有するネットワークにおけるネットワーク装置の動作方法であって、
   シンプル装置記述を要求する少なくとも１つの他の装置に、シンプル装置クエリメッセージを送信し、
   他の装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを他の装置から受信し、
   他の装置から拡張装置記述を要求する他の装置に、拡張装置記述クエリメッセージを送信し、
   可変長の拡張装置記述を他の装置から受信することを有する方法。
2. 請求項１に記載の方法であって、
   少なくとも１つの他の装置にシンプル装置記述を送信するステップの前に、その他の装置又は他の装置のネットワークアドレスを定めることを更に有する方法。
3. 請求項１又は２に記載の方法であって、
   前記シンプル装置記述メッセージは、人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージの形式であり、
   前記メッセージは、他の装置の形式を表す装置形式値を有し、
   前記装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される方法。
4. 請求項３に記載の方法であって、
   前記ネットワーク装置は、コントローラが制御可能な装置形式のリストを有するコントローラ装置である方法。
5. 請求項４に記載の方法であって、
   前記コントローラにより制御され得る装置形式のリストにおいて、他の装置の装置形式又は他の装置の装置形式が付随する上位レベルの装置形式である最下位レベルの装置形式を決定し、前記ネットワーク装置が他の装置を制御可能な程度を決定することにより、前記ネットワーク装置がその他の装置を制御できるか否かを決定することを更に有する方法。
6. 請求項５に記載の方法であって、
   要求された装置形式値を有し、前記コントローラが要求された装置形式の装置を制御可能であるか否かを要求するその他の装置からのコントローラクエリメッセージを受信し、
   前記要求された装置形式又は前記要求された装置形式が付随する上位レベルの装置形式である装置形式のリストにおける最下位レベルの装置形式を表す装置形式値を有するコントローラ応答メッセージで応答することを更に有する方法。
7. 請求項２に記載の方法であって、
   前記装置形式の階層における前記所定の最上位レベルの要素が、複合装置形式を更に有し、
   前記ネットワーク装置は、整数値の他の装置形式の機能を有する複合装置形式であり、
   前記方法は、複合装置としての装置を表す装置形式値と、更に他の装置の数である整数のサブ装置数を有するシンプル装置記述を送信することにより、受信したシンプル装置記述クエリメッセージに応答することを更に有する方法。
8. シンプル装置記述を要求する他の装置のうちの１つから、シンプル装置記述クエリメッセージを受信し、
   ネットワーク装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを他の装置に送信し、
   前記ネットワーク装置から拡張装置記述を要求する他の装置から、拡張装置記述クエリメッセージを受信し、
   可変長の拡張装置記述を他の装置に送信することを有するネットワーク装置の動作方法。
9. メッセージを送受信するトランシーバと、
   他の装置のうちの１つからシンプル装置記述クエリメッセージを受信すると、ネットワーク装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを他の装置に送信するステップと、
   その他の装置から拡張装置記述クエリメッセージを受信すると、可変長の拡張装置記述を他の装置に送信するステップと
   を実行するように構成されたメッセージハンドラと
   を有するネットワーク装置。
10. 請求項９に記載のネットワーク装置であって、
    前記シンプル装置記述メッセージは人間に解読可能なフォーマットから圧縮されたトークン圧縮メッセージの形式であり、
    前記メッセージは他の装置の形式を表す装置形式値を有し、
    前記装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、前記基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、前記コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択されるネットワーク装置。
11. メッセージを送受信するトランシーバと、
    シンプル装置記述を要求するその他の装置にシンプル装置記述クエリメッセージを送信するステップと、
    他の装置の形式を表す装置形式値と、拡張装置記述が利用可能であるか否かを示すフィールドとを有する固定長のシンプル装置記述メッセージを他の装置から受信するステップと
    を実行するように構成され、
    前記シンプル装置記述メッセージをテストし、拡張装置記述が利用可能であるか否かを決定するステップと、
    他の装置から拡張装置記述を要求する他の装置に拡張装置記述クエリメッセージを送信するステップと、
    可変長の拡張装置記述を他の装置から受信するステップと
    を任意選択で実行するように更に構成されたメッセージハンドラと
    を有するネットワーク装置。
12. 請求項１１に記載のネットワーク装置であって、
    前記シンプル装置記述メッセージは、人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージの形式であり、
    前記メッセージは、他の装置の形式を表す装置形式値を有し、
    前記装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択されるネットワーク装置。
13. 請求項１２に記載のネットワーク装置であって、
    前記ネットワーク装置は前記コントローラ装置形式を有し、
    前記ネットワーク装置は、前記ネットワーク装置により制御され得る装置形式のリストを有し、それにより、前記ネットワーク装置は、前記コントローラにより制御され得る装置形式のリストにおいて、他の装置の装置形式又は他の装置の装置形式が付随する上位レベルの装置形式である最下位レベルの装置形式を決定することにより、前記ネットワーク装置が他の装置を制御可能な程度を決定可能であるネットワーク装置。
14. 請求項１３に記載のネットワーク装置であって、
    前記メッセージハンドラが、
    要求された装置形式値を有し、前記コントローラが要求された装置形式の装置を制御可能であるか否かを要求するその他の装置からのコントローラクエリメッセージを受信し、
    前記要求された装置形式又は前記要求された装置形式が付随する上位レベルの装置形式である装置形式のリストにおける最下位レベルの装置形式を表す装置形式値を有するコントローラ応答メッセージで応答するように構成されたネットワーク装置。
15. それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置と、
    他の装置にシンプル装置クエリメッセージを送信し、シンプル装置記述メッセージを受信し、他の装置から受信した後にシンプル装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置と、
    他の装置に拡張装置クエリメッセージを送信し、拡張装置記述メッセージを受信し、他の装置から受信した後に拡張装置記述メッセージを解釈するように構成された少なくとも１つのネットワーク装置と
    を有するシステムであって、
    前記ネットワーク装置のそれぞれは、装置の形式を表す装置形式値を有する定められた長さのシンプル装置記述メッセージを送信することにより、その他の装置からの入力シンプル装置クエリメッセージに応答するように構成され、
    前記ネットワーク装置の少なくとも１つは、拡張装置記述メッセージを送信することにより、その他の装置からの入力拡張装置クエリメッセージに応答するように構成されたシステム。
16. 請求項１５に記載のシステムであって、
    前記複数のネットワーク装置が、
    メッセージを解凍する機能を備えず、圧縮されたメッセージを直接解釈する少なくとも１つの簡単な装置と、
    前記メッセージを解凍するメッセージ解凍構成と、前記解凍されたメッセージを解釈するメッセージ解釈器とを有する少なくとも１つの複雑な装置と
    を有するシステム。
17. 請求項１５又は１６に記載のシステムであって、
    前記所定の最上位レベルの要素が、複合装置形式を更に有し、
    前記システムが、所定の数の他の装置の機能を有する複合装置形式の少なくとも１つのネットワーク装置を有し、前記所定の数は２以上の整数であり、
    前記複合装置形式の前記少なくとも１つのネットワーク装置のそれぞれは、複合装置としての装置形式と所定の数の他の装置を表すサブ装置数とを有するシンプル装置記述を送信することにより、シンプル装置記述を要求する入力装置クエリメッセージに応答するシステム。
18. ネットワーク装置を制御するコンピュータプログラムであって、
    請求項１ないし８のうちのいずれか１項に記載の方法のステップを前記ネットワーク装置に実行させるように構成されたコンピュータプログラム。
19. ネットワーク装置を制御するコンピュータプログラムであって、
    前記ネットワーク装置はトランスポートスタックとアプリケーションを有し、
    前記コンピュータプログラムは、
    前記トランスポートスタックとのインタフェースになるトランスポート適応レイヤを実装するコードと、
    前記アプリケーションとのインタフェースになるアプリケーションプログラミングインタフェースを実装するコードと、
    トークン符号化された人間に解読可能なメッセージフォーマットでメッセージを送受信する機能を有するメッセージングレイヤを実装するコードと
    を有し、
    前記コードはネットワーク装置に
    シンプル装置記述応答を要求する入力装置クエリメッセージを認識させ、装置形式を有するシンプル装置記述応答を提供させ、
    拡張装置記述を要求する入力装置クエリメッセージを認識させ、拡張装置記述で応答させるように構成されたコンピュータプログラム。
20. データ媒体に記録された請求項１８又は１９に記載されたコンピュータプログラム。
21. 電子装置を制御するネットワーク確立及び管理プロトコルであって、
    前記プロトコルは記録媒体に記録され、
    前記メッセージの圧縮機構を定める圧縮アルゴリズムと、
    圧縮されたXML準拠のメッセージである一般メッセージフォーマットの定義と、
    メッセージシーケンス要件の定義と
    を有するプロトコル。
22. 請求項２１に従って電子装置を結合するネットワーク確立及び管理プロトコルに従ったシステム。

Images