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

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”に記載されている。

第２の態様において、本発明は、ネットワーク装置の動作方法に関係し、定められた長さのシンプル装置記述メッセージを送受信することを有し、前記シンプル装置記述メッセージは人間に解読可能なフォーマットから圧縮されたトークン圧縮メッセージの形式であり、前記メッセージは他の装置の形式を表す装置形式値を有し、前記装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される。

第３の態様において、本発明は、対応する装置に関係し、定められた長さのシンプル装置記述メッセージを送受信するように構成されたメッセージハンドラを有し、前記シンプル装置記述メッセージは人間に解読可能なフォーマットから圧縮されたトークン圧縮メッセージの形式であり、前記メッセージは他の装置の形式を表す装置形式値を有し、前記装置形式値は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択される。

ネットワーク装置の動作方法は、適切な応答で入力クエリメッセージに応答するネットワーク装置に関係してもよい。従って、その方法は、シンプル装置記述を要求するその他の装置からのシンプル装置記述クエリメッセージを受信し、固定長のシンプル装置記述メッセージを他の装置に送信することを有してもよい。

本発明はまた、その他の装置の装置形式を決定する方法に関係し、その結果、本発明は、少なくとも１つの他の装置のアドレスを定めるステップと、シンプル装置記述を要求する他の装置又は１つ以上の他の装置にシンプル装置記述クエリメッセージを送信するステップと、他の装置からシンプル装置記述メッセージを受信するステップとを有してもよい。

シンプル装置記述クエリメッセージで利用可能な情報より多い情報を見つけるために、その方法は、他の装置から拡張装置記述を要求する他の装置又は他の装置のうちの１つに拡張装置記述クエリメッセージを送信し、他の装置又は他の装置のうちの１つから可変長の拡張装置記述を受信することを更に有してもよい。

動作方法は、コントローラが制御可能な装置形式のリストを有するコントローラ装置に特に関係してもよい。

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

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

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

多機能装置に対処するために、所定の最上位レベルの要素は、複合装置形式を有してもよい。

複合装置形式のネットワーク装置は、所定の数の他の装置形式の機能を有し、複合装置としての装置形式と即時数の他の装置形式を有するシンプル装置記述を送信することにより、シンプル装置記述を要求する入力装置クエリメッセージに応答するように構成される。

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

更なる態様において、本発明は、それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置を有するシステムに関係し、前記ネットワークメッセージは、ネットワーク装置の装置形式を特定する装置記述メッセージを有し、各ネットワーク装置は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択された所定の装置形式を有し、ネットワーク装置の少なくとも１つは、コントローラ装置形式を有し、ネットワーク装置の少なくとも１つは、基本装置形式の装置形式又は基本装置形式に付随する装置形式を有する。

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

そのシステムは、所定の数の他の装置の機能を有する複合装置形式の少なくとも１つのネットワーク装置を更に有してもよく、その所定の数は２以上の整数であり、その複合装置形式の少なくとも１つのネットワーク装置のそれぞれは、複合装置としての装置形式と所定の数の他の装置を表すサブ装置数とを有するシンプル装置記述を送信することにより、シンプル装置記述を要求する入力装置クエリメッセージに応答する。

本発明はまた、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層を定めるコンピュータプログラムに関係し、そのコンピュータプログラムは、装置形式の階層から選択された装置形式を有するシンプル装置記述メッセージをネットワーク装置に送受信させるように構成される。

そのコンピュータプログラムは、トランスポートスタックとのインタフェースになるトランスポート適応レイヤを実装するコードと、アプリケーションとのインタフェースになるアプリケーションプログラミングインタフェースを実装するコードと、トークン符号化された人間に解読可能なメッセージフォーマットでメッセージを送受信する機能を有するメッセージングレイヤを実装するコードとを特に有してもよい。

そのコードはネットワーク装置に、シンプル装置記述応答を要求する入力装置クエリメッセージを認識させ、コントローラ装置形式の装置形式を有するシンプル装置記述応答を提供させ、所定の装置形式又は所定の装置形式が付随する上位レベルの装置形式であるネットワーク装置により制御され得る装置形式のリストにおける最下位レベルの装置形式で応答することにより、ネットワーク装置が所定の装置形式を制御可能であるか否かを尋ねる入力コントローラクエリメッセージに応答させ、その他の装置に装置クエリメッセージを送信するステップと、他の装置の装置形式を示す他の装置からの応答を受信し、その装置形式は、コントローラ装置形式と基本装置形式を含む所定の最上位レベルの要素と、基本装置形式に付随し、従属装置形式が付随する上位レベルの装置形式の属性を引き継ぐ少なくとも１つの更なるレベルの従属装置形式とを有するが、コントローラ装置形式に付随する更なるレベルの従属装置形式を含まない装置形式の階層から選択されるステップと、ネットワーク装置により制御され得る装置形式のリストにおいて、他の装置の装置形式又は他の装置の装置形式が付随する上位レベルの装置形式である最下位レベルの装置形式を決定することにより、ネットワーク装置が他の装置を制御可能な程度を決定するステップと、決定された最下位レベルの装置形式に属する制御信号のリストから選択された制御信号を送信することにより、決定された最下位レベルの装置形式の機能で他の装置を制御するステップとを実行させるように構成される。

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

プロトコル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装置の装置形式については何も認識していないが、その装置形式は引き継いだ装置も有するため、基本装置を特定することができ、制御可能な最下位の階層的に上位の装置形式としてそれを戻す。

このことにより、例えばPDA形式のコントローラ装置がネットワークを制御するネットワーク管理アプリケーションとして機能することが可能になる。

コントローラはまた、シンプル装置記述で戻された装置形式をスイッチが制御できるか否かを決定するアルゴリズムを実装する(図６)。スイッチが装置のアドレスを発見すると、そのシンプル装置記述を装置に要求し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 (12)

1. ネットワーク装置の動作方法であって、
   前記ネットワーク装置において、少なくとも１つの他の装置のアドレスを定め、
   前記ネットワーク装置において、シンプル装置記述を要求するシンプル装置記述クエリメッセージを前記他の装置又は１つ以上の前記他の装置に送信し、
   前記ネットワーク装置において、前記他の装置から前記シンプル装置記述メッセージを受信し、前記シンプル装置記述メッセージに基づいて前記他の装置と更なる通信が必要であるか否かを決定することを有し、
   前記シンプル装置記述メッセージは人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージの形式のメッセージであり、
   前記シンプル装置記述メッセージは装置形式を示すフィールドと、前記他の装置が前記シンプル装置記述より多くの情報を有する装置記述である利用可能な拡張装置記述を有するか否かを示すフィールドと、所定の数の少なくとも１つの他の装置の状態設定を特定する所定の数の更なるフィールドとを有し、
   前記装置形式を示すフィールドは前記他の装置の形式を表す装置形式値を有し、
   前記装置形式は、装置がコントローラであることを示すコントローラ装置形式と装置が制御され得ることを示す基本装置形式とを有する最上位レベルの要素と、前記基本装置形式に従属する少なくとも１つの更なる装置形式とを含む階層に構成され、任意選択で前記少なくとも１つの更なる装置形式に従属するもうひとつの更なる装置形式を含み、
   それぞれの前記更なる装置形式は、前記基本装置形式の属性を共有するように定義され、前記もうひとつの更なる装置形式は、前記基本装置形式の属性と従属する前記更なる装置形式の属性とを共有するように定義され、
   前記装置形式値は、前記階層に含まれる複数の装置形式から選択される方法。
2. 請求項１に記載の方法であって、
   前記ネットワーク装置において、前記他の装置から拡張装置記述を要求する拡張装置記述クエリメッセージを前記他の装置又は複数の前記他の装置のうちの１つに送信し、
   前記ネットワーク装置において、前記他の装置又は複数の前記他の装置のうちの１つから可変長の拡張装置記述を受信することを更に有する方法。
3. 請求項１に記載の方法であって、
   前記ネットワーク装置は、コントローラ装置であり、
   前記ネットワーク装置は、前記コントローラ装置が制御可能な装置形式のリストを有する方法。
4. ネットワーク装置の動作方法であって、
   前記ネットワーク装置において、シンプル装置記述を要求するシンプル装置記述クエリメッセージを他の装置から受信し、
   前記ネットワーク装置において、固定長の前記シンプル装置記述メッセージを前記他の装置に送信することを有し、前記他の装置が前記受信したシンプル装置記述メッセージに基づいて前記ネットワーク装置と更なる通信が必要であるか否かを決定するように構成され、
   前記シンプル装置記述メッセージは人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージであり、
   前記シンプル装置記述メッセージは装置形式を示すフィールドと、前記ネットワーク装置が利用可能な拡張装置記述を有するか否かを示すフィールドと、所定の数の少なくとも１つの他の装置の状態設定を特定する所定の数の更なるフィールドとを有し、
   前記装置形式を示すフィールドは前記他の装置の形式を表す装置形式値を有し、
   前記装置形式は、装置がコントローラであることを示すコントローラ装置形式と装置が制御され得ることを示す基本装置形式とを有する最上位レベルの要素と、前記基本装置形式に従属する少なくとも１つの更なる装置形式とを含む階層に構成され、任意選択で前記少なくとも１つの更なる装置形式に従属するもうひとつの更なる装置形式を含み、
   それぞれの前記更なる装置形式は、前記基本装置形式の属性を共有するように定義され、前記もうひとつの更なる装置形式は、前記基本装置形式の属性と従属する前記更なる装置形式の属性とを共有するように定義され、
   前記装置形式値は、前記階層に含まれる複数の装置形式から選択される方法。
5. 請求項４に記載の方法であって、
   複数の装置形式が、少なくとも１つの他の装置形式の機能を有するように定義された複合装置形式を更に有し、
   前記ネットワーク装置は、前記複合装置形式であり、
   前記方法は、前記ネットワーク装置において、複合装置としての装置を表す装置形式値と、更に他の装置形式の数である整数のサブ装置数とを有するシンプル装置記述メッセージを送信することにより、受信したシンプル装置記述クエリメッセージに応答することを更に有する方法。
6. それぞれネットワークメッセージを送受信するトランシーバを有する複数のネットワーク装置を有するシステムであって、
   前記ネットワークメッセージは、ネットワーク装置の装置形式を特定する装置記述メッセージを有し、
   各ネットワーク装置は、他の装置の形式を表す所定の装置形式を有し、
   前記装置形式は、装置がコントローラであることを示すコントローラ装置形式と装置が制御され得ることを示す基本装置形式とを有する最上位レベルの要素と、前記基本装置形式に従属する少なくとも１つの更なる装置形式とを含む階層に構成され、任意選択で前記少なくとも１つの更なる装置形式に従属するもうひとつの更なる装置形式を含み、
   それぞれの前記更なる装置形式は、前記基本装置形式の属性を共有するように定義され、前記もうひとつの更なる装置形式は、前記基本装置形式の属性と従属する前記更なる装置形式の属性とを共有するように定義され、
   前記ネットワーク装置の少なくとも１つは、前記コントローラ装置形式を備えたコントローラ装置であり、
   前記ネットワーク装置の少なくとも１つは、前記基本装置形式の属性を有する装置形式又は前記基本装置形式の装置形式を備えた被制御装置であり、
   前記複数のネットワーク装置のうち１つのネットワーク装置は、前記複数のネットワーク装置のうちシンプル装置記述を要求する他のネットワーク装置からシンプル装置記述クエリメッセージを受信するように構成され、
   前記ネットワーク装置は、前記受信したシンプル装置記述クエリメッセージに応じて前記他のネットワーク装置にシンプル装置記述メッセージを送信するように更に構成され、前記他のネットワーク装置は、前記受信したシンプル装置記述メッセージに基づいて前記ネットワーク装置と更なる通信が必要であるか否かを決定するように構成され、
   前記ネットワーク装置は、シンプル装置記述メッセージ及び拡張装置記述メッセージを交換するように構成され、
   前記シンプル装置記述メッセージは人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージであり、
   前記シンプル装置記述メッセージは装置形式を示すフィールドと、前記ネットワーク装置が利用可能な拡張装置記述を有するか否かを示すフィールドと、所定の数の少なくとも１つの他の装置の状態設定を特定する所定の数の更なるフィールドとを有し、
   前記拡張装置記述メッセージは、前記シンプル装置記述メッセージより多くの情報を有する拡張メッセージであるシステム。
7. 請求項６に記載のシステムであって、
   前記複数のネットワーク装置が、
   メッセージを解凍する機能を備えない少なくとも１つの簡単な装置と、
   前記メッセージを解凍するメッセージ解凍構成と、前記解凍されたメッセージを解釈するメッセージ解釈器とを有する少なくとも１つの複雑な装置と
   を有するシステム。
8. 請求項６又は７に記載の方法であって、
   前記所定の最上位レベルの要素が、複合装置形式を更に有し、
   前記システムが、所定の数の他の装置形式の機能を有する複合装置形式の少なくとも１つのネットワーク装置を更に有し、
   前記所定の数は２以上の整数であり、
   前記複合装置形式の少なくとも１つのネットワーク装置のそれぞれは、複合装置としての装置形式と前記所定の数の他の装置を表すサブ装置数とを有するシンプル装置記述を送信することにより、シンプル装置記述を要求する入力装置クエリメッセージに応答するシステム。
9. ネットワーク装置であって、
   前記ネットワーク装置は、シンプル装置記述を要求する他のネットワーク装置からシンプル装置記述クエリメッセージを受信するように構成され、
   前記ネットワーク装置は、前記受信したシンプル装置記述クエリメッセージに応じて前記他のネットワーク装置にシンプル装置記述メッセージを送信するように更に構成され、前記他のネットワーク装置は、前記受信したシンプル装置記述メッセージに基づいて前記ネットワーク装置と更なる通信が必要であるか否かを決定するように構成され、
   前記ネットワーク装置は、
   メッセージを送受信するトランシーバと、
   定められた長さのシンプル装置記述メッセージを送信又は受信するように構成されたメッセージハンドラと
   を有し、
   前記シンプル装置記述メッセージは人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージであり、
   前記シンプル装置記述メッセージは装置の装置形式を示すフィールドと、前記装置が前記シンプル装置記述より多くの情報を有する装置記述である利用可能な拡張装置記述を有するか否かを示すフィールドと、所定の数の少なくとも１つの他の装置の状態設定を特定する所定の数の更なるフィールドとを有し、
   前記装置形式を示すフィールドは前記他の装置の形式を表す装置形式値を有し、
   前記装置形式は、装置がコントローラであることを示すコントローラ装置形式と装置が制御され得ることを示す基本装置形式とを有する最上位レベルの要素と、前記基本装置形式に従属する少なくとも１つの更なる装置形式とを含む階層に構成され、任意選択で前記少なくとも１つの更なる装置形式に従属するもうひとつの更なる装置形式を含み、
   それぞれの前記更なる装置形式は、前記基本装置形式の属性を共有するように定義され、前記もうひとつの更なる装置形式は、前記基本装置形式の属性と従属する前記更なる装置形式の属性とを共有するように定義され、
   前記装置形式値は、前記階層に含まれる複数の装置形式から選択されるネットワーク装置。
10. 請求項９に記載のネットワーク装置であって、
    前記メッセージハンドラが、
    少なくとも１つの他の装置のアドレスを定めるステップと、
    シンプル装置記述を要求するシンプル装置記述クエリメッセージを他の装置に送信するステップと、
    前記他の装置の形式を表す装置形式値と、拡張装置記述が利用可能であるか否かを示すフィールドとを有する固定長の前記シンプル装置記述メッセージを前記他の装置から受信するステップと
    を実行するように構成され、
    前記シンプル装置記述メッセージをテストし、拡張装置記述が利用可能であるか否かを決定するステップと、
    前記他の装置から拡張装置記述を要求する拡張装置記述クエリメッセージを前記他の装置に送信するステップと、
    可変長の拡張装置記述を前記他の装置から受信するステップと
    を任意選択で実行するように更に構成されたネットワーク装置。
11. 請求項９に記載のネットワーク装置であって、
    前記メッセージハンドラが、
    シンプル装置記述を要求するシンプル装置記述クエリメッセージを他の装置から受信するステップと、
    固定長の前記シンプル装置記述メッセージを前記他の装置に送信するステップと
    を実行するように構成され、
    前記シンプル装置記述メッセージが、人間に解読可能なメッセージフォーマットから圧縮されたトークン圧縮メッセージの形式であるネットワーク装置。
12. 請求項１１に記載のネットワーク装置であって、
    人間に解読可能なフォーマットから事前に圧縮された所定のシンプル装置記述メッセージを格納するメモリを更に有し、
    前記メッセージハンドラは、前記メモリから前記所定のシンプル装置記述メッセージを読み取り、入力装置クエリメッセージに応じて前記トランシーバを通じて前記シンプル装置記述メッセージを送信するように構成されたネットワーク装置。

Images